Hack 27 Log a Headless Server Remotely
|
More on headless systems, but this time from the NetBSD perspective. We've already seen in [Hack #26] that it's important to have an alternative method for connecting to a headless server. It's also important to be able to receive a headless system's console messages. This hack will show how to configure both on a NetBSD system. 3.5.1 Enabling a Serial ConsoleIf you have another machine close to your headless server, it may be convenient to enable the serial console so that you can connect to it using a serial communication program. tip, included in the base system, and minicom , available through the packages collection, allow you to handle the server as if you were working on a real physical console. To enable the serial console under NetBSD, simply tell the bootblocks to use the serial port as the console; they will configure the kernel on the fly to use it instead of the physical screen. You also need kernel support for the serial port device, which is included in the default GENERIC kernel. However, changing the bootblocks configuration is a bit tricky because you need write permissions to the raw root device. As we are talking about a server, I assume the securelevel functionality is enabled; you must temporarily disable it by adding the options INSECURE line to your kernel. While in the kernel configuration file, double-check that it includes serial port support. Then, recompile your kernel. Once you have access to the raw partition, update the bootblocks using the installboot utility. The process depends on the NetBSD version you are using. If you are running 2.0 or higher, use the command shown next. Replace the bootxx_ffsv1 file with the one that matches your root filesystem type; failure to do so will render your system unbootable. # /usr/sbin/installboot -o console=com0 /dev/rwd0a /usr/mdec/bootxx_ffsv1 If you are running 1.6, use the following command instead: # /usr/mdec/installboot /usr/mdec/biosboot_com0.sym /dev/rwd0a When done, rebuild your kernel without the options INSECURE line to reenable securelevel. You can also remove the console drivers wscons and pccons to reduce the kernel size, though you must keep the serial port driver.
3.5.2 Setting Up the Logging ServerEven if you have configured a serial console, you won't always be connected to it. Therefore, it is very convenient to redirect important console messages to another machine that has a physical screen connected to it. syslogd lets you do this. Start by allowing incoming syslogd connections on the machine that will be receiving log messages. (I call mine logger.local.) To do this, add the following lines to /etc/rc.conf: syslogd=YES syslogd_flags= The first option is not really needed, as syslogd is enabled by default. The second option overrides the secure (s) flag that otherwise would be passed to the daemon through /etc/defaults/rc.conf. This flag tells syslogd not to listen on a UDP socket, and in this scenario we want to receive log messages over the network. Then, restart the daemon: # /etc/rc.d/syslogd restart logger.local can now receive incoming syslogd connections from any host. If required, you can restrict this by using the built-in firewall, ipf. 3.5.3 Setting Up the Headless SystemYou are ready to configure your headless server to send messages to the logger machine. As an example, we are going to redirect all messages that are actually sent to the serial console to logger.local. Open /etc/syslog.conf in your favorite editor. You will notice that the first uncommented line directs messages to /dev/console. Append the @logger.local string to it, separated by a comma. After the changes, you should end up with something like: *.err;kern.*;auth.notice;authpriv.none;mail.crit /dev/console,@logger.local Repeat for any other categories you want to redirect. When done, restart syslogd as shown earlier. 3.5.4 Shutting Down the Server Using wsmoused
If you are running a headless system at home, you may want to shut it down at night. You could do this by sshing into the server and executing shutdown manually, but this requires a second system. However, since you have physical access to the headless system, you can simply use wsmoused, which will let you execute two or three commands from a mouse one for each mouse button. wsmoused's "action mode" lets you assign commands to mouse buttons. Here's a sample configuration file to shut down and reboot the machine, which you can copy to /etc/wsmoused.conf: device = /dev/wsmoused; modes = action; mode action { button_0_down = "shutdown -p now"; button_2_down = "shutdown -r now"; }Here I've mapped the left mouse button, 0, to the command that will halt the system and the right mouse button, 2, to the command that will reboot the system. (The middle mouse button is 1.) Since I don't plan on using this mouse for its usual input functions, such as copy and paste, this is a really convenient way to power off the system quickly and safely. Enable the startup of wsmoused at boot time: # echo "wsmoused=YES" >> /etc/rc.conf
3.5.5 Beep on HaltSome headless servers don't support APM or ACP, so the kernel can't power them down automatically. The i386 architecture has another option: beep on halt. It beeps the speaker multiple times when it is safe to power off the machine after a successful halt. To enable this feature, add the following line to your kernel configuration file and rebuild it: options BEEP_ONHALT In case you do not like the default tone, you have several other options. Here they're shown with their default values: options BEEP_ONHALT_COUNT=3 # Times to beep options BEEP_ONHALT_PITCH=1500 # Default frequency (in Hz) options BEEP_ONHALT_PERIOD=250 # Default duration (in msecs) 3.5.6 See Also
|
