Prev   Next

10. Advanced FAI

10.1. Creating chroot and virtualization environments

If you have some chroot environments to install, or a virtualization environment where you neither can nor want to run a normal Debian Installer in to get to a working system (for example, Xen guest domains), there is the FAI action dirinstall. By calling

faiserver# fai <options> dirinstall <target-directory>

and using either the option -c <classes> or -N you get a FAI installation, without the partitioning action, right into the target directory. The host name for the target installation can be specified using -u <host-name>

This, for example, can be used to combine FAI with the tool xen-tools, which helps you to build Xen guest domains. xen-tools are very nice for generating configuration files and block devices for new guests based on simple commands and/or configuration files, but they can only assign one role per installation for customization. FAI-users need and want more, as they are used to have the class system. They get them even in xen-tools installations, by using the following code as a xen-tools role script:

#!/bin/sh
TARGET=$1
CMD="fai -N  -v -u ${hostname} dirinstall $TARGET"
echo running $CMD
$CMD

Then, you will want to set the variable install=0 the xen-tools config for that host (in previous versions of xen-tools, this was no-install=1).

10.2. Using FAI for updates

FAI is even usable for system updates, using the same configuration as if initially installing. System update means updating the running system without doing a re-installation. An updated client will almost look like a newly installed machine, though all local data is preserved (except of course newer configuration files introduced in the FAI config).

10.2.1. How does a softupdate work?

Softupdate use the same configuration files as a new FAI installation. They even use the default FAI commands, so they behave nearly in the same way as an installation, though some things are different:

  • By default the old list of classes (created during the initial installation) is used, so fai-class is not called to define a new list of classes. This can be changed by calling fai -N softupdate.
  • No partitioning and file system creation is performed.
  • The basesytem isn't bootstrapped.
  • FAI skips tasks only useful when installing, such as setting up a keymap or starting special daemons.
  • FAI doesn't prevent software packages to (re-)start daemons.
  • FAI doesn't reboot at the end of a softupdate.

Except these changes, things are the same as when installing a new computer:

  1. Define classes (by default use old list) and variables.
  2. Update the installed packages.
  3. Install new software.
  4. Call configuration scripts.
  5. Save the logfiles.

10.2.2. How to run a softupdate

As softupdate use the same infrastructure as a FAI installation, you even start them by using the same command fai(8) which is used for installation:

# fai -v softupdate

starts a softupdate. Make sure to set the variable $LOGSERVER (done in a class/*.var file) if fai should save the log files to a remote machine.

10.2.2.1. How to do mass softupdates

Probably you don't want to run to each client and start a softupdate there locally, so a mechanism to start an update there has to be thought of.

10.2.2.2. Cron

One possible solution is to use crontab entries on the clients to start an update, but in big installations you have to consider including a random-delay mechanism, because too many updates at the same time may produce too much traffic on your network.

10.2.2.3. Starting a softupdate remotely

If you want more control when exactly a softupdate is run on the clients and maybe want to monitor it while it is running, you can install remote root login mechanisms on your clients, preferably using ssh in connection with a authorized key for root logins.

Tools like clusterssh allow you to login onto a group of clients at once and run fai softupdate there, while the results can be seen immediately in the terminals started for each host.

10.2.3. How to write a configuration suitable for softupdate

When you want to do softupdate, you have to be even more careful when writing your configuration: it has to be idempotent, i.e. running all the scripts twice should result in the same system configuration as running them once. Some things to keep an eye on:

  • Never blindly append to files: 

    $ echo $SOMETHING >> /etc/fstab

is almost certainly wrong. Either check manually if the line already exists before appending or use the command ainsl(1). This has a similar function to cfengine's AppendIfNoSuchLine statement

  • Make use of FAI's environment variables to determine what to do in your configuration scripts! Some of the most important ones:

    $FAI_CONFIG_SRC
    is the URI of the configuration space.
    $FAI_ROOT
    points to the client's rootdir. In case of softupdate it's the root directory /
    $ROOTCMD
    contains a command for chrooting into the client. This is empty when doing softupdate (as / is already our root…).
    $FAI_ACTION

    contains the currently executed action:

    • install when installing.
    • softupdate when updating
  • Restart daemons if needed: most daemons only read their configuration when starting; if you modify it, you need to make them reload it using 
        $ROOTCMD invoke-rc.d $somedaemon reload

or even restart them

        $ROOTCMD invoke-rc.d $somedaemon restart

when the configuration for $somedaemon has been changed [9]

  • Other things like scheduling a reboot if a new kernel is installed

10.2.4. What if there are locally changed config files?

Short: there shouldn't be any!

Long: if you are using FAI softupdate to update client's configuration, you shouldn't do any local changes on the install clients, because they may be lost while updating. Backup copies are done by fcopy only on the local disk. By default, they are written to the same directory as the original file, with .pre_fcopy appended. If you want to save them together with the logfiles, add following line to your class/DEFAULT.var:

FAI_BACKUPDIR=$LOGDIR/backup

10.2.5. How to detect locally changed files?

If you are playing with local configuration changes despite all the warnings contained in this section, there must be a way to check what has been changed locally. A simple approach would be to use debsums -e, but this method fails miserably if you modify conffiles in your FAI scripts, because it only checks against the version contained in the Debian package. A better proposal is to setup/abuse tripwire(8) or integrit(1) to scan for local changes and notify you about them.


[9] You can for example use fcopy(8)'s postinst script support for doing this; if other things than fcopy modify your conffiles, you have to keep track of the changes yourself.

Prev   Next
 Home