Streamlining Linux Setups: Mastering Kickstart Files

Deploying Linux across multiple systems can often become repetitive and time-consuming. Whether it’s for a small office, a large enterprise, or even for your home lab, automating the installation process not only saves time but also ensures consistency across installations. One of the most powerful tools available for Linux system administrators for this purpose is the Kickstart file. It's applicable in various distributions like CentOS, Fedora, and Red Hat Enterprise Linux. In this post, we delve into how to customise Linux installations using Kickstart files and manage different package managers including apt (for Debian-based systems), dnf (for Fedora systems), and zypper (for openSUSE).

What is a Kickstart File?

A Kickstart file automates the Linux installation process. It allows the user to preset answers to all questions the installer would normally ask during a manual installation. This includes settings for the disk layout, network configurations, timezone, root password, and more. Once created, this file can be provided to the installation process, and no further interaction is necessary.

Creating a Kickstart File

Crafting a Kickstart file is straightforward. You can manually create the file by defining parameters or by using a system-config-kickstart tool on systems where it's available. Here's a simple example of what a Kickstart file might look like:

# Sample Kickstart file for a basic setup
# System language
lang en_US.UTF-8
# Keyboard layouts
keyboard us
# Install from local CD-ROM
cdrom
# Root password (set to "rootpw" here, consider hashing it for security)
rootpw --plaintext rootpw
# System timezone
timezone America/New_York
# Default boot loader installation
bootloader --location=mbr
# Clear the Master Boot Record
zerombr
# Partition clearing information
clearpart --all --initlabel
# Disk partitioning information
part / --fstype="ext4" --size=1 --grow
part swap --recommended
# System authorization information
auth --useshadow --enablemd5
# SELinux configuration
selinux --enforcing
# Firewall configuration
firewall --enabled --ssh
# Disable system services
services --disabled="chronyd"
# System services
services --enabled="sshd"
# Do not configure X Window System
skipx
# Package selection
%packages
@base
@core
wget
curl
vim
%end

Deploying with the Kickstart File

To utilize the Kickstart file during installation, point the installer to the file. For most systems using a Red Hat variant, you can specify the Kickstart file location right at the boot prompt during the start of the installation process like so:

linux ks=cdrom:/ks.cfg

Alternatively, if the Kickstart file is hosted on a network:

linux ks=http://example.com/ks.cfg

Package Management in Kickstart Files

The %packages section of the Kickstart file allows specifying which packages and groups should be installed. Handling this section varies slightly depending on which Linux distribution you are using.

Using apt (Debian-based systems)

While Debian-based systems like Ubuntu do not use Kickstart by default (they often use preseed files), they can still process kickstart for base installations:

%packages
@ubuntu-server
openssh-server
ftp
%end

You can handle specific package installations using post-install scripts within the Kickstart file.

Using dnf (Fedora, RHEL, etc.)

For distributions using dnf:

%packages
@core
wget
httpd
%end

Using zypper (openSUSE, SLE)

For zypper in openSUSE, package selection remains similar:

%packages
patterns-base
vim
cron
%end

Conclusion

Automating Linux installations using Kickstart files can save tremendous time and effort, especially when deploying multiple systems. By predefining system configurations and included packages, you ensure all installations are consistent and meet predefined specifications for security and functionality. Whether using apt, dnf, or zypper, incorporating package management into your Kickstart files can fully optimise your system installations right from the start.

Remember to always test your Kickstart files in a safe environment before deploying in a production scenario to avoid unwanted outcomes. Happy automating!