Booting a Minimal System

As soon as the appropriate PXE configuration is stored, the client receives the well-known Pxelinux bootloader during the network boot, which in turn loads a classic Debian GNU/Linux-based system, including a RAM drive, with just one task: to support the installation of a local Linux – unless you specify the rescue parameter at boot time. Then, FAI boots into the same minimal Linux but does not automatically start the routine for installing a new system (Figure 2).

Figure 2: FAI boots Pxelinux, which automatically fires up the installer in the default configuration after a time out.

Configuration Space

Once the installation routine described above is running, it is very important that you understand the structure of the configuration space on the previously created NFS server. You will discover several folders (classes, disk_config, basefiles, scripts, etc.). All of these directories play a special role within the framework of the FAI process. One of the most important is the classes folder: FAI groups servers by classes and provides a predefined selection of software according to the class.

Remember that at the time a server boots into the Pxelinux bootloader, FAI has no information other than the MAC address with which it sent the DHCP request. This alone is usually too little to allow FAI to decide which operating system the future host should have, which packages should be installed other than the standard installation, and whether – and, if so, which – scripts should run after installation.

FAI helps itself by dividing servers into classes and defining parameters such as the operating system or package selection for the individual classes. The decision as to which class a server belongs is based on several parameters. The hostname can be a parameter, although this is not very flexible. By default, servers already belong to several standard classes (e.g., DEFAULT and LAST). Class assignment becomes genuinely flexible when scripts enter the scene.

During the installation process, external shell scripts can be called via hooks at specific times. You need to store them in the NFS scripts folder so they can be called. The FAI installer then interprets their output as classes to which the respective hosts belong. If a suitable class definition is found in the classes folder, the FAI installer applies the parameters specified in the class definition to the respective system.

Although this sounds quite complicated in theory, it is simple in practice, as a basic example shows: Suppose FAI is being used on a company's workstations and servers. In this case, FAI is executed on a desktop system, but the FAI installer doesn't know this yet, because it only knows the system's MAC.

In the first step of the process, the FAI installer therefore calls a script that reads and inventories the host hardware. It turns out that a powerful graphics card with a 3D chipset is installed in the respective system. Naturally, this is rarely found in servers, so it's probably a desktop.

The inventory script therefore outputs KDEHOST, and FAI knows that the system belongs to the KDEHOST class. The KDEHOST class definition also states that – besides the basic installation – a full-fledge KDE5 and proprietary drivers for the Nvidia graphics card need to be installed. On servers with less powerful graphics cards, the host would automatically end up in the XFCE class, which is also a graphical desktop, but with a less resource-intensive GUI than KDE.

Similar tricks are conceivable even in combination with the latest technology. For example, if FAI notices that a system has dozens of large hard drives, it could output the CEPH class definition. The corresponding CEPH class would then presumably contain details that allow the packages required for Ceph to find their way onto the system automatically, including a basic configuration.

One thing is clear: The class system in FAI is powerful and contributes a great deal to the solution, being so flexible and dynamic. For example, it also ensures that a host is given a suitable hard drive configuration. With the use of files whose syntax is very similar to that of /etc/fstab, you define the layout that the drives should have on the target system (Figure 3).

Figure 3: The hard drive configuration of a system is defined by the class to which it belongs.

Even More Scripts

By the way, an extremely helpful interaction arises between classes and scripts. If the output of a class script determines that a host belongs to a certain class, further scripts can be defined that are called for certain operations during the setup. For administrators, this means nothing less than the option of arbitrarily intervening in the setup and its central processes at virtually any time.

The FAI documentation [1] lists the possible hooks and the points in time at which they occur. If you stumble over the term "plan" while reading the documentation, FAI understands this to mean the entirety of all the settings that end up in the installation plan.