Automating the OS install options with kickstart

The kickstart file is one of the most important parts of the automated install process. This file contains all the information required to automatically install and configure the OS. The kickstart file is a simple text file that contains the directions to allow an unattended installation.

Getting ready

In order to work with kickstart files, you will need somewhere to build the system, such as Oracle VM VirtualBox. This system can be used to create your first kickstart file, as well as testing new kickstart files before moving them into the PXE environment.

Note

Anaconda is the Oracle Linux installer. It can operate via an automated install using a kickstart file, or interactively via a graphic or text install interface.

How to do it…

While you can manually create a file from scratch, it is much easier to start with the file that Anaconda creates on installation. This kickstart file is created automatically when a manual is installed and saved on the new system in /root/anaconda-ks.cfg. This file can be easily edited and reused for future builds. Let’s look at the file by breaking it down into smaller sections. This system is a graphical installation. Other options are text or cmdline:

Note

There are many options for kickstart, and they are listed in Appendix – kickstart options.

#version=OL8
# Use graphical install
graphical

The repo used to install Oracle Linux was a directory that was loopback mounted from an ISO file. baseurl can also be an HTTPS server, an NFS location, or an FTP server. For example, --baseurl=https://pxe.m57.local/ol8 will tell kickstart to pull the RPMs from a web server:

repo --name="AppStream" --baseurl=file:///run/install/sources/mount-0000-cdrom/AppStream

The packages are the software packages selected. Names starting with an @ sign are package groups, and lines without @ are individual packages. Also, the ^ symbol is used to enable the installation of only the required packages in a group. If ^ is not set, all packages in the group are installed. In this example, the graphical-server-environment package group RPMs are installed as well as the kexec-tools package:

%packages
@^graphical-server-environment
kexec-tools
%end

This is where the default keyboard and language are selected:

# Keyboard layouts
keyboard --xlayouts='us'
# System language
lang en_US.UTF-8

This is the hostname for the new server. Ideally, it should be the Fully Qualified Domain Name (FQDN) for the system:

# Network information
network  --hostname=ol802.lab.m57.local

This is used to select a CD-ROM or a CD-ROM mounted on a filesystem as the installation media:

# Use CDROM installation media
cdrom

This is used to run the setup agent on the first boot:

# Run the Setup Agent on first boot
firstboot --enable

Here, the install disk is selected, as well as the configuration of the logical volume manager and filesystems:

ignoredisk --only-use=sda
# Partition clearing information
clearpart --none --initlabel
# Disk partitioning information
part /boot --fstype="xfs" --ondisk=sda --size=1024
part pv.116 --fstype="lvmpv" --ondisk=sda --size=80868
volgroup ol --pesize=4096 pv.116
logvol /home --fstype="xfs" --size=5120 --name=home --vgname=ol
logvol / --fstype="xfs" --size=51200 --name=root --vgname=ol
logvol /u01 --fstype="xfs" --size=10240 --name=u01 --vgname=ol
logvol /var --fstype="xfs" --size=5120 --name=var --vgname=ol
logvol swap --fstype="swap" --size=4056 --name=swap --vgname=ol
logvol /var/log --fstype="xfs" --size=5120 --name=var_log --vgname=ol

This is the time zone for the server:

# System timezone
timezone America/New_York --isUtc

An encrypted root password can be set on the new system. Normally, the password is encrypted, but optionally, you can use the –-plaintext option with a plaintext password. You can also generate an encrypted password using the python3 -c 'import crypt,getpass;pw=getpass.getpass();print(crypt.crypt(pw) if (pw==getpass.getpass("Confirm: ")) else exit())' Python command:

# Root password
rootpw --iscrypted $6$W5fC.GDUSIVXPDS7$zQFm49tGCtRbfyAd/0f57QcuPZYtOB/gobgN2oKNG
zqrseiNtm7QqkthCcdiNxGJhzLSIQpNyxRQXEPJPuaYM.

This enables kdump, allowing the kernel to save a crash dump to a device for troubleshooting:

%addon com_redhat_kdump --enable --reserve-mb='auto'
%end

This is the password policy for root, users, and Linux Unified Key Setup (LUKS) passphrases:

%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

You can edit the file as needed. Before using a new file, it can be tested with the ksvalidator command. This command is part of the pykickstart package, installed via dnf install -y pykickstart.

Once the package is installed, test a new kickstart file by running ksvalidator $FILE. A sample with an error will look like the following, where line 3 defines the install as xgraphical, which is an unknown option:

[root@localhost ~]# ksvalidator anaconda-ks.cfg
The following problem occurred on line 3 of the kickstart file:
Unknown command: xgraphical

Resolve the error and rerun the validation. In this example, graphical is the correct parameter to use. A clean validation returns nothing and will look as follows:

Figure 2.2 – Clean ksvalidator

Kickstart options!

Now that you have a basic understanding of the kickstart file, you can start adding new options. These options allow you to automate the installation and also grant you more control. The options are covered in Appendix – kickstart options.

How it works…

You can boot any system with kickstart manually by adding the ks parameter to the GRand Unified Bootloader (GRUB) entry. The format is ks=PATH_TO_FILE, where PATH_TO_FILE is a URL where the kickstart file can be read from. This is usually placed on an HTTP server that is accessible to clients.