KickStart configurations automate the installation of RedHat Enterprise Linux and Fedora systems. Different hardware types are supported via several different base configuration files (desktop.cfg versus server.cfg). Initial packages to install and partition layouts are customizable via cf_* kernel boot arguments. Otherwise, the KickStart configurations simply bootstrap CFEngine. Together, KickStart and CFEngine allow for consistent and reproducible maintenance of RedHat Linux systems.
- Fedora Core 2 KickStart configurations
- RedHat Enterprise Linux 3 KickStart configurations
The configurations rely on Yellowdog Updater, Modified (YUM) servers to provide software updates and the CFEngine package. RedHat Enterprise Linux needs a custom yum package installed, unlike Fedora, which ships with yum. Systems will need Pretty Good Privacy (PGP) keys installed to verify packages downloaded from public YUM servers. For more information on signing packages, see RedHat Package Manager Tips.
Consider also the Yam: Yum/Apt Mirroring project for building and maintaining systems. Other methods of install automation include JumpStart for Solaris, Fully Automatic Installation (FAI), and system imager.
Customize via Boot Arguments
These KickStart configurations use a Pre-installation Script (%pre block) to select the filesystem layout file and %packages definition file from custom kernel boot arguments, if specified. Supported cf_* options include:
- cf_group=group1,group2,…
- cf_part_file=filename - select partition layout from file
- cf_part_script=filename.sh - run shell script to generate filesystem layout
- cf_pkg=filename - select initial packages list
The cf_group option specifies filenames to create under the /var/cfengine/etc/classes directory. These files define classes in CFEngine via FileExists statements. This allows the definition of desktop versus server class systems, and to associate a system with a particular group (such as Accounting versus Development) without relying on static hostnames. The following shows an example CFEngine configuration block to set classes from the cf_group files:
classes:
any::
sys_desktop = ( FileExists(/var/cfengine/etc/classes/desktop) )
sys_server = ( FileExists(/var/cfengine/etc/classes/server) )
group_devel = ( FileExists(/var/cfengine/etc/classes/group_devel) )
More information on the setup and usage of CFEngine classes is available.
Use custom partition files from /install/kickstart/partition/filename on the Build Server. The KickStart configurations will first look for a firename file, followed by a cf_part_script argument. If neither of these were specified, the script looks for a file named after the Medium Access Control (MAC) address of the eth0 device, followed by a $MAC_ADDR.sh script. If none of these files can be found, the disk editor will appear during the installation for manual customization.
To reproduce a custom filesystem layout, uncomment and copy the part directives from the /root/anaconda-ks.cfg file after the install is complete. Place these definitions into a new partition layout file.
Runs the shell script /install/kickstart/partition/filename.sh to generate the /tmp/partition-layout included by the KickStart configuration. Will only run if a cf_part_file file cannot be found. The shell script can be used when disks or memory vary by system, requiring a script to configure “best guess” values on the fly, without the need to list each host by MAC address.
Use desktop for a end-user systems (desktops or laptops), and server for a minimal list of packages. Additional packages required by different CFEngine classes should be installed by CFEngine from YUM servers after installation.
Package lists reside under /install/kickstart/{3AS,fedora}/packages/filename. Package names change between RedHat releases, so different lists are maintained for each release. For example, the redhat-config-xfree86 package under RedHat Linux is named system-config-display in Fedora.
If installing via removable media such as floppy disk, copy the appropriate base KickStart configuration to ks.cfg on the floppy. The ks2floppy script will help automate this copy. When installing a new system, type in the custom boot arguments at the boot prompt:
boot: linux ks=floppy cf_group=desktop cf_part_file=autopart cf_pkg=desktop
To automatically boot with custom arguments, mount the install floppy and edit the default option in the syslinux.cfg file to use the appropriate cf_* statements.
A Preboot Execution Environment (PXE) server can be configured with different options to customize the install process. Instead of typing a long boot statement, the short label of rhel-i386-server can be used, which the PXE configuration entry expands out to include the appropriate kernel and cf_* arguments:
label rhel-i386-server # i386 Server
KERNEL rhel/3AS/i386/vmlinuz
APPEND ip=dhcp initrd=rhel/3AS/i386/initrd.img root=/dev/ram0↵
ks=nfs:192.0.2.1:/install/kickstart/default.cfg↵
cf_pkg=server cf_group=server
label rhel-i386-server-mail # i386 Mail Server
KERNEL rhel/3AS/i386/vmlinuz
APPEND ip=dhcp initrd=rhel/3AS/i386/initrd.img root=/dev/ram0↵
ks=nfs:192.0.2.1:/install/kickstart/default.cfg↵
cf_pkg=server cf_group=server,mail_server cf_part_file=mailserver
Partition Layouts
Partition layouts can either be a single large partition, or many smaller partitions. Most systems will benefit from a single large partition, as the users can juggle the needs of the Operating System, application software, and any data (logfiles, configuration). Multiple small partitions will in most cases waste space and require manual intervention should a partition fill up. Use configuration management, and reimage and reinstall this class of system when it fails. Ensure any critical data backed up (e.g. user data under a home directory), or that logs and other data from these systems end up on specialized systems elsewhere (backup server, log archive system, database for application data).
Servers such as databases, fileservers, and other special cases are more likely to require multiple partitions. On the other hand, these servers usually will be rare enough to justify the time spent planning, creating, and maintaining the custom partition layouts. These servers may also use logical volumes or connect into specialized data storage (SAN, distributed filesystems) to meet their data needs.
Whether to use a Logical Volume Manager (LVM) depends on the needs of the system; LVM is more complex, and may be harder to remount on a new system, though will allow filesystem snapshots and other advanced features. Resizing filesystems may be very slow!
For better security on critical servers, isolate untrusted users from critical filesystem areas. This includes user home directories (usually under /home), and the temporary /tmp and /var/tmp directories. Also avoid mixing directories: user home directories should not be used by role accounts or for shared data purposes. Mount the user areas with the nosuid or other options to prevent untrusted execution of code. This setup would be appropriate for a campus mail server, where users have access to run mail programs, but should not be able to affect the operating system and e-mail data partitions.
KickStart Tips
Detailed notes on steps done in example KickStart configurations on this page.
- Change virtual terminal
- Configure startup run of CFEngine
- Example %pre Script
- Record install time and method
- Set system date
- Determine Bootloader used on Running System
chvt(1) can switch virtual terminals. %post scripts should change to terminal 3, where the output of %post is sent by default.
%post
chvt 3
Run cfagent from the rc.local script so that CFEngine runs at each startup.
%post
cat <<'EOF' > /etc/rc.d/rc.local
#!/bin/sh
/usr/sbin/cfagent --no-splay --define sys_startup &
touch /var/lock/subsys/local
EOF
chmod 755 /etc/rc.d/rc.local
I recommend against running cfengine during a KickStart install, as the environment, kernel, and software available may be different than those available under the operating system after a reboot.
kickstarts/automated installs and partition tables
Save the install time and method. This allows scripts to gather when and how each host was installed.
%post
mkdir -p /etc/system-info
date --iso-8601=minutes > /etc/system-info/install-date
echo "method=kickstart version=1 revision=1" > /etc/system-info/install-method
If installing over a network, set the system time. pool.ntp.org offers public time services.
%packages --resolvedeps
ntp
%post
/usr/sbin/ntpdate -su pool.ntp.org
Not really a KickStart tip, though good to know after the fact. Assumes the /root/anaconda-ks.cfg file written by the installer has been left on the system.
$ sudo grep bootloader /root/anaconda-ks.cfg
CFEngine Build Server Setup
With CFEngine, a build_server class of system can host the required PGP keys, packages, and configurations for installation. Clients being installed can use a Network File System (NFS) mount to download files from the build server.
copy:
build_server::
# for NFS via KickStart %post script to read from
$(masterfiles)/etc/rpm-pgp-keys
dest=/install/rpm-pgp-keys
owner=root group=$(zerogroup) mode=444
recurse=inf
backup=false
server=$(policyhost)
type=checksum
purge=true
# yum configurations for KickStart bootstrap
$(masterfiles)/app/yum/conf
dest=/install/yum/conf
owner=root group=$(zerogroup) mode=444
recurse=1
backup=false
server=$(policyhost)
# yum RPM for RHEL bootstrap (Fedora ships with yum)
$(masterfiles)/app/yum/rpm
dest=/install/yum/rpm
owner=root group=$(zerogroup) mode=444
recurse=1
backup=false
server=$(policyhost)
# KickStart configurations, partition layouts, package lists
$(masterfiles)/os/redhat/kickstart/
dest=/install/kickstart
owner=root group=$(zerogroup) mode=444
recurse=inf
backup=false
server=$(policyhost)
type=checksum
purge=true
- /install/rpm-pgp-keys
- /install/yum
- /install/kickstart
The rpm-pgp-keys directory should contain PGP keys collected from the supported systems, along with keys used to sign local packages. Once in production, cfengine updates the keys in this directory, allowing new signing keys to be introduced every year.
$ ls -1 masterfiles/etc/rpm-pgp-keys
BETA-RPM-GPG-KEY
CVS
RPM-GPG-KEY
RPM-GPG-KEY-fedora
RPM-GPG-KEY-fedora-test
SITE-KEY-2005-01-31
Each user doing package signing should use their own key. When a user leaves, their public key must be removed from production systems, and any packages they signed resigned by someone else.
To bootstrap yum, the package and initial configuration files must be copied to the system during the %post script. Fedora systems use both local and remote YUM servers, while RedHat Enterprise uses a local YUM server for both packages converted from up2date and packages created locally. RedHat Enterprise needs a local yum-2.0.7-1.noarch.rpm package, unlike Fedora.
$ ls -1 masterfiles/app/yum/{conf,rpm}
masterfiles/app/yum/conf:
CVS
yum.conf.fedora
yum.conf.rhel
masterfiles/app/yum/rpm:
CVS
yum-2.0.7-1.noarch.rpm
Contains the KickStart configurations for Fedora Core 2 and RedHat Enterprise Linux 3, custom partition layouts, and initial package list files.
$ ls -1 masterfiles/os/redhat/kickstart
3AS
CVS
fedora
partition
$ ls -1 masterfiles/os/redhat/kickstart/{3AS,fedora}
masterfiles/os/redhat/kickstart/3AS:
CVS
default-x86_64.cfg
default.cfg
packages
masterfiles/os/redhat/kickstart/fedora:
CVS
default-x86_64.cfg
default.cfg
packages
