Self-Registration Web Interface for BackupPC

This document describes:

• some advantages and disadvantages of using a web interface that allows clients to self-register and self-administer their backups using BackupPC as the server software.

• how this system works, including modifications and additions that have to made to both the server and client sides.

This project was undertaken as a test case to try out the Turbogears web development platform in preparation for a larger project. It turned out to be a fairly smooth project, but it's a little schizophrenic as BackupPC is Perl-based and Turbogears is Python-based. Nevertheless, I believe it has some value. Below I describe what the web interface does, why it does it, and what you should be aware of.

BackupPC is an Open Source, disk-based backup service written in Perl that runs on a *nix server and uses some neat features to backup specified directories on groups of computers running a variety of Operating Systems. The web interface I'm describing currently works with MS Win2K, WinXP, and WinVista (the latter with minor client-side changes)., Those are the the most popular Desktop OSs in our environment, but BackupPC also works with MacOSX and Linux and while those systems are even easier to support, they are less popular at UCI. Therefore, the web interface was initially targeted at Windows, but a new interface that includes MacOSX and Linux is underway and the mechanism for installing the client software for both those platforms is well-characterized and considerably simpler than with Windows.

BackupPC is useful for short-term backups - up to months - to prevent catastrophic loss of data if the client disk crashes or if the PC walks away (increasingly more likely with more people using laptops). In our environment, it is especially targeted at researchers whose entire intellectual corpus may be on their hard disk - their publication record, email, lab & personnel records, scientific results, presentations, and especially their in-progress grants. The loss of this data really would be quite serious.

After personally using BackupPC for a while, I very much like the architecture and performance (even with multi-user servers), was very impressed by the protocol options, and REALLY liked that clients could restore their backups by themselves, but was concerned that it was too complicated for a mere human to install on a Windows machine. Hence this Web interface.

3.1. The short version

3.1.1. For Windows (2k, XP, Vista)

• Fill out the web interface.

• Click the submit button.

• You get an email with a 1MB zip file containing the entire installation (usually*).

• Unzip the zip file to create C:\rsyncd

• cd into the C:\rsyncd directory.

• run the installation batch/bat file.

• That's it (usually*).

3.1.2. For MacOSX & Linux (very soon)

• Fill out the web interface.

• Click the submit button.

• You get an email with a small zip file containing the entire installation (usually*).

• unzip it into a temporary dir

• run the installation shell script as sudo root

• That's it (usually*).

* Due to individual configuration changes wanted, non-standard firewall configuration, and occasional missing DLLs, about 1/5 of the installs done so far have required intervention or correction. As we install on more clients, we will get a better idea of what the usual configuration state is. Also, some email systems will strip zip files from emailo attachments due to security concerns. This transfer can be re-written to email only the URL, and login info to download the same zipfile from the server.

3.2. The long version

3.2.1. For Windows (2k, XP, Vista)

Windows is the most troublesome platform, but the following also describes the approach for MacOSX and Linux clients.

• Fill out the form

  • Agree to the Service Level Agreement (SLA - a strawman version is included)

  • Fill in the IP and client hostname of the registering computer. The form auto-populates the values via a host lookup, but they can be erased and filled in with other values if a computer support person is filling out the form for others. If the IP of the client is set dynamically, the user is asked to set a uniquely identifying hostname NOTE TO SELF: which must be checked before being used. Many DHCP hostnames refer to network and IP number (dhcp-125.english.uci.edu) whereas we want one that we can use to map it more uniquely, perhaps a combination of username and favorite pet/movie/book/city (churchill_fluffypoo.english.uci.edu).

  • Whether the PC IP assignment is static or DHCP. If DHCP is selected, additional functionality is added to the client package to track changes in the assigned IP, so the machine will continue to be backed up even if its IP changes. NOTE TO SELF: maybe this option should be moved above the preceding one? Also, is it possible to portably test whether this is the case?? checking /etc/network/interfaces on Linux?

  • what Operating System and Version to support. Currently, the only distinction that matters is Win2K, WinXP and Vista ( Any server-side differences between Vista and XP? ). The new interface offers the 2 most recent versions of MacOSX (Tiger and Leopard) and several Linux distributions (altho whether different versions will be necessary remains to be seen).

  • What directory you want backed up. For Windows, you have restricted options. Either you can back up your existing C:\Documents and Settings or C:\Users dirs or choose C:\Data or C:\Backup. This is to prevent you from choosing the entire C:\ drive, which in most cases is mostly Applications and Operating System files. The point is not to back up all files, but only those that cannot be easily replaced. For MacOSX and Linux, you can choose the directory, but do so carefully. For multi-user machines, the /home and /etc directories are recommended, but note that ALL files not explicitly excluded will be backed up. Examine the rsync.exclude file carefully.

  • Provide contact info, and a login name/password to interact with the server. You can use your UCINetID, but don't use the corresponding password. Only [a-zA-Z0-9_] are allowed for for logins. DO NOT use a full email address (@ will cause problems - NOTE TO SELF: this should be checked on submission).

  • Click the Submit button. If anything was wrong, you get sent back to the registration page to correct it; if everything was fine, you get a "Thank You" confirmation notice. NOTE TO SELF: don't re-check the host lookup - if the user changed it, don't change it back. But do an nslookup on it to see whether it's a real one or not (if it's a DHCP address).

• After a few minutes, you get an email with a 1MB zip file containing the entire installation and complete instructions in text and HTML.

• Unzip the file to create C:\rsyncd (or ~/rsyncd on MacOSX and Linux)

• Browse or cd into the rsyncd directory.

• Run the installation script (winXP_install_rsync.bat on Win; install_LinMac_backuppc_client.sh on Linux/MacOSX) file. You will be prompted for an administrator password to install the scheduled task - this may be a problem if you don't have admin privs on your own machine.

• That's it. Once the server has validated your information, it automatically updates the BackupPC files and within 24 hours your PC should be automatically backed up, unless you log in before then and request an immediate backup (recommended).

3.2.2. For Linux Client

We assume that each Linux client has a recent, working rsync executable. If it doesn't, the installation script will tell you to install it and then you can rerun the script again.

For each Linux client, the server needs to generate 3 files:

• rsyncd.conf (generated from the form input)

• rsyncd.secrets (generated from form input (backuppc_user:plaintext_password)

• rsyncd.exclude (optional, copied from a single multiplatform version)

The backuppc client runs under a regular user UID so it can only read things that it should - sensitive system files cannot be read (altho sensitive user files can be if they are not explicitly excluded). If the backup needs exceptions, they should be made by manipulating the appropriate group in /etc/group.

The rsyncd.* files above should have the following permissions:

-rw-r--r-- 1 root root  987 2008-06-18 08:23 rsyncd.conf
-rw-r--r-- 1 root root  357 2008-06-18 08:23 rsyncd.exclude
-rw------- 1 root root   52 2008-10-15 15:07 rsyncd.secrets <== NOTE!!

The rsyncd.conf file defines how the different backup modules or shares are backed up.

Here's the rsyncd.conf file that will back up an entire /home dir on Linux or MacOSX

# GLOBAL OPTIONS
log file=/var/log/rsyncd
pid file=/var/run/rsyncd.pid
# the following line 'auth users' is not a real login user.  This is the ID that the
# rsync server and client have agreed to use to allow rsyncs back and forth.
auth users = user_from_form

# the 'secrets file' contains the CLEARTEXT passwords of the 'auth users' group
# so it MUST NOT be readable by everyone.
secrets file = /etc/rsyncd.secrets
# the 'dont compress' line contains regexes for files that should not be compressed
dont compress = *.gz *.tgz *.zip *.z *.rpm *.deb *.iso *.bz2 *.tbz *.exe

# MODULE OPTIONS

[home]
        comment = The complete /home dir (all users)
# Note that everything in /home will be read by the uid defined
# below. If that user doesn't have sufficient privs, the backup will just
# skip the file/dir. Adjust required privs to the user by adding that user
# to an appropriate group in '/etc/group'
        path = /home
        use chroot = no
        max connections=1
        lock file = /var/lock/rsyncd

# the default for read only is yes...
        read only = yes
        list = yes

# the uid/gid should be that of a regular user so we don't accidentally read private data
        uid = backuppc
        gid = backuppc

# this sets a universal exclude, but each Module (or share) can have its own exclude file.
        exclude from = /etc/rsyncd.exclude
        strict modes = yes
# 1st we deny all hosts
        hosts deny = *
# then allow ONLY the BackupPC server.  Files will be read only if
# 1 - a request comes from the BackupPC server IP
# 2 - the auth matches
# 3 - an rsyncd (with the correct auth) is running on the client
# 4 - the files have ownership and privs that allows the backuppc user to read them
        hosts allow = ###.###.84.82
        ignore errors = no
        ignore nonreadable = yes
        transfer logging = yes
        timeout = 600
        refuse options = checksum dry-run

• as noted above, if you submit a User ID that is an email address or contains the @ character, everything will appear to install, but the rsync connection will fail. This must be checked on the server side at Submission time.

• in a few cases on WindowsXP, the netsh script that is executed to set up the firewall parameters will fail, citing the absence of framedyn.dll. This Dynamic Link Library should be present on all Windows machines but sometimes the search path has not been set to include it. This Microsoft page tells you how to address this.

• if you change, move, rename, or delete the files rsyncd.conf or rsyncd.secrets file, the backup may fail due to configuration and/or authorization problems. If you know what you're doing, you can change your configuration to be more to your liking, but make copies of these files before you edit. To prevent backing up confidential files, you can edit the file rsyncd.exclude which defines file types to ignore (files matching the patterns therein will NOT be backed up).

• If you selected C:\Data or C:\Backup as the target directory and did not create them before the backup is initiated, then (unsurprisingly) the backup will fail.

Once the client software is installed, you can either wait for the server to initiate a backup or you can log into the BackupPC web admin page and initiate a backup yourself (advised). The 1st run will do a complete backup of the requested directory tree, taking a time proportional to the size of the directory. Successive backups will take time proportional to the changed files (the backup protocol is rsync).

As an example, my home dir is about 43GB, but after subtracting mp3s, pictures, and Virtualbox partition, there are only about 12GB to be backed up, which took about 35m. The time taken to do an incremental backup was less than 2 min over a 100Mb connection, most of that time exchanging rsync comparison data.

The slowdown on my system (a 1.6GHz, 2core laptop) when doing the backup is almost undetectable unless I'm doing a lot of other disk activity.

• If you make an error filling out the registration page, you are returned to the original registration page and the form again auto-populates the client PC IP # and hostname of the PC from which you're working, even if you've set it to something different the 1st time. Bug or feature?

• One login name can be used to create packages for other PCs, but you can't create multiple packages for one PC. This is a feature - if we allowed this, anyone could essentially delete a PC from the backup schedule. If you need to delete a PC and start over, an administrator has to step in to delete the PC from the database. This is one of the few times administrative intervention is needed.

• If one login is used to set up multiple PCs, that login is the only one allowed to self-administer the PCs via the normal BackupPC web interface. This was done to allow a group administrator to oversee a number of PCs with one login. This feature should be used only if the regular user is unable or unwilling to do it.

7.1. Owners and Permissions

BackupPC normally runs under a non-root user and group (normally backuppc for both) and stores its configuration files in /etc/BackupPC. Because of the web interaction, the backuppc group must include the web user (often www-data) so the cgi script can write new configuration files into that directory. The additional options that the web form allows requires some additional directories to be created in the root (/etc/BackupPC) dir beyond those created by a standard BackupPC installation

7.2. Handling Dynamic IPs

An increasing number of people are using laptops as their main computer. Such machines often connect using dynamic IP assignment (DHCP) so that their IP number can vary from day to day.

The feature that allows BackupPC to back up even such roving PCs requires the creation of a new directory (/etc/BackupPC/alive) to hold the periodic IP updates. This directory is populated by the client machines periodically sending their current IP #s to the server via a restricted, constricted (low bandwidth connection) rsyncd process running on the server.

On MacOSX (M) and Linux (L), if the client is registered as DHCP, it will get a few additional bits of code that

• adds a line to the crontab to run the update script (imalive.py)

• imalive.py generates a tiny, uniquely named file that contains the current client IP #

• imalive.py sends that file back to the server via rsync.

Every X minutes (15 is the default), the server runs a cron script that checks to see if any DHCP info has changed and if so, stream-edits it into the server's /etc/hosts file between identifying fencepost markers, as below

     20 #### BackupPC hosts BEGIN - DO NOT MODIFY THIS LINE ####
     21 ###.###.###.147    flip.xxx.uci.edu        flip
     22 ###.###.###.231   jackrabbit.xxx.uci.edu  jackrabbit
     23 ###.###.###.148    flop.xxx.uci.edu        flop
     24 ###.###.###.8      tatry.xxx.uci.edu      tatry
     25 ###.###.###.144    flipper.xxx.uci.edu     flipper
     26 ###.###.###.31    haggis.xxx.uci.edu      haggis
     27 ###.###.###.211    mmg-dhcp77.xxx.uci.edu  mmg-dhcp77 < 'real' hostname=fredo
     28 #### BackupPC hosts END - DO NOT MODIFY THIS LINE ####

These entries, being in the /etc/hosts file, pre-empt the official hostname <-> IP mapping of the client machine. This should bypass the requirement of making up a unique hostname, but may saddle the user with a hostname that no relationship to the name that the user gave it or thinks of it as (see fredo example above).

We may be able to address this with more sophisticated web forms, but for now, I'm going to just keep the DHCP-supplied hostname and have the user make one up that will be used here.

BackupPC and our web interface to it are not highly secure. They are meant to provide Backup services in a fairly protected environment (local networks, not Enterprise WANs) Because of this, the default configuration provides for reasonable security but not full end-to-end encryption and encrypted storage. A determined, talented attacker should be able to read BackupPC data over the wire, but over modern switched wired networks this should not be trivial. Note that for security and bandwidth constraints, wireless networks should not be used as a communication channel for BackupPC. We can certainly add ssh encryption to the protocol, but it's not being done now.

Because our implementation of BackupPC uses rsync as the transfer protocol, any security weakness of rsync also applies to BackupPC.

The web registration form constrains Windows clients to use the C:\Documents and Settings directory or a (probably) new C:\Data or C:\Backup dir in part to make them copy data to that dir to be backed up so that they will not inadvertantly back up sensitive data. The current exclude list lists the default file types that are excluded.

The client-side configuration files included with the installation package allow an interested client to manipulate many of the rsyncd parameters. She could increase the directories to back up, enable backing up normally excluded files (such as her MP3 collection, tax returns, and in fact her entire disk, OS included.) However, this would show up on a quota scan and the BackupPC administrator could suspend her backups and/or delete her stored backups.

The imalive.py script sends small files back to the server via an bandwidth-constrained (1kB/s) rsyncd process. A normally registered, but malevolent client could configure his client to send a stream of data back to the server to slowly fill up the root file system and therefore crash the server. At this point in the development process, I haven't added a check for that (is the imalive dir larger than X bytes), but it could easily be added to the imalive.py script.

These Q&As are answered to the best of my ability. Please correct them if you find an error or mistaken assumption.

• a unix-like OS. BackupPC runs on BSD & Solaris, but most instances run on Linux. The current Long Term Support Ubuntu distribution of Linux (8.04) is what we're using.

• root privs on the server.

• reliable storage - most users use at least RAID5 (preferably RAID6) to provide some redundancy to the storage. It should be noted that BackupPC is not typically used for long term or archival storage so it does not require elaborate multi-level storage systems.

• enough hard disk space to store the client files. BackupPC is fairly efficient about pooling files, but you should assume about 2 times the amount of disk space for each client due to incremental backups and overhead.

• sufficiently fast network connections to service the clients. You may want to use multiple interfaces to enable connections to multiple networks simultaneously.

• the apache web server to provide BackupPC services (requests for file restores, initiating off-schedule backups, etc).

• a recent version of BackupPC installed and verified that it can back up a client or two.

• the Python & a recent Turbogears 1.x runtime requirements to handle the registration form

  • python version 2.3 or greater

  • cherrypy

  • kid templates

  • SQLAlchemy

  • SQLite3

• the todos utility to convert unix End-Of-Lines to DOS.

• the WebBUPC package, either as a tarball or pulled from the Subversion repository.

I'm going to assume that you're using the Ubuntu 8.04 LTS release.

• Install in order, apache2, backuppc, python, python-turbogears, sqlite3

• the backuppc user should be created when you install backuppc, but if not, create it.

• add the www-data user to the backuppc group.so the cgi can write to the backuppc-owned dir.

• configure the backuppc instance to use rsync, rest of configurations (include local config file) with the package & add it to backuppc dir of SVN.

• download the webbupc pkg or pull from SVN.

• unpack the WebBUPC tarball or move it to it's final resting place.

• use supplied BackupPC.config as template to configure the BackupPC server.

• change the server IP number and port in dev.cfg and start the form server to answer requests on the port you've requested.

• create the appropriate subdirs in /etc/BackupPC. the ones needed are:

  • alive holds the most current info for the DHCP-allocated IP#s. The file names indicate the hostname and user of the machine. The contents of each file is the naked IP number of the host.

  • backup simply contains backups of files that get changed automatically, in case something goes wrong and I have to restore the info.

  • pc is a standard BackupPC directory that contains customized configuration lines (as Perl code) for each client.

  • NB: the backuppc user below is completely separate from any login user. it is the username that the user chooses when filling in her webbupc form (possibly their UCINetID) The rsyncd.conf file requires the "auth users = xxxxx" line to refer to that user, the same one as in the rsyncd.secrets file, with the same passwd.