The Red Hat installer, Anaconda, uses a scripting language called kickstart to define unattended builds. This is well documented, and there are many examples available on the internet for you to work from—in fact, when you manually install a Red Hat derivative such as CentOS 7, you will find a kickstart file in /root/anaconda-ks.cfg, which could be employed to automate future builds! In the following, we will build up our own simple kickstart file, based loosely on a minimal install of CentOS 7 from the interactive installer.

1. Let's start building up our example kickstart file for use in this chapter. Consider this block of code:

auth --enableshadow --passalgo=sha512
url --url="http://192.168.201.1/centos7/"
graphical
firstboot --enable
ignoredisk --only-use=sda
keyboard --vckeymap=gb --xlayouts='gb'
lang en_GB.UTF-8 
reboot

Much of the kickstart file is very readable—in the preceding code block, you can see the following: we are defining sha512 for the password hashing algorithm; our repository server is available at http://192.168.201.1/centos7/; we are performing a graphical install, using only /dev/sda, and with some GB specific locale settings. We also tell the installer to reboot automatically once the install completes successfully.

2. We then build on this by setting up the network (note that you must know the network device name in advance of creating this file, so you might find it useful to boot into a live environment to check this first) by running the following code:

network --bootproto=dhcp --device=ens33 --ipv6=auto --activate
network --hostname=ksautomation

This sets the hostname of our newly built server to ksautomation, and enables IPv6 and IPv4 DHCP on the network device called ens33.

3. We then define the root account password, and—optionally—any additional accounts we want to be added as part of the build, by running the following code:

rootpw --iscrypted $6$cUkXdOxB$o8uxoU6arUj0g9SXqMGnigBYDH4rCkkQt9z/qYPm.lUYNwaZChCz2epQMUlbHUg8IVzN9lei9i/rschw1HydU.
user --groups=wheel --name=automation --password=$6$eCIJyrjn$Vu30KX//UntsM0h..MLT6ik.m1GL8ayILBFWjbDrKSXowli5/hycMaiFzGI926YXEMfXXjAuwOFLIdANZ09/g1 --iscrypted --gecos="Automation User"

Note that the password hashes must be used in this file—there are many ways to generate these. I used the following snippet of Python to generate unique hashes for the password string (you would obviously want to choose a more secure password!):

$ python -c "import random,string,crypt;
pwsalt = ''.join(random.sample(string.ascii_letters,8));
print crypt.crypt('password', '$6$%s$' % pwsalt)"

Running the preceding three lines of code in the shell of any Linux server that has Python installed will generate the password hash needed for your kickstart file, which you can copy and paste into your installation.

4. Finally, we set the time zone appropriately, and enable the chrony time synchronization service. We initialize the disk label on our chosen boot device, sda, and make use of Anaconda's automated partitioning (designated by the autopart directive), to set up the disk.

Note that clearpart --none does not actually clear the partition table—and if you run through this example with the kickstart file as defined here, the installation will only complete if there is space on the target disk to install CentOS 7. To have the kickstart file wipe the target disk and perform a fresh installation of CentOS 7 (which may be desirable to avoid having to manually wipe old machines before reuse), perform the following changes to the kickstart file:

1. Insert the zerombr directive above the clearpart statement to ensure the boot sector is cleared.
2. Change the clearpart line to read clearpart --drives=sda --initlabel --all—be sure to only specify the drives you want clearing in the --drives= parameter!

The fragment of following code does not include these changes as they are destructive—however, you are free to experiment with them as you wish in your test environment:

services --enabled="chronyd"
timezone Europe/London --isUtc

bootloader --location=mbr --boot-drive=sda
autopart --type=lvm
clearpart --none --initlabel

We then define our packages to be installed by default. Here, we are installing the core package group, the minimal system package set, and the chrony package. We are also disabling kdump for our test server, as shown in the following code block:

%packages
@^minimal
@core
chrony

%end

%addon com_redhat_kdump --disable --reserve-mb='auto'

%end

Finally, we can perform additional customization, such as setting a strong password policy—the following lines are actually the defaults from the interactive installer, and should be customized to your requirements:

%anaconda
pwpolicy root --minlen=6 --minquality=1 --notstrict --nochanges --notempty
pwpolicy user --minlen=6 --minquality=1 --notstrict --nochanges --emptyok
pwpolicy luks --minlen=6 --minquality=1 --notstrict --nochanges --notempty
%end

When you have built your complete kickstart file, it's time to test the boot process. Remember the PXELINUX boot configuration we used in the last section? Well, that is reused almost in its entirety, except this time, we need to tell it where to find the kickstart file. I am storing the file we have just created in /var/www/html/centos7-config/centos7unattended.cfg—thus, it can be downloaded from our HTTP server, just like with the packages for the installer. In this case, our PXELINUX configuration would look like this:

default isolinux/menu.c32
prompt 0
timeout 120

menu title --------- Enterprise Automation Boot Menu ---------

label 1
menu label ^1. Install CentOS 7.6 from local repo
kernel centos7/vmlinuz
append initrd=centos7/initrd.img method=http://192.168.201.1/centos7 devfs=nomount ip=dhcp inst.vnc inst.vncpassword=password inst.ks=http://192.168.201.1/centos7-config/centos7unattended.cfg

Let's run through the installation process, and see what happens. Initially, the process will look identical to the interactive installation we performed earlier in this chapter.

Indeed, when you connect to the VNC console of your machine as it is being built, things will initially look the same—the graphical installer for CentOS 7 loads, as shown in the following screenshot:

So far, everything looks like an ordinary interactive installation. However, once the installer finishes the various tasks listed (for example, Saving storage configuration...), you will note that you are presented with a screen that looks complete, save for the Begin Installation button being grayed out (as shown in the following screenshot):

Note the differences here—the installation source has now been set to the HTTP server we set up for our installation process. All other items that are usually completed manually, such as disk selection, have been completed automatically, using the configuration in our kickstart script. In fact, if we wait a short while longer, you will see that the installation commences automatically, without the need to click the Begin Installation button, as shown in the following screenshot:

The installation now proceeds, using the parameters from our kickstart file. Note that the root password and initial user account creation has been completed, using the parameters from the kickstart script, and so, these buttons are again grayed out. In short, although the installation process appears very similar to a normal interactive installation, the user is not able to interact with the process in any way.

There are only two times when a user will be expected to interact with a kickstart installation, as follows:

1. A configuration is incomplete or incorrect—in this instance, the installer will pause and expect the user to intervene, and (if possible) correct the issue.
2. If the reboot keyword has not been specified in the kickstart file.

In the latter case, the installation will complete, but the installer will wait for the Reboot button to be clicked, as shown in the following screenshot:

Rebooting automatically at the end of a kickstart installation is often desirable, as it saves the need to connect to the console. However, there are times when it is not—perhaps you don't actually want the newly built server to be running on the network at the present time. Or, perhaps you are building an image for templating purposes, and so don't want the first boot to complete, as it will mean log files and other data that subsequently need to be cleaned up. 

The exact path the installation takes is up to you—the important thing to note is that you can connect to the VNC console, as shown in the preceding screenshots, and see exactly how the installation is going. If there are any errors or issues, you will be alerted.

Test this out, and see how the build performs for you. In the event of any issues, the installer runs up several consoles on the physical server that contain logging information—you can switch between these using Alt + Tab, or Alt + F<n>, where F<n> is one of the function keys—each of the first six corresponds to a different console, which will contain useful logging information. These can be queried, to debug any issues that might arise. The instructions are actually shown at the bottom of the text mode console screen—see the following screenshot for an example:

In the preceding screenshot, we can see we are on console 1, entitled main. Console 2 has a shell for debugging purposes, and consoles 3 through 5 show log files specific to the installation process.

However, if all of this goes well, you will see the installer run without any intervention required, and then, the server will reboot and present you with a login prompt. From there, you should be able to log in, using the password you defined via the password hash earlier.

That concludes the process of building a CentOS 7 server over the network using a kickstart file. The same high-level process can be followed for Ubuntu and other Debian derivatives through the use of pre-seed files, as we shall explore in the next section.