[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ next ]

FAI Guide (Fully Automatic Installation)
Chapter 10 - Advanced FAI

10.1 Installing into a mounted directory for chroot and virtualization

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

     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

in 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?

Softupdates 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:

Define classes (by default use old list) and variables.

Update the installed packages.

Install new software.

Call configuration scripts.

Save the logfiles.

10.2.2 How to run a softupdate

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

     		/usr/sbin/fai softupdate

starts a softupdate. If you want to use softupdates on a system not installed with fai, the first time you need to run fai with the -N switch: fai -N softupdate - see fai(8) for details.

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.1.1 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.1.2 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 /usr/sbin/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 softupdates

When you want to do softupdates, 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 cfengine's AppendIfNoSuchLine statement instead.

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

FAI_ROOT

points to the client's rootdir. In case of softupdates: /

ROOTCMD

contains a command for chrooting into the client. This is empty when doing softupdates (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[14].

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

10.2.4 What if there are locally changed conffiles?

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,

     		FAI_BACKUPDIR=$LOGDIR/backup

in class/DEFAULT.var will do the job.

10.2.4.1 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 or integrit to scan for local changes and notify you about them.