Installing Linux – the advanced stages
In this section, we will cover the more advanced aspects of installing Linux. As we saw in the previous sections, installation on bare metal and VM requires direct access to the given machines. But what if we do not have access to the location? Or there are so many machines that need to be set up, that completing the task manually would be tedious at best, and infeasible at worst?
Installing Linux in an enterprise environment with tens or hundreds of machines in use can be done using an automated environment by booting through the network. As we stated earlier, a detailed overview of the network boot technique is out of the scope of this book; nevertheless, we will describe the process and show you the most important aspects of it, as none of the prominent books out there discuss this.
But first, to better understand how network booting works, let us take a short look at the Linux boot process.
The Linux boot process
How does Linux boot? We will give you a comprehensive view of the process without getting into too many details.
When you first start your Linux-powered computer or virtual machine, the BIOS (or boot firmware) starts loading and initiates a bootloader. The BIOS has a specific configuration and is loaded by the manufacturer onto a memory chip on the motherboard (in the case of physical computers, not VMs). The BIOS has information about the hardware and capabilities of controlling peripherals such as keyboards and monitors. It also has information about the operating system and the location of the bootloader. Some of this information is user controlled and can be changed according to the user’s needs, such as the boot sequence for example, or password protection. The BIOS also has control over the network interface controllers (NICs) and all the external ports, including USB and display ports. But this is about all it can do, as it requires a bootloader to further initiate any operating system existing on the disk.
A newer version of the BIOS is the Unified Extensible Firmware Interface (UEFI). It has the same advantages as the older BIOS, but offers more interactive interfaces and better support for newer operating systems. The drawback, however, is the lack of software support from third-party vendors.
There is also Secure Boot, a feature introduced to offer an extra layer of security for the operating system and the software that runs. Some Linux distributions support it, but not all of them. Secure Boot uses a digital signature that proves the authenticity of the operating system. In order to support Secure Boot, the operating system developer must obtain a valid certificate for the software that can be verified on boot to prove that the system is valid and has not been tampered with.
Now that we know what the BIOS, UEFI and Secure Boot are, let us learn about the bootloader. Once Power-On Self Test (POST) is finished, the bootloader is accessed to load the operating system. POST is a series of tests that are conducted upon startup to ensure that the hardware is fully functional. What is a bootloader? It is the bridge between the hardware and the operating system. It is stored in the boot sector of the bootable storage. It can be either a partition or the very first block of the storage medium.
The bootloader used on Linux is the Grand Unified Bootloader (GRUB). It is responsible for loading the kernel of the operating system. The kernel is the central component of Linux, responsible for all the software components, drivers, services, and hardware integration. All of this forms what we call user space. It is the GRUB that has the capacity to support network booting.
The information provided in this section is sufficient to get a grasp of the Linux boot process. We will now detail the use of network boot to install Linux in the following section.
PXE network boot explained
Earlier in this chapter we mentioned the PXE (pronounced pixie) boot option. What exactly is PXE? It is a service that uses different networking protocols for booting over the network. It is based on different protocols and standards that were introduced forty years ago to define the much-needed network boot interoperability, also known as the Network Bootstrap Program (NBP).
The protocols that PXE is based on are Trivial File Transfer Protocol (TFTP), Dynamic Host Configuration Protocol (DHCP), and the UDP/IP stack using the Hyper Text Transfer Protocol (HTTP). These three are the base for PXE’s application programming interface. Nowadays, most network cards available on the market already have the PXE firmware installed. This makes PXE the standard for network boot on many architectures. For more information on the latest PXE version 2.1, visit the following link: https://web.archive.org/web/20110524083740/http://download.intel.com/design/archives/wfm/downloads/pxespec.pdf.
For PXE to work, we need to have a PXE server on the network. This machine will provide the necessary bootable files in response to client requests on the network. For this, at least a DHCP and a TFTP server need to be installed on the PXE server. In addition, a Network File System (NFS) server must also be installed, as this protocol is required for network file sharing and is used in modern Linux operating systems.
But before we go into further detail, let us discuss how network boot works. PXE relies on a client/server environment where different machines are equipped with PXE-enabled NICs. The network configuration of the PXE environment was developed so that it does not interfere with the existing network configuration. As DHCP and TFTP are needed, the PXE environment makes sure that it does not interfere with the existing DHCP configuration of the non-PXE router from the local network. This is a well-thought-out design for corporate environments.
In a basic scenario, after all clients are set up for PXE boot (an option available from the BIOS on almost every computer), the NICs send DHCP requests over the network in order to find the local PXE server. In order to be able to correctly respond to those requests, PXE uses a sort of proxy DHCP that sends IP and mask information of the TFTP server back to the PXE-enabled clients. This way, it does not interfere with the local network’s DHCP server.
Setting up a PXE server is beyond the scope of this chapter, but useful information about what this is and how it works is relevant and can be found at https://ubuntu.com/server/docs/install/netboot-amd64 and https://www.redhat.com/sysadmin/pxe-boot-uefi. However, further details, such as how to practically set up a DHCP server, will be found in Chapter 13.
For a PXE server to work, there are some specific steps to take, depending on the installation root you follow. There are several options available, as you can use iPXE (an open source network boot firmware), cloud-init (specific to Ubuntu), or kickstart (for Fedora-based systems). Nonetheless, setting up DHCP, TFTP, and NFS servers is required, with the DNS server being optional (details on setting up these servers are available in Chapter 13).
As you’ll see these details later, we will not include them here. This is the introductory chapter, intended to make you comfortable with different ways to install Linux, and we will slowly build upon this foundation throughout the book to get you ready for the more advanced stuff as you go through the chapters.
In the next section, we will give you some scenarios of using certain Linux flavors depending on specific needs. We will present to you what we consider to be the appropriate distributions and applications to use in different case studies. Please keep in mind that installing applications and working with package managers will be discussed in more detail in Chapter 3.
