Infrastructure automation is ubiquitous now, but long before Puppet, Chef, and Ansible came on the scene, FAI (fully automatic installation) was deploying Linux across servers and installing and configuring software without the need for interaction. Although FAI has been around since 1999, it is still an active project and an excellent option for infrastructure automation.

Auto-Advantages

Automation is the basis for economies of scale as a result of the synergistic effects it generates. The initial work that flows into the automation of a platform then pays dividends with each new node that is added and does not require hours of configuration.

Automation occurs at many levels, starting with the infrastructure and extending to include, for example, switch configuration or the deployment of services and their configuration to turn a basic system into a functioning node that hosts virtual machines in a cloud. Automation also includes the operating system. Rolling out a Linux distribution manually – as every admin knows – is no longer a complicated task, but still a tedious one. However, it's also easy to automate: as Red Hat's Kickstart or preseeding with the Debian installer bear witness.

FAI is a separate software tool that enters the scene with its claim to install Linux operating systems in the shortest possible time. FAI is not limited to a specific distribution; it supports Debian, Ubuntu, CentOS, and other lesser known candidates. (See the "Reinventing the Wheel?" box.)

Reinventing the Wheel?

Some might ask, in the face of FAI, how useful it actually is; after all, various distribution-specific mechanisms already exist. Mixed environments don't occur that often – for example, Ubuntu and Red Hat in the same environment would be an exception rather than the rule – but anyone asking this question is barking up the wrong tree. The correct question to ask is: Why did Red Hat, Debian, and others feel like they had to do their own thing, even though FAI already existed?

FAI, already 18 years old, was created at a time when IT was still in its infancy, at least in terms of automation. Tools that can automatically install operating systems on a server are a far more recent development than many admins might guess.

Puppet, for example, first saw the light of day in 2005 when FAI had already been around for six years. In 1999, when work on FAI began, Debian was still working with boot floppies and an ancient installer no one would have ever dreamed would progress to preseeding and automatic installation. Anyone who managed to install Debian 2.2, alias Potato, or 3.0, alias Woody, on their hard drives were more likely to have been absolutely delighted that it actually worked. The Debian installer that finally retired the boot floppies did not appear until 2005, along with Debian GNU/Linux Sarge.

For Thomas Lange (Figure 1), this development would have been far too late. In 1999, he was working at the University of Cologne, which had just purchased a smart new cluster of 16 servers, and the installation task fell to Lange. However, he had no use for the annoying Debian boot floppies, and because he had previously worked with Solaris and was familiar with Solaris Jumpstart, he came up with the idea of giving Linux a similar installation system.

The rest is history: FAI has enjoyed a large fan base ever since. Lange even became an official Debian developer thanks to FAI, and to this day he maintains the packages needed for FAI at Debian.

Figure 1: Thomas Lange is the mastermind behind FAI and was responsible for kick-starting its development in 1999.

How FAI Works

In this article, I introduce FAI in a very practical way and explain how the program works and which tweaks you can use. For a better understanding of the big picture, I take a bird's eye view. What strategies does FAI follow? How does it fundamentally complete its task?

More interesting is that FAI offered a similar functionality 20 years ago – with the tools that were available at that time. To be honest, the protocols that are used have not changed so radically since then. Many of them date back to the early days of the Internet.

Old Acquaintances

When a server is powered up or rebooted, you have several options for achieving a running operating system. The first and most common option is to boot from a local storage device – usually the system disk, which contains the regular operating system. Once the server has booted from this disk, the rest of the boot process happens automatically.

However, a server that comes straight out of the box does not typically have an operating system. Although you could install a temporary local boot medium (e.g., a USB stick) manually, that's precisely what you would want to avoid. An alternative approach to installing the system would be booting via a network – not a new invention. Three protocols, all primeval rocks of the Internet, collaborate: DHCP provides a server with an IP address so that it can speak TCP/IP and UDP.

With TFTP, the system downloads a bootloader and boots. From now on, everything that would be possible after booting from a local medium is theoretically feasible. For example, having your own root filesystem on a server in the network and operating the system without a local boot medium – in diskless mode – is no problem.

The combination of DHCP and TFTP, as described in this article, are known as the Preboot Execution Environment (PXE). If a system wants to boot via PXE, at least one built-in network card must support PXE. In the server environment, where servers without PXE-enabled network cards are virtually non-existent, this is not a problem.

With end-user systems, PXE will only be missing if you go for the cheapest available components. Today, you even have comprehensive support for UEFI via PXE, so systems can be booted on a UEFI basis in line with the BIOS successor's requirements.