Firefox 3 native widgets on Linux

As you can see, there’s an ugly white box around the otherwise rounded widgets. Originally, I thought my CSS was lacking, but after hours–literally–of googling I determined that Firefox’s implementation of gtk+ widgets is just shoddy. Of course, on a site with a white background, they look great. I’m reminded of that Henry Ford quote: “Any customer can have a car painted any colour that he wants as long as it is black.”

Applying any styling to the input elements will completely disable the native widgets. I ended up writing some basic CSS:

input, textarea { border: 2px solid #888888; }
input:focus, textarea:focus {
	border-color: #D9D27C;
	background-color: #FFFBC4;
}

They don’t look nearly as good as native widgets on a white background, but they look a whole lot better than native widgets on my site. See below:

Basic styled widgets

I also added some input focus bling to the form:

Text input with keyboard focus

Even though they look alright now, I’ve decided that my next major project on my blog should be a complete theme redesign. Traditional color schemes are easier to work with and I’ll also get familiar with a lot of Wordpress PHP code.

About a year ago I bought an external SATA drive for backups. My normal usage consisted of:

1. Power on and connect the drive
2. mount /media/backup
3. Run my backup script
4. umount /media/backup
5. Power off and unplug the drive

This seemed to work pretty well–at the very least, I wasn’t losing data–except the drive made a strange sound when I powered it off. It wasn’t a normal drive spin down sound; it was louder and shorter. So, I googled for authoritative instructions on using external drives with Linux. While most sources suggest doing exactly what I did, it’s not ideal.

It turns out that most cheap external USB/SATA/firewire enclosures don’t properly issue a stop command to the drive when you flick the power switch. Instead, the power switch simply cuts power to the drive, which forces the drive to do an emergency head retract. If you think that sounds bad, you’re right. Emergency retracts aren’t going to brick your drive immediately, but if they occur regularly they’re putting a lot of unnecessary wear and tear on the drive. In fact, some drives monitor how often this happens with S.M.A.R.T. attribute 192. (Check Wikipedia’s S.M.A.R.T. page for a comprehensive list of attributes)

Solution

The solution is to spin down the drive via software before turning it off and unplugging it. The best way to do this is with a utility called scsiadd. This program can add and remove drives to Linux’s SCSI subsystem. Additionally, with fairly modern kernels, removing a device will issue a stop command, which is exactly what we’re looking for. Run:

$ sudo scsiadd -p

which should print something like:

Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: ATA      Model: SAMSUNG HD300LJ  Rev: ZT10
  Type:   Direct-Access                    ANSI  SCSI revision: 05
Host: scsi4 Channel: 00 Id: 00 Lun: 00
  Vendor: LITE-ON  Model: DVDRW LH-20A1L   Rev: BL05
  Type:   CD-ROM                           ANSI  SCSI revision: 05
Host: scsi5 Channel: 00 Id: 00 Lun: 00
  Vendor: ATA      Model: WDC WD10EACS-00Z Rev: 01.0
  Type:   Direct-Access                    ANSI  SCSI revision: 05

Identify the drive you want to remove and then issue:

$ sudo scsiadd -r host channel id lun

substituting the corresponding values from the scsiadd -p output. For example, if I wanted to remove “WDC WD10EACS-00Z”, I would run:

$ sudo scsiadd -r 5 0 0 0

If everything works, scsiadd should print:

Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: ATA      Model: SAMSUNG HD300LJ  Rev: ZT10
  Type:   Direct-Access                    ANSI  SCSI revision: 05
Host: scsi4 Channel: 00 Id: 00 Lun: 00
  Vendor: LITE-ON  Model: DVDRW LH-20A1L   Rev: BL05
  Type:   CD-ROM                           ANSI  SCSI revision: 05

You can double-check the end of dmesg. You should see:

[608188.235216] sd 5:0:0:0: [sdb] Synchronizing SCSI cache
[608188.235362] sd 5:0:0:0: [sdb] Stopping disk
[608188.794296] ata6.00: disabled

At this point, the drive is removed from Linux’s SCSI subsystem and it should not be spinning. It’s safe to unplug and turn off.

Using scsiadd directly can be inconvenient because it requires looking up the host, channel, id, and lun of the drive. I wrote a short script that will take a normal Linux device file like /dev/sdb, figure out the correct arguments to scsiadd, and run scsiadd -r. I use this script in my larger backup script.

#!/bin/sh

if [ $# -ne 1 ]; then
    echo "Usage: $0 <device>"
    exit 1
fi

if ! which lsscsi >/dev/null 2>&1; then
    echo "Error: lsscsi not installed";
    exit 1
fi

if ! which scsiadd >/dev/null 2>&1; then
    echo "Error: scsiadd not installed"
    exit 1
fi

device=`lsscsi | grep $1`
if [ -z "$device" ]; then
    echo "Error: could not find device: $1"
    exit 1
fi

hcil=`echo $device | awk \
    '{split(substr($0, 2, 7),a,":"); print a[1], a[2], a[3], a[4]}'`

scsiadd -r $hcil

It does require the lsscsi command to be present on the system.

Why Use S.M.A.R.T.?

Basically, S.M.A.R.T. may give you enough of a warning that you can safely backup all your data before your hard drive dies. There is some amount of conflicting information on the internet about how reliable the warnings are. The best source of research that I found is a paper from Google that describes an internal study of hard drive failure. A quick summary: certain events greatly increase the chance of hard drive failure including reallocation events and failed self-tests, but only about 60% of the drives that failed in the study had any negative S.M.A.R.T. attributes. Obviously, nothing replaces regular backups.

A good source for more information is the S.M.A.R.T. wikipedia page.

Installation

On Debian or Ubuntu systems:

$ sudo apt-get install smartmontools

On Fedora:

$ sudo yum install smartmontools

Capabilities and Initial Tests

smartmontools comes with two programs: smartctl which is meant for interactive use and smartd which continuously monitors S.M.A.R.T. Let’s look at smartctl first:

$ sudo smartctl -i /dev/sda

Replace /dev/sda with your hard drive’s device file in this command and all subsequent commands. If there’s only one hard drive in the system, it should be /dev/sda or /dev/hda. If this command fails, you may need to let smartctl know what type of hard drive interface you’re using:

$ sudo smartctl -d TYPE -i /dev/sda

where TYPE is usually one of ata, scsi, or sat (for serial ata). See the smartctl man page for more information. Note that if you need -d here, you will need to add it to all smartctl commands. This should print information similar to:

=== START OF INFORMATION SECTION ===
Model Family:     SAMSUNG SpinPoint T133 series
Device Model:     SAMSUNG HD300LJ
Serial Number:    S0D7J1UL303628
Firmware Version: ZT100-12
User Capacity:    300,067,970,560 bytes
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   7
ATA Standard is:  ATA/ATAPI-7 T13 1532D revision 4a
Local Time is:    Fri Jan  2 03:08:20 2009 EST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

Now that smartctl can access the drive, let’s turn on some features. Run the following command:

$ sudo smartctl -s on -o on -S on /dev/sda

• -s on: This turns on S.M.A.R.T. support or does nothing if it’s already enabled.
• -o on: This turns on offline data collection. Offline data collection periodically updates certain S.M.A.R.T. attributes. Theoretically this could have a performance impact. However, from the smartctl man page:
  

  Normally, the disk will suspend offline testing while disk accesses are taking place, and then automatically resume it when the disk would otherwise be idle, so  in  practice  it has little effect.

• -S on: This enables “autosave of device vendor-specific Attributes”.

The command should return:

=== START OF ENABLE/DISABLE COMMANDS SECTION ===
SMART Enabled.
SMART Attribute Autosave Enabled.
SMART Automatic Offline Testing Enabled every four hours.

Next, let’s check the overall health:

$ sudo smartctl -H /dev/sda

This command should return:

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

If it doesn’t return PASSED, you should immediately backup all your data. Your hard drive is probably failing. Next, let’s make sure that the drive supports self-tests. I have yet to see a drive that doesn’t, but the following command also gives time estimates for each test:

$ sudo smartctl -c /dev/sda

I won’t list the complete output because it’s somewhat lengthy. Make sure “Self-test supported” appears in the “Offline data collection capabilities” section. Also, look for output similar to:

Short self-test routine
recommended polling time: 	 (   2) minutes.
Extended self-test routine
recommended polling time: 	 ( 127) minutes.

These are rough estimates of how long the short and long self-test’s will take respectively. Let’s run the short test:

$ sudo smartctl -t short /dev/sda

On my drive, this test should take 2 minutes, but this obviously varies. You can run:

$ sudo smartctl -l selftest /dev/sda

to check results. Unfortunately, there’s no way to check progress, so just keep running that command until the results show up. A successful run will look like:

=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed without error       00%     21472         -

Now, do the same for the long self-test:

$ sudo smartctl -t long /dev/sda

The long test can take a significant amount of time. You might want to run it overnight and check for the results in the morning. If either test fails, you should immediately backup all your data and read the last section of this guide.

Configuring smartd

We’ve now enabled some features and run the basic tests. Instead of repeating the previous section daily, we can setup smartd to do it all automatically. If your system has an /etc/smartd.conf file, check for a line that begins with DEVICESCAN. If you find one comment it out by adding a ‘#’ to the beginning of the line. DEVICESCAN doesn’t work on my system and specifying a device file is easy. Add the following line to /etc/smartd.conf:

/dev/sda -a -d sat -o on -S on -s (S/../.././02|L/../../6/03) -m root -M exec /usr/share/smartmontools/smartd-runner

Here’s what each option does:

• /dev/sda: Replace this with the device file you’ve been using in smartctl commands.
• -a: This enables some common options. You almost certainly want to use it.
• -d sat: On my system, smartctl correctly guesses that I have a serial ata drive. smartd on the other hand does not. If you had to add a “-d TYPE” parameter to the smartctl commands, you’ll almost certainly have to do the same here. If you didn’t, try leaving it out initially. You can add it later if smartd fails to start.
• -o on, -S on: These have the same meaning as the smartctl equivalents
• -s (S/../.././02|L/../../6/03): This schedules the short and long self-tests. In this example, the short self-test will run daily at 2:00 A.M. The long test will run on Saturday’s at 3:00 A.M. For more information, see the smartd.conf man page.
• -m root: If any errors occur, smartd will send email to root. On my system, mail for root is forwarded to my normal email account. If you don’t have a similar setup, replace root with your normal email address. This option also requires a working email setup. Most Linux distributions automatically have working outbound email.
• -M exec /usr/share/smartmontools/smartd-runner: This last part may be specific to the Debian and Ubuntu smartmontools packages. Check if your system has /usr/share/smartmontools/smartd-runner. If it doesn’t, remove this option. Instead of sending email directly, “-M exec” makes smartd run a different command when errors occur. On Debian, smartd-runner will run each script in /etc/smartmontools/run.d/, one of which emails the user specified by the “-m” option.

If you have more than one hard drive in your system, add a line for each one replacing /dev/sda with a different device file.

Finally, restart smartd:

$ sudo /etc/init.d/smartmontools restart

If this command fails, the end of /var/log/daemon.log should have some diagnostic information. If smartd started fine, we should still test that email notifications are working. Add “-M test” to the end of the configuration line in /etc/smartd.conf. This will make smartd send out a test notification when it’s next started. Once again, restart smartd:

$ sudo /etc/init.d/smartmontools restart

You should receive an email similar to:

This email was generated by the smartd daemon running on:

   host name: polar
  DNS domain: shadypixel.com
  NIS domain: (none)

The following warning/error was logged by the smartd daemon:

TEST EMAIL from smartd for device: /dev/sda

For details see host's SYSLOG (default: /var/log/syslog).

Afterward, you can delete “-M test”.

What To Do If smartd Detects Problems

First, immediately backup everything. Depending on the error, your drive might be close to death or it may still have a long life ahead. Consult the smartmontools FAQ. It has some recommendations for specific errors. Otherwise, ask for help on the smartmontools-support mailing list.

I did apply all the Debian patches that were still relevant so it should be the equivalent of the official Debian package.

First, as is always the case when you’re modifying disk volumes, partitions, or file systems, you should really have a recent backup. A typo in one the following commands could easily destroy data. You have been warned!

All of the required steps must be performed on an unmounted volume. If want to reduce the size of a non-root volume, simply unmount it. For a root volume, you’ll have to boot from a CD. Any modern live or rescue CD should work fine. I prefer SystemRescueCD. It includes almost any disk management programs you might need. After booting from a CD, you may have to issue:

# vgchange -a y

This makes any logical volumes available to the Linux. Most boot CD’s will do it automatically some time during the boot process, but repeating the command won’t hurt. Next, force a file system check on the volume in question:

# e2fsck -f /dev/polar/root

Device names for LVM volumes follow the convention: /dev/<volume group>/<logical volume>. In this case, my volume group is named polar and the volume I’m going to shrink is named root. This is a critical step; resizing a file system in an inconsistent state could have disastrous consequences. Next, resize the actual file system:

# resize2fs /dev/polar/root 180G

Replace 180G with about 90% of the size you want the final volume to be. For example, in this case, I want the final volume to be 200 gigabytes, so I’ll reduce the file system to 180 gigabytes. Why is this necessary? When we reduce the size of the actual volume in the next step, it’s critical that the new size is greater than or equal to the size of the file system. After reading the documentation for both resizefs and lvreduce, I still haven’t been able to find out whether they’re using standard computer gigabytes (1024^3 bytes) or drive manufacturer gigabytes (1000^3 bytes). In this case, the difference is very important. To be on the safe side, we’ll just shrink the file system a bit more than necessary and expand it to use the full space available later. Next, reduce the size of the logical volume:

# lvreduce -L 200G /dev/polar/root

In this case, use the actual size you want to the volume to be. Finally, grow the file system so that it uses all available space on the logical volume:

# resize2fs /dev/polar/root

That’s it. Enjoy your newly acquired free space.

First, create a file called utorrent with the following content:

#!/bin/sh

if [ "$1" ]; then
    torrent_file="Z:`echo $1 | sed 's/\//\\\/g'`"
    env WINEPREFIX="/home/avery/.wine" wine \
        "C:\\Program Files\\uTorrent\\uTorrent.exe" "$torrent_file"
else
    env WINEPREFIX="/home/avery/.wine" wine \
        "C:\\Program Files\\uTorrent\\uTorrent.exe"
fi

Replace /home/avery with the path to your home directory. Make sure to make the file executable:

$ chmod +x utorrent

This is the main script that we’ll start uTorrent with. Basically, if given a file path on the command line, it will transform it from a linux path to a wine path. /tmp/sample.torrent will become Z:\tmp\sample.torrent. The sed bit comes from an Ubuntu forums thread.

Next, we need to fix the .desktop file. It should be located at ~/.local/share/applications/wine/µTorrent.desktop and contain something like:

[Desktop Entry]
Name=µTorrent
Exec=env WINEPREFIX="/home/avery/.wine" wine \
    "C:\\Program Files\\uTorrent\\uTorrent.exe"
Type=Application
StartupWMClass=Wine
Icon=6948_utorrent.0

Add the following two lines to the end of the file:

Categories=Network;FileTransfer;P2P
MimeType=application/x-bittorrent

The first line makes uTorrent show up correctly in the GNOME menu system. The next associates uTorrent with the BitTorrent MIME type. Also, change the Exec line to:

Exec=/home/avery/bin/utorrent %f

Obviously, replace the path with wherever you put the utorrent script from above. The .desktop file should now contain:

[Desktop Entry]
Name=µTorrent
Exec=/home/avery/bin/utorrent %f
Type=Application
StartupWMClass=Wine
Icon=6948_utorrent.0
Categories=Network;FileTransfer;P2P
MimeType=application/x-bittorrent

To make uTorrent the default BitTorrent client, edit ~/.local/share/applications/defaults.list:

[Default Applications]
application/x-bittorrent=µTorrent.desktop

This file might already exist, in which case you can just add the second line. Finally, we need to update GNOME’s file associations database:

$ update-desktop-database ~/.local/share/applications

Success:

Iceweasel offers to open a torrent with uTorrent running under wine.

First, get the installer from Real’s site. Download the normal installer, named something like RealPlayer11GOLD.bin, instead of the RPM version. To use the installer and RealPlayer, you’ll need to get 32-bit versions of some common libraries.

$ sudo apt-get install ia32-lib ia32-libs-gtk

Navigate to the directory where you saved the installer and run:

$ chmod +x ./RealPlayer11GOLD.bin
$ ./RealPlayer11GOLD.bin

The installation is self-explanatory. I installed to ~/software/RealPlayer. The installer adds a link in the GNOME Sound & Video menu. It doesn’t work though.

Error after running RealPlayer from the menu entry

This is because I installed as a normal user instead of root. It didn’t add a link to RealPlayer in the system path. To solve this problem, add a shell script like the following to a directory in your path:

#!/bin/bash
exec /home/avery/software/RealPlayer/realplay $@

Name the script realplay and make it executable. Obviously, replace /home/avery/software/RealPlayer with whatever directory you installed RealPlayer to. I put this script in ~/bin, which is in my path. Now, you should be able to launch RealPlayer from the command line, but the menu item still might not work. If you added the script to a location in the system path, like /usr/bin, it will work fine. In my case, I put it in ~/bin, which is in my path, but not the system path. To fix this, you can modify the .desktop entry for RealPlayer, which is installed as ~/.local/share/applications/realplay.desktop. Replace the line:

Exec=realplay %U

with:

Exec=/home/avery/bin/realplay %U

The GNOME menu doesn’t expand ~, so you need to enter the full path to the script. Now, the menu item should work. The next thing you might notice is that while RealPlayer works, it looks awful.

RealPlayer with image loader errors

This happens because Debian’s version of ia32-libs-gtk has some packaging bugs. See Debian bug #484581. To solve this, we’ll run RealPlayer in a 32-bit chroot instead of using 32-bit libraries in a normal x86_64 installation. I’m not going to get into setting up a 32-bit chroot here. Instead follow the instructions in the Debian GNU/linux AMD64 HOW-TO. Be sure to setup schroot. schroot makes using a 32-bit chroot very simple. Once the chroot is setup and schroot is working, modify the realplay script as follows:

#!/bin/bash
real_path=/home/avery/software/RealPlayer/realplay
if [ -f /etc/debian_chroot ]; then
    exec $real_path $@
else
    exec schroot -p $real_path $@
fi

Basically, if the /etc/debian_chroot file exists, it runs RealPlayer directly. Otherwise, it runs RealPlayer using schroot. I don’t think standard chroot creates the /etc/debian_chroot file, but schroot does. The reason the script doesn’t always run RealPlayer using schroot is that applications that are already in a chroot, like firefox, may need to run RealPlayer. There’s no point in creating yet another chroot if we’re already in one.

Running RealPlayer in a chroot

It works!

Update: After a bit of testing, I think it’s better to add a link to the realplay script system-wide. In addition to the GNOME menus, firefox only looks in system-wide paths. You’ll probably want to add a link in your chroot as well:

$ sudo ln -s /home/avery/bin/realplay /usr/bin/realplay
$ sudo ln -s /home/avery/bin/realplay /var/chroot/lenny-ia32/usr/bin/realplay

First, to give you some idea of what I mean by explode, take a look at this:

KDE explosion in the GNOME menus

All of that comes from installing k3b. The problem is that KDE doesn’t honor the freedesktop.org Desktop Menu Specification. Specifically, KDE should be putting OnlyShowIn entries into their .desktop files that shouldn’t be displayed in GNOME. This isn’t exactly a new problem. Given the fact that kicker bug #63933 was logged in 2003 and still isn’t fixed, I figured I’d have to fix it myself.

Here’s my solution. For each .desktop file in each package specified, this script will add OnlyShowIn=KDE if it isn’t already present.

#!/bin/bash

package_list="kamera kcontrol kdebase-data kdebase-kio-plugins \
              kdemultimedia-kio-plugins libkcddb1"

for package in $package_list; do
    for desktop_file in `dpkg -L $package | grep 'applications/.*\.desktop'`; do
        count=`grep -c -i OnlyShowIn $desktop_file`
        if [ $count -eq 0 ]; then
            echo "Modifying $package: $desktop_file"
            echo 'OnlyShowIn=KDE;' >> $desktop_file
        fi
    done
done

It needs to be run with sudo or as root since it’s modifying system files. Also, the list of packages I provided are not comprehensive. They’re simply the ones that I noticed didn’t honor the specification. If you aren’t using Debian or Ubuntu, you’ll have to modify the dpkg command to the equivalent rpm command.

Use GNOME Power Manager and hal

On Debian or Ubuntu systems, install the nut-hal-drivers package.

$ sudo apt-get install nut-hal-drivers

GNOME Power Manager should already be running and should automatically detect the UPS. If it’s not running, you can start it from the command line or set it to start automatically in each session with the Sessions system preference. An icon will appear in the system tray if everything is working.

GNOME Power Manager system tray icon and tooltip.

Clicking the system tray icon and selecting UPS from the menu will give detailed information.

GNOME Power Manager UPS details.

GNOME Power Manager can be configured to shutdown or hibernate the computer when the UPS battery level drops below certain thresholds. There are also gconf keys to change which thresholds are used, percentage or time left, and what those thresholds are.

This method of monitoring a UPS is useful for a workstation, but there are three significant disadvantages:

1. GNOME Power Manager is not running when you aren’t logged in. If your machine loses power at the login screen, it will not shutdown automatically.
2. Currently, the nut-hal-drivers package only supports USB-based UPS’s. Many older and higher-end UPS’s are serial-based.
3. GNOME Power Manager’s UPS support is buggy. While it displays notifications of low battery and critically low battery, it doesn’t take any actions. See Debian bug #482431 and GNOME bug #539843.

Use nutd and upsmon

Install the nut package. This should conflict with nut-hal-drivers if it’s already installed.

$ sudo apt-get install nut

Installing the nut package, should add the nut user and group. If it doesn’t, you have to add those manually. Next, create or edit /etc/nut/ups.conf:

# /etc/nut/ups.conf

[apc]
    driver = usbhid-ups
    port = auto

The label in the square brackets can be anything. It identifies the UPS to upsd and upsmon. Find your UPS model on the NUT hardware compatibility list and substitute the corresponding driver for usbhid-ups above. If your UPS isn’t listed, find similar ones. They probably use the same driver. If you have a USB-based UPS, you can leave the port as auto; it’s ignored. Otherwise, the port will usually be /dev/ttyS0, the first serial port, or /dev/ttyS1, the second. If your UPS is connected via the serial port, you’ll need to modify the permissions on the serial port device so that nut can access it. Create the file /etc/udev/rules.d/99_nut-serialups.rules:

# /etc/udev/rules.d/99_nut-serialups.rules
KERNEL=="ttyS0", GROUP="nut"

Replace ttyS0 with ttyS1 if your UPS is connected to the second serial port. Next, issue the following two commands to force udev to make the necessary permissions change:

$ sudo udevadm control --reload_rules
$ sudo udevadm control trigger

Note that the preceding two steps are unnecessary if you have USB-based UPS. Finally, we can make sure that nut properly detects the UPS:

$ sudo upsdrvctl start

You should see something like the following:

Network UPS Tools - UPS driver controller 2.2.2
Network UPS Tools: 0.29 USB communication driver - core 0.33 (2.2.2)

Using subdriver: APC HID 0.92

Now, we need to configure upsd and upsmon. upsd communicates with the UPS driver that we just started. upsmon communicates with upsd and actually shuts down the machine in the event of a power failure. Why the extra level of indirection? Multiple instances of upsmon can be started on different machines. They can all share the same physical UPS. Create the file /etc/nut/upsd.conf as follows:

# /etc/nut/upsd.conf
ACL all 0.0.0.0/0
ACL localhost 127.0.0.1/32
ACCEPT localhost
REJECT all

This rejects all connections not originating from the local machine. If you need to monitor from multiple machines, see the man page for upsd.conf. Next, create /etc/nut/upsd.users:

# /etc/nut/upsd.users
[local_mon]
    password = PASSWORD_HERE
    allowfrom = localhost
    upsmon master

Replace PASSWORD_HERE with a real password. You should add multiple users if you are monitoring from multiple machines. See the man page for upsd.users for more information. Now we need to configure upsmon. Create /etc/nut/upsmon.conf as follows:

# /etc/nut/upsmon.conf
MONITOR apc@localhost 1 local_mon PASSWORD_HERE master
POWERDOWNFLAG /etc/killpower
SHUTDOWNCMD "/sbin/shutdown -h now"

Replace apc with the name you have your UPS in /etc/nut/ups.conf and PASSWORD_HERE with the password you set in /etc/nut/upsd.users. Since these files contain sensitive data, we should fix the permissions:

$ sudo chown root:nut /etc/nut/*
$ sudo chmod 640 /etc/nut/*

Finally, edit /etc/default/nut so that upsd and upsmon will start at system boot:

# /etc/default/nut
START_UPSD=yes
START_UPSMON=yes

The moment of truth:

$ sudo /etc/init.d/nut start

Check the end of /var/log/daemon.log to make sure everything started up. Also, you can run the following command which should print out some statistics:

$ upsc apc

Replace apc with whatever you named your UPS. What’s left? Save your work, unplug the UPS, and make sure your machine shuts down cleanly. This may take a while. By default, upsmon waits until the battery is at a critically low level before initiating a shutdown. What’s the point of having 20 minutes of battery life if you aren’t going to use it?

As you can see, this second method is quite a bit more difficult to configure. That said, using upsd and upsmon, as opposed to nut-hal-drivers, is probably the more reliable method of monitoring a UPS. It’s also the only option available if you need to monitor one UPS from multiple machines.