Automating Linux installations with Kickstart


Red Hat, and their community effort, Fedora, are more or less enterprise-oriented. That being said, it’s only natural they offer enterprise-specific tools that don’t quite make sense on other desktop oriented operating systems. In the enterprise environment, where the system administrator has to manage lots of machines and installations, one tool that helps a lot is one that facilitates automated installations on several computers, using the same options for each of them. Instead of installing each system separately, the administrator just boots the installation media, tells the system where to find the options for installation and comes back after an hour to check on the system. It’s a tremendous advantage in terms of time and effort, especially when dealing with lots of systems. Just like HP-UX offers Ignite or OpenSUSE offers AutoYAST, Red Hat/Fedora offers Kickstart. You will learn what that is, how to get the best of it and how to use the newly created Kickstart file. We assume basic knowledge of Linux and we recommend you try this in a virtual machine first before going into production.

Beginning work with Kickstart

We want to make a few practical points before diving into the article, so you know what’s available and how/when to use it. First of all, we assume you have a Fedora installation (or Red Hat, but we tested this on our Fedora 16 box), up-to-date and ready to use. You will see, if you look in root’s home folder, that you have a file there called anaconda-ks.cfg. That’s the Kickstart file generated by Anaconda when (or, better said, after) you installed your system. It contains your options like partitioning or package selection. We recommend you use your favorite text editor to browse it in order to get familiar with the syntax, which isn’t complicated at all.

Second, Fedora offers an utility named system-config-kickstart, which is a small GUI program that takes you through each and every part of the install options and, after you’re done, offers you the possibility to save the file to be used as you wish.

Kickstart GUI

Now, it’s obvious that, at least for starters, you’ll be better off using this utility instead of manually writing ks files. However, there are some drawbacks. We usually recommend the use of the command-line, because it’s bound to work without X, without local access (think about a long-distance connection with ssh – you wouldn’t want to use X there), and, in the end, you will learn something new and cool that will help you a great deal when dealing with Red Hat-based systems. So, we recommend starting with the GUI and slowly migrating to a text editor and the Fedora documentation for writing your own Kickstart files. We’ll focus on the latter approach for the rest of the article, for reasons exposed above, but we’ll start with the GUI-generated ks.cfg and go from there.

Creating Kickstart files

After this article, we hope that you’ll know how to write your own ks files, but of course you are welcome to use the GUI if you so desire. But for now, let’s look at the file I generated using system-config-kickstart. We recommend you generate one yourself, with your options, and compare your ks file with mine, as it will make learning easier. The first few lines look like this (we will assume that you start from scratch):

#platform=x86, AMD64, or Intel EM64T
# Install OS instead of upgrade
# Firewall configuration
firewall --enabled --ssh
# Use CDROM installation media
# Network information
network --bootproto=dhcp --device=eth0

We gather from here that we want to install, but you can replace “install” with “upgrade” if you so wish, enable the the firewall with SSH as the trusted service, ( we recommend this setup if you don’t have other needs), we will install from optical media (you can opt for harddrive, nfs or url) and the network is set up using DHCP on eth0. Let’s take each option and see what other options you have. Regarding the firewall, if you need to specify a trusted interface, you can tell Kickstart that by using “–trust=$interface”. It seems that one of the advantages of using a text editor start to make themselves obvious: you don’t need “–ssh” in the firewall line, because that’s enabled by default. Other services you can specify here are smtp, http or ftp, also prefixed with a double dash and space-separated.

Going further to installation media, as we already told you about available options, we just want to outline some options. A typical harddrive line would look like this:

harddrive --partition=sdb3 --dir=/install

This means that directory /install on /dev/sdb3 must contain the ISOs and images/install.img as well. If using nfs, the syntax is more or less the same, in that you must specify a server and a directory on that server, plus some options if you need to:

nfs --dir=install

Like before, the install directory must contain the same things for the installation to work. Finally, the url option has the form “url –”. The server must offer FTP or HTTP services, so it can be a public mirror or a private one.

If you want to set up networking with a static IP, here’s an example:

network --bootproto=static --ip= --netmask= --gateway=\ 

Be aware: although we wrapped the above line for readability, in your ks file you must enter it all on one line. You can also set the device to configure if you have more than one installed with “–device=ethx” and activate it at boot time with “–onboot=yes”.

Setting the root password is as simple as

# Root password
rootpw --iscrypted $hash

If you don’t want to enter your password encrypted, although we really, really recommend you do so, replace “–iscrypted” with “–plaintext” and enter your desired password afterwards, but make sure you have the ks.cfg file saved securely and with proper permissions. Authorization options are set by a line like this:

# System authorization information
auth --useshadow --passalgo=md5

Read the authconfig manual page for more options, but this is a sensible default. If you want to select a graphical installation, you don’t need to do anything, since it’s the default. If not, just type “text” alone on a line and text installation it will be.

If you want the Setup Agent to start on first boot, which will enable you to create a normal user, set timezone and so on, although you can set these up right in your kickstart file (see user and timezone in
Fedora’s excellent documentation), then you can add this line to your ks file:

firstboot --enable

Alright, let’s see how the next part of my ks.cfg looks like:

# System keyboard
keyboard us
# System language
lang en_US
# SELinux configuration
selinux --enforcing
# Installation logging level
logging --level=info
# Reboot after installation
# System timezone
timezone Europe/Bucharest

Some of these options are pretty much self-explanatory, so we’ll only stop at a few of them. The “selinux” option can be set to “–enforcing”, “–permissive” or “–disabled”, depending on your wishes. However, just because SELinux gave you some headaches in the past, don’t rush and disable it right away. With a little bit of work it can prove to be useful, especially in a large network. We recommend a reboot after installation, provided you have the BIOS boot order properly set up.

What follows is my setup for a small and single-disk system, but Anaconda is flexible and understands RAID, LVM or FCoE. The bootloader will be installed to MBR which is to be wiped clean, just like the partition table.

# System bootloader configuration
bootloader --location=mbr
# Clear the Master Boot Record
# Partition clearing information
clearpart --all --initlabel
# Disk partitioning information
part / --asprimary --fstype="ext4" --size=10240
part swap --asprimary --fstype="swap" --size=1024

Since the drive is small, I didn’t feel the need to create more separate partitions, especially since users’ important files are backed up via NFS.

Just like RPM specfiles, Kickstart files are divided in sections, named by prefixing the names with a ‘%’. You can also write %pre and %post scripts, to be executed before and after the contents of the ks file are parsed, but that’s a bit out of our scope. So now that we’re finished with basic boot options, what packages should we install? Remember that this is supposed to be a fully automated install, so we can’t stop and ask the user what packages (s)he wants. First, we start our section and then we define groups and individual packages:


The lines starting with ‘@’ denote packages groups (use “yum grouplist” to see them all) and the others define individual packages. When you’re done, remember to put an “%end” to your section. Save the file, and let’s see how to use it in a real life scenario.

Using Kickstart files

You can put your ks.cfg file onto a CDROM, floppy or on the network. We won’t discuss the floppy option here, because it’s as simple as copying the ks.cfg file, so let’s see how to put the Kickstart file on a CD. There is a lot of documentation about how to create a bootable Red Hat or Fedora iso. The idea is simple: make sure that the file is named ks.cfg and copy it inside the isolinux directory before creating the image. As for network installation, things are a bit more complicated, but the scenario more common, since in an environment where Kickstart proves useful there is usually a network available. You will need a BOOTP/DHCP server and a NFS server for this, and the short idea is that the dhcpd.conf file must contain something like this:

 filename "/usr/share/kickstarts/" #use the directory name where ks.cfg is, or the full path, e.g. "/usr/share/ks.cfg"
servername "hostname.dom.ain" #the NFS server

If you will boot from CD, just alter the boot prompt to look like this: “linux ks={floppy, cdrom:/ks.cfg, nfs:/$server/$path…}”. Check the documentation for possible options depending on your setup.


As before, this article only managed to cover a basic setup using Kickstart, but the system is capable of so much more. The link provided above will list all options and guide you through if you need a more complex arrangement.

Comments and Discussions
Linux Forum