LINK="#3366FF" VLINK="#A000A0">



[ Table Of Contents ][ Answer Guy Current Index ] greetings   Meet the Gang   1   2   3   4   5   6   7 [ Index of Past Answers ]


(?) The Answer Gang (!)


By Jim Dennis, Ben Okopnik, Dan Wilder, Breen, Chris, and... (meet the Gang) ... the Editors of Linux Gazette... and You!
Send questions (or interesting answers) to The Answer Gang for possible publication (but read the guidelines first)


(!) Serial Console "buddy system"

Answer By James T. Dennis

Do you have a stack of Linux machines in a server room or at a co-location site? Do they all have serial consoles hooked up to a reliable terminal server? Or, is it that you can't afford to buy one of those cool Cyclades or other terminal servers, or your boss won't let you take up valuable rack space for one?
Depending on your answers to these questions you may qualify to use the unrevolutionary, completely unpatented "serial buddy system" Just take (or make) a few inexpensive null modem cables (n+1 for n machines) and link the systems in a chain (COM1 on System X to COM2 on System X+1 and around to System 0 to form a loop).
Install minicom or ckermit/gkermit, and mgetty, agetty, or uugetty (any getty that's capable of null modem -- serial, operation) and add the appropriate lines to your /etc/inittab, and option to /etc/lilo.conf or your grub configuration files (to pass console= directives to the kernel(s)) and (also optionally) compile your kernel with serial console support.
(The gory details are left for more detailed treatises such as http://www.tldp.org/HOWTO/Text-Terminal-HOWTO-17.html#term_as_console and .../linux/Documentation/serial-console.txt --- wherever your kernel sources are stored).
The end result of all this is that, when you need to look at the console of any machine, you can use a terminal package (such as minicom, or ckermit/gkermit) on the machine "next to" your target. This is much less flexible and convenient and a bit less robust than using a good terminal server --- but it's better than driving across town to the colo facility just because you're reboot failed, or you have to pass some new option to your (possibly new) kernel, or whatever). It's predicated on the likelihood that you won't manage to munge all of your machines at once.

Pros

Cheap:

you can get null modem cables for less than $5 (U.S) (Better you can make your own RJ45 to DB-9 null modem adapter pairs and use normal ethernet patch cords, in a wide selection of colors ;) to connect them! That keeps the rats nest behind you machines a tad more manageable).

Available:

you probably already have a couple of spare serial ports on that server, anyway (and some of the new kernels even support USB serial console drivers!)

More Available/Robust:

some PC motherboards support serial console right into their CMOS set-up --- so you can change the boot device, etc.

Fairly Robust:

No single point of failure? It's possible (with more advanced fussing) to force the getty's to be quiet. That should allow each of the null modems to be bi-directiional (a login could be initiated from either end by connecting to the line and hitting enter or sending a BREAK) (The trick is to force the getty's to wait for a line signal before issuing and login: prompt --- some of them have this option). Obviously systems with four serial ports can be cross wired for additional redundancy --- though only one port on any system can be the "console" --- serial getty's can be run on the others.
Did I mention CHEAP! This is way cheaper than by a Cyclades and paying the rackspace rent on it, too; and much cheaper than a PC Weasel 2000 (and spending a PCI slot on that!) and even cheaper than a set of KVM cables (not to speak of the KVM switch and rackspace consumption you'd devote to THAT).
BTW: you can also add a modem or two into the mix --- putting them on systems with a extra serial ports (COM3 or even COM2 on some system where you've got the "bi-directional, quiet getty hack" working). This can get you in to do troubleshooting even if you're network connection to the colo goes down. That's especially handy if you happen to have another null modem into your router's console! (As I: "I updated the packet filters on the Cisco and now we're locked out! Ooops!").
[And, if it's saved your butt a few times, but proves to be unbearable for other reasons (see below) it's easy to plug in that terminal server when you get your boss to pony up for it ;) ].

Cons

Kludgy:

You have to remember which machines are neighbored to one another; you have to mark up your rack diagrams with another cryptic detail.

No centralized control, logging, monitoring etc:

There are a lot of advantages to a modern terminal system (in the case of recent Cyclades products --- the are embedded systems running a Linux kernel from flash and supporting ssh for network to serial gateway functions). The "buddy system" is much simpler than all that, but much less "featureful."

Works "well enough":

This approach may deter your boss/manager from letting you get that terminal server and "do it right." C'est la vie!


This page edited and maintained by the Editors of Linux Gazette Copyright © 2002
Published in issue 78 of Linux Gazette May 2002
HTML script maintained by Heather Stern of Starshine Technical Services, http://www.starshine.org/


[ Table Of Contents ][ Answer Guy Current Index ] greetings   Meet the Gang   1   2   3   4   5   6   7 [ Index of Past Answers ]