Comment Re:Livingston PortMasters (or similar) (Score 1) 104
When we got more powerful hardware for the SSH bastion host, I wrote a set of daemons and scripts which would maintain one 'screen' session for each console port. At startup it would enable logging, make a 'telnet' connection, and then disconnect the session and leave it idle. When a user wanted to access a port, they'd run a menu tool (setuid launcher and Perl, iirc) that would give them a list of sessions to which they were entitled access, and also show the status of each screen session -- alive, dead, or in use by somebody else. When you attached to a screen, the script would send a 'title update' escape sequence, so with PuTTY your terminal titlebar shows what device you were attached to, no more pasting into the wrong window!
The main reason for using screen was that when you attached to an existing session, you didn't just get a blank prompt like 'tip' or telnet, you were dropped into a session with the latest output on the screen and scrollback available to go back hundreds of lines. So if you were trying to connect to a Cisco router that had just frozen, instead of seeing nothing, you saw the panic message it had last emitted. Also gave an audit log of everything executed on every console, going back basically forever.
Saved the company $$$$$$ with this build, between not spending money on half-ass Digi appliances and faster diagnosis and recovery when devices went braindead (especially in lights-out remote data centers). By the time I was downsized out of the corp, we had 3-4 deployments across multiple cities/countries.