05|25 Lights out without a LOM
From the first time I played with the LOM (Lights Out Management) interface on a Netra, I've wanted a way of getting that functionality on all of my boxes. I've found that by making use of a serial port, wake on lan, and a TFTP server, you can get similar functionality without breaking the bank. This guide assumes that you're attempting to boot x86 hardware with PXE/Wake on Lan support and are using OpenBSD for the netboot server. I'll try to point out any significant differences between OpenBSD and other Linux/Unixes.
First, record the MAC address of the system you want to work with, you'll need this later for DHCP and Wake on Lan. The easiest way to get the MAC is to run /sbin/ifconfig or /sbin/ip link but if the box isn't running or doesn't have an OS installed, you can pop the cover off and read it off the NIC. Or for the extremely lazy (myself included) you can have the box attempt to PXE boot and watch your DHCP server logs.
Next, setup your TFTP server by creating /tftpboot and uncommenting the appropriate line in /etc/inetd.conf. Restart inetd. Depending on what hardware you're booting and what you want to install/boot, you need to add the proper files to your /tftpboot directory. I keep a number of different kernels/bootloaders on my TFTP server so that I can boot just about any hardware I come across with any distro I want.
Let's assume that you want to install Debian on an x86 box. The Debian folks have been nice enough to create a tarball of everything you need to get going on a TFTP server. Just grab /dists/stable/main/installer-i386/current/images/netboot/netboot.tar.gz from your nearest Debian mirror and unpack it in /tftpboot. In the event that the tarball isn't available for the branch or distro you want, you'll need at least a pxelinux file and a kernel. Other files may be necessary depending on the distribution. Check your documentation for details.
Now you need to add a section to your /etc/dhcpd.conf so that the filename and location of the TFTP server is given to the PXE bootloader when it broadcasts for DHCP.
Once you've saved and reloaded your dhcpd.conf, your box should now boot on the console assuming that the BIOS is configured to allow PXE booting. Double check that it grabs a configuration from DHCP and downloads the image from the TFTP server. Once this is working, you're ready to move on to the serial port.
This is where things really deviate depending on what distro you're trying to boot. I'll do my best to cover as many scenarios as possible.
Add a line that looks like this to your pxelinux.cfg file:
Add the following lines to your /boot/grub/menu.lst
Add the following line to your lilo.conf to enable serial console access. Once again, a password is advisable.
The BSD bootloaders are a bit different than LILO and GRUB. They tend to resemble OpenBoot in some ways, making complicated configurations not so complicated. OpenBSD's pxeboot will attempt to download boot.conf from your TFTP root for additional configuration information. It'll still work if this file doesn't exist. Create /tftpboot/boot.conf and add the following line to it:
Depending on the kernel you're booting, you may also need to specify a serial console in the kernel arguments by appending the following to the kernel command line.
If you boot the system now, you'll be able to see kernel messages scroll by as the system boots. Depending on the userspace setup, you still may or may not get a terminal. If not, you'll need to find a way to add the following line to /etc/inittab
Once your system is installed and running, you may have to tweak the installed bootloader and/or userspace to get the serial console working again. This probably seems like a lot of extra work without much gain, but once you've done it a few times, it becomes second nature and the benefits of running the system on a serial console are apparent.
The last piece of the puzzle is Wake on LAN. WOL works by having the NIC watch for a 'magic packet' on the local link while the system is powered off (ATX power supplies provide 5 volts to the motherboard in the off state for just this sort of thing). When the magic packet is received, the NIC sends a wake up event to the motherboard which relays it to the power supply as if the power button were pushed. You may need to enable these features in the BIOS and/or network card configuration. Not all cards support PXE booting and others do, but call it something different. If in doubt, Google for the model of the card.
In order to send the magic packet, you need to have at least one machine already running on the network segment. There are dozens of scripts on the net for sending out Wake on LAN packets, but because I'm a Python advocate, I tend to prefer this one. Create a .wake_hosts file in your home directory with one host on each line in the format:
While the serial console may not be practical for system installs, netbooting certainly is. But once you've got everything running, the serial console can be an invaluable tool in case you manage to lock yourself out of the system by crashing sshd, adding a bad rule to iptables, messing up the routing table, installing a bad kernel, or losing the root password. This approach is limited in comparison to a LOM in that you don't get direct access to the BIOS or more complete diagnostic tools without setting up something like memtest86.
A word on security; in most cases, adding another avenue of access to the system that is not necessarily needed is considered bad security practice. However, by installing a boot loader password and securing your terminal server, the chances of a successful attack through the serial console are probably on par with running an SSH daemon. Even if it does provide a secuity hole, I believe the benefits of having a lifeline like this outweigh the risks.