[Howto] Pimp your kickstart, Part one

fedora-logo-bubble
In Fedora and Red Hat/CentOS unattended installations are done via kickstart. It is also the tool of your choice if you want to set up several systems in the exact same way. With some simple tricks it can become even more useful.

The kickstart documentation is very detailed and covers the most important install options and flags. However, it is not really flexible – you can create one kickstart file for several servers, but as soon as some details in the setup need to be changed most people create another kickstart file containing that changes.
This makes it harder to maintain the kickstart files and can easily be avoided.

Parameters via command line arguments

Kickstart is usually launched via the boot command line with a string like linux ks=nfs:/myserver.com/ks.cfg. And the boot command line string can be accessed later on via /proc/cmdline – which you can now process further.

For example, imagine you have one set of machines accessing the internet via a proxy, and one set of machines in another network which don’t. You could now define a boot command line parameter like myop_proxy. If it is set to myop_proxy=yes, the %post section of the kickstart file adds the proxy to yum, if the parameter is set to myop_proxy=no, the proxy is not set. Therefore, first the post section would have to read in the command line, sort after the myop_proxy parameter, put it into a text file and source the text file. As a result, the post section, which works just like a typical shell script, now has the variable myop_proxy set to either yes or no. A simple if statement can now check for the value of the variable and add the proxy configuration:

%post
 /tmp/boot_parameters
. /tmp/boot_parameters

if [[ "$myop_proxy" = "yes" ]]; then
  echo "proxy=http://proxy.myserver.com:8080" >> /etc/yum.conf
elif [[ "$myop_proxy" = "no" ]]; then
  echo 'No proxy configured.' >&2
fi

The first line at the begin of the post section is in so far interesting as it makes sure that all parameters beginning with myop_ are filtered and afterwards sourced. So more parameters for more options can be defined, for example to distinguish normal machines from setups in a DMZ where some packages should be removed after the basic installation:

if [[ "$myop_type" = "DMZ" ]]; then
  yum -y remove httpd *samba*
else
  echo 'This machine is not in the DMZ.' >&2
fi

Extra: Pre-testing additional kickstart commands

The best way to test scripts and commands which should be triggered by the parameters is to launch an installation with the yet unmodified kickstart script, wait until it is finished, and then switch to the terminal on Alt+F2. With a chroot /mnt/sysimage an environment can be created just like the one in the normal post section. Now everything which should find its way into the kickstart script can be tested. This might be handy to avoid too many restarts to test changes to the kickstart routines.

Extra: Extended log file

In case you take advantage of the options you might also want to have a look at the log file. This can easily be done via:

%post
(
echo "Here is the place for usual post commands." >&2
...
) > /root/post_install.log 2>&1

This trick is also mentioned in the above linked RHEL documentation.

Other possible ways

These options are not the only way to dynamically modify and personalize kickstart scripts. Other possible ways are to use ldap: kickstart can query an ldap-server and hand over system data to get back further details, options or scripts. Also, via DHCP kickstart files depending on the IP can be provided, and last but not least kickstart can also query a http server to hand it over a kickstart file fitting to the network MAC address.

About these ads

3 thoughts on “[Howto] Pimp your kickstart, Part one

  1. # /tmp/boot_parameters

    The first line at the begin of the post section is in so far interesting as it makes sure that all parameters beginning with myop_

    Well ^rb certainly doesn’t match ^myop_ but maybe it’s me…

Comments are closed.