[Fai-commit] r5495 - trunk/doc
Thomas Lange
lange at alioth.debian.org
Mon Aug 10 11:46:17 UTC 2009
Author: lange
Date: 2009-08-10 11:46:17 +0000 (Mon, 10 Aug 2009)
New Revision: 5495
Removed:
trunk/doc/entities/
trunk/doc/fai-guide.sgml
Log:
remove sgml files of fai-guide
Deleted: trunk/doc/fai-guide.sgml
===================================================================
--- trunk/doc/fai-guide.sgml 2009-08-08 16:36:17 UTC (rev 5494)
+++ trunk/doc/fai-guide.sgml 2009-08-10 11:46:17 UTC (rev 5495)
@@ -1,2970 +0,0 @@
-<!DOCTYPE debiandoc PUBLIC "-//DebianDoc//DTD DebianDoc//EN" [
- <!-- include version information so we don't have to hard code it
- within the document -->
- <!-- common, language independent entities -->
- <!entity % commondata SYSTEM "common.ent" > %commondata;
- <!-- SVN revision of this document -->
- <!entity svn-rev "$Id$">
-
-<!entity faiver "3.3">
-<!entity faiverdate "XXXXXXXXX Oct 2009">
-
-<!entity version "2.8.7">
-<!entity date "19 july 2009">
-
-<!entity faisetup system "entities/faisetup.sgml">
-<!entity bootexample system "entities/bootexample.sgml">
-<!entity bootlog system "entities/bootlog.sgml">
-
-]>
-
-
-<debiandoc>
-<book>
- <title>FAI Guide (Fully Automatic Installation)
-
- <author>Thomas Lange <email>lange at informatik.uni-koeln.de</email>
- <version>FAI Guide version &version;, &date; for FAI package version &faiver;
-
-<abstract>
-FAI is a non-interactive system to install, customize and manage
-Linux systems and software configurations on computers as well as
-virtual machines and chroot environments, from small networks to
-large infrastructures and clusters.
-
-This manual describes the fully automatic installation package for
-Debian GNU/Linux. This includes the installation of the package, planning and
-creating of the configuration and how to deal with errors.
-
-<copyright>
-<copyrightsummary>
-Copyright © 2000-2009 Thomas Lange
-</copyrightsummary>
-<copyrightsummary>
-Copyright © 2005 Henning Glawe
-</copyrightsummary>
- <p>
-This manual is free software; you may redistribute it and/or modify it
-under the terms of the GNU General Public License as published by the
-Free Software Foundation; either version 2, or (at your option) any
-later version.
- <p>
-This is distributed in the hope that it will be useful, but
-<em>without any warranty</em>; without even the implied warranty of
-merchantability or fitness for a particular purpose. See the GNU
-General Public License for more details.
- <p>
-A copy of the GNU General Public License is available as &file-GPL; in
-the &dgl; distribution or on the World Wide Web at <url id="&url-gpl;"
- name="the GNU website">. You can also obtain it by
-writing to the &fsf-addr;.
-
-<toc detail="sect2">
-
-<chapt id="intro">Introduction<p>
-<!--MT: general comments:
- - dirinstall is only mentioned at the end
- - mailinglists, IRC channel should be mentioned
- - ULRs should be http://www. ... or only www. ..., but please be consistent
- - Variables $VARNAME or VARNAME only? Be consistent.
--->
-<sect id="availability">Availability<p>
-<!--MT: put Motivation before Availability-->
-The homepage of FAI is <url id="&faiwww;">. There's a wiki for FAI
-available at <httpsite>faiwiki.informatik.uni-koeln.de</httpsite>.
-There you will find all information about FAI, for example the mailing
-list archives. The FAI packages are also available from
-<url id="&faidownload;">. They are also available from
-all Debian mirrors. To access the newest versions of the FAI packages,
-you can add the following line to your <file>/etc/apt/sources.list</file> file.
-
-<example>deb http://www.informatik.uni-koeln.de/fai/download lenny koeln</example>
-
-User visible changes are listed in <file>/usr/share/doc/fai-doc/NEWS.Debian.gz</file>.
-<p> Send any comments to
-<email>fai at informatik.uni-koeln.de</email>. You should use the
-Debian bug tracking system (BTS)
-<url id="http://&www-debian-org;/Bugs/"> for reporting errors.
-<p>
-You can access the subversion repository containing the newest developer
-version of FAI from a Unix shell using the
-following commands.
-<example>
-# svn co svn://svn.debian.org/svn/fai/trunk fai
-</example>
-
-You can also use the web interface for the subversion repository at:
-<httpsite>svn.debian.org/</httpsite><httppath>wsvn/fai/</httppath>.
-<p>
-Now read this manual, then enjoy the fully automatic installation and
-your saved time.
-
-
-<sect id="motivation">Motivation<p> Have you ever performed identical
-installations of an operating system several times? Would you like to
-be able to install a Linux cluster with dozens of nodes single
-handedly?
-
-<p>
-Repeating the same task again and again is boring -- and will surely
-lead to errors. Also a whole lot of time could be saved if the
-installations were done automatically. An installation process with
-manual interaction does not scale. But clusters have the habit of
-growing over the years. Think long-term rather than planning just a
-few months into the future.
-
-<p>
-In 1999, I had to perform an installation of a Linux cluster with one
-server and 16 clients. Since I had much experience doing automatic
-installations of Solaris operating systems on SUN SPARC hardware, the
-idea to build an automatic installation for Debian was born. Solaris
-has an automatic installation feature called JumpStart<footnote> <p>
-Solaris 8 Advanced Installation Guide at
-<httpsite>docs.sun.com</httpsite></p> </footnote>. In conjunction
-with the auto-install scripts from Casper Dik<footnote><p><url
-id="ftp://ftp.wins.uva.nl:/pub/solaris/auto-install/"></p> </footnote>,
-I could save a lot of time not only for every new SUN computer, but
-also for re-installation of existing workstations. For example, I had
-to build a temporary LAN with four SUN workstations for a conference,
-which lasted only a few days. I took these workstations out of our normal
-research network and set up a new installation for the conference.
-When it was over, I simply integrated the workstations back into the
-research network, rebooted just once, and after half an hour,
-everything was up and running as before. The configuration of all
-workstations was exactly the same as before the conference, because
-everything was performed by the same installation process. I also used
-the automatic installation for reinstalling a workstation after a
-damaged hard disk had been replaced. It took two weeks until I
-received the new hard disk but only a few minutes after the new disk
-was installed, the workstation was running as before. And this is why
-I chose to adapt this technique to a PC cluster running Linux.
-
-
-
-<sect id="overview">Overview and concepts<p>
-<p>
-
-FAI is a non-interactive system to install, customize and manage
-Linux systems and software configurations on computers as well as
-virtual machines and chroot environments, from small networks to
-large infrastructures and clusters. You can take one or more virgin
-PCs, turn on the power and after a few minutes Linux is installed,
-configured and running on the whole cluster, without any interaction
-necessary. Thus, it's a scalable method for installing and updating a
-cluster unattended with little effort involved. FAI uses the &dgl;
-distribution and a collection of shell and Perl scripts for the
-installation process. Changes to the configuration files of the
-operating system can be made by cfengine, shell, Perl and expect scripts.
-
-<p>
-FAI's target group are system administrators who have to install
-Linux onto one or even hundreds of computers. Because it's a general
-purpose installation tool, it can be used for installing a Beowulf
-cluster, a rendering farm or a Linux laboratory or a classroom. Also
-large-scale Linux networks with different hardware or different installation
-requirements are easy to establish using FAI. But don't forget to plan
-your installation. <ref id="plan"> has some useful hints for this topic.
-<p>
-First, some terms used in this manual are described.
-
-<taglist>
- <tag> install server : <item> <p>The host where the package
- <tt>fai-server</tt> is installed. It provides several services and data for
- all install clients. In the examples of this manual this
- host is called <tt>faiserver</tt>.
-
- <tag>install client : <item> A host which will be installed using
- FAI and a configuration provided by the install server. Also called
- client for short. In this manual, the example hosts are
- called <tt>demohost, nucleus, atom01, atom02,...</tt></p> </item>
- <tag> configuration : <item> The details of how the installation
- of the clients should be performed. All configuration data
- is stored in a certain directory structure and is also
- called configuration space or config space for short. It
- includes information about:
-<list>
- <item> <p>Hard disk layout</p> </item>
- <item> <p>Local file systems, their types, mount points
- and mount options</p> </item>
- <item> <p>Software packages</p> </item>
- <item> <p>Keyboard layout, time zone, NIS,
- Xorg configuration, remote file systems, user accounts,
- printers ...</p> </item>
-</list>
- <tag> nfsroot : <item> A file system located on the install
- server. It's the complete file system for the install
- clients during the installation process. All clients share the
- same nfsroot, which they mount read only.</item>
-</taglist>
-
-<sect id="work">How does FAI work?<p>
-
-The install client which will be installed using FAI, is
-booted via network card or from CD or USB stick. It gets an IP address and
-boots a Linux kernel which mounts its root file system via NFS from the install
-server. After the kernel is loaded, the FAI startup script
-performs the automatic installation which doesn't need any
-interaction. First, the hard disks will be partitioned, file systems are
-created and then software packages are installed. After that, the new
-installed operating system is configured to your local needs using
-some scripts. Finally the new operating system will be booted from the local
-disk.
-<p>
-The details of how to install the computer (the configuration) are
-stored in the configuration space on the install server. Configuration
-files are shared among groups of computers if they are similar using the
-class concept. So you need not create a configuration for every new
-host. Hence, FAI is a scalable method to install a big cluster with a
-great number of nodes.
-
-<p>
-FAI can also be used as a network rescue system. You can boot your
-computer, but it will not perform an installation. Instead it will run a
-fully functional &dgl; without using the local hard disks. Then you can
-do a remote login and backup or restore a disk partition, check a file system,
-inspect the hardware or do any other task.
-
-<!--MT: here the class concept should be described, move the entire section
-here.-->
-
-<sect id="features">Features<p>
-<!--MT: Full stop after each item or not? Be consistent.-->
-<list>
- <item> <p>A fully automated installation can be performed.</p> </item>
- <item> <p>Very quick unattended installation</p> </item>
- <item> <p>Update of running systems without re-installation</p> </item>
- <item> <p>Hosts can boot from network card, CD, USB stick.</p> </item>
- <item> <p>Easy creation of the CD and USB stick</p> </item>
- <item> <p>PXE with DHCP and BOOTP boot methods are supported.</p> </item>
- <item> <p>Lilo and grub support</p> </item>
- <item> <p>ReiserFS, ext3 and XFS file system support</p> </item>
- <item> <p>Software RAID and LVM support</p> </item>
- <item> <p>Automatic hardware detection</p> </item>
- <item> <p>Remote login via ssh during installation process
- possible.</p> </item>
- <item> <p>Two additional virtual terminals available
- during installation</p> </item>
- <item> <p>All similar configurations are shared among
- all install clients.</p> </item>
- <item> <p>Log files for all installations are saved to the installation server.</p> </item>
- <item> <p>Shell, Perl, expect and cfengine scripts are
- supported for the configuration setup.</p> </item>
- <item> <p>Access to a Debian mirror via NFS, FTP or HTTP</p> </item>
- <item> <p>Can be used as a rescue system.</p> </item>
- <item> <p>Flexible system through easy class concept </p> </item>
-<!-- <item> <p>Predefined Beowulf classes included </p> </item> -->
- <item> <p>Diskless client support</p> </item>
- <item> <p>Easily add your own functions via hooks.</p> </item>
- <item> <p>Easily change the default behavior via hooks.</p> </item>
- <!--MT: SVN/CVS config management, softupdate, dirinstall-->
-</list>
-
-<chapt id=impatient>Quickstart - For the impatient user<p>
-
-So, you do not like to read the whole manual? You like to try an
-installation without reading the manual? OK. Here's how to succeed in
-a few minutes.
-
-<list>
- <item><p>Install the package <tt>fai-quickstart</tt> (see
-<ref id="faisetup"> on your install server).</p></item>
- <item><p>Edit &fc;, run fai-setup -v and read its output.</p></item>
-
-<item><p>
-Install the simple examples into the configuration space:
-<p><tt>cp -a /usr/share/doc/fai-doc/examples/simple/* /srv/fai/config/</tt>
-</p></item>
-
-<item><p>Get the MAC address of your demo host.</p></item>
- <item><p>Add your host (try to name it <tt>demohost</tt>)
- to <file>dhcpd.conf</file> and <file>/etc/hosts</file> (=your DNS) on the FAI server.</p></item>
-<item><p>When using PXE, tell the install client to boot the install
- kernel and perform an installation during the next boot by calling
- <example>fai-chboot -IFv demohost</example> on the install server.
-</p></item>
-<item><p>If you want to try FAI without setting up a PXE+DNS+DHCP-environment:
-put the host names into <file>/etc/hosts</file> inside the nfsroot at
-<file>/srv/fai/nfsroot</file> and use
-a CD/DVD to boot the client.
-<item><p>Boot your demo host and enjoy the fully automatic installation.</p></item>
-<item><p>If the installation has finished successfully, the computer should boot a
-small Debian system. You can login as user <tt>demo</tt> or <tt>root</tt> with password <tt>fai</tt>.</p></item>
-
-</list>
-But now don't forget to read chapters <ref id="plan">, <ref id="instprocess"> and <ref id="config">!
-
-<chapt id="inst">Installing FAI
-<sect id="requirements">Requirements<p>
-<!--MT: split this section to mark the specific requirments:
- - boot media
- - source of the root file system
- - config source
--->
-
-The following items are required for an installation via FAI.
-
-<taglist>
- <tag>A computer: </tag><item> The computer must have a
- network interface card<footnote>If you install from USB
- stick or CD you do not need a network
- card</footnote>. Unless a diskless installation
- should be performed a local hard disk is also needed. No floppy disk,
- CD-ROM, keyboard or graphics adapter is needed.</item>
-
- <tag>DHCP or BOOTP server: </tag><item> <p>
-The clients need one of these daemons to obtain boot information.</item>
-
- <tag>TFTP server:<item> The TFTP daemon is used for
- transferring the kernel to the clients. It's only needed when
- booting from network card with a boot PROM.</item>
- <tag>NFS-Root:<item> It is a directory which contains the whole
- file system for the install clients during installation. It
- must be exported via NFS, so the install clients can mount
- it. It will
- be created during the setup of the FAI package and is also
- called <strong>nfsroot</strong>.</item>
- <tag>Debian mirror:<item> Access to a Debian
- mirror is needed. A local mirror of all Debian packages or
- an <manref name="apt-proxy" section="8"> is recommended if
- you install several computers.</item>
- <tag>Configuration space:<item> This directory tree, which
- contains the configuration data, is mounted via NFS by
- default. But you can also get this directory from a revision
- control system like CVS, subversion or Git.
- </taglist>
-<p>
-The NFS server will be enabled automatically when
-installing the <tt>fai-server</tt> package.
-<p>
-
-
-<sect id="debian-mirror">How to create a local Debian mirror<p>
-<!--MT: move this section near the end of the chapter, it's not as important-->
-
-The script <prgn>mkdebmirror</prgn> <footnote> You can find the script in
- <p><file>/usr/share/doc/fai-doc/examples/utils/</file>.</p> </footnote> can be used
- for creating your own local Debian mirror. This script uses the
- script <manref name="debmirror" section="1">. A partial Debian mirror only for i386 architecture for
- Debian 5.0 (aka lenny) without the source packages needs about
- &mirrorsize of disk space. Accessing the mirror via HTTP will be the
- default way in most cases. To see more output from the
- script call <tt>mkdebmirror -v</tt>. A root account is not
- necessary to create and maintain the Debian mirror.
-<p>
-You can use the command <manref name="fai-mirror" section="1"> for
-creating a partial mirror that only contains the software
-packages that are used in the classes in your configuration
-space. A partial mirror containing all package for the simple
-examples from the package fai-doc will only need about 300MB of disk
-space.
-
-To use HTTP access to the local Debian mirror, install a web server
-and create a symlink to the local directory where your mirror
-is located:
-
-<example># apt-get install apache2
-# ln -s /files/scratch/debmirror /var/www/debmirror
-</example>
-
-Create a file <manref name="sources.list" section="5"> in
-<file>/etc/fai/apt</file> which gives access to your Debian mirror. An
-example can be found in
-<file>/usr/share/doc/fai-doc/examples/etc</file>. Also add the IP-address
-of the HTTP server to the variable <var>NFSROOT_ETC_HOSTS</var> in
-&mfnc; when the install clients have no DNS access.
-<!--MT: some link to a signing howto would be nice-->
-
-<sect id=faisetup> Setting up FAI<p>
-
-To setup a FAI install server you need at least the packages
-<tt>fai-server</tt> and <tt>fai-doc</tt>. The package
-<tt>fai-quickstart</tt> contains dependencies on all required packages
-for an install server. Do not install the package <tt>fai-nfsroot</tt>
-on a normal system. This package can only be installed inside the nfsroot.
-
-If you would like to install all packages that are useful
-for a FAI install server, use the following command
-
-<p><example>
-# aptitude install fai-quickstart
-Reading Package Lists... Done
-Building Dependency Tree
-Reading extended state information
-Initializing package states... Done
-Reading task descriptions... Done
-
-The following NEW packages will be installed:
- apt-move{a} dhcp3-server{a} fai-doc{a} fai-quickstart fai-server{a}
- genisoimage{a} inetutils-inetd{a} nfs-kernel-server{a}
- openssh-server{a} syslinux-common{a} tftpd-hpa{a}
-0 packages upgraded, 11 newly installed, 0 to remove and 0 not upgraded.
-Need to get 2593kB of archives. After unpacking 8561kB will be used.
-Do you want to continue? [Y/n/?]
-</example><p>
-
-<p>The configuration for the FAI package (not the configuration data
-for the install clients) is defined in &fc;. Definitions that are only
-used for creating the nfsroot are located in &mfnc;. Edit these files before calling
-<prgn>fai-setup</prgn>. These are important variables in &mfnc;:
-
-<taglist>
- <tag><var>FAI_DEBOOTSTRAP</var></tag>
- <item>
- <p>For building the nfsroot there's the command called
- <manref name="debootstrap" section="8">. It needs
- the location of a Debian mirror and the name of the distribution
- (etch, lenny, sid) for which the basic Debian
- system should be built.
- </p> </item>
-
- <tag><var>NFSROOT_ETC_HOSTS</var></tag>
- <item>
- <p>If you use HTTP or FTP access to the Debain mirror,
- add its IP-address and the name to this
- variable. For a Beowulf master node, add the name and
- IP-address of both networks to it. This variable is not
- needed when the clients have access to a DNS server.</p>
- </item>
- </taglist>
-
-<p>
-
-These are important variables in &fc;:
-<taglist>
-
- <tag><var>FAI_CONFIG_SRC</var></tag>
- <item> <p>This variables described how to access the
- configuration space on the install clients. It's an Universal Resource
- Identifier (URI) even it may not always comply to the
- official schemes. <!--MT: not so important... See
- <httpsite>en.wikipedia.org</httpsite><httppath>/wiki/URI_scheme</httppath>
- for details.--> <p>
- Currently supported methods are:
-
- <taglist>
- <tag><var>nfs://host/path/to/exported/config</var></tag>
- <item> <p>The config space is mounted from host via NFS.</p></item>
-
- <tag><var>cvs[+ssh]://user at host/path/to/cvsroot
- module[=tag]</var></tag>
- <item> <p>The config space is received from a cvs checkout.</p></item>
-
- <tag><var>svn://user@host/svnpath</var></tag>
- <item> <p>The config space checked out from a
- subversion repository. Also supported are svn+file,
- svn+http, svn+ssh, svn+https and checkouts without a user
- name.</p></item>
-
- <tag><var>git://host/path</var></tag>
- <item> <p>The config space checked out from a
- git repository, host can be empty. Also supported is git+http.</p></item>
- </taglist>
-
- If <var>FAI_CONFIG_SRC</var> is undefined in &fc, then the
- default is to use an NFS mount from the fai install server
- onto the install client. It's the same as
- <tt>nfs://`hostname`/$FAI_CONFIGDIR</tt> with the host name
- determined on the install server. Remember that this directory
- must be exported to all install clients, so that all files
- can be read by root. </p></item>
-
-
- <tag><var>FAI_DEBMIRROR</var></tag>
- <item>
- <p> If you have NFS access to your local Debian mirror,
- specify the remote file system. It will be mounted to
- <var>$MNTPOINT</var>, which must also be defined. It's
- not needed if you use access via FTP or HTTP.</p>
- </item>
- </taglist><p>
-
-
-The content of <file>/etc/fai/apt/sources.list</file> and <var>FAI_DEBMIRROR</var>
-are used by the install server and also by the clients. If your
-install server has multiple network cards and different host names for
-each card (as for a Beowulf server), use the install
-server name which is known by the install clients.<p>
-
-FAI uses <manref name="debootstrap" section="8"> and <manref name="apt-get" section="8"> to create the nfsroot
-file system in <file>/srv/fai/nfsroot</file>. It needs about
-&nfsrootsize; of free disk space. After editing &fc; and &mfnc; call
-<prgn>fai-setup</prgn>.
-
-<!--MT: smaller font, if possible-->
-&faisetup;
-
-<p>
-A complete example of <file>fai-setup.log</file> is available on the FAI web page.
-It's important that you find both lines that are marked with an
-asterisk in your output. Otherwise something went wrong. If you'll get a lot of blank
-lines, it's likely that you are using <tt>konsole</tt>, the X terminal
-emulation for KDE which has a bug. Try again using <tt>xterm</tt>.
-<!--MT: this problem should be debugged-->
-<p>
-The warning messages from dpkg about dependency problems can be ignored.
-If you have problems running fai-setup, they usually stem from
-<manref name="make-fai-nfsroot" section="8">.
-Adding '-v' gives you a more verbose output which may help you
-pinpoint the error. The output is written to <file>/var/log/fai/make-fai-nfsroot.log</file>.
-It may help to enter the chroot environment manually
-<example>
-sudo chroot /srv/fai/nfsroot/live/filesystem.dir
-</example>
-The setup routine adds some lines to <file>/etc/exports</file> to export
-the nfsroot and the configuration space to all hosts that belong to
-the netgroup <em>faiclients</em>. If you already export a parent directory
-of these directories, you may comment out these lines, since the kernel NFS
-server has problems exporting a directory and one of its
-subdirectories with different options.
-
-All install clients must belong to this netgroup,
-in order to mount these directories successfully. Netgroups are
-defined in <file>/etc/netgroup</file> or in the corresponding NIS
-map. An example for the netgroup file can be found in
-<file>/usr/share/doc/fai-doc/examples/etc/netgroup</file>. For more
-information, read the manual pages <manref name="netgroup"
-section="5"> and the NIS HOWTO. After changing the netgroups, the NFS
-server has to reload its configuration. Use the following
-command:
-
-<example>
-faiserver# /etc/init.d/nfs-kernel-server reload
-</example>
-
-<p>
-The setup also creates the account <tt>fai</tt> (defined by <var>$LOGUSER</var>)
-if not already available. So you can add a user before calling <manref
-name="fai-setup" section="8"> using the command
-<manref name="adduser" section="8"> and use this as your local account
-for saving log files. The log
-files of all install clients are saved to the home directory of this
-account. If you boot from network card, you should change the primary
-group of this account, so this account has write permissions to
-<file>/srv/tftp/fai</file> in order to change the symbolic links to the kernel
-image which is booted by a client.
-<!--MT: the log files - which ones? Give a little explanation here-->
-
-
-<p>
-After that, FAI is installed successfully on your server, but has no
-configuration for the install clients. Start with the examples from
-<tt> /usr/share/doc/fai-doc/examples/simple/</tt> using the copy command above
-and read <ref id="config">. Before you can set up a DHCP or BOOTP
-daemon, you should collect some network information of all your
-install clients. This is described in section <ref id="mac">.
-<p>
-When you make changes to &fc;, &mfnc; the nfsroot has to be rebuilt by calling <manref
-name="make-fai-nfsroot" section="8">. If you only like to install a new kernel to
-the nfsroot add the flags <tt>-k</tt> or <tt>-K</tt> to
-<tt>make-fai-nfsroot</tt>. This will not recreate your nfsroot, but
-only updates your kernel and kernel modules inside the nfsroot or add
-additional packages into the nfsroot.
-
-<sect1 id=troublefaisetup> Troubleshooting the setup<p>
-
-The setup of FAI adds the <tt>fai</tt> account, exports file systems and calls
-<manref name="make-fai-nfsroot" section="8">. If you call
-<tt>make-fai-nfsroot -v</tt> you
-will see more messages. When using a local Debian mirror, it's
-important that the install server can mount this directory via
-NFS. If this mount fails, check <file>/etc/exports</file> and <file>/etc/netgroup</file>.
-
-
-<chapt id="booting">Preparing booting <p>
-
-Before booting the client for the first time, you have to choose which medium you
-use for booting. Normally, you will configure the computer
-to boot via network card. The preferred method for booting is using
-PXE. PXE is the Preboot Execution Environment which most modern network cards support.
-Also booting from CD-ROM or from an USB stick is easy to set up.
-
-<sect id="nicboot">Enabling PXE on a 3Com network card with boot PROM
-<p>
-If you have a 3Com network card that is equipped with a boot ROM by
-Lanworks Technologies or already includes the DynamicAccess Managed PC
-Boot Agent (MBA) software<footnote> <p><httpsite>support.3com.com/</httpsite>
-<httppath>infodeli/tools/nic/mba.htm</httppath></p></footnote>, you
-can enter the MBA setup by typing <tt>Ctrl+Alt+B</tt> during boot. The
-setup should look like this:
-
-<!--MT: smaller font, if possible-->
-<example>
-Managed PC Boot Agent (MBA) v4.00
-(C) Copyright 1999 Lanworks Technologies Co. a subsidiary of 3Com Corporation
-All rights reserved.
-===============================================================================
- Configuration
-
-Boot Method: PXE
-
-Default Boot: Network
-Local Boot: Enabled
-Config Message: Enabled
-Message Timeout: 3 Seconds
-Boot Failure Prompt: Wait for timeout
-===============================================================================
- Use cursor keys to edit: Up/Down change field, Left/Right change value
- ESC to quit, F9 restore previous settings, F10 to save
-</example>
-
-Set the boot method to <tt>PXE</tt> (do not use RPL or BOOTP) and
-enable local boot in this
-menu. So the first boot device will be the network card using PXE, and
-the second should be the local hard disk. This has to be configured in
-the BIOS of your computer.
-
-<sect id="pxeboot">Booting from network card with a PXE conforming boot ROM<p>
-Most modern bootable network cards support the PXE boot environment.
-Some network cards (e.g. on notebooks) have a fixed
-boot configuration, so they can only use the PXE boot protocol. This requires a PXE
-Linux boot loader and a special version of the <tt>TFTP</tt> daemon,
-which is available in the Debian package <package>tftpd-hpa</package>.
-
-First install following additional needed packages:
-
-<example>
-# apt-get install dhcp3-server syslinux-common tftpd-hpa
-</example>
-
-Then set up the DHCP daemon. A sample configuration file can be
-found in <file>/usr/share/doc/fai-doc/examples/etc/dhcpd.conf</file>. Copy
-this file to <file>/etc/dhcp3/dhcpd.conf</file>.
-Then enable the special tftp daemon
-using this line in file <file>/etc/inetd.conf</file>:
-<example>
-tftp dgram udp wait root /usr/sbin/in.tftpd in.tftpd -s /srv/tftp/fai
-</example>
-
-The install client then loads the pxelinux boot loader which receives
-its configuration via TFTP from a file in the directory
-<file>/srv/tftp/fai/pxelinux.cfg</file> (defined by the variable
-<var>TFTPROOT</var> in &mfnc;). Using the command <manref
-name="fai-chboot" section="8"> you can
-define which kernel will be loaded by the PXE Linux loader and
-which additional parameters are passed to this kernel. You should
-read the manual pages, which give you some good examples.
-<!--MT: $TFTPROOT only tells FAI where the tftpd directory is found, but what
-you are saying here rather refers to the entry in inetd.conf-->
-
-See <file>/usr/share/doc/syslinux/pxelinux.doc</file> for more detailed
-information.
-
-<sect id="bootfloppy">Creating a boot floppy
-<p>
-
-If your network card can't boot by itself, you can create a small
- boot floppy that uses etherboot, which
-will provide the PXE feature for your network card. So you can
-use DHCP and TFTP to get the install kernel that was created with
-<manref name="mknbi-linux" section="8">. A lot of ethernet cards
-support booting via ethernet if a special boot EPROM is inserted or
-booted from floppy provided by <httpsite>rom-o-matic.net/</httpsite>. In
-depth documentation about booting via ethernet may be found at
-<httpsite>www.etherboot.org</httpsite>.
-
-
-<sect id="cdboot">Booting from a CD-ROM<p>
-
-It's possible to perform an automatic installation from CD-ROM without
-an install server. The CD-ROM contains all data needed for the
-installation. The command <manref name="fai-cd" section="8"> puts the
-nfsroot, the configuration space and a subset of the Debian mirror
-onto a CD-ROM. The partial mirror is created using the command
-<manref name="fai-mirror" section="1"> which contains all packages
-that are used by the classes used in your configuration space.
-
-A sample ISO image is available at
-<httpsite>www.informatik.uni-koeln.de</httpsite><httppath>/fai/fai-cd/</httppath>.
-
-<sect id="usbboot">Booting from USB stick<p>
-
-Using the command <manref name="fai-cd" section="8"> you can also
-create a bootable USB stick. First format your stick with an ext2 file
-system (ext3 makes no sense on flash memory devices). Then mount it.
-After that call:
-<tt>fai-cd -m /path/to/mirror -u /path/to/mounted/stick</tt>
-Then unmount the USB stick.
-
-The USB stick must be formatted with an ext2 file system. VFAT is not
-yet tested. Currently the file system that will be written onto the
-stick is not compressed.
-
-<sect id="mac">Collecting Ethernet addresses<p>
-
-Now it's time to boot your install clients for the first time. They
-will fail to boot completely, because no BOOTP or DHCP daemon is running yet or
-recognizes the hosts. But you can use this first boot attempt to
-easily collect all Ethernet addresses of the network cards.
-<p>
-
-You have to collect all Ethernet (MAC) addresses of the install clients
-and assign a host name and IP address to each client. To collect
- all MAC addresses, now boot all your install clients. While the
-install clients are booting, they send broadcast packets to the LAN. You
-can log the MAC addresses of these hosts by running the following
-command simultaneously on the server:
-
-<example># tcpdump -qtel broadcast and port bootpc >/tmp/mac.list</example>
-
-<p>
-After the hosts have been sent some broadcast packets (they will fail
-to boot because <prgn>bootpd</prgn> isn't running or does not recognize the MAC
-address yet) abort <prgn>tcpdump</prgn> by typing <tt>ctrl-c</tt>. You get a list
-of all unique MAC addresses with these commands:
-
-<example># perl -ane 'print "\U$F[0]\n"' /tmp/mac.lis|sort|uniq</example>
-
-After that, you only have to assign these MAC addresses to host names
-and IP addresses (<file>/etc/ethers</file> and <file>/etc/hosts</file>
-or corresponding NIS maps). With this information you can configure
-your <prgn>BOOTP</prgn> or <prgn>DHCP</prgn> daemon (see the section
-<ref id="bootptab">). I recommend to write the MAC addresses (last
-three bytes will suffice if you have network cards from the same
-vendor) and the host name in the front of each chassis.
-
-<sect id=bootptab>Configuration of the BOOTP daemon<p>
-You should only use this method if you can't use a DHCP server, since
-it's easier to create and manage the configuration for DHCP.
-An example configuration for the BOOTP daemon can be found in
-<file>/usr/share/doc/fai-doc/examples/etc/bootptab</file>.
-
-<example>
-# /etc/bootptab example for FAI
-# replace FAISERVER with the name of your install server
-
-.faiglobal:\
- :ms=1024:\
- :hd=/srv/tftp/fai:\
- :hn:bs=auto:\
- :rp=/srv/fai/nfsroot:
-
-.failocal:\
- :tc=.faiglobal:\
- :sa=FAISERVER:\
- :ts=FAISERVER:\
- :sm=255.255.255.0:\
- :gw=134.95.9.254:\
- :dn=informatik.uni-koeln.de:\
- :ds=134.95.9.136,134.95.100.209,134.95.100.208,134.95.140.208:\
- :nt=time.rrz.uni-koeln.de,time2.rrz.uni-koeln.de:
-
-# now one entry for each install client
-demohost:ha=0x00105A240012:bf=demohost:tc=.failocal:T172="verbose sshd createvt debug":
-ant01:ha=0x00105A000000:bf=ant01:tc=.failocal:T172="sshd":
-</example>
-<!--MT: break the lines of the host entries as well-->
-
-Insert one entry for each install client at the end of this file as
-done for the hosts <em>demohost</em> and <em>ant01</em>. Replace the string
-<tt>FAISERVER</tt> with the name of your install server. If the
-install server has multiple network cards and host names, use the host
-name of the network card to which the install clients are
-connected. Then adjust the other network tags (<tt>sm, gw, dn,
-ds</tt>) to your local needs.
-
-<taglist>
- <tag>sm:</tag> <item> <p>Subnet mask</p> </item>
- <tag>gw:</tag> <item> <p>Default gateway / router</p> </item>
- <tag>dn:</tag> <item> <p>Domain name</p> </item>
- <tag>ds:</tag> <item> <p>List of DNS server. The
- <file>/etc/resolv.conf</file> file will be created using this list
- of DNS servers and the domain name.
- <tag>T172:</tag> <item> <p>List of <var>FAI_FLAGS</var>;
- e.g. verbose, debug, reboot, createvt, sshd</p> </item>
- </taglist>
-
-The tag for time servers (<tt>nt</tt>) are
-optional. Tags with prefix <tt>T</tt> (starting from T170) are generic
-tags which are used to transfer some FAI specific data to the
-clients<footnote>T170=FAI_LOCATION (now defined in
-<file>fai.conf</file>) and T171=FAI_ACTION. You can define theses
-variables in a class/*.var script. But for backward compatibility, you
-can define theses variables also from a BOOTP or DHCP
-server.</footnote>
-
-The list of <var>FAI_FLAGS</var> can be space or comma
-separated. <var>FAI_FLAGS</var> in <file>bootptab</file> must be
-separated by whitespace. If you define <var>FAI_FLAGS</var> as
-an additional kernel parameter, the flags must be separated with a
-comma.
-If you do not have full control over the BOOTP or DHCP daemon (because
-this service is managed by a central service group) you can also
-define the variable <var>FAI_ACTION</var> in
-the <file>$FAI/class/*.var</file> scripts.
-
-When you have created your <file>bootptab</file> file, you have to
-enable the BOOTP daemon once. It's installed but Debian does not enable it
-by default. Edit <file>/etc/inetd.conf</file> and remove the comment
-(the hash) in the line containing <tt>#bootps</tt>. Then tell
-<prgn>inetd</prgn> to reload its configuration.
-
-<example># /etc/init.d/inetd reload</example>
-
-The BOOTP daemon automatically reloads the configuration file if any changes are
-made to it. The daemon for DHCP must always be manually restarted
-after changes to the configuration file are made.
-
-<p>
-Now it's time to boot all install clients again!
-FAI can perform several actions when the client is booting. This action
-is defined in the variable <var>FAI_ACTION</var>.
-Be very careful if you set <var>FAI_ACTION </var> to
-<em>install</em>. This can destroy all your data on the install
-client, indeed most time it should do this ;-). It's recommended to change this only
-on a per-client base in the BOOTP configuration. Do not change it in
-the section <tt>.failocal</tt> in <file>/etc/bootptab</file>, which
-is a definition for all clients.
-
-<sect1 id=troublebootp>Troubleshooting BOOTP daemon<p>
-The BOOTP daemon can also be started in debug mode if it is not
-enabled in <file>inetd.conf</file>:
-<example># bootpd -d7</example>
-
-<sect id="bootdhcp">Configuration of the DHCP daemon <p>
-An example for <manref name="dhcpd.conf" section="5"> is available in
-<file>/usr/share/doc/fai-doc/examples/etc/dhcpd.conf</file>, which is working with
-version 3.x of the DHCP daemon. Start using this example
-and look at all options used therein. The only FAI specific
-information inside this configuration file is to set <tt>filename</tt> to
-<tt>pxelinux.0</tt> and to set <tt>next-server</tt> and
-<tt>server-name</tt>. All other information is only network related
-data, which is used in almost all DHCP configurations.
-
-If you make any changes
-to the DHCP daemon configuration, you must restart the daemon.
-<example># /etc/init.d/dhcp3-server restart</example>
-By default, the DHCP daemon
-writes its log files to <file>/var/log/daemon.log</file>.
-The command <manref name="fai-chboot" section="8"> is used for creating a per host
-configuration for the pxelinux environment.
-
-
-<sect id="bootmesg">Boot messages <p>
-
-When booting from network card with PXE you will see:
-
-&bootexample;
-
-When the copyright message of FAI is shown, the install client has mounted
-the nfsroot<footnote> <p><file>/srv/fai/nfsroot</file> from the
-install server</p> </footnote> to the clients' root directory. This is
-the whole file system for the client at this moment.
-
-After <tt>task_confdir</tt> is executed, the configuration space is
-mounted or received from a CVS repository.
-
-Before the installation is started (<var>FAI_ACTION=install</var>) the computer
-beeps three times. So, be careful when you hear three beeps
-but you do not want to perform an installation!
-
-<sect1 id=booterror>Troubleshooting the boot messages<p>
-
-This is the error message you will see, when your network card is
-working, but the install server does not export the configuration
-space directory to the install clients, mostly a problem of missing
-permissions on the server side.
-<example>
-Begin: Mounting root file system... ...
-eth0: link up
-
-BusyBox v1.10.2 (Debian 1:1.10.2-1) Built-in shell (ash)
-Enter 'help' for a list of built-in commands.
-/bin/sh: can't access tty: job control turned off
-(initramfs)
-</example>
-You will get a shell prompt and can look at the log files, for
-examples <file>/live.log</file> or <file>/tmp/net-eth0.conf</file>.
-<p>
-Use the following command on the install server to see which directories are exported
-from the install server (named faiserver):
-<example>showmount -e faiserver</example>
-
-<p>
-
-The following error message indicates that your install client doesn't
-get an answer from a DHCP server. Check your cables or start the
-<manref name="dhcpd" section="8"> daemon with the debug flag enabled.
-<example>
-PXE-E51: No DHCP or BOOTP offers received
-Network boot aborted
-</example>
-
-These are the messages when you are using the BOOTP method and no
-BOOTP server replies.
-<example>
-Sending BOOTP requests ........ timed out!
-IP-Config: Retrying forever (NFS root)...
-</example>
-
-If you get the following error message, the install kernel could not
-detect your network card, for example because of a missing driver:
-<example>
-Begin: Mounting root file system... ...
-Kernel panic - not syncing: Attempted to kill init!
-</example>
-Check the initrd in the nfsroot if the kernel driver of your network
-card is included there.
-
-<sect id="sysinfo">Collecting other system information
-<p>
-
-Now the clients have booted with <var>FAI_ACTION</var> set to <em>sysinfo</em>. Type
-<tt>ctrl-c</tt> to get a shell or use <tt>Alt-F2</tt> or
-<tt>Alt-F3</tt> and you will get another console terminal, if you have added <tt>createvt</tt>
-to <var>FAI_FLAGS</var>.
-
-Remote login is available via the secure shell if <tt>sshd</tt> is
-added to <var>FAI_FLAGS</var>. The encrypted password is set with the
-variable <var>FAI_ROOTPW</var> in &mfnc; and defaults to "fai". You can
-create the encrypted password using <manref name="mkpasswd"
-section="1"> and use the <manref name="crypt" section="3"> or md5 algorithm. This
-is only the root password during the installation process, not for the
-new installed system. You can also log in without a password when
-using <var> SSH_IDENTITY</var>. To log in from your server to the
-install client (named demohost in this example) use:
-
-<example>> ssh root at demohost
-Warning: Permanently added 'demohost,134.95.9.200' to the list of known hosts.
-root at demohost's password:
-</example>
-
-
-You now have a running Linux system on the install client
-without using the local hard disk. Use this as a rescue system if
-your local disk is damaged or the computer can't boot properly from
-hard disk. You will get a shell and you can execute various commands
-(<prgn>dmesg</prgn>, <prgn>lsmod</prgn>, <prgn>df</prgn>,
-<prgn>lspci</prgn>, ...). Look at the log file in
-<file>/tmp/fai</file>. There you can find much information about the boot
-process.
-
-All log files from <file>/tmp/fai</file> are also written to the
-<var>$LOGSERVER</var> (if not defined: the server defined by
-<var>$SERVER</var> from <tt>get-boot-info</tt>) into the
-directory <tt>~fai/demohost/sysinfo/</tt><footnote>More general:
-<tt>~$LOGUSER/$HOSTNAME/$FAI_ACTION/</tt>. Two additional symbolic
-links are created. The symlink <file>last</file> points to the log
-directory of the last fai action performed. The symlinks
-<file>last-install</file> and <file>last-sysinfo</file> point to the
-directory with of the last corresponding action.
-<!--MT: I think it should be <tt>~$LOGUSER/$HOSTNAME/$FAI_ACTION-`DATE`/</tt>-->
-
-Examples of the log
-files can be found on the FAI homepage.
-</footnote>
-
-<p>
-FAI mounts all file systems it finds on
-the local disks read only. It also tells you on which partition a file
-<file>/etc/fstab</file> exists. When only one file system table is found, the
-partitions are mounted according to this information. Here's an
-example:
-<example>
-demohost:~# df
-Filesystem 1K-blocks Used Available Use% Mounted on
-rootfs 4099064 414088 3645296 11% /
-udev 10240 76 10164 1% /dev
-192.168.1.250:/srv/fai/nfsroot
- 3905600 410976 3454944 11% /live/image
-aufs 4099064 414088 3645296 11% /
-tmpfs 193464 0 193416 0% /live
-tmpfs 193464 3112 190352 2% /live/cow
-faiserver:/srv/fai/config
- 3905600 410976 3454944 11% /var/lib/fai/config
-/dev/sda1 241116 74519 154149 33% /target
-/dev/sda9 4364212 139888 4179988 4% /target/home
-/dev/sda7 553376 16840 536536 4% /target/tmp
-/dev/sda8 2221628 275936 1832840 14% /target/usr
-/dev/sda6 577096 172924 374856 32% /target/var
-aufs 193464 2376 191243 2% /target/dev
-</example>
-
-<strong>This method can be used as a rescue environment!</strong> In the
-future it will be possible to make backups or restore data to existing
-file systems. If you need a file system with read-write access use the
-<prgn>rwmount</prgn> command:
-
-<example>demohost:~# rwmount /target/home</example>
-
-<sect id=checkbootp>Checking parameters from BOOTP and DHCP servers<p>
-
-If the install client boots with action <em>sysinfo</em>, you can also
-check if all information from the BOOTP or DHCP daemons are received
-correctly. The received information is written to
-<file>/tmp/fai/boot.log</file>. An example of the result of a DHCP
-request can be found in <ref id="s1">.
-
-
-<sect id=reboot>Rebooting the computer<p>
-At any time you can reboot the computer using the command
-<prgn>faireboot</prgn>, also if logged in from remote. If the
-installation hasn't finished, use <tt>faireboot -s</tt>, so the log
-files are also copied to the install server.
-
-<chapt id=instprocess>Overview of the installation sequence<p>
-
-The following tasks are performed during an installation after the Linux kernel
-has booted on the install clients.
-
-<enumlist>
- <item> <p>Set up FAI </p> </item>
- <item> <p>Define classes</p> </item>
- <item> <p>Define variables</p> </item>
- <item> <p>Partition local disks</p> </item>
- <item> <p>Create and mount local file systems</p> </item>
- <item> <p>Install software packages</p> </item>
- <item> <p>Call site specific configuration scripts</p> </item>
- <item> <p>Call tests if available</p> </item>
- <item> <p>Save log files</p> </item>
- <item> <p>Reboot the new installed system</p> </item>
- </enumlist>
- <!--MT: debconf, update base missing-->
-
-You can also define additional programs or scripts
-which will be run on particular
-occasions. They are called <tt>hooks</tt>. Hooks can add additional
-functions to the installation process or replace the default subtasks
-of FAI. So it's very easy to
-customize the whole installation process. Hooks are explained in
-detail in <ref id="hooks">.
-
-<p>
-The installation time is determined by the amount of software but also
-by the speed of the processor and hard disk. Here are some sample
-times. All install clients have a 100Mbit network card installed.
-Using a 10 Mbit LAN does not decrease the installation time
-considerably, so the network will not be the bottleneck when
-installing several clients simultaneously.
-
-<example>
-Athlon XP1600+ , 896MB,SCSI disk, 1 GB software 6 min
-AMD-K7 500MHz , 320MB, IDE disk, 780 MB software 12 min
-PentiumPro 200MHz , 128MB, IDE disk, 800 MB software 28 min
-Pentium III 850MHz, 256MB, IDE disk, 820 MB software 10 min
-Pentium III 850MHz, 256MB, IDE disk, 180 MB software 3 min
-</example>
-
-
-<sect id=faimond>Monitoring the installation<p>
-You can monitor the installation of all install clients with the
-command <manref name="faimond" section="8">. All clients check if this
-daemon is running on the install server (or the machine defined by the variable
-<var>monserver</var>. Then, a message is sent when a task starts and
-ends. The fai monitor daemon prints this messages to standard
-output. There's also a graphical frontend available, called
-<prgn>faimond-gui</prgn>.
-
-
-<sect id=bootkernel>Booting the kernel<p>
-The install client receives and loads the kernel and initial RAM disk. The kernel
-boots up and load the RAM disk. It does some hardware detection and
-then tries to figure where the root file system is located. When
-booting from network, this is determined by parameters from additional
-kernel parameters (<tt>root=/dev/nfs</tt> and
-<tt>nfsroot=/srv/fai/nfsroot</tt>). When booting from CD-ROM or USB
-stick the kernel
-and initial RAM disk probes removable devices and tries to figure out
-where the root file system is located. This may also be a compressed
-file system (using squashfs).
-
-After the root file system is mounted read only, it is made writable
-by mounting a RAM disk via aufs (another unionfs) on top of it. So it's possible for
-programms or daemons to write to files inside a read only mounted file system.
-We are using the package <manref name="live-initramfs" section="7"> to
-mount the nfsroot and to make this file system writable using aufs. The package
-<tt>live-initramfs</tt> is only needed inside the nfsroot and adds
-some initramfs hooks.
-
-
-<sect id=isetup>Set up FAI<p>
-<!--MT: CVS, SVN missing-->
-
-After the install client has booted, only the script
-<file>/usr/sbin/fai</file><footnote><p>Since the root file system on
-the clients is mounted via NFS, <prgn>fai</prgn> is located in
-<file>/srv/fai/nfsroot/live/filesystem.dir/usr/sbin</file> on the install server.</p>
-</footnote> is executed. This is the main script which controls the
-sequence of tasks for FAI. No other scripts in
-<file>/etc/init.d/</file> are executed.
-<p>
-Additional parameters are received from the BOOTP or DHCP
-daemon and the configuration space is
-made available via the configured method (an NFS mount by default) from the install server to <file>$FAI</file>. The
-setup is finished after additional virtual terminals are created and
-the secure shell daemon for remote access is started on demand.
-
-<sect id=iclass>Defining classes, variables and loading kernel modules<p>
-
-Now the script <manref name="fai-class" section="1"> is used to define
-classes. Therefore several scripts in <file>$FAI/class/</file> are
-executed to define classes. All scripts matching <tt>[0-9][0-9]*</tt>
-(they start with two digits)
-are executed in alphabetical order. Every word that these scripts
-print to the standard output are interpreted as class names.
-Scripts ending in <tt>.source</tt>
-are sourced, so they can define new classes by adding these classes to
-the variable <var>newclasses</var> (see <file>20-hwdetect.source</file> for an
-<!--MT: 20-hwdetect.source does not really use newclasses-->
-example). The output of these scripts is ignored.
-These classes are defined for the
-install client. You can also say this client belongs to these
-classes. A class is defined or undefined and has no value. Only
-defined classes are of interest for an install client. The description
-of all classes can be found in
-<file>/usr/share/doc/fai-doc/classes_description.txt</file>. It is
-advisable to document the job a new class performs. Then, this
-documentation is the base for composing the whole configuration from classes.
-The scripts <prgn>20-hwdetect.source</prgn> loads kernel modules on
-demand.
-The complete description of all these scripts can be found in <ref id="cscripts">.
-
-<p>
-After defining the classes, every file matching <tt>*.var</tt> with a
-prefix which matches a defined class is executed to define variables.
-There, you should define the variable <var>FAI_ACTION</var> and
-others. By default, <var>FAI_ACTION</var> is defined via the command
-<manref name="fai-chboot" section="8">.
-
-
-<sect id=ipartition>Partitioning local disks, creating file systems<p>
-
-For disk partitioning exactly one disk configuration file from
-<file>$FAI/disk_config</file> is selected using classes. This file
-describes how all the local disks will be partitioned, where
-file systems should be created (and their types like ext2, ext3,
-reiserfs), and how they are mounted. It's also possible to preserve
-the disk layout or to preserve the data on certain partitions.
-
-The old tool for partitioning the hard disks is called
-<prgn>setup_harddisks</prgn>, which uses <prgn>sfdisk</prgn>. The
-format of the configuration file is described in <ref id="diskconfig">.
-With FAI 3.2.8 a new partitioning tool called <manref
-name="setup-storage" section="8"> was added to FAI. It uses <manref
-name="parted" section="8"> for editing the partition table and now has
-support for software RAID and LVM. This tool
-uses a slightly different format for the configuration files in
-<file>disk_config</file>. Read the manual page for a detailed
-description of the new format. The variable <tt>USE_SETUP_STORAGE</tt>
-now determines which tool to use. When set to 1 it uses the new tool
-which is now defined in <file>FAIBASE.var</file> by default.
-
-<p>During the installation process all local file systems are mounted
-relative to <file>/target</file>. For example
-<file>/target/home</file> will become <file>/home</file> in the
-new installed system.
-
-<sect id=ipackages>Installing software packages<p>
-
-When local file systems are created, they are all empty (except for
-preserved partitions). Now the Debian base system and all requested
-software packages are installed on the new file systems. First the
-base archive is unpacked, then the command
-<manref name="install_packages" section="8"> installs all packages using <manref
-name="apt-get" section="8"> or <manref name="aptitude" section="1">
-without any manual interaction needed. If a packages requires another
-package, both commands resolve this dependency by installing the
-required package.
-<p>
-
-Classes are also used when selecting the configuration files in
-<file>$FAI/package_config/</file> for software installation. The
-format of the configuration files is described in <ref
-id="packageconfig">.
-
-<sect id=icscripts>Site specific configuration<p>
-
-After all requested software packages are installed, the system is
-nearly ready to go. But not all default configurations of the software
-packages will meet your site-specific needs. So you can call arbitrary
-scripts which adjust the system configuration. Therefore scripts which
-match a class name in <file>$FAI/scripts</file> will be executed. If
-<file>$FAI/scripts/</file><var>classname/</var> is a directory, all
-scripts that match <tt>[0-9][0-9]*</tt> in this directory are executed. So
-it is possible to have several scripts of different types (shell,
-cfengine, ...) to be executed for one class. FAI comes with some
-examples for these scripts, but you can write your own Bourne, bash,
-Perl, cfengine or expect scripts.
-<p>
-More information about these scripts are described in <ref id="cscripts">.
-
-
-<sect id=itests>Automatic tests<p>
-
-After the customization scripts are executed, FAI will execute some
-tests if available. Using these test, you can check for errors of the
-installation or of the softupdate. Test scripts are called via
-<manref name="fai-do-scripts" section="1"> and should append it's
-messages to <tt>$LOGDIR/test.log</tt>. A Perl module including some
-useful subroutines can be found in <tt>Faitest.pm</tt>. A test can
-also define a new class for executing another tests during next boot
-via the variable <var>ADDCLASSES</var>.
-
-
-<sect id=isavelog>Save log files<p>
-
-When all installation tasks are finished, the log files are written to
-<tt>/var/log/fai/$HOSTNAME/install/</tt> <footnote>
-<p><file>/var/log/fai/localhost/install/</file> is a link to this
-directory.</p> </footnote> on the new system and to the account on the
-install server if <var>$LOGUSER</var> is defined in &fc;. It is also
-possible to specify another host as log saving destination through
-the variable <var>$LOGSERVER</var>. If <var>LOGSERVER</var> is not
-defined, FAI uses the variable <var>SERVER</var> which is only defined
-during an initial installation (by get-boot-info). Make sure to set
-<var>LOGSERVER</var> in a <tt>class/*.var</tt> script if you are using
-the action <tt>softupdate</tt>.
-
- Additionally, two symlinks will
-be created to indicated the last directory written to.
-By default log files will be copied to the log server using scp.
-
-<p>
-You can use other methods to save logs to the remote server. The currently
-selected method is defined by the <var>$FAI_LOGPROTO</var> variable in
-file &fc;:
-<taglist>
- <tag>rsh</tag> <item><p>Use the rcp command to copy the log files to
- the log server.</p></item>
-
- <tag>ftp</tag><item><p>
- This option saves logs to the remote FTP server defined by the
- <var>$LOGSERVER</var> variable (<var>$SERVER</var> value is used if
- not set). Connection to the FTP server is done as user
- <var>$LOGUSER</var> using password <var>$LOGPASSWD</var>. The FTP
- server log directory is defined in <var>$LOGREMOTEDIR</var>. These
- variables are also defined in file &fc;. You need write access for
- the <var>$LOGREMOTEDIR</var> on the FTP server.</p>
-
- <p> All files in the directory <tt>/tmp/fai</tt> are copied to the
- FTP server following this example:
- <tt>ftp://<var>$LOGUSER</var>:<var>$LOGPASSWD</var>@<var>$LOGSERVER</var>/<var>$LOGREMOTEDIR</var>/</tt>.</p>
- </item>
- <tag>none</tag> <item><p>Don't save the log file to the install server.</p></item>
-</taglist>
-</p>
-
-<sect id=ireboot>Reboot the new installed system<p>
-
-At last the system is automatically rebooted if "reboot" was added to
-<var>FAI_FLAGS</var>. Normally this should boot the new installed
-system from its second boot device, the local hard disk. To skip
-booting from network card, you can use the command <manref
-name="fai-chboot" section="8"> to enable localboot.
-
-<chapt id=plan>Plan your installation, and FAI installs your plans<p>
-<p>
-Before starting your installation, you should spend a lot of time in
-planning your installation. When you're happy with your installation
-concept, FAI can do all the boring, repetitive tasks to turn your plans
-into reality. FAI can't do good installations if your concept is
-imperfect or lacks some important details. Start planning the
-installation by answering the following
-questions:
-
-<taglist>
- <tag></tag> <item> <p>Will I create a Beowulf cluster, or do I
- have to install some desktop machines?</p> </item>
- <tag></tag> <item> <p>What does my LAN topology look like?</p> </item>
- <tag></tag> <item> <p>Do I have uniform hardware?
- Will the hardware stay uniform in the future?</p> </item>
- <tag></tag> <item> <p>Does the hardware need a special kernel?</p> </item>
- <tag></tag> <item> <p>How should the hosts be named?</p> </item>
- <tag></tag> <item> <p>How should the local hard disks be partitioned?</p> </item>
- <tag></tag> <item> <p>Which applications will be run by the users?</p> </item>
- <tag></tag> <item> <p>Do the users need a queueing system?</p> </item>
- <!--MT: what is a queueing system?-->
- <tag></tag> <item> <p>What software should be installed?</p> </item>
- <tag></tag> <item> <p>Which daemons should be started, and what
- should the configuration for these look like?</p> </item>
- <tag></tag> <item> <p>Which remote file systems should be mounted?</p> </item>
- <tag></tag> <item> <p>How should backups be performed?</p> </item>
- <tag></tag> <item> <p>Do you have sufficient power supply?</p> </item>
- <!--MT: not a problem of using FAI-->
- <tag></tag> <item> <p>How much heat do the cluster nodes produce and how are
- they cooled?</p> </item>
- <!--MT: not a problem of using FAI-->
-</taglist>
-
-You also have to think about user accounts, printers, a mail system, cron jobs,
-graphic cards, dual boot, NIS, NTP, timezone, keyboard layout,
-exporting and mounting directories via NFS and many other things. So,
-there's a lot to do before starting an installation. And remember
-that knowledge is power, and it's up to you to use it. Installation
-and administration is a process, not a product. FAI can't do things
-you don't tell it to do.
-<p>
-But you need not start from scratch. Look at all files and scripts
-in the configuration space. There are a lot of things you can use for
-your own installation.
-
-A good paper with more aspects of building an infrastructure is
-<url id="http://www.infrastructures.org/papers/bootstrap/">
-"Bootstrapping an Infrastructure".
-
-<chapt id=config>Installation details<p>
-
-<sect id=c3>The configuration space<p>
-
-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 <file>/srv/fai/config</file>
-and its subdirectories. This will be mounted by the install clients to
-<file>/var/lib/fai/config</file>. It's also possible to receive all the
-configuration data from a <manref name="cvs" section="1">,
-subversion (<manref name="svn" section="1">) or Git (<manref name="git" section="1">) repository.
-The following subdirectories are present and include
-several files:
-
-<taglist>
- <tag><tt>class/</tt></tag> <item> <p>Scripts and files to
- define classes and variables and to load kernel modules.</p> </item>
-
- <tag><tt>disk_config/</tt></tag> <item> <p>Configuration
- files for disk partitioning and file system creation.</p> </item>
-
- <tag><tt>debconf/</tt></tag> <item> <p>This directory holds
- all <manref name="debconf" section="8"> data. The format is
- the same that is used by <manref name="debconf-set-selections"
- section="8">.</p> </item>
-
- <tag><tt>package_config/</tt></tag> <item> <p>File with
- lists of software
- packages to be installed or removed.</p> </item>
-
- <tag><tt>scripts/</tt></tag> <item> <p>Script for local site
- customization.</p> </item>
-
- <tag><tt>files/</tt></tag> <item> <p>Files used by
- customization scripts.
- Most files are located in a subtree structure
- which reflects the ordinary directory tree. For example, the
- templates for <file>nsswitch.conf</file> are located in
- <file>$FAI/files/etc/nsswitch.conf</file> and are named
- according to the classes that they should match:
- <file>$FAI/files/etc/nsswitch.conf/NIS</file> is the version
- of <file>/etc/nsswitch.conf</file> 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 <manref
- name="fcopy" section="8"> command.</p> </item>
-
- <tag><tt>basefiles/</tt></tag> <item> <p> Normally the file
-<file>/var/tmp/base.tgz</file> 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
-<file>basefiles/</file> and name it after a class. Then the command
-<manref name="ftar" section="8"> is used to extract the tar file based
-on the classes defined. This is done in task <tt>extrbase</tt>.
-</p>
-</item>
-
- <tag><tt>hooks/</tt></tag> <item> <p>Hooks are user defined
- programs or scripts, which are called during the
- installation process. The can extend or replace the default tasks.</p> </item>
-</taglist>
-
-The main installation command <manref name="fai" section="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
-<file>/usr/share/doc/fai-doc/examples</file>. 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.
-
-<example>
-# cp -a /usr/share/doc/fai-doc/examples/simple/* /srv/fai/config
-# chown -R fai /srv/fai/config
-</example>
-
-These files contain simple configuration for some example
-hosts. Depending on the host name used, your computer will be
-configured as follows:
-
-<taglist>
- <tag>demohost</tag> <item> <p>A machine which needs only a small
- hard disk. This machine is configured with network (as DHCP
- client), and an account demo is created.<p>
-
- <tag>gnomehost</tag> <item> <p>A GNOME desktop is installed, and
- the account demo is created. <p>
-
- <tag>other host names</tag> <item> Hosts with other host name will
- most notably use the classes FAIBASE, DHCPC and GRUB.<p>
-
-</taglist>
-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!
-
-<sect id=tasks>The default tasks<p>
-
-After the kernel has booted, it mounts the root file system via NFS
-from the install server and <manref name="init" section="8"> starts the script
-<file>/usr/sbin/fai</file>. This script controls the
-sequence of the installation. No other scripts in
-<file>/etc/init.d/</file> are used.
-<p>
-
-The installation script uses many subroutines, which are defined in
-<file>/usr/share/fai/subroutines</file>, and an operating system specific
-file <footnote><file>/usr/share/fai/subroutines-linux</file> for Linux.</footnote>.
-All important tasks of the
-installation are called via the subroutine <tt>task</tt>
-appended by the name of the task as an option (e.g. <tt>task
-instsoft</tt>). The subroutine <tt>task</tt> calls hooks with prefix
-<em>name</em> if available and then calls the default task (defined as
-<tt>task_<em>name</em></tt> in <file>subroutines</file>). The default
-task and its hooks can be skipped on demand by using the subroutine
-<tt>skiptask()</tt>.<p>
-
-Now follows the description of all default tasks, listed in the order
-they are executed.
-<taglist>
-
- <tag>confdir</tag> <item><p>The kernel appended parameters define
-variables, the syslog and kernel log daemon are started. The list of
-network devices is stored in <var>$netdevices</var>. Then additional
-parameters are fetched from a DHCP or BOOTP server and also
-additional variables
-are defined. The DNS resolver configuration file is created.
-<p>
-The location of the configuration space is defined by the variable
-<var>$FAI_CONFIG_SRC</var>. You can use NFS, cvs, svn or git to access the
-configuration space. See section <ref id="isetup"> for how to set the variable.
-<!--MT: there is no info about that at id="isetup"-->
-<!--MT: config is also mounted/checked out in this task-->
-<p>
-After that, the file
-<file>$FAI/hooks/subroutines</file> is sourced if it exists. Using
-this file, you can define your own subroutines or override the
-definition of FAI's subroutines.
-
- <tag>setup</tag> <item><p>This task sets the system time, all
- <var>FAI_FLAGS</var> are defined and two additional virtual
- terminals are opened on demand. A secure shell daemon is started
- on demand for remote logins.
-
- <tag>defclass</tag> <item><p>Calls <manref name="fai-class"
- section="1"> to define classes using scripts and
- files in <file>$FAI/class</file> and classes from
- <file>/tmp/fai/additional-classes</file> and the variable
- <var>ADDCLASSES</var>.</p> </item>
-
- <tag>defvar</tag> <item><p>Sources all files
- <file>$FAI/class/*.var</file> for every defined class. If a hook
- has written some variable definitions to the file
- <file>/tmp/fai/additional.var</file>, this file is also
- sourced.</p></item>
-
- <tag>action</tag> <item><p>Depending on the value of
- <var>$FAI_ACTION</var> this subroutine decides which action FAI
- should perform. The default available actions are:
- <tt>sysinfo</tt>, <tt>install</tt> and <tt>softupdate</tt>.
- If <var>$FAI_ACTION</var>
- has another value, a user defined action is called if a file
- <file>$FAI/hooks/$FAI_ACTION</file> exists. So you
- can easily define your own actions.<p>
-
-
- <tag>sysinfo</tag> <item><p>Called when no installation is
- performed but the action is <tt>sysinfo</tt>. It shows information
- about the detected hardware and mounts the local hard disks read
- only to <file>/target/<var>partitionname</var></file> or with regard to a
- <file>fstab</file> file found inside a partition. Log files are
- stored to the install server.</p> </item>
-
- <tag>install</tag> <item><p>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 <file>/tmp/fai/fai.log</file>. If you have any problems
- during installation, look at all files in
- <file>/tmp/fai/</file>. You can find examples of the log files
- for some hosts in the download directory of the FAI homepage.</p>
- </item>
-
- <tag>softupdate</tag> <item>This task, executed inside a running
- system via the <manref name="fai" section="8"> command line interface, performs a softupdate.
- See chapter <ref id=softupdate> for details. </item>
-
- <tag>partition</tag> <item><p>Calls <prgn>setup_harddisk</prgn>
- or <prgn>setup-storage</prgn>
- to partition the hard disks and to create file systems. The task writes variable
- definitions for the root and boot partition and device (<var>$ROOT_PARTITION,
- $BOOT_PARTITION, $BOOT_DEVICE</var>) to
- <file>/tmp/fai/disk_var.sh</file> and creates an <file>fstab</file> file.</p></item>
- <tag>mountdisks</tag> <item><p>Mounts the created partitions
- according to the created <file>/tmp/fai/fstab</file> file relative to
- <var>$FAI_ROOT</var>.</p> </item>
-
- <tag>extrbase</tag> <item><p>Extracts a minimal system after
- that a chroot can be made into it. By default the base tar file
- <file>/var/tmp/base.tgz</file> will be extracted. The command
- <tt>ftar -1v -s $FAI/basefiles /</tt> 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
- <file>base.tgz</file> is a snapshot of a basic Debian system created
- by <manref name="debootstrap" section="8"></p> </item>
-
- <tag>mirror</tag> <item><p>If a local Debian mirror is accessed via NFS
- (when <var>$FAI_DEBMIRROR</var> is defined), this directory will
- be mounted to <var>$MNTPOINT</var>.</p> </item>
-
- <tag>debconf</tag> <item><p>Calls <manref name="fai-debconf"
- section="8"> to set the values for the debconf database.</p> </item>
-
- <tag>prepareapt</tag> <item><p>Set up resolv.conf and some
- other files, for the next task updatebase.</p> </item>
-
- <tag>updatebase</tag> <item><p>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 <manref name="dpkg-divert"
- section="8">.</p>
- </item>
-
- <tag>instsoft</tag> <item><p>Installs the desired software
- packages using class files in
- <file>$FAI/package_config/</file>.</p> </item>
-
- <tag>configure</tag> <item><p>Calls scripts in
- <file>$FAI/scripts/</file> and its subdirectories for every
- defined class.</p> </item>
-
- <tag>finish</tag> <item><p>Unmounts all file systems in the
- new installed system and removes diversions of files
- using the command <prgn>fai-divert</prgn>.</p></item>
-
- <tag>chboot</tag> <item><p>Changes the PXE configuration for a
- host on the install
- server which indicates which kernel image to load on the next
- boot from network card via TFTP. Therefore the
- <manref name="fai-chboot" section="8"> command is executed
- remotely on the install server.</p> </item>
-
- <tag>savelog</tag> <item><p>Saves log files to local disk and to
- the account <var>$LOGUSER</var> on <var>$LOGSERVER</var> (defaults to
- the install server). Currently the file <file>error.log</file>
- will not be copied to the log server.</p> </item>
- <!--MT: why is error.log not copied?-->
-
- <tag>faiend</tag> <item><p>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.</p> </item>
- </taglist>
-
-
-<sect id=s1>The setup routines of the install clients<p>
-
-After the subroutine <prgn>fai_init</prgn> has done some basic
-initialization (create RAM disk, read <file>fai.conf</file> and all
-subroutines definitions, set path, print copyright notice), the setup
-continues by calling the task <tt>confdir</tt> and the task
-<tt>setup</tt>. The command <prgn>get-boot-info</prgn> is called to
-get all information from the BOOTP or DHCP server. This command writes
-the file <file>/tmp/fai/boot.log</file>, which then is sourced to
-define the corresponding global variables. This is an example for this
-log file when using a DHCP server.
-
-&bootlog;
-
-Additional information is passed via the kernel command line or read
-from &fc;. When booting with PXE, command line parameters are created using <manref
-name="fai-chboot" section="8">.
-
-If you do not boot from network card but from CD-ROM or USB stick, you
-may also give network parameters to the kernel via the kernel command
-line. Two interesting parameters are
-
- <example>nfsroot=[<server-ip>:]<root-dir>[,<nfs-options>]</example>
-
- <example>ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf></example>
-Those parameters are described in the documentation of the Linux
-kernel sources in <file>/usr/src/linux/Documentation/nfsroot.txt</file>.
-
-The variable <var>$FAI_FLAGS</var>
-contains a space separated list of flags. The following flags are
-known:
-<taglist>
- <tag>verbose</tag> <item> <p>Create verbose output during
- installation. This should always be the first flag, so consecutive
- definitions of flags will be verbosely displayed.</p> </item>
-
- <tag>debug</tag> <item> <p>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.</p> </item>
-
- <tag>sshd</tag> <item> <p>Start the ssh daemon to enable remote
- logins.</p> </item>
-
- <tag>createvt</tag> <item> <p>Create two virtual terminals and
- execute a bash if <tt>ctrl-c</tt> is typed in the console
- terminal. The additional terminals can be accessed by typing
- <tt>Alt-F2</tt> or <tt>Alt-F3</tt>. Otherwise no terminals are
- available and typing <tt>ctrl-c</tt> 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.</p> </item>
-
- <tag>reboot</tag> <item> <p>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.</p> </item>
-</taglist>
-
-
-<sect id=classc> The class concept<p>
-<!--MT: as marked above, this section should be put in chapter 1-->
-
-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.
-<p>
-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:
-
-<example>
- 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
-</example>
-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 <tt>A</tt>, we
-say the class <tt>A</tt> is defined. A class has no value, it is just
-defined or undefined. Within scripts, the variable <var>$classes</var>
-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 <tt>FTP</tt> 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:
-<enumlist>
- <item><p>Some default classes are defined for every host:
- DEFAULT, LAST and its host name.</p> </item>
- <item><p>Classes may be listed within a file.</p> </item>
- <item><p>Classes may be defined by scripts.</p> </item>
- </enumlist>
-
-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 <file>/usr/share/doc/fai-doc/classes_description.txt</file>.
-<p>
-
-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.
-
-<sect id=s2> Defining classes<p>
-
-The task <em>defclass</em> calls the script <manref
-name="fai-class" section="1"> to define classes. Therefore, scripts
-matching <tt>[0-9][0-9]*</tt> in <tt>$FAI/class</tt> 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 <manref
-name="fai-class" section="1">. <p>
-
-The list of all defined classes is stored in the variable
-<var>$classes</var> and saved to
-<file>/tmp/fai/FAI_CLASSES</file>. The list of all classes is
-transferred to <prgn>cfengine</prgn>, so it can use them too. The
-script <file>10-base-classes</file> (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.
-<example>
-# 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 /etc/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
-</example>
-
-The script <tt>20-hwdetect.source</tt> 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 <file>/tmp/fai/kernel.log</file> and
-on the fourth console terminal by pressing <tt>Alt-F4</tt>.<p>
-
-<sect id=classvariables> Defining variables<p>
-
-The task <tt>defvar</tt> defines the variables for the install
-client. Variables are defined by scripts in
-<tt>class/*.var</tt>. All global variables can be set in
-<file>DEFAULT.var</file>. For certain groups of hosts use a class file
-or for a single host use the file
-<var>$HOSTNAME</var><tt>.var</tt>. 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:
-
-<taglist>
- <tag>FAI_ACTION</tag> <item> <p>Set the action fai should
- perform. Normally this is done by <manref name="fai-chboot"
- section="8">. If you can't use this command and are not using a
- BOOTP server, define it in the script <file>LAST.var</file>.
-
- <tag>CONSOLEFONT</tag> <item> <p>Is the font which is loaded during
- installation by <manref name="consolechars" section="8">.</p> </item>
-
- <tag>KEYMAP</tag> <item> <p>Defines the keyboard map files in
- <file>/usr/share/keymaps</file> and <file>$FAI/files</file>. You
- need not specify the complete path, since this file will be located
- automatically.</p> </item>
-
- <tag>ROOTPW</tag> <item> <p>The encrypted root password for the new
- system. You can use <manref name="crypt" section="3"> or md5
- encryption for the password.</p> </item>
-
- <tag>UTC</tag> <item> <p>Set hardware clock to UTC if
- <tt>$UTC=yes</tt>. Otherwise set clock to local time. See <manref
- name="clock" section="8"> for more information.</p> </item>
-
- <tag>TIMEZONE</tag> <item> <p>Is the file relative to
- <file>/usr/share/zoneinfo/</file> which indicates your time
- zone.</p> </item>
-
- <tag>MODULESLIST</tag> <item> <p>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).</p>
- </item>
-
- <tag>USE_SETUP_STORAGE</tag> <item> <p>If set to one (the default
- when using the class <tt>FAIBASE</tt> the new partitioning tool <manref
- name="setup-storage" section="8"> will be used. Otherwise the old
- <prgn>setup_harddisks</prgn> program is used.</p>
- </item>
-
-</taglist>
-
-<sect id=diskconfig>Hard disk configuration<p>
-This section describes the old format of the configuration files in <tt>disk_config</tt>.
-Read the manual page of <manref name="setup-storage" section="8"> for a detailed
-description of the new format.
-<p>
-
-The script <prgn>setup_harddisks</prgn> partitions and formats
-the local disks. It uses all configuration files in
-<file>$FAI/disk_config/</file> which are also defined as classes.
-Lines beginning with # are comments. The config file
-<file>$FAI/disk_config/FAIBASE</file> 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 <footnote><p>Currently
-this script uses the command <tt>sfdisk(8)</tt>, which isn't available
-on SUN SPARC, IA64 and PowerPC.</p> </footnote>, use a hook instead. The hook should
-write the new partition table, create the file systems and create the
-files <file>/tmp/fai/fstab</file> and <file>/tmp/fai/disk_var.sh</file>, which
-contains definitions of boot and root partitions.
-
-<p>
-The following example is a configuration for the first IDE disk <tt>disk1</tt>
-and for the second SCSI disk <tt>disk2</tt> The numbering of the disks comes
-from the order in <file>/proc/partitions</file>.
-
-<example>
-# <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
-</example>
-
-Every disk configuration starts with the command <tt>disk_config</tt>
-followed by <tt>diskX</tt> where <tt>X</tt> is the number of the HDD. The
-Linux device names <file>/dev/hda</file> and <file>/dev/sda</file>
-correspond to <tt>disk1</tt>, <tt>disk2</tt> corresponds to
-<file>/dev/hdb</file> and <file>/dev/sdb</file> and so on.
-<p>
-After <tt>disk_config</tt> one line containing the type, mount point
-and size is added for each partition on the hard disk. Mount options
-and additional parameters for <prgn>mke2fs</prgn> -- separated from
-the mount options by a semicolon -- can be added.
-
-<taglist>
- <tag>Type</tag> <item> <p>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.
- <p>
- 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 <tt>disk1</tt> in the example above.
-
- <tag>Mount point</tag> <item> <p> The mount point is the full path
- (beginning with a slash) for the file system. The value <tt>swap</tt>
- defines a Linux swap partition. Both types will be automatically
- added to <file>/etc/fstab</file>. A dash (<tt>-</tt>) indicates that
- the partition will not be mounted and can be used for other types of
- file systems (FAT, NTFS, UFS, MINIX, ...)
-
- <tag>Size</tag> <item> <p> 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:
- <example>
- "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
- </example>
- <p>
- 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
- <tt>preserve<no></tt> will be described later.
- <p>
- Calculating the partition size:
- If an interval is defined for several partition sizes, the script
- maximizes the values by preserving the ratio between them.
-
-
- <tag>Mount options</tag> <item> <p>The mount options will be copied
- to <file>/etc/fstab</file>. An empty field sets the option to
- <tt>defaults</tt> (see <manref name="mount" section="8">).
-
-
- <tag>Extra options</tag> <item> <p>The last field is a space
- separated extra options list. The following options are known:
- <example>
-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.
- </example>
- <p>
- The order of the extra options is not relevant. For more information
- see <manref name="mke2fs" section="8">.
- <p>
- Thus, we have the following interactions between <tt>-j</tt>,
- <tt>ext2</tt> and <tt>ext3</tt> :
- <example>
-<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!!
- </example>
- <p>
- Using <tt>auto</tt> in the fstab for ext3 file systems enables a
- non-ext3-enabled kernel or tool to cope with these partitions.
-</taglist>
-
-<p>
-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 <tt>preserve<no></tt> The number
-<tt><no></tt> is the device number (as in <file>/dev/hda<no></file>,
-or see the output of <prgn>df</prgn>) of the partition. Primary partitions
-are numbered from one to four, the numbers for logical partitions
-begin at five.
-<p>
-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.
-<p>
-In the following example, the partition numbers (= device number) are also
-shown for disk <tt>disk2</tt>:
-
-<example>
-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
-</example>
-
-<p>
-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 <file>/dev/hda7</file>
-you have to insert a minimum of two logical partitions before it.
-
-<p>
-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
-<file>/home</file> or <file>/var/log</file> or
-<file>/var/lib/mysql</file> or whatever. You can even lazyformat
-the swap partition to gain a minor installation speed improvement
-after the first installation!
-
-<p>
-If you have a separate <file>/boot</file> partition, you must add the
-extra option <tt>boot</tt> to make it your boot partition. Otherwise
-your system will not be bootable. By default (if no boot option was
-specified) the root partition (<file>/</file>) will become the boot
-partition. <prgn>setup_harddisks</prgn> will write some variables
-containing the information about boot partition and boot device to
-<file>/tmp/fai/disk_var.sh</file>.
-<!--MT: I think you did not say how to preserve data-->
-
-<sect id=packageconfig>Software package configuration<p>
-<!--MT: This section is pretty much a chaos:
- - which commands belong to which package tools
- - you say something about PRELOADRM and PRELOAD commands, but give no example
- and don't list them otherwise
--->
-The script <manref name="install_packages" section="8"> installs the selected software
-packages. It uses all configuration files in <file>$FAI/package_config</file>
-whose file name matches a defined class. The syntax is very
-simple.
-
-<example>
-# 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
-</example>
-
-Comments are starting with a hash (#) and are ending at the end of
-the line. Every command begins with the word <tt>PACKAGES</tt>
-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 <tt>install_packages -H</tt>.
-Supported package tools are: <tt>aptitude, apt-get, smart, y2pmsh,
-yast, yum, urpm, rpm</tt>
-
-<taglist>
-<tag>hold:</tag> <item> <p>Put a package on hold. This package will
-not be handled by dpkg, e.g not upgraded.</p> </item>
-
-<tag>install:</tag> <item> <p>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.</p> </item>
-
-<tag>remove:</tag> <item> <p>Remove all packages that are specified in
-the following lines. Append a + to the package name if the package
-should be installed.</p> </item>
-
-<tag>taskinst:</tag> <item> <p>Install all packages belonging to the
-tasks that are specified in the following lines using <manref
-name="tasksel" section="1">. You can also use <tt>aptitude</tt> for
-installing tasks.</p> </item>
-
-<tag>aptitude:</tag> <item> <p>Install all packages with
-the command <prgn>aptitude</prgn>. This will be the default in the future
-and may replace apt-get and taskinst. Aptitude can also install task
-packages.</p> </item>
-
-<tag>aptitude-r:</tag> <item> <p>Same as aptitude with option
-<tt>--with-recommends</tt>.
-
-<tag>unpack:</tag> <item> <p>Download package and unpack only. Do not
-configure the package.
-
-<tag>dselect-upgrade</tag> <item> <p> Set package selections using the
-following lines and install or remove the packages specified. These
-lines are the output of the command <tt>dpkg --get-selections</tt>.
-</taglist>
-
-
-Multiple lines with lists of space separated names of packages follow
-the PACKAGES lines. All dependencies are resolved. Packages with
-suffix <tt>-</tt> (eg. <tt>lilo-</tt>) 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
-<tt>openoffice.org/etch-backports</tt>. You can also specify a certain
-version like <tt>apt=0.3.1</tt>. More information on these features
-are described in <manref name="aptitude" section="8">.
-<p>
-
-A line which contains the <tt>PRELOADRM</tt> commands, downloads a
-file using <manref name="wget" section="1"> into a directory before
-installing the packages. Using the <tt>file:</tt> URL, this file is copied
-from <var>$FAI_ROOT</var> to the download directory.
-For example the package
-<prgn>realplayer</prgn> needs an archive to install the software, so
-this archive is downloaded to the directory <file>/root</file>. After
-installing the packages this file will be removed. If the file
-shouldn't be removed, use the command <tt>PRELOAD</tt> instead.
-
-<p>
-It's possible to append a list of class names after the command for
-apt-get. So this <tt>PACKAGE</tt> 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.
-
-<p>
-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.
-
-
-<p>
-If you specify a package that does not exist this package will be
-removed from the installation list when the command <tt>install</tt>
-is used.
-
-<sect id=cscripts>Scripts in <tt>$FAI/scripts</tt><p>
-
-The default set of scripts in <file>$FAI/scripts</file> 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.
-<p>
-The command <manref name="fai-do-scripts" section="1"> is called to
-execute all scripts in this directory. If a directory with a class
-name exists, all scripts matching <file>[0-9][0-9]*</file> are executed in
-alphabetical order. So it's possible to use scripts of different
-languages (shell, cfengine, Perl,..) for one class.
-
-<sect1 id=shell>Shell scripts<p>
-
-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
-<tt>ifclass</tt>. For copying files with classes, use the command
-<manref name="fcopy" section="8">. If you want to extract an archive
-using classes, use <manref name="ftar" section="8">.
-But now have a look at the scripts and see what they are doing.
-
-<sect1 id=perl>Perl scripts<p>
-Currently no Perl script are used in the simple examples for modifying the system
-configuration.
-
-<sect1 id=expect>Expect scripts<p>
-Currently no expect scripts are used in the simple examples for modifying the system
-configuration.
-
-<sect1 id=cfengine>Cfengine scripts<p>
-
-Cfengine has a rich set of functions to edit existing configuration
-files, e.g <tt>LocateLineMatching, ReplaceAll, InsertLine,
-AppendIfNoSuchLine, HashCommentLinesContaining</tt>. 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 <manref
-name="cfengine" section="8"> or at the cfengine homepage
-<httpsite>www.cfengine.org</httpsite>.
-
-
-<sect id=changeboot>Changing the boot device<p>
-
-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.
-<!--MT: recently, there has been some discussion on linux-fai, add a link to the
-archives-->
-<p>
-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 <manref name="fai-chboot" section="8">.
-
-Here is how to set up a 3Com network card as first boot device.
-Enable LAN as first boot device in the BIOS.
-
-<example>
-Boot From LAN First: Enabled
-Boot Sequence : C only
-</example>
-
-Then enter the MBA setup of the 3Com network card and change it as follows:
-<example>
-Default Boot Local
-Local Boot Enabled
-Message Timeout 3 Seconds
-Boot Failure Prompt Wait for timeout
-Boot Failure Next boot device
-</example>
-
-This will enable the first IDE hard disk as second boot device after
-the network card.
-
-<sect id=hooks>Hooks<p>
-
-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 <tt>debug</tt> is included in <var>$FAI_FLAG</var> the option
-<tt>-d</tt> is passed to all hooks, so you can debug your own hooks.
-If some default tasks should be skipped, use the subroutine
-<tt>skiptask</tt> and a list of default tasks as parameters. The
-example <file>partition.DISKLESS</file> skips some default tasks.
-<p>
-
-
-The directory <file>$FAI/hooks/</file> 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 <file>partition.DISKLESS</file> is called for every client
-belonging to the class <tt>DISKLESS</tt> 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 <tt>/tmp/fai/fstab</tt>.
-After that, the installation process will not try to partition and
-format a local hard disk, because a file <file>/tmp/fai/fstab</file>
-already exists.
-<p>
-A hook of the form <tt>hookprefix.classname</tt> 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 <tt>.source</tt> (e.g. <file>partition.DEFAULT.source</file>) must
-be Bourne shell scripts and are sourced. So it's possible to
-redefine variables for the installation scripts.
-<p>
-
-In the first part of FAI, all hooks with prefix <tt>confdir</tt> are called.
-Since the configuration directory <file>$FAI</file> is mounted in the
-default task <tt>confdir</tt>, the hooks for this task are the only
-hooks located in <var>$nfsroot</var><file>$FAI/hooks</file> on the
-install server. All other hooks are found in
-<file>$FAI_CONFIGDIR/hooks</file> on the install server.
-<!--MT: what about softupdate?-->
-
-All hooks that are called before classes are defined can only use the
-following classes: <tt>DEFAULT $HOSTNAME LAST</tt>. If a hook for
-class <tt>DEFAULT</tt> should only be called if no hook for class
-<var>$HOSTNAME</var> is available, insert these lines to the default
-hook:
-
-<example>
-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
-.
-.
-</example>
-
-
-<p> Some examples for what hooks could be used:
-
-<list>
-<item> <p>Use <prgn>ssh</prgn> in the very beginning to verify that
-you mounted the configuration from the correct server and not a
-possible spoofing host.</p></item>
-
-<item> <p>Do not mount the configuration directory, instead get a
-compressed archive via HTTP and extract it into a
-new RAM disk, then redefine <var>$FAI_LOCATION</var>.</p></item>
-
-<item> <p>Load kernel modules before classes are defined
-in <file>$FAI/class</file>. </p></item>
-
-<item> <p>Send an email to the administrator if the installation is finished.</p></item>
-
-<item> <p>Install a diskless client and skip local disk
-partitioning. See <file>hooks/partition.DISKLESS</file>.</p></item>
-
-<item> <p>Partition the hard disk on an IA64 system, which needs a
-special partition table type that must be created with <manref
-name="parted" section="8">.</p></item>
-</list>
-
-<sect id=errors>Looking for errors<p>
-If the client can't successfully boot from the network card, use
-<manref name="tcpdump" section="8"> to look for Ethernet packets
-between the install server and the client. Search also for entries in
-several log files made by <manref name="tftpd" section="8">,
-<manref name="dhcpd3" section="8"> or <manref name="bootpd" section="8">:
-
-<example>egrep "tftpd|bootpd|dhcpd" /var/log/*</example>
-
-If the installation process finishes, the hook
-<file>savelog.LAST.source</file> searches all log files for common errors and
-writes them to the file <file>error.log</file>. So, you should first
-look into this file for errors. Also the file <file>status.log</file>
-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.<p>
-
-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 <manref name="top" section="1"> and <manref
-name="pstree" section="1">. You can add <tt>debug</tt> to
-<tt>FAI_FLAGS</tt> 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
-<email>fai at informatik.uni-koeln.de</email> if you have any
-questions. Sample log files from successfully installed computers are
-available on the FAI homepage.
-
-<chapt id=beowulf>How to build a Beowulf cluster using FAI<p>
-<!--MT: I did not read this chapter-->
-
-This chapter describes the details about building a Beowulf
-cluster using &dgl; and FAI. This chapter was written for FAI
-version 2.x for Debian woody and was not yet updated. The example
-configuration files were removed from the fai packages after FAI 2.8.4.
-
-For more information about the Beowulf
-concept look at <httpsite>www.beowulf.org</httpsite>.
-
-<sect id=beoplan> Planning the Beowulf setup<p>
-
-The example of a Beowulf cluster consists of one master node and 25
-clients. A big rack was assembled which all the cases were put into. A
-keyboard and a monitor, which are connected to the master server
-most of the time, were also put into the rack. But since we have very long
-cables for a monitor and a keyboard, they can also be connected to all
-nodes if something has to be changed in the BIOS, or when looking for
-errors when a node does not boot. Power supply is another topic you
-have to think about. Don't connect many nodes to one power cord and
-one outlet. Distribute them among several breakout boxes and outlets.
-And what about the heat emission? A dozen nodes in a small room can
-create too much heat, so you will need an air conditioner. Will the
-power supplies of each node go to stand-by mode or are all nodes
-turned on simultaneously after a power failure?
-
-<p>
-All computers in this example are connected to a Fast Ethernet switch. The master node
-(or master server) is called <em>nucleus</em>. It has two network
-cards. One for the connection to the external Internet, one for the
-connection to the internal cluster network. If connected from the
-external Internet, it's called <em>nucleus</em>, but the cluster nodes
-access the master node with the name <em>atom00</em>, which is a name
-for the second network interface. The master server is also the
-install server for the computing nodes. A local Debian mirror will be
-installed on the local hard disk. The home directories of all user
-accounts are also located on the master server. It will be exported via
-NFS to all computing nodes. NIS will be used to distribute account,
-host, and printer information to all nodes.
-
-<p>
-All client nodes <em>atom01</em> to <em>atom25</em> are connected via
-the switch with the second interface card of the master node. They can
-only connect to the other nodes or the master, but can't communicate
-to any host outside their cluster network. So, all services (NTP, DNS,
-NIS, NFS, ...) must be available on the master server. I chose the class C
-network address <em>192.168.42.0</em> for building the local Beowulf
-cluster network. You can replace the subnet 42 with any other number
-you like. If you have more than 253 computing nodes, choose a class A
-network address (10.X.X.X).
-
-<p>
-In the phase of preparing the installation, you have to boot the first
-install client many times, until there's no fault in your configuration
-scripts. Therefore you should have physical access to the master
-server and one client node. So, connect both computers to a switch
-box, so one keyboard and monitor can be shared among both.
-
-<sect id=master> Set up the master server<p>
-
-The master server will be installed by hand if it is your first
-computer installed with Debian. If you already have a host running
-Debian, you can also install the master server via FAI. Create a
-partition on <file>/files/scratch/debmirror</file> for the local
-Debian mirror with more than &mirrorsize; GB space available.
-
-<sect1 id=beonetworkmaster> Set up the network<p>
-
-Add the following lines for the second network card to
-<file>/etc/network/interfaces</file>:
-<example>
-# Beowulf cluster connection
-auto eth1
-iface eth1 inet static
-address 192.168.42.250
-netmask 255.255.255.0
-broadcast 192.168.42.255
-</example>
-
-Add the IP addresses for the client nodes. The FAI package has an
-example for this <file>/etc/hosts</file> file:
-<example>
-# create these entries with the Perl one liner
-# perl -e 'for (1..25) {printf "192.168.42.%s atom%02s\n",$_,$_;}'
-
-# Beowulf nodes
-# atom00 is the master server
-192.168.42.250 atom00
-192.168.42.1 atom01
-192.168.42.2 atom02
-</example>
-
-You can give the internal Beowulf network a name when you add this
-line to <file>/etc/networks</file>:
-<example>beowcluster 192.168.42.0</example>
-
-
-Activate the second network interface with: <tt>/etc/init.d/networking start</tt>.
-
-<sect1 id=beonis> Setting up NIS<p>
-
-Add a normal user account <var>tom</var> which is the person who edits
-the configuration space and manages the local Debian mirror:
-<example># adduser tom
-# addgroup linuxadmin
-</example>
-
-This user should also be in the group <var>linuxadmin</var>.
-<example>
-# adduser tom linuxadmin
-</example>
-
-First set the NIS domainname name by creating the file
-<file>/etc/defaultdomain</file> and call <manref name="domainname" section="8">.
-To initialize the master server as NIS server call <tt>/usr/lib/yp/ypinit -m</tt>.
-Also edit <file>/etc/default/nis</file> so the host becomes a NIS
-master server.
-Then, copy the file <file>netgroup</file> from the examples directory
-to <file>/etc</file> and edit other files there. Adjust access to the
-NIS service.
-
-<example># cat /etc/ypserv.securenets
-# Always allow access for localhost
-255.0.0.0 127.0.0.0
-# This line gives access to the Beowulf cluster
-255.255.255.0 192.168.42.0
-</example>
-
-Rebuild the NIS maps:
-<example># cd /var/yp; make</example>
-
-You will find much more information about NIS in the
-<file>NIS-HOWTO</file> document.
-
-<sect1 id=beomirror> Create a local Debian mirror<p>
-
-Now the user <var>tom</var> can create a local Debian mirror on
-<file>/files/scratch/debmirror</file> using
-<prgn>mkdebmirror</prgn>. You can add the option <tt>--debug</tt> to
-see which files are received. This will
-need about &mirrorsize; GB disk space for Debian 3.0 (aka woody). Export this
-directory to the netgroup <tt>@faiclients</tt> read only.
-Here's the line for <file>/etc/exports</file>
-<p><tt>/files/scratch/debmirror *(ro)</tt>
-
-<sect1 id=fai1> Install FAI package on the master server<p>
-
-Add the following packages to the install server:
-<example>nucleus:/# apt-get install ntp tftpd-hpa dhcp3-server \
-nfs-kernel-server etherwake fai
-nucleus:/# tasksel -q -n install dns-server
-nucleus:/# apt-get dselect-upgrade
-</example>
-Configure NTP so that the master server will have the correct system time.
-
-<p>
-It's very important to use the internal network name <var>atom00</var>
- for the master server (not the external name <var>nucleus</var>) in
- <file>/etc/dhcp3/dhcpd.conf</file> and &mfnc;. Replace
- the strings FAISERVER with <tt>atom00</tt> and uncomment the following line in &mfnc;
- so the Beowulf nodes can use the name for connecting to their master server.
-<example>
-NFSROOT_ETC_HOSTS="192.168.42.250 atom00"
-</example>
-
-<sect1 id=bootp1> Prepare network booting<p>
-
-Set up the install server daemon as described in <ref
-id="pxeboot">. If you will have many cluster nodes (more than about
-10) and you will use <tt>rsh</tt> in &fc; raise the number of connects
-per minute to some services in <file>inetd.conf</file>:
-<example>
-shell stream tcp nowait.300 root /usr/sbin/tcpd /usr/sbin/in.rshd
-login stream tcp nowait.300 root /usr/sbin/tcpd /usr/sbin/in.rlogind
-</example>
-
-The user <var>tom</var> should have permission to create the
-symlinks for booting via network card, so change the group and add
-some utilities.
-
-<example># chgrp -R linuxadmin /srv/tftp/fai; chmod -R g+rwx /srv/tftp/fai
-# cp /usr/share/doc/fai-doc/examples/utils/* /usr/local/bin
-</example>
-
-Now, the user <var>tom</var> sets the boot image for the first beowulf
-node.
-<example>fai-chboot -IFv atom01</example>
-
-Now boot the first client node for the first
-time. Then start to adjust the configuration for your client
-nodes.
-
-<sect id=beotools> Tools for Beowulf clusters<p>
-
-The following tools are useful for a Beowulf cluster:
-
-<taglist>
- <tag> all_hosts <item> <p>Print a list of all hosts, print
- only the hosts which respond to a ping or the hosts which
- do not respond. The complete list of hosts is defined by the
- netgroup <tt>allhosts</tt>. Look at
- <file>/usr/share/doc/fai-doc/examples/etc/netgroup</file> for an
- example.</p></item>
-
- <tag>rshall<item><p>Execute a command on all hosts which are
- up via rsh. Uses <prgn>all_hosts</prgn> to get the list of all
- hosts up. You can also use the <manref name="dsh" section="1">
- command (dancer's shell, or distributed shell).
-
- <tag>rup<item><p> The command <manref name="rup" section="1">
- shows briefly the CPU load of every host.
-
- <tag>clusterssh<item><p> The package clusterssh allows you to
- control multiple ssh or rsh sessions at the same time.
-
-</taglist>
-These are some common tools for a cluster environment:
-
-<taglist>
- <tag>rgang</tag> <item> <p>For a huge cluster try
- <prgn>rgang</prgn>. It's is a tool which executes commands on or
- distributes files to many nodes. It uses an algorithm to build a
- tree-like structure to allow the distribution processing time to
- scale very well to 1000 or more nodes (available at
- <httpsite>fermitools.fnal.gov/</httpsite>
- <httppath>abstracts/rgang/abstract.html</httppath>). </p></item>
-
- <tag>jmon</tag><item><p>For observing the resources of all
- clients (CPU, memory, swap,...) you can use <manref
- name="jmon" section="1"> which installs a simple daemon on
- every cluster node. </item>
-
- <tag>ganglia</tag><item><p>This toolkit is very good for monitoring
- your cluster with a nice web frontend. Available at
- <httpsite>ganglia.sourceforge.net/</httpsite> </p> </item>
-
-</taglist>
-
-<sect id=wol> Wake on LAN with 3Com network cards<p>
-
-Wake on LAN is a very nice feature to power on a computer without
-having physical access to it. By sending a special ethernet packet to
-the network card, the computer will be turned on. The following things
-have to be done, to use the wake on LAN (WOL) feature.<p>
-
-<enumlist>
-<item><p>Connect the network card to the Wake-On-LAN connector on the
-motherboard using a 3 pin cable.</p></item>
- <item><p>My ASUS K7M motherboard has a jumper called
-<tt>Vaux (3VSBSLT)</tt> which allows to select the voltage supplied to add-in
-PCI cards. Set it to <tt>Add 3VSB</tt> (3 Volt stand by).</p></item>
-<item><p>Turn on the wake on LAN feature in BIOS</p></item>
-<item><p>For a 3Com card using the 3c59x driver you must enable the
-WOL feature using the kernel module option <tt>enable_wol</tt>.
-</enumlist>
-
-To wake up a computer use the command <manref name="ether-wake" section="8">.
-Additional information is available from
-<httpsite>www.scyld.com/</httpsite><httppath>expert/wake-on-lan.html</httppath>.
-
-<chapt id=arch>FAI on other architectures and distributions<p>
-If you want to use FAI on other architectures than i386 or amd64 you might need
-to take care of some things yourself.
-
-These are things that may have to be changed on other architectures:
-
-<taglist>
- <tag> Boot loader: <item> <p> There are scripts for setting up
- <manref name="lilo" section="8"> and <manref name="grub" section="8">. Here you may
- add support for your specific boot loader.
-</taglist>
-
-If you want to serve multiple nfsroot directories on one FAI server,
-you need to create specific config directories in <file>/etc</file>
-for fai, like <file>/etc/fai-sarge</file> and
-<file>/etc/fai-etch</file>. Then you need to set the
-<var>NFSROOT</var> variables to different directories and run
-<tt>make-fai-nfsroot -c /etc/fai-sarge</tt>.
-
-<sect id=powerpc>FAI on PowerPC<p>
-There's some stuff on <httpsite>www.layer-acht.org</httpsite><httppath>/fai</httppath>.
-Most notably there are hooks for partitioning and config-files to
-setup bootloaders for oldworld and newworld.
-
-<sect id=ia64>FAI on IA64<p>
-There's one big IA64 Beowulf cluster running which was installed with
-FAI. Only the partitioning part has to be replaced by a short script,
-since sfdisk is not available on IA64. This should not be need any
-more since the patitioning tool <manref name="setup-storage"
-section="8"> works on all architectures, were parted is supported.
-
-<sect id=odists>FAI for Ubuntu, Suse, Redhat and Gentoo<p>
-All FAI packages are available in Ubuntu and are used by a large
-number of people since many version.
-
-Many people are interested in FAI for other (mostly RPM based) Linux
-distributions. I made some research and it should not be much work to
-implement it. But I need more help to implement it. If you are
-interested and would like to help me, please send an email to
-<email>fai at informatik.uni-koeln.de</email>.
-
-A brief description how to install SLES9 with FAI is available at
-<httpsite>www.sourcecode.de</httpsite><httppath>/install_sles_with_fai</httppath>.
-
-There are also some information in the faiwiki.
-
-<sect id=sparc>FAI on SUN SPARC hardware running Linux<p>
-
-Although FAI is architecture independent, there are some packages which
-are only available for certain architectures (e.g. silo, sparc-utils).
-
-SUN SPARC computers can boot from their boot prompt. To boot a SUN
-use: <example>boot net:dhcp - ip=::::::dhcp</example>
-
-
-You have to convert the kernel image from ELF format to a.out
-format. Use the program <prgn>elftoaout</prgn> (mentioned in
-the FAQ). The symlink to the kernel image to be booted is not the host
-name. Look at the FAQ at
-<httpsite>www.ultralinux.org</httpsite> for more information
-and <httpsite>www.sparc-boot.org/</httpsite>.
-.
-
-A success report is available at
-<httpsite>www.opossum.ch/</httpsite><httppath>fai/</httppath>.
-
-<sect id=solaris>FAI for Solaris<p>
-FAI has also been ported for use with SUN Solaris OS installations
-in cooperation with Solaris jumpstart. This was done using FAI 2.8.4
-and Solaris 9. Get the FAI sources from FAI 2.8.4 and change to the
-<file>sunos</file> directory. There
-you can call <tt>make</tt> which creates the tarball
-<file>/tmp/fai-solaris.tar.gz</file>. You have to read the file
-<file>README.sunos</file> and have some knowledge about Solaris
-jumpstart. The Solaris support was removed in FAI 2.9.
-<p>
-The file format of the configuration files in <file>disk_config</file> and
-<file>package_config</file> are different than those for Linux.
-
-<chapt id=advanced>Advanced FAI<p>
-
-<sect id="dirinstall">Installing into a mounted directory for chroot and virtualization<p>
-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 <tt>dirinstall</tt>.
-
-By calling
-<example>fai <options> dirinstall <target-directory></example>
-and using either the option <tt>-c <classes></tt> or
-<tt>-N</tt> 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 <tt>-u <host-name></tt>
-
-This, for example, can be used to combine FAI with the tool <tt>xen-tools</tt>, which
-helps you to build Xen guest domains. <tt>xen-tools</tt> 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:
-
-<example>
-#!/bin/sh
-TARGET=$1
-CMD="fai -N -v -u ${hostname} dirinstall $TARGET"
-echo running $CMD
-$CMD
-</example>
-
-Then, you will want to set the variable <example>install=0</example> in the xen-tools config for
-that host(in previous versions of xen-tools, this was <tt>no-install=1</tt>).
-
-<sect id=softupdate>Using FAI for updates
-<p>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).</p>
-
-<sect1 id=aboutsoftupdate>How does a softupdate work?
-<p>Softupdate use the same configuration files as a new FAI installation. They
-even use the default FAI commands, so they behave <em>nearly</em> in
-the same way as an installation, though some things are different:
-<list>
- <item>By default the old list of classes (created during the
- initial installation) is used, so <prgn>fai-class</prgn>
- is not called to define a new list of classes. This can be
- changed by calling <tt>fai -N softupdate</tt>.</item>
- <!--MT: Is this still the current behavior?-->
- <item>No partitioning and file system creation is performed.</item>
- <item>The basesytem isn't bootstrapped.</item>
- <item>FAI skips tasks only useful when installing, such as setting up
- a keymap or starting special daemons.</item>
- <item>FAI doesn't prevent software packages to (re-)start daemons.</item>
- <item>FAI doesn't reboot at the end of a softupdate.</item>
-</list>
-Except these changes, things are the same as when installing a new computer:
-<enumlist>
- <item>Define classes (by default use old list) and variables.</item>
- <item>Update the installed packages.</item>
- <item>Install new software.</item>
- <item>Call configuration scripts.</item>
- <item>Save the logfiles.</item>
-</enumlist>
-</sect1>
-
-<sect1 id=runsoftupdate>How to run a softupdate
-<p>As softupdate use the same infrastructure as a FAI installation, you even
-start them by using the same command <manref name="fai" section="8"> which is used for
-installation:
- <example>
- /usr/sbin/fai softupdate
- </example>
-starts a softupdate.
-
-If you want to use softupdate on a system not installed with fai,
-the first time you need to run fai with the -N switch: <tt>fai -N softupdate</tt> - see <manref name="fai" section="8"> for details.
-
-Make sure to set the variable <var>LOGSERVER</var> (done in a <tt>class/*.var</tt>
-file) if fai should save the log files to a remote machine.
-</p>
-
-<sect2 id=startsoftupdate>How to do mass softupdates
-<p>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.</p>
-
-<sect3 id=cronsoftupdate>Cron
-<p>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.</p>
-
-<sect3 id=remotesoftupdate>Starting a softupdate remotely
-<p>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.</p>
-<p>Tools like <tt>clusterssh</tt> allow you to login onto a group of clients at
-once and run <tt>/usr/sbin/fai softupdate</tt> there, while the results can be
-seen immediately in the terminals started for each host.</p>
-</sect2>
-</sect1>
-
-<sect1 id=confsoftupdate>How to write a configuration suitable for softupdate
-<p>When you want to do softupdate, you have to be even more careful when
-writing your configuration: it has to be <strong>idempotent</strong>, 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:
-<list>
- <item><em>Never</em> blindly append to files:
- <example>
- echo $SOMETHING >> /etc/fstab
- </example>
- is almost certainly wrong. Either check manually if the
- line already exists <strong>before</strong> appending
- or use the command <manref name="ainsl"
- section="1">. This has a similar function to
- cfengine's <tt>AppendIfNoSuchLine</tt> statement
- </item>
-
- <item>Make use of FAI's environment variables to determine what to do in
- your configuration scripts! Some of the most important ones:
- <taglist>
- <tag><var>FAI_ROOT</var></tag>
- <item>points to the client's rootdir.
- In case of softupdate: <tt>/</tt></item>
- <tag><var>ROOTCMD</var></tag>
- <item>contains a command for <tt>chrooting</tt>
- into the client. This is empty when doing
- softupdate (as <tt>/</tt> is already our
- root...).</item>
- <tag><var>FAI_ACTION</var></tag>
- <item>contains the currently executed action:
- <taglist>
- <tag><tt>install</tt></tag>
- <item>when installing.</item>
- <tag><tt>softupdate</tt></tag>
- <item>when updating</item>
- </taglist>
- </taglist>
-
- <item>Restart daemons if needed: most daemons only read their
- configuration when starting; if you modify it, you need to
- make them reload it using
- <example>
- $ROOTCMD invoke-rc.d $somedaemon reload
- </example>
- or even restart them
- <example>
- $ROOTCMD invoke-rc.d $somedaemon restart
- </example>
- when the configuration for <tt>$somedaemon</tt> has been
- changed<footnote>You can for example use <manref
- name="fcopy" section="8">'s
- <tt>postinst</tt> script support for doing this; if other
- things than <tt>fcopy</tt> modify your conffiles, you have to
- keep track of the changes yourself.</footnote>.
- </item>
-
- <item>Other things like scheduling a reboot if a new kernel is installed</item>
-</list></p>
-</sect1>
-
-<sect1 id=localconfsoftupdate>What if there are locally changed conffiles?
-<p><strong>Short: there shouldn't be any!</strong></p>
-<p><strong>Long: </strong> <em>if</em> you are using FAI <tt>softupdate</tt> 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
-<tt>.pre_fcopy</tt> appended); if you want to save them together with
-the logfiles,
- <example>
- FAI_BACKUPDIR=$LOGDIR/backup
- </example>
-in <tt>class/DEFAULT.var</tt> will do the job.</p>
-
-<sect2 id=detectlocalchanges>How to detect locally changed files?
-<p>If you are playing with local configuration changes <em>despite all the warnings
-contained in this section</em>, there must be a way to check what has been
-changed locally. A simple approach would be to use <tt>debsums -e</tt>,
-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 <tt>tripwire</tt> or <tt>integrit</tt> to scan
-for local changes and notify you about them.</p>
-</sect2>
-
-</sect1>
-</sect>
-</chapt>
-
-<chapt id=hints>Various hints<p>
-
-<p>
-This chapter has various hints which may not always be explained in great
-detail.
-<p>
-To generate a md5 hash for the password use this
-<tt>echo "yoursecrectpassword" | mkpasswd -Hmd5 -s</tt>
-<p>
-When using HTTP access to a Debian mirror, the local <tt>/var</tt>
-partition on all install clients must be big enough to keep the
-downloaded Debian packages. Do not try with less than 250 Mbytes
-unless you know why. You can limit the number of packages installed at
-a time with the variable <var>$MAXPACKAGES</var>.
-<p>
-You can shorten some scripts by using one single fcopy
-command <tt>fcopy -r /</tt>.
-<p>
-If you rebuild the nfsroot, you will create a new ssh host key inside
-the nfsroot. Then logging in to an install client may fail, because
-the host key changes. You can use this:
-
-<example>
-ssh -o StrictHostKeyChecking=no root at installclient
-</example>
-
-
-You can also delete the host entry on your install client in your
-<tt>~/.ssh/known_hosts</tt> file by unsing the <tt>ssh-keygen -R</tt>
-command.
-<p>
-In the tasks chboot and savelog, a connection using secure shell is opened to
-the FAI server (see <ref id="isavelog">). To ensure that this works
-non-interactively, a proper entry in <file>NFSROOT/root/.ssh/known_hosts</file> must be
-created. When using fai-setup, this is done automatically, but it may require
-manual editing in case the name of your FAI server was not determined correctly.
-If you stumble over ssh connections that require typing "yes" to accept the host
-key during installation, please check the contents of your
-<file>NFSROOT/root/.ssh/known_hosts file</file>
-
-<p>
-
-You can calculate the IP subnet address (which is used in
-&mfnc; for the variable <var>FAICLIENTS</var> by using
-the nice tool ipcalc. Following example gives you the notation for a
-class C network (16) when the server netork interface has the IP address
-123.45.6.123
-<example>
- ipcalc -nb 123.45.6.123 16|grep Network:
-</example>
-
-You can merge two directories which contain configuration
-information, if one is a global one, and the other a local one. We use
-it to merge the templates from the FAI package, and our local
-configuration, which contains encrypted passwords and other
-information that should not be readable by others.
-If you remove a file in your local configuration, do not forget to
-remove this file also in the configuration space, otherwise it will
-still be used.
-<p>
-After calling <prgn>set-disk-info</prgn>, a list of all local hard disks is
-stored in <var>$disklist</var> and <var>$device_size</var>
-contains a list of disk devices and their sizes.
-<p>
-
-
-Use <prgn>fai-divert -a</prgn> if a postinst script calls a
-configuration program, e.g. the postinst script for package apache calls
-apacheconfig, which needs manual input. You can fake the configuration
-program so the installation can be fully automatic. But don't forget
-to use <prgn>fai-divert -R</prgn> to remove all faked scripts.
-
-<p>
-During the installation you can execute commands
-inside the newly installed system in a chroot environment by using <tt>chroot /target</tt>
-or just <tt>$ROOTCMD</tt> followed by the command you want to call; for
-example <tt>$ROOTCMD dpkg -l</tt> shows the packages installed on
-the new system.
-<p>
-
-<!--MT: has been said already
-The only task which has to be done manually for new hardware is to
-assign the MAC address to a host name and to an IP address, and to define
-classes for this host if the existing configuration files are not generic
-enough to deal with this new host.
-<p>
-There's a tradeoff between writing a few large configuration scripts,
-or many short scripts, one for each class. Large scripts can
-distinguish classes by using case statements, the <tt>ifclass</tt>
-test or with class mechanisms for <tt>cfengine</tt> scripts.
-<p>
--->
-If your computer can't boot from the network card, you do not always need to boot
-from floppy. Add the class
-<tt>FAI_BOOTPART</tt> and FAI will automatically create a
-lilo or grub entry for
-booting the FAI bootfloppy from this partition. So you can start the
-re-installation without a boot floppy. This will also make the test
-phase shorter, since booting from hard disk is much faster than booting
-from floppy. You can also set a password for this boot menu.
-<p>
-
-<p> How can I define classes on the kernel command line?
-<p> Read the man page of <manref name="fai-class" section="8">
-
-
-<sect id=difai>Using FAI after an Installation with the Debian-Installer<p>
-On <httpsite>www.layer-acht.org</httpsite><httppath>/fai</httppath> you
-will find an example how to fully automatically install a system using the Debian
-Installer (d-i) in conjunction with FAI's new softupdate (see <ref id=softupdate>).
-
-</book>
-</debiandoc>
-
-<!-- Keep this comment at the end of the file
-Local variables:
-mode: sgml
-sgml-omittag:t
-sgml-shorttag:t
-sgml-minimize-attributes:nil
-sgml-always-quote-attributes:t
-sgml-indent-step:2
-sgml-indent-data:nil
-sgml-parent-document:nil
-sgml-exposed-tags:nil
-sgml-declaration:nil
-sgml-local-catalogs:nil
-sgml-local-ecat-files:nil
-End:
--->
More information about the Fai-commit
mailing list