![]() |
Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
Jarod Wilson wrote: > I have a thought... Serial console connections, managed by a console > manager, which lets you reconnect to the serial console session, plays > back log of prior stuff, etc... Interesting, but I'm not sure I see how that accomplishes the stated goals. Lets ignore the hardware issues for the moment, and presume that conman can manage an ssh connection that loops back to the local machine, so we don't need to worry about having physical serial ports for each shell session. > I have serial console output set up on a number of boxes in my cube. > These are hooked up to server machine...[which] runs the conman daemon... > I run the conman client on my laptop, instructed to point at the server. > A simple 'conman foo' in an xterm gives you serial console on machine 'foo'. OK, so the client-server model used by conman lets you attach and detach to an already running shell. I see it supports logging, but what about in-memory scrollback buffer. That's really more of a UI function than a serial console function. It sounds like screen is a better fit for the described problem. So far I'm not seeing anything that conman does to address the gaps in the screen approach. A reboot of the local machine still wipes away all state with either approach, if the shells are running on the local machine. But I appreciate the suggestion. -Tom -- Tom Metro Venture Logic, Newton, MA, USA "Enterprise solutions through open source." Professional Profile: http://tmetro.venturelogic.com/ -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ Discuss mailing list [hidden email] http://lists.blu.org/mailman/listinfo/discuss