search

xbianonpi / xbian

XBMC on Raspberry Pi, Bleeding Edge
https://xbian.org
GNU General Public License v3.0
294 stars 44 forks source link

Keep telnet session alive when user is using it #560

Closed CurlyMoo closed 9 years ago

CurlyMoo commented 10 years ago

telnet is started very early in the boot process. The problem is that telnet automatically closed when ssh starts. If a user is working in a telnet session and ssh starts, it looses its terminal and possibly work it was working on.

Why not let the telnet session live until the user closes it and then stop the telnet daemon so the user is forced to use ssh next time.

mk01 commented 10 years ago

@CurlyMoo

because busybox is not spawning sessions by default - and I found no way to instruct it so. that doesn't mean it is not possible - so this is definitely open to commmits.

CurlyMoo commented 10 years ago

Is there any place you stop the telnet service?

CurlyMoo commented 10 years ago

I at least noticed two things. Whenever a telnet session is running you'll see:

root@pi:~# ps aux | grep login
root      6950  0.8  0.4   5288  1824 pts/6    Ss   01:00   0:00 /bin/login

and

root@pi:~# who
root     pts/2        2014-06-24 00:57 (10.0.0.145)
root     pts/4        2014-06-24 00:57 (10.0.0.145)
xbian    pts/6        2014-06-24 01:00 (10.0.0.145:7510)

Telnet sessions always show an ip:port combination, a ssh session just an ip. Not sure how accurate the ps output is, but the who output seems consistent.

If we combine the port number with a netstat lookup, we can be sure that it is a telnet session:

root@pi:~# netstat -anp | grep 7510
tcp        0      0 10.0.0.141:23           10.0.0.145:7510         ESTABLISHED 6832/busybox
mk01 commented 10 years ago

@CurlyMoo

no, currently there is no place where the process is stopped. it is simple upstart job (xbian-failaccess). it's stopping strategy is defined as follows:

stop on started openbsd-inetd

what actually means sshd in that case. of course more variable process can be added with no big issues via upstarts pre-stop definition.

what you are saying is true. but I still don't see easy workflow to precisely duplicate effect of having one daemon and spawned sessions. we can effectively wait in pre-stop for pts be closed but for the time being we can't (once entered pre-stop) nicely refuse new connections - although a simple but hacky solution would be to block NEW TCP IN on DPORT 23 (once entered pre-stop). that means process of stopping of generally dangerous telnetd could be blocked indefinitely.

very similar it could be blocked that way by crashed process not freeing pts. so with all this considerations - and it's primary purpose for simple failrecovery / system status check - I decided for this hard close as being less evil than keeping telnetd potentially for ever.

(I personally put openbsd-inet to disabled/manual after logging into telnet if I consider my telnet sessions being important. after I finish I just start openbsd-inetd from console then)

at any case feel free to propose something for further discussion.

CurlyMoo commented 9 years ago

We changed this to an early ssh session.