APC make some great UPS products and they all have the ability to communicate with a host PC to advise of its state, eg: on mains, on battery, fault, etc. The support software is available aplenty for Windows and Mac, but what about Linux?

This guide will show you how to hook up an APC UPS to an Ubuntu-based Desktop or Server PC and allow your UPS to email you when mains power has failed, when mains power has been restored, and also give your PC ample opportunity to shutdown when battery on the UPS gets to a critical low.

Pre-requisites:

• Ubuntu-based PC. I am using Ubuntu 10.04 Lucid Lynx in this guide.
• An APC UPS. I’m using a Back-UPS RS 800 in this guide.
• Details about your ISP’s mail server, or your own local mail server.

Configuration:

1. Setup your APC UPS as outlined in the instruction manual. Ensure that the USB or serial cable is connected from the UPS to the PC. This is what the UPS uses to communicate with the PC.
   .
2. On your Ubuntu PC, go into a Terminal. If you are using Ubuntu Desktop, you can do this by going to the Applications menu, then Accessories and then Terminal. If you are using Ubuntu Server, simply login to your server by the console or SSH in remotely.
   .
3. The Ubuntu repositories contain a UPS daemon specifically designed with APC UPS units in mind called APCUPSD, so let’s install it:

   $ sudo apt-get install apcupsd

4. Once installed, we need to configure it to suit your UPS. Bring up the configuration file by typing in:

   $ sudo nano /etc/apcupsd/apcupsd.conf

5. In the editor, scroll down to UPSNAME and give the UPS a name, eg:

   UPSNAME MyAwesomeUPS

6. Scroll down to UPSCABLE and change the parameter to the type of cable you are using to connect to your UPS. In my case, I use a USB cable that came with the UPS, so I changed this line to read:

   UPSCABLE usb

7. The next line to modify is the UPSTYPE line. Again, because I’m using USB I specify:

   UPSTYPE usb

   If you have a DEVICE /dev/ttyS0 line after the UPSTYPE line, comment it out by adding a hash symbol at the start of the line like so:

   #DEVICE /dev/ttyS0

8. We do not need to modify anything else, so press CTRL+X, then “Y” and then Enter to save your changes and exit the Nano text editor.
   .
9. Now we need to tell the system that the UPS daemon has been setup and is essentially ready to go. Type in:

   $ sudo nano /etc/default/apcupsd

10. In the file that appears, modify the ISCONFIGURED line to say Yes”, ie:

    ISCONFIGURED=yes

11. Press CTRL+X, then “Y” and then Enter to save your changes and exit.
    .
12. We’re pretty much done here. Start the daemon now with the following command:

    $ sudo service apcupsd restart

    …or simply reboot your PC. Your PC is now monitoring the state of the UPS.
    .

13. Let’s check the UPS now. Type in the following command:

    $ apcaccess

    …and you will get output similar to the following:

    $ apcaccess
    APC      : 001,043,1045
    DATE     : Tue Feb 01 00:02:36 EST 2011
    HOSTNAME : lamaar
    VERSION  : 3.14.6 (16 May 2009) debian
    UPSNAME  : LAMAAR
    CABLE    : USB Cable
    MODEL    : Back-UPS BR  800
    UPSMODE  : Stand Alone
    STARTTIME: Mon Jan 31 23:43:37 EST 2011
    STATUS   : ONLINE
    LINEV    : 250.0 Volts
    LOADPCT  :  40.0 Percent Load Capacity
    BCHARGE  : 100.0 Percent
    TIMELEFT :  19.9 Minutes
    MBATTCHG : 5 Percent
    MINTIMEL : 3 Minutes
    MAXTIME  : 0 Seconds
    OUTPUTV  : 230.0 Volts
    SENSE    : Medium
    DWAKE    : 000 Seconds
    DSHUTD   : 000 Seconds
    LOTRANS  : 194.0 Volts
    HITRANS  : 264.0 Volts
    RETPCT   : 000.0 Percent
    ITEMP    : 29.2 C Internal
    ALARMDEL : Always
    BATTV    : 27.4 Volts
    LINEFREQ : 50.0 Hz
    LASTXFER : Low line voltage
    NUMXFERS : 0
    TONBATT  : 0 seconds
    CUMONBATT: 0 seconds
    XOFFBATT : N/A
    SELFTEST : NO
    STATFLAG : 0x07000008 Status Flag
    SERIALNO : xxxxxxxxxxxx  
    BATTDATE : 2001-09-25
    NOMOUTV  : 230 Volts
    NOMINV   : 230 Volts
    NOMBATTV :  24.0 Volts
    NOMPOWER : 540 Watts
    FIRMWARE : 9.o5 .I USB FW:o5
    APCMODEL : Back-UPS BR  800
    END APC  : Tue Feb 01 00:02:41 EST 2011
    $

14. Pat yourself on the back, you’re basically done.

But hang on, what about setting up email notifications? Read on.

Setting up Email Notifications

By default, APCUPSD is configured to use sendmail to send emails, but sendmail is finicky. There is a better way using a similar application called sendemail instead.

Why use sendemail instead of sendmail? Well, sendemail is a simple command-line SMTP client. You construct a simple message with a recipient and off it goes, but the key difference here is that sendemail is a CLIENT, not a SERVER. This means for sendemail to work, you need a third-party mail server to send it through. You may already have a mail server on your network running Postfix or similar. If not, your ISP will most certainly have one that you can use.

1. Let’s start by installing sendemail:

   $ sudo apt-get install sendemail

2. Now we need to configure apcupsd to use it. If you have a look inside the /etc/apcupsd directory, you will see several important files as follows:
   • changeme – notifies you if the UPS battery needs changing.
   • commfailure – notifies you if the PC loses communication with the UPS.
   • commok – notifies you if lost communication is restored with the UPS.
   • onbattery – notifies you if the UPS engages battery mode due to mains power failure.
   • offbattery – notifies you if the UPS returns to mains mode after a mains power failure.
     .
3. Let’s modify the onbattery message:

   $ sudo nano /etc/apcupsd/onbattery

4. You will notice there are some lines in this file that define some variables followed by a message and then finally a command that sends an email using the sendmail app. Since we are not using sendmail, we need to modify a number of areas. Replace the content of the entire text file with the following:

   #!/bin/sh
   #
   # This shell script if placed in /etc/apcupsd
   # will be called by /etc/apcupsd/apccontrol when the UPS
   # goes on batteries.
   #
   SYSADMIN=jbloggs@mydomain.com.au
   APCUPSD_MAIL="/usr/bin/sendemail"
   HOSTNAME=`hostname`
   MSG="Ubuntu PC Power Failure !!!"
   #
   (
   echo " "
   echo " ====================================="
   echo " POWER FAILURE ON $HOSTNAME !!"
   echo " ====================================="
   echo " "
   echo " The UPS on your Ubuntu PC has experienced a power problem that has required the UPS to engage battery mode."
   echo " "
   echo " Do not panic! Remain calm..."
   echo " "
   echo "Current UPS status:"
   echo " "
   /sbin/apcaccess status
   ) | $APCUPSD_MAIL -u "$MSG" -f MyUbuntuPC@mydomain.com.au -t $SYSADMIN -s mail.myisp.com:25
   exit 0

   So what have we done here? The first part of the file sets some variables, namely the email address(es) of the people required to be notified. If you need to send to more than one recipient, separate email addresses with a comma, eg:

   SYSADMIN=jbloggs@mydomain.com.au,fredsmith@thatotherdomain.com

   We then define the path to the sendemail app, the hostname of the PC running the UPS daemon, a subject line for the email in question, and then a big email body explaining what’s going on, in this case that the UPS battery mode has been engaged.

   All this is then piped into the sendemail application with a fake sender’s address to give you an idea where it came from and we also specify the mail server that the email will be sent via. In this case, we are using our ISP’s mail server that has the address mail.myisp.com
   .

5. Save your changes by pressing CTRL+X, then “Y” and then Enter.
   .
6. You can now test the script by simply executing it (we don’t have to disconnect the UPS’ mains cable to trigger this until we’re ready to test that). Execute the file using the command:

   $ sh /etc/apcupsd/onbattery

7. Check for any errors and then check to see if you got an email in your mailbox advising that the UPS is on battery (the UPS of course is not, we’re just testing the email).
   .
8. If all is well, continue to change the other four message files to be similar to the above, changing the message as you go of course.
   .
9. Pat yourself on the back – you now have custom, explicit messages to let you know what’s going on with the UPS.

Setting up your own mail server to use instead

If, in your testing, you discover that your ISP’s mail server does not allow you to randomly spam messages to it using fake from addresses, you have two choices – either specify a valid email address as the sender’s address, or you can setup a simple email server of your own using Postfix:

$ sudo apt-get install postfix

In the case of setting up your own email server, simply go with Postfix and set it up as an “Internet Site”. The basic configuration is good enough to deal with our needs, but make sure your basic network security is adequate to prevent outsiders from trying to use your mail server to send unsolicited mails, or spam, through it.

This article will not describe how to setup or secure Postfix as it is beyond the scope of this article, however you do need to modify the outgoing mail server name in all your communication messages to reflect the change of name or internal IP address of your mail server instead of mail.myisp.com.

Testing

You can test your daemon setup easily enough by doing any of the following:

• Remove mains power cable from UPS.
• Remove the USB cable to the UPS.
• Verify that an email is sent for either of the error conditions above.

Enjoy!

The machine starts up fine, but when you try and hit the network, you can’t. Closer inspection using the ifconfig command reveals that there is no “eth0″ adapter configured. Why?

Here’s how to fix it.

Ubuntu Server keeps tabs on the MAC address of the configured ethernet adapter. Unlike Ubuntu Desktop, you can’t simply change network cards willy nilly – while Ubuntu Server does detect and automatically setup new cards, it won’t automatically replace any adapter already configured as eth0 with another one, so you need to tell Ubuntu Server that you no longer need the old adapter.

This problem can also appear if you have a virtual machine such as one from Virtualbox, and you move or copy it from one host to another without ensuring that the MAC address configured for that VM’s ethernet adapter is 100% identical to the previous one.

These instructions were done with Ubuntu Server 9.04 Jaunty Jackalope in mind, but should apply to just about any release.

1. Since you can’t SSH in, you will need to login directly on the Ubuntu Server console as an appropriate user with sudo rights.
   .
2. Once logged in, type in the following and hit Enter:

   $ sudo nano /etc/udev/rules.d/70-persistent-net.rules

3. You are now presented with the Nano text editor and some info that looks similar to the following:

   # This file was automatically generated by the /lib/udev/write_net_rules
   # program, run by the persistent-net-generator.rules rules file.
   #
   # You can modify it, as long as you keep each rule on a single
   # line, and change only the value of the NAME= key.
   
   # PCI device 0x8086:0x1004 (e1000)
   SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="0a:03:27:c2:b4:eb", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

4. Delete the last two lines or simply comment out the SUBSYSTEM line on the end. This is a rule defining what MAC address should be explicitly assigned to “eth0″. Since you no longer have an ethernet card with the specified MAC address in this machine (it’s on the old PC, remember), Ubuntu Server effectively ignores your new ethernet adapter because its MAC address does not match the defined rule for “eth0″.
   .
5. Once you’ve made your changes, press CTRL + X and then Y and then Enter to save your changes.
   .
6. Now reboot your box with:

   $ sudo reboot

7. Upon reboot, Ubuntu Server will detect the “new” ethernet adapter in your PC and will automatically write a new rule into the /etc/udev/rules.d/70-persistent-net.rules file, thus enabling networking over eth0 for your server.
   .
8. To verify that the new adapter is working, type in:

   $ ifconfig

   …and you should see eth0 now listed with your defined IP address.
   .

9. Test remote connectivity to the server and if all is well, then pat yourself on the back. You’re done.

You’re probably thinking “why the hell would anyone want to do that?!”… well, the fact of the matter is you sometimes come across a client who is just too mind-set and refuses to use anything but Windows, so yes – sometimes you need to restore the Windows MBR, but how do you do that when you don’t have a Windows CD handy?

Well, here’s how to do it using nothing but an Ubuntu 9.10 (or later) LiveCD.

It’s a little known fact that the Windows bootloader is nothing special. In fact it contains nothing proprietary to Windows at all. All the Windows bootloader does is simply look for the partition marked as “bootable” or “active” and transfer control of the boot process to it.

And would you know it? The Ubuntu LiveCD has a binary image of a generic open source bootloader that does just that!

1. Boot your soon-to-be-Windows-only machine using the Ubuntu 9.10 (or later) LiveCD. Doesn’t matter if it’s the 32-bit or 64-bit version.
   .
2. Once booted on the LiveCD, open a terminal by going to the Applications menu and then choose Accessories and then Terminal.
   .
3. Find out what the designation of the Windows drive is (generally it will be the first drive, eg: /dev/sda or /dev/hda). If you are not sure, issue the command:

   $ sudo fdisk -l 

   …and review the output, looking for your NTFS Windows partition. Make note of the drive that partition resides on (not the partition itself), eg: “/dev/sda”, not “/dev/sda1″.

    

4. Now type in the following (remembering to substitute the correct drive device name for your setup in place of “/dev/sda”):

   $ sudo dd if=/usr/lib/syslinux/mbr.bin of=/dev/sda

   …which will write the image of a standard MBR contained in the /usr/lib/syslinux directory of the LiveCD environment to the first hard-drive, overwriting GRUB. WARNING: Do NOT use a partition designation, eg: “sda1″ or “sda2″, etc. This will overwrite the start of that partition which will effectively destroy data. The MBR exists at the start of the drive only, so only specify “sda” with no number on the end.

    

5. Shutdown and reboot. Windows should now start “natively” without GRUB appearing at all.
   .
6. Normally I’d say “pat yourself on the back” here, but it’s Windows…

Like most people, I use an external hard-drive to backup data to, or to shift things around if I’m low on space on my PC’s internal drive. Well, today that external drive reported that it was full. Damn.

So I fire up Ubuntu’s Disk Usage Analyser, aka Boabab, to find out what’s consuming the most space. I use a 1TB external drive and it’s formatted total is about 916GB, which is about right, however Boabab reported that the total consumption of data on the drive only added up to about 860GB – wtf? Even Nautilus’s Volume Properties window was reporting that the drive still had 50GB-odd free, so why is the system telling me it’s full?

I use Ext3 on my drives and, being a journalled filesystem, some space on the drive is reserved to record these journals among other functions which is expected, but 50GB worth? I did some research and found out that the Ext3 filesystem reserves 5% of disk space by default for itself! In this day and age of large drives, that’s a huge chunk of lost space!!

Thankfully there is a way to tell Linux not to reserve so much space. Read on…

1. First up, unmount your drive. You can do that by either right-clicking on the drive icon on the desktop and choosing “Unmount volume” or by clicking on the Eject icon next to it in the Places pane of any Nautilus window.
   .
2. Next, open up a terminal and type the following:

   $ sudo fdisk -l
   

   This will list all your available drives. Identify which one is your external drive and take note of the device name, eg: in my case my external drive appears as /dev/sdb with one partition on it, sdb1.
   .

3. Now type in the following:

   $ sudo tune2fs -m 1 /dev/sdb1
   

   This will modify the filesystem on that drive, on that one partition, to only reserve 1% instead of the default 5%.
   .

4. Now re-mount your drive by clicking on its name in the Places pane in a Naultilus window.
   .
5. The Nautilus Device Properties window will still show the same free space as before, because it reports the true total free space, but any Nautilus File Manager window only reports usable free space, which in the case of my external drive had now freed up a very sizable 37GB!
   .
6. Lather, rinse, repeat on any other non-system drive partitions on the same or different drive you want to reclaim space back for.

You learn something new everyday.

• Backup to an image file
• Clone to another hard-drive (eg: building multiple identical workstations) either directly or via an image file
• Data recovery (it’s safer and easier to examine an image file than risk further damage to the hard-drive itself)

Linux has a neat little command that can do this for us called simply “dd”. It is completely filesystem independent, so you can backup any hard-drive regardless of whether it was Linux formatted, Mac formatted or Windows formatted. It copies the drive bit by bit, sector by sector, not file by file.

WARNING: The following article describes commands that can destroy the information on your hard-drive with next-to-no-chance of being able to rescue what’s left. Make sure that you have full backups of your data prior to using these commands. You use these commands at your own risk!

First up, your drive/partition being backed up or written to should be unmounted before you begin. If you were trying to backup the partition containing your system’s root filesystem, you should boot up your system on a LiveCD so you can access your root partition unmounted.

You then need to determine which drive or partition you want to backup. Easiest way to do this is to fire up a terminal session and type in:

$ sudo fdisk -l

…which will list all your drives, their partitions and sizes. Note down the device name of the drive or partition you wish to backup, eg: /dev/sda for the whole of your first drive or /dev/sda1 for just the first partition of that drive, and you’re ready to begin backup.

At its simplest, backing up a drive takes two basic parameters – input device and output device or file as follows:

$ sudo dd if=/dev/sda1 of=/dev/sdb1

…will copy the content of the first partition on drive sda to the first partition of drive sdb (destroying whatever was in /dev/sdb1 previously).

$ sudo dd if=/dev/sda1 of=~/mybackup.img

…will copy the content of the first partition on drive sda to a file called mybackup.img in your Home directory.

If you wish to backup an entire drive rather than just a partition, drop the number on the drive name, ie: /dev/sda1 becomes /dev/sda instead.

To restore the image to a drive, simply reverse the parameters:

$ sudo dd if=~/mybackup.img of=/dev/sda1

How simple is that? The only issue with this method of backup, though, is that if you were to backup a 10GB partition containing only 5GB of actual data, the resulting image file will still be 10GB as dd does not simply copy active data from the drive, it copies everything.

So with that in mind, let’s compress the image, so any empty space on the drive doesn’t take up unnecessary space in the image file. We can do this by piping the data from dd into gzip before writing it to a file:

$ sudo dd if=/dev/sda1 | gzip -9 > ~/mybackup.img.gz

…and to restore, we simply pipe the decompressed data into dd again for writing to the drive:

$ gunzip -c ~/mybackup.img.gz | sudo dd of=/dev/sda1

But wait! There’s more!

This just scratches the surface of what you can do with dd. For example, you can also use dd to destroy a drive’s content before you dispose of, or sell the drive by using the following:

$ sudo dd if=/dev/random of=/dev/sda1

…which will write random data to the partition sda1 using the virtual random device, completely obliterating it.

Or, if you want a more uniform destruction, try:

$ sudo dd if=/dev/zero of=/dev/sda1

…which will – no surprises here – write zeros across the entire partition.

Or perhaps you have a drive that isn’t playing nice, for example Microsoft Windows can get stroppy when working with, or removing partitions created by a foreign OS. The easiest way to fix this is to simply destroy the Master Boor Record (MBR). You can achieve this by specifying a blocksize parameter. The MBR is inside the first 512 bytes of the drive, so all we have to do is blank those 512 bytes out using:

$ sudo dd if=/dev/zero of=/dev/sda bs=512 count=1

The bs parameter specifies the block size in bytes (in this case 512) and the count parameter specifies how many blocks of 512 bytes we’re doing (only one in this case, the first 512 bytes of the drive where the MBR resides).

Any PC will now view this hard-drive as a brand new, never partitioned drive.

Rescuing a dying hard-drive

The dd command is particularly useful for recovering data on a drive that’s about to become a paperweight. As long as it can power up and identify itself to the system, you can attempt data recovery by taking an image of the drive and then try to recover the files from that image.

Since dying hard-drives are typically sown with errors, we need to tell dd to ignore them and keep pulling as much data off as possible. Taking our first imaging example, we add a couple of parameters to the command as follows:

$ sudo dd if=/dev/sda of=~/mybackup.img conv=noerror,sync

This will make a full backup of all partitions on drive /dev/sda to a file called mybackup.img in your Home directory, and the conv parameter tells dd to ignore any errors found during the read by skipping over them. The sync parameter tells dd to replace the errors with null values – blanks – so that the resulting image file is the same data length as the drive.

Once the backup is complete, you can then mount the image to view its content. As long as the MBR (the first 512 bytes of the hard-drive) were not damaged, you will be able to now recover most, if not all your files, without worrying about further failure to the drive or odd behaviour due to the physical errors on the drive itself.

To mount the image file, you do the following. First we need a mountpoint – a place to reference the mounted image volume:

$ mkdir /dev/shm/myrecoveryimage

This creates a directory called “myrecoverytimage” in your system’s RAM drive. Before you point out that you have less physical RAM than the capacity of your hard-drive, don’t worry – this is just a mount-point. The image will still be physically read from wherever you put it on another drive.

Now we mount the image. Let’s say we backed up a standard Linux ext3-formatted drive:

$ sudo mount -t ext3 -o loop ~/.mybackup.img /dev/shm/myrecoveryimage

…or for a Windows NTFS formatted backup image:

$ sudo mount -t ntfs -o loop ~/.mybackup.img /dev/shm/myrecoveryimage

We have told the system to mount an image file of filesystem type Ext3 (or NTFS). We have to specify the loopback device because an image file is not a block device like a hard-drive is. We then specify the filename of the image we are wanting to mount, and finally where we are mounting it to.

You can now simply switch over to the mountpoint directory and see the content of the image file as though it were any normally mounted hard-drive.

$ cd /dev/shm/myrecoveryimage
$ ls -l

There are a plethora of filesystems that the mount command can manage including FAT, NTFS network filesystems etc. Refer to the man page for the mount command for more details.

When you have finished with the image, you can unmount it with:

$ sudo umount /dev/shm/myrecoveryimage

…and that will make the /dev/shm/myrecoverimage directory revert back to an ordinary empty directory again (which, being in the RAM disk, will be lost when you reboot).

Happy dd’ing!