An uninterruptible power supply (UPS) is a must-have in server environments, and for many desktop users as well. But although simply connecting your PC or server to a UPS will protect you from intermittent power outages and give you the chance to shut the system down at the keyboard, an unattended power outage could still cause problems. For added protection, you can run a power-monitoring utility that will read status information from the UPS and perform a clean shutdown of the connected machine (or machines), preserving data and stopping processes in the proper state.
NUT Basics
The premiere UPS monitoring tool on Linux is Network UPS Tools (NUT), a free software tool that supports hundreds of UPS models from a wide range of vendors. NUT can monitor UPSes connected via serial cable or USB, and is designed for networked operation to control multiple servers and workstations.
Since the vast majority of UPSes include only one USB or serial connection, NUT can be configured to run in “slave” mode, listening on a TCP port for a shutdown notice from the directly-connected computer. That way, you can connect your primary server to the UPS with the cable in “master” mode, but ensure that other devices — such as a workstation, firewall, or NAS box — receive the message that power is out and shut down cleanly. You can even configure NUT to shut down the slave devices immediately, preserving more battery power for the master, in case power is restored.
NUT consists of three main pieces: the drivers that interface with the actual UPS hardware, decoding its status and reports to determine whether power is present and how much battery charge remains, the upsmon client that monitors UPS status and responds to power events by logging, sending notification messages, and shutting down the system when needed, and the upsd daemon that passes information between upsmon and the various drivers. This separation of duties is what allows NUT to work in a networked environment; a slave machine can run only upsmon and listen for power outage events from the master, and the master can connect to multiple hardware UPSes, as is the case for servers with redundant power supplies.
Setup and Basic Monitoring
You can download NUT source code and binaries from the project’s Web site, but most Linux distributions include it through their package management systems. The newest release is version 2.4, from January of 2009. As of the moment, the online documentation has not caught up to the changes since the last release (2.2), but the documentation and configuration help included in the packages is enough to go by.
To configure your system, first check the model names and numbers of the UPSes you wish to monitor. NUT installs a current list sorted by manufacturer to /usr/share/nut/driver.list; consult the list and note the name of the driver required for your UPS. Many USB-connected models are supported by the same driver, usbhid-ups, so it will appear in the examples that follow. Serial port models generally use a specific driver.
Next you will need to set up up to five configuration files (depending on how you use NUT): nut.conf, ups.conf, upsd.conf, upsd.users, and upsmon.conf. All reside in /etc/nut/. nut.conf contains only one entry, the mode in which you want to run NUT. The choices are standalone, netserver, and netclient. Use netclient on slave machines, and the only other file you need to configure is upsmon.conf. Standalone mode is for basic, single-machine usage; netserver adds the ability to send messages over the network to slave machines.
In ups.conf, you add an entry for each UPS physically connected to the machine — only one for basic usage, but redundant, server setups could contain multiple entries. A typical entry in ups.conf looks like this:
[primaryups]
driver = usbhid-ups
port = auto
desc = "My main server"
The name in brackets is entirely your choice; it should be descriptive if you have more than one UPS, as it will appear in the logs and in NUT’s system messages. The “driver” property lists which hardware driver NUT should use to communicate with the UPS — the same driver you looked up earlier in /usr/share/nut/driver.list. The “port” property tells NUT where the UPS is connected; for USB-connected UPSes, use auto; serial-connected UPSes would use /dev/ttyS0, /dev/ttyS1, or so on. The “desc” property is solely to record further detail about the UPS to aid your memory.
In upsd.conf, the most important setting is the LISTEN directive; it specifies the IP addresses (and optionally, ports) on which NUT will respond to messages. For a standalone setup, use LISTEN 127.0.0.1. For a netserver master, you should also add an entry for the computer’s public IP address, such as LISTEN 192.168.2.10. You can specify the port after the IP address if you desire; the default is 3493.
The upsd.users file allows you to configure “NUT users” that upsmon uses to connect; not simply using the system’s real Unix accounts provides a layer of increased security. This can be as simple as:
[myupsuser]
password = thepassw0rd
upsmon master
…for a basic upsmon account on the master machine. An account for slave machines should specify upsmon slave instead. More complex setups allow you to grant specific privileges to different user accounts; the comments in the sample upsd.users file explain the options.
Finally, upsmon.conf configures the behavior of upsmon, the program that will actually monitor the UPS status of either the physical machine or a remote master. There are a lot of options allowing you to change the status polling frequency, log messages, and other details, but to get started the only line you need to add is a MONITOR directive, specifying the UPS, server, and NUT username/password. For example, MONITOR primaryups@bigserver 1 myupsuser thepassw0rd master indicates monitoring of the UPS example specified in the example file configurations above.
“Bigserver” is the hostname of the machine, “1” is the number of power supplies controlled by this server (1 is the default, and is unlikely to need changing unless you deal with redundant setups), and “master” indicates that this is the NUT master. A slave machine, such as a second PC attached to the same UPS but not connected to the USB monitoring cable, would specify MONITOR primaryups@bigserver 1 myupsuser thepassw0rd slave. Once configuration is complete, you can start the system with /etc/init.d/nut start.
With this configuration, upsd will monitor the UPS, and upsmon will look for power events. Should building power fail, upsmon will log the event and send a “We are shutting down soon” message to all logged-in users. When the battery power gets low, the upsmon process running on the master relays a shutdown command to the upsmon processes on the slaves. The slave machines will shut down gracefully, ensuring that disk partitions and RAID arrays are not left in an unstable state, lock files strewn about heedlessly, or any of the other nastiness associated with a sudden power outage. Last but not least, after the slave machines have shut down, the master shuts itself down.
PowerChute, Apcupsd, and Other Options
Admittedly, for basic use, NUT requires quite a few configuration steps. Fortunately, as we have seen, none of them are arduous in length or particularly arcane in syntax. The benefit is the flexibility to support an wide variety of hardware products and complex configurations, something other UPS monitoring options cannot do.
For example, there is a package called upsd unrelated to the NUT daemon of the same name. This upsd can monitor just one UPS attached directly to the host computer, and is limited in its hardware support to devices made by Powercom. However, if you use a Powercom UPS and do not need the networking or redundancy functions of NUT, you should take a look; this upsd’s simplicity and ease-of-use may fit the bill.
Similarly, OpenUPSd is limited in scope to certain kinds of serial-connected Belkin UPSes — those that share a single communications protocol called “regulator pro.” On the other hand, OpenUPSd does support networking, and the author reports that he is adding support for American Power Conversion (APC) UPS models, making the project one to watch.
Finally, APC provides a proprietary UPS monitoring tool called PowerChute with many of its UPSes. PowerChute is a Java-based program, and is naturally limited to APC hardware. More interesting is Apcupsd, a GPL-licensed replacement. Apcupsd offers many of the same features as NUT, including networking, though of course only for APC devices. It is configured through a single file, apcupsd.conf, making it potentially easier to maintain and troubleshoot than NUT.
For example, a sample configuration for a networked server would contain just:
UPSCABLE usb
UPSTYPE usb
DEVICE
LOCKFILE /var/lock
UPSCLASS standalone
UPSMODE disable
NETSERVER on
Corresponding slave machines would use an apcupsd.conf file like this:
UPSCABLE ether
UPSTYPE net
LOCKFILE /var/lock
DEVICE 192.168.2.10:3551
UPSCLASS standalone
UPSMODE disable
POLLTIME 10
…in order to connect to the master running at IP address 192.168.2.10.
Whichever solution you use, though, you benefit through the increased reliability of a “smart” power management system. Simply shutting down your machine cleanly during a blackout can prevent stability problems the next time you start up, and the odds are against the blackout striking during business hours when you are at the keyboard. Advanced features in both NUT and Apcupsd can do more, like manage multiple UPSes on servers, or (with proper BIOS support) automatically restart computers after a blackout is over and power has been restored.
That’s smart power, indeed.
