Felix Miata wrote: > Dan Purgert composed on 2016-06-02 19:57 (UTC): > >> Felix Miata wrote: > >>> I have no interest in answers explaining ssh and security risk. These are >>> understood. All I'm interested in is capturing dmesg and logs from a test >>> installation while normal logins are busy with segfaulting or otherwise >>> inaccessible. > >> well, if /dev/tty# is shot because segfaulting (or otherwise >> inaccessible), I wouldn't expect telnetd to help there any (unless >> telnet uses a different pool of ttys). > > Actually I would expect it to use a different "pool", but this is not a > subject I know more than a trifle about.
Same here :( > [snip] > IOW, current need is past, but I'd still like to know what's wrong and > get it fixed for a possible next time. Good that you found / fixed the problem. >> Would a serial console (i.e. /dev/ttyS0) suit your needs? > > Probably not well, something yet else to configure that I haven't > needed to do in more than two decades, another cable to locate and > connect, and likely for a one time only use. Or can serial connection > be shared over existing ethernet? No, serial connections are via serial ports, and won't traverse ethernet networks (though you could probably get ethernet -> serial modems if you really wanted to). I have enough random network hardware that uses serial consoles between my desk (a.k.a. "test bench") and my main network kit, that adding in a serial null-modem cable for the server was 'no big deal' - just some config changes in /etc/inittab, and running out to Microcenter. After having more than a few occasions where something was mis-behaving sufficently to *require* serial console access (thanks buggy router flash media), it's becoming one of those things that I look for now, and will spend extra money to get. Sure, I might only use it once or twice ever in the lifetime of the product (this being "at home" and all) ... but it's cheap insurance. -- Registered Linux user #585947 Github: https://github.com/dpurgert
