17.1. Preparing a Server for Serial Console Administration

Problem

You have an ordinary x86 server that you want to run headless, with serial console administration enabled, and you want to verify that all the pieces—hardware and software—are present. The serial console might or might not be your primary method of administering your server; regardless, you want to be sure that you can connect to it with a serial console.

Solution

First, check the BIOS for your server to see if it comes with serial console support already built-in. Most likely, a low-end PC won't, but higher-end and server-quality equipment might. If it does, follow the directions for your particular machine for setting it up for a serial console, and ignore the rest of this recipe.

If not, you'll need the following:

Discussion

Serial port is one of those terms that covers a lot of ground. It means the physical connector, which on most PCs, is a male DB9 connector. It connects to a Universal Asynchronous Receiver-Transmitter (UART) chip on the motherboard. A serial port is also a logical device, /dev/ttyS*.

	$ setserial -g /dev/ttyS[0123]
	/dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4
	/dev/ttyS1: No such device
	/dev/ttyS2, UART: unknown, Port: 0x03e8, IRQ: 4
	/dev/ttyS3, UART: unknown, Port: 0x02e8, IRQ: 3

This shows that the system has only one serial port, /dev/ttyS0. That is the only one with a UART value. You can get more information about it with the -a flag:

	$ setserial -a /dev/ttyS0
	/dev/ttyS0, Line 0, UART: 16550A, Port: 0x03f8, IRQ: 4
	        Baud_base: 115200, close_delay: 50, divisor: 0
	        closing_wait: 3000
	        Flags: spd_normal skip_test

This shows a nice modern serial port that has a transfer rate of 115,200 baud. (Keep in mind this is the transfer rate between the UART chip and the PC—anything outside the PC is limited by cabling, network traffic, and other factors.)

You may be more familiar with COM1, COM2, COM3, and COM4 than /dev/ttyS1, dev/ttyS2, and so forth. The ports and interrupts are the same no matter what you call it:

	0x03f8 IRQ4 COM1 /dev/ttyS0
	0x02f8 IRQ3 COM2 /dev/ttyS1
	0x03e8 IRQ4 COM3 /dev/ttyS2
	0x02e8 IRQ3 COM4 /dev/ttyS3

A getty ("get tty"—a holdover from the days of teletypes) is a program that manages logins over serial connections. It opens a serial device, such as a modem or virtual console, and waits for a connection. getty displays the login prompt, then hands off to the login program when a username is entered, and then quietly retires. There are all kinds of gettys. mingetty and fgetty support only local virtual consoles and have no serial support, so don't use them. It's OK if they are already present on the system because you'll use /etc/inittab to control which one is used for serial console logins. mgetty is an excellent getty that also supports faxing and voicemail. agetty, uugetty, and plain old getty all work fine for serial consoling.

Most, but not all, PC BIOSes support booting without an attached keyboard. If yours doesn't, and a BIOS upgrade does not fix it, you'll need something like the PC Weasel to make it work. (See this chapter's Introduction for more information on hardware options.)

You can see what options your kernel has been compiled to support by looking at your /boot/config-* file. For example, on my Debian system, this is /boot/config-2.6.20-16. This is a not a file that you edit; it is a record of how your kernel was built. Options are either built-in, =y, compiled as loadable modules, =m, or not included, like this example shows:

	2.6.20-16
	CONFIG_X86=y
	CONFIG_X86_CPUID=m
	# CONFIG_EMBEDDED is not set

Look for these lines to confirm console support, and remember you want it built-in, and not loadable modules:

	#
	# Serial drivers
	#
	CONFIG_SERIAL_8250=y
	CONFIG_SERIAL_8250_CONSOLE=y

If it says CONFIG_SERIAL_8250=m or CONFIG_SERIAL_8250 is not set, then you'll need to rebuild the kernel. Look under Device Drivers → Character devices → Serial drivers in menuconfig.

Here are related configuration items to look for:

	CONFIG_VT=y
	CONFIG_VT_CONSOLE=y
	CONFIG_HW_CONSOLE=y
	CONFIG_SERIAL_NONSTANDARD=y

Most likely these will already be present.

Yes, I know that hardware-controller modems cost more than Winmodems/ softmodems. Trust me, you want a good-quality hardware-controller modem on the server. If you can't afford new, try eBay and other secondhand outlets.

There are many advantages: you don't have to hassle with drivers, so it Just Works. The whole point of accessing a system via the serial line is to get the most low-level access you can, which you can't do if you have to hassle with drivers. An external modem has nice blinky lights that aid troubleshooting, and it's portable. Internal modems save space. An important feature to look for is retaining settings after a power outage, usually in nonvolatile RAM (NVRAM). Cheap modems lose their settings after a power cycle, so when you try to dial in, the modem does not respond.

I favor U.S. Robotics modems. Prices range from around $80 U.S. to $300. The following models (and all of their variants) work great with Linux:

For the purpose of Linux serial console administration, the lower-priced ones work fine, as all you're using are the most basic modem functions: answering the phone, keeping the data flowing, and then hanging up. The higher-end models, like the USR Courier, include useful security features such as callback, caller line identification, and authorized caller lists. These are useful in preventing attackers from ever getting as far as a login prompt.

See Also