In these modern times, a hardworking admin might be tempted to turn her back on the Old Ways, and indulge in increasingly exotic methods of interfacing with servers: SSH over ethernet, USB, Firewire, wireless, infrared, KVM switches, VNC, VPN ... next stop: direct neural implants.
There's one old timer that still has useful place in the admin's tool kit: the serial console. Sure, it's slow and funky. But there are times it can be a real lifesaver. When nothing else works, it's a direct pipeline into your system. It's simple and cheap. You don't need to install drivers or expansion cards, it's just there.
There are a number of ways to make the physical connection. You can connect an external modem -- the kind us old timers fondly refer to as "real" modems -- and do remote administration via dialup. It couldn't be any simpler, just dial direct. Or grab a null modem cable, connect to a laptop or a nearby workstation, and you have an instant terminal.
Serial Consoling A Local Machine
Pretend you have a laptop that you are going to use as your remote terminal, connected to a headless server. The server needs a few configuration tweaks first, so don't chuck the monitor and keyboard just yet. Make sure you have a bootable rescue disk handy. You'll also need a null modem cable, and a serial communication program like Minicom on the terminal.
On most modern PCs, when we say "serial port" we mean a DB9 connector. A serial port is also a logical connection, like this:
# setserial -g /dev/ttyS /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 /dev/ttyS2, UART: unknown, Port: 0x0000, IRQ: 0 /dev/ttyS3, UART: unknown, Port: 0x02e8, IRQ: 3
This shows two active serial ports on our soon-to-be-headless server. Not earth-shaking, just nice to know. Next, reboot the soon-to-be headless server and go into the BIOS settings. Make sure it is not configured to halt when there is no keyboard. This is also a good place to poke around if by some odd chance your serial ports are not enabled, or there is only one, and you think there should be more.
Then boot up and open /etc/inittab. First job is to make booting to a text console the default. X shouldn't be on a server anyway, and you sure as heck don't want to bump into an X session over serial lines:
# The default runlevel. id:3:initdefault:
This is the default text mode for most Linuxes. On Debian, the default runlevels 2-5 are all the same, so Debian users must configure a text-only runlevel. Then open up a serial port to accept logins:
# Example how to put a getty on a serial line (for a terminal) # #T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100 #T1:23:respawn:/sbin/getty -L ttyS1 9600 vt100
Uncomment the one for the serial port you are going to use; in this article, ttyS0. Save the change, then restart init:
# init q
Now edit the server bootloader to tell the kernel to make ttyS0 (or whichever one you use) the default system console. In LILO, make a copy of your existing default stanza, and add these lines:
Call it "Serial Kernel", or some such. For GRUB users, do the same -- make a copy of your default boot stanza, then append the console values to the kernel line:
kernel /vmlinuz-2.4.24 ro root=/dev/hda2 / console=tty0 console=ttyS0,9600n8
Then boot the machine a few times to make sure it works. When you're satisfied with your bootloader configuration, make the new boot stanza the default.
In both LILO and GRUB, disable any splash images. The whole point of editing the bootloader is to redirect the boot messages that ordinarily go to the screen to the console. A splash image will gum it up.