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 VM first before going into production.
2. 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.
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.
3. 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
#version=DEVEL
# Install OS instead of upgrade
install
# Firewall configuration
firewall --enabled --ssh
# Use CDROM installation media
cdrom
# 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 --server=mynfs.server.org --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
--url=myftp.server.org". 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=192.168.2.13 --netmask=255.255.255.0 --gateway=192.168.2.1\
--nameserver=192.168.2.2
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
reboot
# 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
zerombr
# 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:
%packages
@admin-tools
@base
@base-x
@dial-up
@editors
@fonts
@hardware-support
@input-methods
@system-tools
@window-managers
fluxbox
jed
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.
4. 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 mus
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.