[openSUSE] shellinabox #2006
Comments
|
@Luke-Nukem Nice find and point. I was wondering how we would do in this area. As for official openSUSE OBS, yes agreed. But we don't really want to carry any special packages if we can help it. But may be unavoidable. This feature was added by @MFlyer so mentioning here as he may have some input. Over to project lead @schakrava for official rockstor account creation at openSUSE OBS. I'll revisit this task if we don't hear back shortly on this TODO: |
The point would be to use it as a base for staging packages for inclusion in to devel projects there, where they can then be submitted for inclusion in to Factory, then to Tumbleweed releases, and backports for Leap. But then again, anyone can do this for any package 😉 |
|
@Luke-Nukem Maybe we should take your question: "So I'm wondering if there are better alternatives ..." onto the forum as we have more eyes there. I'm not up on what alternatives there are but hopefully others on the forum may be. Best if you could take a look at how @MFlyer implemented this so that you might judge if suggested replacements are viable. This is more in your area of expertise I believe so best if you ask: if you are game? Linking to @MFlyer's pr that added our Web-UI shell capability: "Issue#518 console access via web ui shellinabox" #1388 I expect that we can agree that carrying additional packages for our upstream is beyond our current 'crew' and best if we can resource something already there (in, or available for, our upstream distro already) and most importantly, currently developed, as all code tends to rot and if we need to move then so be it. We could always have conditionals using python-distro, as I've already started doing, to carry us over the transition phase to openSUSE. That way we can leave shellinabox specific code for the time being for our CentOS based subscribers while additionally adding what ever is to take it's place. Hey there might even be a Rust option out there :). |
|
I came across a similar project today: WeTTY (MIT license) It seems to be based entirely on javascript:
Based on its documentation, it can be ran as a service, or even inside a docker container. It would add another js-lib dependency, however... Just leaving this here in case it turns out being useful. |
|
I was curious and had a quick look at the openSUSE repos and there seems to be a few non-official shellinabox packages: https://software.opensuse.org/package/shellinabox?search_term=shellinabox The following one may be interesting, but we would need to add another repo... |
|
@FroggyFlox Thanks for the pointers on this on. https://build.opensuse.org/package/show/home:Knurpht:Extras/shellinabox Plus this repo's maintainer has an @opensuse.org email address. |
|
@FroggyFlox OK, so if we drop the 15.2 availability with the hope it arrives in time, we also have a more direct drop-in replacement that includes a move to systemd & firewalld. Our other openSUSE options thus far have still used chkconfig and SuSEfirewall2 where as our shellinabox related code currently expects systemd capability. Maintainer @suse.com with this time 2 other Users involved with the same repo. So this one looks to be a little more official to me, and looks like it's appeared since you last looked. |
|
Hi @phillxnet, and thanks for having a look at that one. The second package you list seems really good, especially if it's a drop-in replacement! It actually seems like a perfect replacement if I understand correctly. |
|
I am currently working on this issue. |
A recently available OBS shells.repo hosted shellinabox package had breaking differences from our prior epel CentOS pacakge. The following code changes were made to support both packages concurrently: - Move to re-configure service on every service enable and black format the associated file: shellinaboxd_service.py, with minor refactoring. - Remove build time 'initial' config file instantiation, along with the prior listed change this establishes a single point, within code, where our desired configuration is written. This also ensures we overwrite package default config prior to initial service start. - Establish distro specific configuration options: the proposed openSUSE shells repo package has a different certificates location. - Go with both package defaults re user/group for running the shellinabox deamon. - Account for differing default configuration file names. - Account for differing systemd service file names by normalising on our existing 'shellinaboxd' and establishing this if not found during the initrock.py script run by rockstor-pre.service. - Improve comments in prep_db.py pertaining to shellinaboxd + black format. - Remove unused status() and associated import from shell.py. - Pass systemd service name to shell.py to reduce hardcoded instances. - Move shell.py to string.format + black formatting. - Fix existing bug where shellinabox config file options had no closing quote and carriage return.
Separating out black formatting of this file to ease the review process.
[openSUSE] adapt to shellinabox package differences. Fixes #2006
shellinaboxwill need to be packaged. However:So I'm wondering if there are better alternatives - but these must be written in systems languages, not for eg, python or node-js, these are just far too heavy-weight.
Fedora package source is here
At this point I also suggest creating an official rockstor account on openSUSE OBS to ease package building and supply, you should be able to get packages merged to official channels if required also.
The text was updated successfully, but these errors were encountered: