Hack 26 Run a Headless System
|
For those times when you want to run a system "headless." Sometimes it is a simple matter of economy. Perhaps you've managed to scrounge up another system, but you don't have enough monitors, keyboards, or mice to go around. You also don't have the budget to purchase either those or a KVM switch. Sometimes it is a matter of security. Perhaps you're introducing a PC to a server closet and your physical security policy prevents server closet devices from being attached to monitors, keyboards, and mice. Before you can run a system "headless," you need to have an alternative for accessing that system. Once you've removed input and output peripherals, your entry point into the system is now either through the network card or a serial port. Going in through the network card is the easiest and is quite secure if you're using SSH. However, you should also consider a plan B. What if for some reason the system becomes inaccessible over the network? How do you get into the system then? Do you really want to gather up a spare monitor, keyboard, and mouse and carry them into the server closet? A more attractive plan B may be to purchase a null modem cable as insurance. This is a crossed serial cable that is designed to go from one computer's serial port to another computer's serial port. This type of cable allows you to access a system without going through the network, which is a real lifesaver when the system isn't responding to the network. You can purchase this type of cable at any store that sells networking cables. Your last consideration is whether the system BIOS will cooperate with your plan. Most newer BIOSes will. Many have a CMOS option that can be configured to disable "halt on errors." It's always a good idea to check out your available CMOS options before you start unplugging your peripherals. 3.4.1 Preparing the SystemI've just installed a new FreeBSD 5.1 system. Since I didn't have a null modem cable handy, I installed the old-fashioned way with the monitor and keyboard attached. If you do have a null modem cable and want to experiment with a headless install, follow the directions in the Handbook section referenced at the end of this hack. Since I want to access the server over the network, I'll double-check that the NIC is properly configured and that sshd is running: % ifconfig ed0 ed0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 192.168.2.94 netmask 0xffffff00 broadcast 192.168.2.255 ether 00:80:ad:79:4e:fd % sockstat | grep sshd root sshd 389 4 tcp4 *:22 *:* The ifconfig command is used to verify an interface's configuration; in this example, the interface is ed0. The flags indicate that this interface is UP and RUNNING. The interface also has an IP address of 192.168.2.94. The sockstat command is similar to the netstat command, but I find it provides a more intuitive output. For each open port it will display the owner of the service (root), the name of the service (sshd), the PID (389), the socket file descriptor (4), the transport (tcp4), the local address (*:22), and the foreign address (*.*). The PID is useful if you need to send a signal to the process. The local address indicates which interfaces on this system (in this case, all, or *) are listening on which port number (22). There aren't any current sessions, as the foreign address section is *.*. If there were a current session, it would show the address of the other system followed by the socket number being used for the connection. If for some reason sshd isn't running on your system, add the following line to /etc/rc.conf: sshd_enable="YES" and double-check that it'll be available at bootup, like so: # /etc/rc.d/sshd rcvar #sshd $sshd_enable=YES Finally, typing sshd as the superuser should start the daemon. You can prove this by checking that it's listening with sockstat | grep sshd. One last test I'll make sure I can log into the system over the network: % ssh 192.168.2.94 Password: % Now that I knew the system was accessible over the network, it was time for the moment of truth. After halting the system, I entered its CMOS configuration. I was a little bit worried because there weren't any options dealing with "halt errors." Undaunted, I left CMOS and powered off and unplugged the monitor, keyboard, and mouse. I then opened the case and physically removed the video card. When I powered up, the system responded with a longer than ordinary beep. But after a few seconds, my hard drive light flashed and I could hear the operating system probing my devices and loading the drivers. After a moment or so, I tried to ssh into the system and was greeted with my password prompt! Assuming your BIOS is willing to cooperate, FreeBSD has no problem loading headless. 3.4.2 If the Headless System Becomes InaccessibleShould your system ever stop responding over the network, you'll be glad you purchased that null modem serial cable. Connect one end to the COM port of the headless system, and the other end to the COM port of another system that you can access either directly or over the network. If that other system is running a Windows operating system, go to Start You'll also have to configure the port properties for that COM port. Change the default 2400 bits per second to 9600. Finally, change hardware flow control to none. Press Enter, and you should be connected to the headless system. If you're not, double-check that you chose the correct COM port. If you're attaching from a system running any variant of Unix, you can use either the cu or tip commands to connect via the serial cable. To use cu, simply specify your COM port using the line switch -l and a speed of 9600 baud using the speed switch -s. For example, this syntax allows you to connect to COM2 or cuaa1: # cu -l /dev/cuaa1 -s 9600 Connected. You should now be able to see what is happening on your headless system. One of the advantages of connecting through a serial cable is that you can watch the boot process of the system. You can't do this over a network connection, because initializing the network occurs toward the end of a successful boot. Before the network can be initialized, the kernel must successfully load into memory and the necessary hardware must be probed. If you're having problems booting a system, it is usually due to a missing or corrupt kernel or a hardware problem. To disconnect from the cu session, type ~., then press the Enter key. You should receive a Disconnected. message and receive the prompt of the system you started from. The tip utility doesn't use line or speed switches. It instead expects you to use one of the finger friendly shortcuts found at the end of the /etc/remote file. Let's take a look at that section: # tail /etc/remote # Hardwired line cuaa0b|cua0b:dv=/dev/cuaa0:br#2400:pa=none: cuaa0c|cua0c:dv=/dev/cuaa0:br#9600:pa=none: # Finger friendly shortcuts com1:dv=/dev/cuaa0:br#9600:pa=none: com2:dv=/dev/cuaa1:br#9600:pa=none: com3:dv=/dev/cuaa2:br#9600:pa=none: com4:dv=/dev/cuaa3:br#9600:pa=none: Notice that there is an entry for each COM port. This means that to connect to COM2, you simply have to type: # tip com2 connected You need a little bit more coordination to disconnect, though. Hold down Shift while you press the ~ key. Keep your finger on Shift as you press the Ctrl key, then the letter D: # ~^D [EOT] 3.4.3 See Also
|
Programs 