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
%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
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.