[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ next ]
If there is a team of administrators involved, a revision control/sourcecode management system like CVS can make coordination easier: many people can work on the configuration files simultaneously, while the system helps avoiding conflicts (and if they occur it helps resolving them). Another advantage lies in branching: while the administrator works out a new configuration and tries it out using a test system, other clients aren't disturbed in any way, because they use another branch of the configuration.
First you should setup a CVS repository and within it a module to store the FAI configuration files. In this example a CVS pserver will be used for read-only access to the configuration files by the clients, while ssh is used for the developers access (rw)[14].
The relevant variables in /etc/fai/fai.conf
and
/etc/fai/make-fai-nfsroot.conf
for CVS are:
This variable must not be set if you want to use CVS.
contains the cvsroot where the configuration is stored.
FAI_CVSROOT=":pserver:client@cvs.local.net:/var/lib/cvs"
contains the module in the cvsroot where the configuration is stored.
FAI_CVSMODULE="config"
contains the tag of the CVS branch to be checked out by the client[15].
FAI_CVSTAG="STABLE"
If you use a CVS pserver for storing configuration files, the file
/root/.cvspass
has to exist and be valid in the nfsroot. CVS uses
this file to get the password for the pserver. The easiest way to create it is
cvs -d$FAI_CVSROOT login
and then copy the generated line from your ~/.cvspass
into
/root/.cvspass
in the nfsroot.
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 reinstallation. 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).
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 filesystem 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.
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.
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.
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.
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.
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:
points to the client's rootdir. In case of softupdates: /
contains a command for chrooting into the client. This is empty when doing softupdates (as / is already our root...).
contains the currently executed action:
when installing.
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[16].
Other things like scheduling a reboot if a new kernel is installed
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.
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.
[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ next ]
FAI Guide (Fully Automatic Installation)
FAI Guide version 2.5.4, 20 april 2006 for FAI package version 2.10.1lange@informatik.uni-koeln.de