[Howto] Pimp your kickstart, Part two

fedora-logo-bubble
Kickstart can be used to automatically set up Fedora/Red Hat installations, but also deploy larger setups of similar systems. In a recent post it was explained how to use boot parameters to flexibly influence the kickstart installation. This post will expand this idea further via remotely provided configuration files.

Part one explained howto use kickstart with boot parameters. While the advatange of this method is that different setup configurations can be stored in one file it also means that the kickstart file can become quite crowded over the time. A way to avoid this is to use shell scripts provided on a server and launch them depending on the boot options.

A NFS/hostname example

In this example most servers just get the same setup, but only few servers are monitoring servers which require very specific additions. Additionally, a NFS server is already available on the net (maybe to deliver the kickstart files), and the machines are distinguished by their hostname.

First, the specific additions need to be placed in a shell script. The shell script(s) are named after the hostname of the corresponding host and are copied to the NFS share. Second, the kickstart file gets a section to mount the NFS share right after the installation. To avoid problems with NFS support in the newly installed machines, the share is mounted right before the default %post section in a special section which has not changed the root yet:

%post --nochroot
mkdir -p /mnt/sysimage/media/nfsshare
mount myserver.com:/nfsexport /mnt/sysimage/media/nfsshare

Afterwards, the normal %post section follows as usual, but has access to the NFS share in /media/nfsshare.

Next, the kickstart file needs a function in %post to first check if the host name is set, if a file of that name exists on the server, and if yes, copy and launch it. This requires of course the preparations explained in part one to filter for the boot parameters.

if test "${myop_hostname+set}" = set ; then
  if [ -e /media/nfsshare/$myop_hostname ]; then
    cp /media/nfsshare/$myop_hostname /root/.
    chmod +x /root/$myop_hostname
    /bin/sh /root/$myop_hostname
  fi
fi

The kickstart installation can can now be called with the hostname as a boot parameter: linux ks=nfs:/myserver.com/ks.cfg myop_hostname=blueserver. If no hostname is given, host-specific configuration is ignored.

Other ways

Of course there is no need to use a NFS server, or a server it all: the different shell scripts can be provided directly on the installation medium, or on a web server. Also, using host based configuration makes it more difficult again to maintain all the different scripts for all the different servers. If the number of servers grow above a certain number the best way would be to manage all the options, scripts and parameters in a database and export host-based configuration files when needed or provide it via ldap.

Extra: Tiny installation

Quite often it happens that people only need small Fedora/RHEL setups. However, even with no arguments in the %packages section a default installation takes quite some space. This is due to the fact that in the default configuration kickstat installs all packages from the base group. A special flag must be set to avoid that. Together with that flag, a base installation requiring “only” roughly 160 packages looks like:

%packages --nobase
openssh-clients
openssh-server
ntp
yum
dhclient
sendmail
man
-system-config-securitylevel-tui

But beware: such installations are really basic and are missing basic tools like which!

4 thoughts on “[Howto] Pimp your kickstart, Part two”

  1. Thanks, these are nice articles.

    If you’re using RHN, for the minimal install you also need yum-rhn-plugin too. Also, note that it is so minimal that you won’t get any fancy stuff like LDAP authentication either!

Comments are closed.