KickStart Configurations & CFEngine

Customize via Boot Arguments | Partition Layouts | KickStart Tips | CFEngine Build Server Setup

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.

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:

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.

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