• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

[webshell] Command line access from web browser

It's a curiosity but it doesn't seem to cause any problems so I'm not that bothered. Of more concern is:

prpr said:
/mod/boot/xinit.d/webshell is missing on all 4 of the HDRs I look after and on my HD.
Click to expand...
And apparently on my machines as well, including HDR3 (with a recent FFP).

prpr said:
Obviously it stops Webshell working.
Click to expand...
Does it? Not on my machines it doesn't. I've not tried it in maintenance mode.
 
Black Hole said:
And apparently on my machines as well, including HDR3 (with a recent FFP).
Click to expand...
I reinstalled webshell on all machines on Friday and checked all was correct (I wrote a script to check all packages!).
I checked yesterday and it was OK. I checked just now and /mod/boot/xinit.d/webshell is missing again on 4 out of 5 boxes.
The one it's not missing on (the HD) is the one that hasn't been rebooted since.
So I rebooted it...
...and the file is missing from there also now.
It looks like this file is being removed at startup somehow.
Any ideas what is doing this @af123 ? Or how we debug it?
 
Black Hole said:
Does it? Not on my machines it doesn't.
Click to expand...
Something did on mine (which is what alerted me to all this), but it wasn't this missing file, which I now believe is only used in Maintenance Mode.
The opportunity to find the source of the original problem is gone, as it was fixed by a reboot.
But now this has come to light - go scratching looking for one thing and you find a different itch.
 
Last edited:
prpr said:
Any ideas what is doing this @af123 ? Or how we debug it?
Click to expand...
I need to look and remember how it all works; there is certainly a fundamental difference between how webshell works in normal versus maintenance mode and there is probably something different between custom firmwares, but it's a long time since I did this.. leave it with me.
 
Right...

The /mod/boot/xinit.d/webshell file is for firmware versions lower than 3.11; recent versions have it built in for use during initial installation and in maintenance mode and therefore remove the xinit.d file during boot (see /etc/init.d/S37bootstrap). With these firmwares there is no need to install the package in order to use webshell in maintenance however, if the package is installed and provides a newer version than the built-in one, then it will be used automatically (but the xinit.d file is still not required).

When in normal mode, the package must be installed and it is the packaged version that is used - in normal mode the webshell server runs on a UNIX domain socket and is proxied to by the main web server, in maintenance mode webshell runs on its own port (88).
 
af123 said:
The /mod/boot/xinit.d/webshell file is for firmware versions lower than 3.11; recent versions have it built in... and therefore remove the xinit.d file during boot (see /etc/init.d/S37bootstrap).
Click to expand...
This strikes me as somewhat poor design. The firmware part shouldn't really have any knowledge of the packages you may or may not choose to install on top of it and certainly should NOT be deleting bits of such things. It is certainly unintuitive and confusing, as we have seen, and it breaks my (perfectly reasonably implemented) package checker.
Surely a better way would be to remove this deletion code from S37bootstrap and put a check in xinit.d/webshell for whether it is running on lower than 3.11 and act accordingly?
Something for the next CF version then?
 
prpr said:
Surely a better way would be to remove this deletion code from S37bootstrap and put a check in xinit.d/webshell for whether it is running on lower than 3.11 and act accordingly?
Click to expand...
That definitely sounds better. I suspect the reason I did not do that is that it doesn't handle upgrading the firmware with an older webshell package in place.
prpr said:
Something for the next CF version then?
Click to expand...
Maybe next year : )
 
af123 said:
I suspect the reason I did not do that is that it doesn't handle upgrading the firmware with an older webshell package in place.
Click to expand...
I would guess a new S37bootstrap might be able to tell (relative to itself) whether the /mod/boot/2/webshell/shellinaboxd is old or not and deactivate it. I think this would be allowable in this specific case to force the user to update the package next time they want to use it. (The number of instances of this setup is probably approximately zero though!)
Maybe next year : )
Click to expand...
See you on Jan. 1st then. Give you something to do to distract from (potential) headache...
 
Why does webshell not respect the "Disable telnet menu" setting in WebIF >> Settings >> Advanced Settings?
 
At one level, because tmenu is actually specified as the login program for webshell sessions.

At another level, because the setting isn't "Disable telnet and webshell menu"?
 
/df said:
At another level, because the setting isn't "Disable telnet and webshell menu"?
Click to expand...
Yeah, but regardless of the usual objections, for all intents and purposes webshell is Telnet so far as a "normal" user might think - certainly I would like to kill tmenu.
 
af123 said:
I imagine that expert users aren't likely to use it in preference to real telnet/ssh anyway.
Click to expand...
It's convenient, especially when using an iPad (no decent free Telnet apps). Why switch to a Telnet client when everything can be done through a browser (except for the PIN & "cli" tedium of course)?
 
I mocked up an implementation of this where the check for the /mod/boot/xtelnet flag file is moved into the tmenu script, with this logic:
  • if the flag file is present, skip the PIN check and preload the "cli" response;
  • run this loop
    • if a preloaded response is not set, show the banner and run the menu;
    • execute the preloaded or selected response;
    • clear any preloaded response.
Compared with the current implementation, this starts the cli like this:
Code: 
Menu version 1.22df                                                                             
                                                                                                
-----------------------------------------------------------------------                         
                                                                                                
Humax HD-Fox T2 (humax) 1.03.02/3.13                                                            
                                                                                                
To return to the menu, type: exit                                                               
                                                                                                
humax#
If the flag file check were removed from the telnet startup script, you'd get the same behaviour for a telnet cli session; but that script is in the RO flash (as is the base version of tmenu, but it punts to a version in RW flash if any).
 
You must log in or register to reply here.
Back
Top