vermaneerajin / shellinabox

Automatically exported from code.google.com/p/shellinabox
Other
0 stars 0 forks source link

wishlist: Session to survive /etc/init.d/shellinabox restart #90

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
One of the ways we'd like to use shellinabox is to upgrade a server (apt-get 
dist-upgrade on debian). Part of that upgrade might be to upgrade to a new 
version of shellinabox, which involves restarting it.

Currently that terminates the active session in the browser.

Having an upgrade terminate somewhere in the middle of its execution can easily 
leave the system in a bad state.

Currently we all upgraders use ssh and ssh *does* survive a restart of ssh. 
Similarly, if possible, we wish for shellinabox to survive a restart.

Running:
shellinabox 2.10-1

Original issue reported on code.google.com by pmo...@gmail.com on 1 Sep 2010 at 3:27

GoogleCodeExporter commented 8 years ago
I don't really see how this would be possible with a web-based protocol.

Sshd can easily achieve this goal, because it only ever needs to keep a single 
TCP connection open. And it is OK if the process that initially created this 
connection dies and gets replaced with something else. The connection continues 
to live.

Web-based protocols are different. It is quite common for the TCP connection to 
regularly get closed and for a new connection to be opened between the browser 
and the server. The shellinaboxd then looks at the payload in this connection 
and associates it with one of the currently active sessions. If the daemon gets 
restarted at any time, it no longer knows which sessions are active, and it 
wouldn't be able to forward data to any of them.

Yes, it is conceivably possible to make the daemon processes maintain a 
secondary "backdoor" network connection that could allow a newly spawned daemon 
to control them. But this would be a security nightmare to get right.

I don't think, this is worth it. Your use case is very specific, and can 
fortunately be addressed quite easily using other tools. Have you considered 
running all your upgrades inside of a "screen" session? That would be the 
natural choice for this type of work.

Original comment by zod...@gmail.com on 1 Sep 2010 at 3:36

GoogleCodeExporter commented 8 years ago
Fair enough. Thanks for the quick response.
Yeah, we've considered screen and perhaps we'll go this route.

Original comment by pmo...@gmail.com on 1 Sep 2010 at 3:53

GoogleCodeExporter commented 8 years ago
For future reference to anyone reading these pages.  Just run tmux or screen 
and that will do the session management for you and a lot more.  Works great 
with shell in a box.  Close a web page, and when you go back, your shell is 
exactly how you left it.

Original comment by uudrui...@gmail.com on 16 Nov 2014 at 2:55