[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:

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

Obviously it stops Webshell working.
Does it? Not on my machines it doesn't. I've not tried it in maintenance mode.
 
And apparently on my machines as well, including HDR3 (with a recent FFP).
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?
 
Does it? Not on my machines it doesn't.
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:
Any ideas what is doing this @af123 ? Or how we debug it?
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).
 
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).
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?
 
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?
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.
Something for the next CF version then?
Maybe next year : )
 
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.
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 : )
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"?
 
At another level, because the setting isn't "Disable telnet and webshell menu"?
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.
 
I imagine that expert users aren't likely to use it in preference to real telnet/ssh anyway.
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).
 
Back
Top