Lead Image © Nataliya Hora, 123RF.com

Lead Image © Nataliya Hora, 123RF.com

Build operating system images on demand

Assembly Line

Article from ADMIN 55/2020
By
If you are looking for a way to build images quickly and easily, FAI.me is the place to go.

In popular clouds, the providers usually roll out standard distribution images. SUSE, Red Hat, and Canonical offer these explicitly, and there is no reason why you should not use them. However, these images may have one or two annoying features, such as missing packages, wrong configurations, or other everyday difficulties.

Changing a finished image is not trivial. Instead, many admins start rebuilding from the source and, sooner or later, give up. In most cases it is not possible to achieve the same image quality as that of the distributors. Either the DIY images are bulky and far too big or they don't work well.

This problem is exactly what FAI.me addresses: The tool is an extension of the Fully Automated Installer (FAI; see also the "FAI Review" box) [1] that builds operating system (OS) images on demand, for both bare metal and use in the cloud. In this article, I introduce FAI.me and explain what happens in the background.

FAI Review

A short review of FAI will help you understand FAI.me. Although FAI is not new, the author Thomas Lange is continuously adding new features. Moreover, a small but hard-working community has gathered around the tool, keeping it up to date and ensuring that it can install Ubuntu and CentOS in addition to Debian.

The original purpose of FAI was clearly defined: After unpacking, new servers install autonomously to the extent possible and without too much manual intervention. Quite remarkably, FAI was created back in the late 1990s, long before automation tools such as Puppet or Ansible existed.

FAI offered the ability to roll out an OS automatically at an early stage. In the standard configuration, it combines a number of different protocols. A DHCP server is supported by a TFTP server. Clients use the PXE protocol to obtain an IP and then load a bootloader via TFTP. A kernel, usually one from the installation routine, is responsible for taking care of the rest.

The program needs PXE to boot into a custom environment where it can roll out its various operating systems. Lange and volunteer FAI developers have implemented many features for this purpose. Scripts can be executed at different stages of the installation, which then implement certain functions not provided out of the box in FAI. All FAI components can be loaded from a central network server for this purpose.

The highlight is that FAI does not depend on the installation routine of an installer. If you want to implement automation for SUSE, CentOS, and Debian, you would theoretically have to create three boot environments: for AutoYaST, Kickstart, and preseeding.

FAI offers a mostly generic interface. Only local modifications, such as the selection of the packages to be installed automatically, add pitfalls because not all packages for the same components have identical names across distributions.

Lange recognized early on that dependence on the network can be quite disadvantageous. Conceivably a DHCP server may exist, but it then takes some time to integrate with FAI – or DHCP is not allowed at all. Maybe the systems you want to install just can't use PXE – not all network cards come with support for this protocol. However, the network boot in FAI will not work without a network either.

For many years, FAI has supported the possibility of generating a static image from a precomposed FAI configuration, which you can then burn to a CD-ROM or DVD or write to a USB stick. The local boot medium then behaves exactly as a network-based FAI, but with a few system-related limitations: If you change the FAI configuration, you have to create new images afterward.

In the first years of FAI's existence, this function was limited to generating images for bare metal, but now FAI also provides functions for building images for cloud environments. Taking Debian as an example, the command

fai-diskimage -u cloudhost -S900M -cDEFAULT,DEBIAN,AMD64,FAIBASE,DEMO,GRUB_PC,CLOUD /tmp/disk

creates an image of an installed Debian system built for the AMD64 architecture in /tmp/disk; it contains the GRUB bootloader and needs 900MB of storage space (Figure 1). If you have fast Internet access on the system on which you call the fai-diskimage command, the process is also quick. It hardly takes a minute for the finished image to become available. Debian is happy to have the tool, because, among other things, the project uses it to create its official images for the cloud [2].

Figure 1: fai-diskimage creates a cloud image based on an existing FAI configuration.

Instant Images

FAI.me provides the functionality of FAI without the kind of tinkering that's otherwise necessary. Basically, it's not much more than a graphical web-based interface for fai-diskimage, which assembles bootable OS images on demand. Images for bare metal installations as well as for clouds are included, but FAI.me offers a whole host of extremely practical functions.

Naturally, the bootable FAI images for bare metal differ significantly from the cloud images. The one contains the normal FAI installer, which starts its work after launching from the boot medium, whereas the cloud version comes with a pre-installed operating system. To take this into account, Lange has implemented FAI.me on two subpages on the FAI website for cloud images [3] and bare metal [4]. Both pages are quite straightforward.

Clouds

If you look at the cloud page, you only have a few – really important – parameters to set. At the very top of the form, for example, you need to enter both the target size of the image and its format. The background to this is that if you build an image for AWS, it needs a different format than for KVM, which usually wants the QCOW2 format for hard drives.

You can define the hostname, but it is usually overwritten by the software-defined networks in clouds and their name resolution. Practically, if you add your public SSH key to a cloud image, you don't have to specify it when starting the virtual machine.

If you want to set a password for root, you can, but I strongly advise against it. Leaving the field empty is one less attack vector, and it doesn't mean having to do without root rights thanks to sudo. If you then set the desired language and the release you want to use, you are virtually ready to start.

FAI.me just wants to know which packages it should integrate into the image. Best be economical here: As a rule, clouds are connected by fast lines, so it is advisable to keep the basic image as small as possible and load the rest off the network or a local mirror as needed.

The big distributors demonstrate this vividly. The Ubuntu images, for example, which Canonical makes available for use in OpenStack, have managed with around 260MB for years.

Bare Metal

If you want to build an image for use on bare metal instead, the effort is not much greater. Although a separate option displays the advanced settings, it only takes you to the settings for the root password and lets you add a public SSH key. FAI assumes by default that it will create a user with a password, who then becomes root with sudo.

You can specify the partition scheme in a drop-down menu. FAI.me provides several suggestions for the use of the Logical Volume Manager or /home on your own partition. The remaining settings largely correspond to those of the cloud variant.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs



Support Our Work

ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.

Learn More”>
	</a>

<hr>		    
			</div>
		    		</div>

		<div class=