[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ next ]
The configuration is the collection of information about how exactly to install
a computer. The central configuration space for all install clients is located
on the install server in /srv/fai/config and its subdirectories.
This will be mounted by the install clients to
/var/lib/fai/config. It's also possible to receive all the
configuration data from a cvs(1) or subversion repository. The
following subdirectories are present and include several files:
Scripts and files to define classes and variables and to load kernel modules.
Configuration files for disk partitioning and file system creation.
This directory holds all debconf(8) data. The format is the same
that is used by debconf-set-selections(8).
File with lists of software packages to be installed or removed.
Script for local site customization.
Files used by customization scripts. Most files are located in a subtree
structure which reflects the ordinary directory tree. For example, the
templates for nsswitch.conf are located in
/fai/files/etc/nsswitch.conf and are named according to the
classes that they should match: /fai/files/etc/nsswitch.conf/NIS
is the version of /etc/nsswitch.conf to use for the NIS class.
Note that the contents of the files directory are not automatically copied to
the target machine, rather they must be explicitly copied by customization
scripts using the fcopy(8) command.
THE USE OF THIS DIRECTORY IS NOW OBSOLETE.
Normally the file /var/tmp/base.tgz is extracted on the install
client after the new file systems are created and before package are installed.
This is a minimal base image, created right after calling debootstrap during
the make-fai-nfsroot process on the install server. If you want to install
another distribution than the nfsroot is, you can put a tar file into the
subdirectory basefiles/ and name it after a class. Then the
command ftar(8) is used to extract the tar file based on the
classes defined. This is done in task extrbase.
Hooks are user defined programs or scripts, which are called during the installation process.
The main installation command fai(8) uses all these subdirectories
in the order listed except for hooks. The FAI package contains examples for
all these configuration scripts and files in
/usr/share/doc/fai-doc/examples. Copy the configuration examples
to the configuration space and start an installation. These files need not
belong to the root account. You can change their ownership and then edit the
configuration with a normal user account.
# cp -a /usr/share/doc/fai-doc/examples/simple/* /srv/fai/config
# chown -R fai /srv/fai/config
These files contain simple configuration for some example hosts. Depending on the host name used, your computer will be configured as follows:
A machine which needs only a small hard disk. This machine is configured with network (as DHCP client), and an account demo is created.
A GNOME desktop is installed, and the account demo is created.
Hosts with other host name will most notably use the classes FAIBASE, DHCPC and GRUB.
Start looking at these examples and study them. Then change or add things to these examples. But don't forget to plan your own installation!
After the kernel has booted, it mounts the root file system via NFS from the
install server and init(8) starts the script
/usr/sbin/fai. This script controls the sequence of the
installation. No other scripts in /etc/init.d/ are used.
The installation script uses many subroutines, which are defined in
/usr/share/fai/subroutines, and an operating system specific file
[12]. All important tasks of the
installation are called via the subroutine task appended by the
name of the task as an option (e.g. task instsoft). The
subroutine task calls hooks with prefix name if available
and then calls the default task (defined as task_name in
subroutines). The default task and its hooks can be skipped on
demand by using the subroutine skiptask().
Now follows the description of all default tasks.
The kernel appended parameters define variables, the syslog and kernel log daemon are started. The list of network devices is stored in $netdevices. Then additional parameters are fetched from a DHCP or BOOTP server and also additional variables are defined. The DNS resolver configuration file is created.
The location of the configuration space is defined by the variable $FAI_CONFIG_SRC. You can use NFS, cvs, svn or git to access the configuration space. See section Set up FAI, Section 5.3 for how to set the variable.
After that, the file /fai/hooks/subroutines is sourced if it
exists. Using this file, you can define your own subroutines or override the
definition of FAI's subroutines.
This task sets the system time, all FAI_FLAGS are defined and two additional virtual terminals are opened on demand. A secure shell daemon is started on demand for remote logins.
Calls fai-class(1) to define classes using scripts and files in
/fai/class and classes from
/tmp/fai/additional-classes.
Sources all files /fai/class/*.var for every defined class. If a
hook has written some variable definitions to the file
/tmp/fai/additional.var, this file is also sourced.
Depending on the value of $FAI_ACTION this subroutine decides which
action FAI should perform. The default available actions are:
sysinfo, install and softupdate. If
$FAI_ACTION has another value, a user defined action is called if a
file /fai/hooks/$FAI_ACTION exists. So you can easily define your
own actions.
Called when no installation is performed but the action is
sysinfo. It shows information about the detected hardware and
mounts the local hard disks read only to
/target/partitionname or with regard to a
fstab file found inside a partition. Log files are stored to the
install server.
This task controls the installation sequence. You will hear three beeps before
the installation starts. The major work is to call other tasks and to save the
output to /tmp/fai/fai.log. If you have any problems during
installation, look at all files in /tmp/fai/. You can find
examples of the log files for some hosts in the download directory of the FAI
homepage.
This task, executed inside a running system via the fai(8) command
line interface, performs a softupdate. See chapter Using FAI for updates, Section 10.2
for details.
Calls setup_harddisk to partition the hard disks. The task writes
variable definitions for the root and boot partition and device
($ROOT_PARTITION, $BOOT_PARTITION, $BOOT_DEVICE) to
/tmp/fai/disk_var.sh and creates an fstab file.
Mounts the created partitions according to the created
/tmp/fai/fstab file relative to $FAI_ROOT.
Extracts a minimal system after that a chroot can be made into it. By default
the base tar file /var/tmp/base.tgz will be extracted. The
command ftar -1v -s $FAI/basefiles / is used for unpacking a
different tar file depending on classes defined. This can be used for
installing different Linux distributions than the one used for creating the
nfsroot. The default file base.tgz is a snapshot of a basic
Debian system created by debootstrap(8)
If a local Debian mirror is accessed via NFS (when $FAI_DEBMIRROR is defined), this directory will be mounted to $MNTPOINT.
Calls fai-debconf(8) to set the values for the debconf database.
Set up resolv.conf and some other file, for the next task updatebase.
Updates the base packages of the new system and updates the list of available
packages. It also fakes some commands (called diversions) inside the new
installed system using dpkg-divert(8).
Installs the desired software packages using class files in
/fai/package_config/.
Calls scripts in /fai/scripts/ and its subdirectories for every
defined class.
Unmounts all file systems in the new installed system and removes diversions of
files using the command fai-divert.
Wait for background jobs to finish (e.g. emacs compiling lisp files) and automatically reboots the install clients or waits for manual input before reboot.
Changes the symbolic link on the install server which indicates which kernel image to load on the next boot from network card via TFTP.
Saves log files to local disk and to the account $LOGUSER on
$LOGSERVER (defaults to the install server). Currently the file
error.log will not be copied to the log server.
After the subroutine fai_init has done some basic initialization
(create RAM disk, read fai.conf and all subroutines definitions,
set path, print copyright notice), the setup continues by calling the task
confdir and the task setup. The command
get-boot-info is called to get all information from the BOOTP or
DHCP server. This command writes the file /tmp/fai/boot.log,
which then is sourced to define the corresponding global variables. This is an
example for this log file when using a DHCP server.
# cat /tmp/fai/boot.log
netdevices_all="eth0"
netdevices_up="eth0"
netdevices="eth0"
BROADCAST='192.168.1.255'
DOMAIN='localdomain'
DNSSRVS='192.168.1.1'
DNSSRVS_1='192.168.1.1'
HOSTNAME='demohost'
IPADDR='192.168.1.12'
NETWORK='192.168.1.0'
GATEWAYS='192.168.1.250'
GATEWAYS_1='192.168.1.250'
SERVER='faiserver'
NETMASK='255.255.255.0'
Additional information is passed via the kernel command line or read from
/etc/fai/fai.conf. When booting with PXE, command line parameters
are created using fai-chboot(8). The variable
$FAI_FLAGS contains a space separated list of flags. The following
flags are known:
Create verbose output during installation. This should always be the first flag, so consecutive definitions of flags will be verbosely displayed.
Create debug output. No unattended installation is performed. During package installation you have to answer all questions of the postinstall scripts on the client's console. A lot of debug information will be printed out. This flag is only useful for FAI developers.
Start the ssh daemon to enable remote logins.
Create two virtual terminals and execute a bash if ctrl-c is typed in the console terminal. The additional terminals can be accessed by typing Alt-F2 or Alt-F3. Otherwise no terminals are available and typing ctrl-c will reboot the install client. Setting this flag is useful for debugging. If you want an installation which should not be interruptible, do not set this flag.
Reboot the install client after installation is finished without typing RETURN on the console. This is only useful if you can change the boot image or boot device automatically or your assembly robot can remove the boot floppy via remote control :-) Currently this should only be used when booting from network card.
Classes determine which configuration file to choose from a list of available templates. Classes are used in all further tasks of the installation. To determine which config file to use, an install client searches the list of defined classes and uses all configuration files that match a class name. It's also possible to use only the configuration file with the highest priority since the order of classes define the priority from low to high. There are some predefined classes (DEFAULT, LAST and the host name), but classes can also be listed in a file or defined dynamically by scripts. So it's easy to define a class depending on the subnet information or on some hardware that is available on the install client.
The idea of using classes in general and using certain files matching a class name for a configuration is adopted from the installation scripts by Casper Dik for Solaris. This technique proved to be very useful for the SUN workstations, so I also use it for the fully automatic installation of Linux. One simple and very efficient feature of Casper's scripts is to call a command with all files (or on the first one) whose file names are also a class. The following loop implements this function in pseudo shell code:
for class in $all_classes; do
if [ -r $config_dir/$class ]; then
your_command $config_dir/$class
# exit if only the first matching file is needed
fi
done
Therefore it is possible to add a new file to the configuration without changing the script. This is because the loop automatically detects new configuration files that should be used. Unfortunately cfengine does not support this nice feature, so all classes being used in cfengine also need to be specified inside the cfengine scripts. Classes are very important for the fully automatic installation. If a client belongs to class A, we say the class A is defined. A class has no value, it is just defined or undefined. Within scripts, the variable $classes holds a space separated list with the names of all defined classes. Classes determine how the installation is performed. For example, an install client can be configured to become an FTP server by just adding the class FTP to it. Mostly a configuration is created by only changing or appending the classes to which a client belongs, making the installation of a new client very easy. Thus no additional information needs to be added to the configuration files if the existing classes suffice for your needs. There are different possibilities to define classes:
Some default classes are defined for every host: DEFAULT, LAST and its host name.
Classes may be listed within a file.
Classes may be defined by scripts.
The last option is a very nice feature, since these scripts will define classes
automatically. For example, several classes are defined only if certain
hardware is identified. We use Perl and shell scripts to define classes. All
names of classes, except the host name, are written in uppercase. They must
not contain a hyphen, a hash or a dot, but may contain underscores. A
description of all classes can be found in
/usr/share/doc/fai-doc/classes_description.txt.
host names should rarely be used for the configuration files in the configuration space. Instead, a class should be defined and then added for a given host. This is because most of the time the configuration data is not specific for one host, but can be shared among several hosts.
The task defclass calls the script fai-class(1) to define
classes. Therefore, scripts matching [0-9][0-9]* in
/fai/class are executed. Additionally, a file with the host name
may contain a list of classes. For more information on defining class, read
the manual pages for fai-class(1).
The list of all defined classes is stored in the variable $classes
and saved to /tmp/fai/FAI_CLASSES. The list of all classes is
transfered to cfengine, so it can use them too. The script
10-base-classes (below is a stripped version) is used to define
classes depending on the host name. First this script defines the class with
the name of the hardware architecture in uppercase letters.
# cat 10-base-classes
# echo architecture and OS name in upper case. Do NOT remove these two lines
uname -s | tr '[:lower:]' '[:upper:]'
dpkg --print-installation-architecture | tr /a-z/ /A-Z/
[ -f /boot/RUNNING_FROM_FAICD ] && echo "FAICD"
# use a list of classes for our demo machine
case $HOSTNAME in
demohost)
echo "FAIBASE GRUB DHCPC DEMO" ;;
gnomehost)
echo "FAIBASE GRUB DHCPC DEMO XORG GNOME";;
*)
echo "FAIBASE GRUB DHCPC" ;;
esac
The script 20-hwdetect.source uses the default Debian commands to
detect hardware and to load some kernel modules. If some specific hardware is
found, it can also define a new class for it. You can find messages from
modprobe in /tmp/fai/kernel.log and on the fourth console terminal
by pressing Alt-F4.
The task defvar defines the variables for the install client.
Variables are defined by scripts in class/*.var. All global
variables can be set in DEFAULT.var. For certain groups of hosts
use a class file or for a single host use the file
$HOSTNAME.var. Also here, it's useful to study all the
examples. The following variables are used in the examples and may also be
useful for your installation:
Set the action fai should perform. Normally this is done by
fai-chboot(8). If you can't use this command and are not using a
BOOTP server, define it in the script LAST.var.
Is the font which is loaded during installation by
consolechars(8).
Defines the keyboard map files in /usr/share/keymaps and
$FAI/files. You need not specify the complete path, since this
file will be located automatically.
The encrypted root password for the new system. You can use
crypt(3) or md5 encryption for the password.
Set hardware clock to UTC if $UTC=yes. Otherwise set clock to
local time. See clock(8) for more information.
Is the file relative to /usr/share/zoneinfo/ which indicates your
time zone.
Can be a multi line definition. List of modules (including kernel parameters) which are loaded during boot of the new system (written to /etc/modules).
The script setup_harddisks partitions and formats the local disks.
It uses all configuration files in /fai/disk_config/ which are
also defined as classes. Lines beginning with # are comments. The config file
/fai/disk_config/FAIBASE is a generic description for one hard
disk (IDE or SCSI), which most installations should be able to adapt. If you
can't partition your hard disk using this script [13], use a hook instead. The hook should write the new
partition table, create the file systems and create the files
/tmp/fai/fstab and /tmp/fai/disk_var.sh, which
contains definitions of boot and root partitions.
The following example is a configuration for the first IDE disk
disk1 and for the second SCSI disk disk2 The
numbering of the disks comes from the order in /proc/partitions.
# <type> <mount point> <size in MB> [mount options] [;extra options]
disk_config disk1
primary / 200 defaults,errors=remount-ro
logical /home 100-300
logical /scratch1 10- defaults,nosuid ; -i 15000 -m 0
disk_config disk2
primary /tmp 300-500 rw ;ext2
primary /backup preserve2 rw
logical swap 50-100
logical /scratch2 100-300 rw ;-m 30
logical - preserve7
logical /var 100 ;-j
logical /var/tmp preserve9 ;format
primary /tmp/mytmp -300
Every disk configuration starts with the command disk_config
followed by diskX where X is the number of the HDD.
The Linux device names /dev/hda and /dev/sda
correspond to disk1, disk2 corresponds to
/dev/hdb and /dev/sdb and so on.
After disk_config one line containing the type, mount point and
size is added for each partition on the harddisk. Mount options and additional
parameters for mke2fs -- separated from the mount options by a
semicolon -- can be added.
There are two types of partitions: primary and logical. Primary partitions are bootable, but there is a maximum of four primary partitions on each disk. The Linux root file system must be of this type.
All other partitions are called logical. Because logical partitions are gathered internally in one big primary partition, only three primary partitions can be used if logical partitions are defined. Normally only one primary partition for the root file system is created and all others are logical, like disk1 in the example above.
The mount point is the full path (beginning with a slash) for the file system.
The value swap defines a Linux swap partition. Both types will be
automatically added to /etc/fstab. A dash (-)
indicates that the partition will not be mounted and can be used for other
types of file systems (FAT, NTFS, UFS, MINIX, ...)
This is the size of the partition in megabytes. This value is rounded up to fit to a cylinder number. There are several ways of defining the size:
"200" means about 200MB, no more no less
"100-300" sets a 100MB minimum and a 300MB maximum
"10-" sets a minimum of 10MB and a maximum of the disk size
"-300" sets a minimum of 1MB and a 300MB maximum
By default, a new file system (currently of type ext2 or swap) will be created, and all data on the partition is lost. The meaning of preserve<no> will be described later.
Calculating the partition size: If an interval is defined for several partition sizes, the script maximizes the values by preserving the ratio between them.
The mount options will be copied to /etc/fstab. An empty field
sets the option to defaults (see mount(8)).
The last field is a space separated extra options list. The following options are known:
boot : Make this partition the boot-partition (the
Linux root file system is the default).
-i <bytes> : bytes per inode (ext2/3 only)
-m <blocks> : reserved blocks percentage (ext2/3 only)
-j : Create the file system with an ext3 journal.
-c : Check for bad blocks.
ext2 : Flag as ext2 instead of auto in /etc/fstab.
ext3 : Flag as ext3 instead of auto in /etc/fstab.
swap : swap partition
dosfat16 : DOS 16 bit FAT file system
winfat32 : Win95 FAT32 file system
reiser : Create a ReiserFS file system, not an ext2.
xfs : XFS
format : Always format even if preserve is specified.
writable : Mounts a preserved partition writable.
lazyformat : Do not format if partition has not moved.
The order of the extra options is not relevant. For more information see
mke2fs(8).
Thus, we have the following interactions between -j, ext2 and ext3 :
<no option> : An ext2 fs flagged as auto in the fstab
-j : An ext3 fs flagged as auto in the fstab.
ext2 : An ext2 fs flagged as ext2 in the fstab.
-j ext2 : An ext3 fs flagged as ext2 in the fstab.
-j ext3 : An ext3 fs flagged as ext3 in the fstab.
ext3 : An ext2 fs flagged as ext3 in the fstab. !!BAD!!
Using auto in the fstab for ext3 file systems enables a non-ext3-enabled kernel or tool to cope with these partitions.
It is possible to preserve the size and even the existing data on a partition.
To preserve only the partition size, the number of the partition must be
unchanged and the size must be specified as preserve<no> The
number <no> is the device number (as in
/dev/hda<no>, or see the output of df) of the
partition. Primary partitions are numbered from one to four, the numbers for
logical partitions begin at five.
Problems were reported (February 2003) when using more than two primary partitions and trying to preserve a logical partition. If you have this problem, try to use only two primary partitions.
In the following example, the partition numbers (= device number) are also shown for disk disk2:
primary /tmp 300-500 # 1
primary /backup preserve2 # 2
logical swap 50-100 # (3) 5
logical /scratch2 100-300 # (3) 6
logical - preserve7 # (3) 7
logical /var 100 # (3) 8
logical /var/tmp preserve9 # (3) 9
primary /tmp/mytmp -300 # 4
The first two partitions are of type primary, so they get the numbers 1 and 2.
The logical partitions start at 5 and the last gets number 9. All logical
partitions define the primary partition 3, but this number is not used. So if
you want to preserve /dev/hda7 you have to insert a minimum of two
logical partitions before it.
Lazyformating partitions is another method to preserve partitions after they
were formatted once. This is useful to design systems which can be reinstalled
without loosing data on partitions like /home or
/var/log or /var/lib/mysql or whatever. You can even
lazyformat the swap partition to gain a minor installation speed improvement
after the first installation!
If you have a separate /boot partition, you must add the extra
option boot to make it your boot partition. Otherwise your system
will not be bootable. By default (if no boot option was specified) the root
partition (/) will become the boot partition.
setup_harddisks will write some variables containing the
information about boot partition and boot device to
/tmp/fai/disk_var.sh.
The script install_packages installs the selected software
packages. It uses all configuration files in /fai/package_config
whose file name matches a defined class. The syntax is very simple.
# an example package class
PACKAGES taskinst
german
PACKAGES aptitude
adduser netstd ae
less passwd
PACKAGES remove
gpm xdm
PACKAGES aptitude GRUB
lilo- grub
PACKAGES dselect-upgrade
ddd install
a2ps install
Comments are starting with a hash (#) and are ending at the end of the line. Every command begins with the word PACKAGES followed by a command name. The command defines which command will be used to install the packages named after this command. The list of all available commands can be listed using install_packages -H. Supported package tools are: aptitude, apt-get, smart, y2pmsh, yast, yum, urpm, rpm
Put a package on hold. This package will not be handled by dpkg, e.g not upgraded.
Install all packages that are specified in the following lines. If a hyphen is appended to the package name (with no intervening space), the package will be removed, not installed. All package names are checked for misspellings. Any package which does not exist, will be removed from the list of packages to install. So be careful not to misspell any package names.
Remove all packages that are specified in the following lines. Append a + to the package name if the package should be installed.
Install all packages belonging to the tasks that are specified in the following
lines using tasksel(1). You can also use aptitude
for installing tasks.
Install all packages with the command aptitude. This will be the
default in the future and may replace apt-get and taskinst. Aptitude can also
install task packages.
Same as aptitude with option --with-recommends.
Download package and unpack only. Do not configure the package.
Set package selections using the following lines and install or remove the packages specified. These lines are the output of the command dpkg --get-selections.
Multiple lines with lists of space separated names of packages follow the
PACKAGES lines. All dependencies are resolved. Packages with suffix
- (eg. lilo-) will be removed instead of installed.
The order of the packages is of no matter. If you like to install packages
from another release than the default, you can append the release name to the
package name like in openoffice.org/etch-backports. You can also
specify a certain version like apt=0.3.1. More information on
these features are described in aptitude(8).
A line which contains the PRELOADRM commands, downloads a file
using wget(1) into a directory before installing the packages.
Using the file: URL, this file is copied from $FAI_ROOT
to the download directory. For example the package realplayer
needs an archive to install the software, so this archive is downloaded to the
directory /root. After installing the packages this file will be
removed. If the file shouldn't be removed, use the command
PRELOAD instead.
It's possible to append a list of class names after the command for apt-get. So this PACKAGE command will only be executed when the corresponding class is defined. So you can combine many small files into the file DEFAULT. WARNING! Use this feature only in the file DEFAULT to keep everything simple. See this file for some examples.
If you want to remove a package name from a certain class was part of this class before, you should not remove the package name from the class file, but instead append a dash (-) to it. This will make sure that the package is remove during a softupdate on hosts which were installed using the old class definition which included this package name.
If you specify a package that does not exist this package will be removed from
the installation list when the command install is used. You can
also test all software package configuration files with the utility
chkdebnames, which is available in
/usr/share/doc/fai-doc/examples/utils/.
> chkdebnames stable /srv/fai/config/package_config/*
The default set of scripts in /fai/scripts is only an example.
But they should do a reasonable job for your installation. You can edit them
or add new scripts to match your local needs.
The command fai-do-scripts(1) is called to execute all scripts in
this directory. If a directory with a class name exists, all scripts matching
[0-9][0-9]* are executed in alphabetical order. So it's possible
to use scripts of different languages (shell, cfengine, Perl,..) for one class.
Most scripts are Bourne shell scripts. Shell scripts are useful if the
configuration task only needs to call some shell commands or create a file from
scratch. In order not to write many short scripts, it's possible to
distinguish classes within a script using the command ifclass.
For copying files with classes, use the command fcopy(8). If you
want to extract an archive using classes, use ftar(8). But now
have a look at the scripts and see what they are doing.
Currently no Perl script are used in the simple examples for modifying the system configuration.
Currently no expect scripts are used in the simple examples for modifying the system configuration.
Cfengine has a rich set of functions to edit existing configuration files, e.g
LocateLineMatching, ReplaceAll, InsertLine, AppendIfNoSuchLine,
HashCommentLinesContaining. But it can't handle variables which are
undefined. If a variable is undefined, the whole cfengine script will abort.
Study the examples that are included in the fai package. More information can
be found in the manual page cfengine(8) or at the cfengine
homepage www.cfengine.org.
Changing the boot sequence is normally done in the BIOS setup. But you can't change the BIOS from a running Linux system as far as I know. If you know how to perform this, please send me an email. But there's another way of swapping the boot device of a running Linux system.
So, normally the boot sequence of the BIOS will remain unchanged and your
computer should always boot first from its network card and the second boot
device should be the local disk. Then, it will get an install kernel image
from the install server, when an installation should be performed, or we can
tell pxelinux to boot from local disk. This is done using
fai-chboot(8). Here is how to set up a 3Com network card as first
boot device. Enable LAN as first boot device in the BIOS.
Boot From LAN First: Enabled
Boot Sequence : C only
Then enter the MBA setup of the 3Com network card and change it as follows:
Default Boot Local
Local Boot Enabled
Message Timeout 3 Seconds
Boot Failure Prompt Wait for timeout
Boot Failure Next boot device
This will enable the first IDE hard disk as second boot device after the network card. If booting from a FAI floppy disk, another solution can be used to skip a re-installation if the BIOS is configured to boot from the floppy disk first and you are not there to remove the floppy disk:
# lilo -R ...
will instruct the FAI floppy to boot from the hard disk only once (see
lilo(8)). Thus after this first reboot, the FAI floppy disk can
be used for another FAI installation.
Hooks let you specify functions or programs which are run at certain steps of
the installation process. Before a default task is called, FAI searches for
existing hooks for this task and executes them. As you might expect, classes
are also used when calling hooks. Hooks are executed for every defined class.
You only have to create the hook with the name for the desired class and it
will be used. If several hooks for a task exists, they are called in the order
defined by the classes. If debug is included in
$FAI_FLAG the option -d is passed to all hooks, so you
can debug your own hooks. If some default tasks should be skipped, use the
subroutine skiptask and a list of default tasks as parameters.
The example partition.DISKLESS skips some default tasks.
The directory /fai/hooks/ contains all hooks. The file name of a
hook consists of a task name as a prefix and a class name, separated by a dot.
The prefix describes the time when the hook is called, if the class is defined
for the install client. For example, the hook partition.DISKLESS
is called for every client belonging to the class DISKLESS before
the local disks would be partitioned. If it should become a diskless client,
this hook can mount remote file systems via NFS and create a
/tmp/fai/fstab. After that, the installation process will not try
to partition and format a local hard disk, because a file
/tmp/fai/fstab already exists.
A hook of the form hookprefix.classname can't define variables for
the installation script, because it's a subprocess. But you can use any binary
executable or any script you wrote. Hooks that have the suffix
.source (e.g. partition.DEFAULT.source) must be
Bourne shell scripts and are sourced. So it's possible to redefine variables
for the installation scripts.
In the first part of FAI, all hooks with prefix confdir are
called. Since the configuration directory /fai is mounted in the
default task confdir, the hooks for this task are the only hooks
located in $nfsroot/fai/hooks on the install server.
All other hooks are found in $FAI_CONFIGDIR/hooks on the install
server. All hooks that are called before classes are defined can only use the
following classes: DEFAULT $HOSTNAME LAST. If a hook for class
DEFAULT should only be called if no hook for class
$HOSTNAME is available, insert these lines to the default hook:
hookexample.DEFAULT:
#! /bin/sh
# skip DEFAULT hook if a hook for $HOSTNAME exists
scriptname=$(basename $0 .DEFAULT)
[-f /fai/hooks/$scriptname.$HOSTNAME ] && exit
# here follows the actions for class DEFAULT
.
.
Some examples for what hooks could be used:
Use ssh in the very beginning to verify that you mounted the
configuration from the correct server and not a possible spoofing host.
Do not mount the configuration directory, instead get a compressed archive via HTTP or from floppy disk and extract it into a new RAM disk, then redefine $FAI_LOCATION.
Load kernel modules before classes are defined in /fai/class.
Send an email to the administrator if the installation is finished.
Install a diskless client and skip local disk partitioning. See
hooks/partition.DISKLESS.
Partition the hard disk on an IA64 system, which needs a special partition
table type that must be created with parted(8).
If the client can't successfully boot from the network card, use
tcpdump(8) to look for Ethernet packets between the install server
and the client. Search also for entries in several log files made by
tftpd(8), dhcpd3(8) or bootpd(8):
egrep "tftpd|bootpd|dhcpd" /var/log/*
If the installation process finishes, the hook savelog.LAST.source
searches all log files for common errors and writes them to the file
error.log. So, you should first look into this file for errors.
Also the file status.log give you the exit code of the last
command executed in a script. To be sure, you should look for errors in all
log files.
Sometimes the installation seems to stop, but often there's only a postinstall
script of a software package that requires manual input from the console.
Change to another virtual terminal and look which process is running with tools
like top(1) and pstree(1). You can add
debug to FAI_FLAGS to make the installation process
show all output from the postinst scripts on the console and get its input also
from the console. Don't hesitate to send an email to the mailing list or to
fai@informatik.uni-koeln.de
if you have any questions. Sample log files from successfully installed
computers are available on the FAI homepage.
[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ next ]
FAI Guide (Fully Automatic Installation)
FAI Guide version 2.6.8, 7 December 2007 for FAI package version 3.2.1lange@informatik.uni-koeln.de