Closed GoogleCodeExporter closed 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
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
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
Original issue reported on code.google.com by
pmo...@gmail.com
on 1 Sep 2010 at 3:27