Monday, 20 August 2012

Automating Linux Installation and configuration with Kickstart



Automating Linux Installation and configuration with Kickstart

If you are working for an IT Support company means you regularly have to install OSs like CentOS, Fedora & Redhat on servers, desktop computers or even Virtual Machines. 

Following this guide will explain you how to automate the install process using a simple Kickstart file.

Prerequisites

Install and Configure a PXE Boot Environment


What is Kickstart?

For those of you who do not know Kickstart, "The Red Hat Kickstart installation method is used primarily (but not exclusively) by the Red Hat Enterprise Linux operating system to automatically perform unattended operating system installation and configuration."

Kickstart is normally used at sites with many such Linux systems, to allow easy installation and consistent configuration of new computer systems.
Kickstart configuration files can be built three ways:
  1. By hand (manually).
  2. By using the GUI system-config-kickstart tool.
  3. By using the standard Red Hat installation program called Anaconda.
Anaconda will produce an anaconda-ks.cfg configuration file at the end of any manual installation. This file can be used to automatically reproduce the same installation or edited (manually or with system-config-kickstart). 

For the purpose of this tutorial, we have done just this. We have extracted a kickstart file from a previously installed CentOS VM, modified it according to our needs and then use it to create new CentOS VMs on the fly.

First of all if you have never seen a kickstart file before and you have installed a flavour of Redhat Linux on a system go look in the /root dir you should see a file called “anaconda-ks.cfg” open it up and you will see the parameters you entered during your install in the kickstart file. 

It is a good way to understand by example (providing you can remember the options you selected at boot time).

So let's get started with Kickstart.

Setup Process

First, let's create a new directory at /var/www/html directory level and name it ks for starters.
Copy the existing kickstart file from the current running VM and place it in this newly created folder

# cd /var/www/html
# mkdir ks
# cp /root/anaconda-ks.cfg ../ks


I am just renaming the file to something I can use. You can do the same or leave this step.


Once the file is copied, provide it the necessary permissions so that it can be read
# chmod 775 centos58-ks.cfg
 

Once this is done, you can now customize the kickstart file as per your needs and requirements.

The kickstart file is a simple text file, containing a list of items, each identified by a keyword.

It comprises of the following sections:
  • Basic Configuration Here you specify the root password, default language, keyboard, and time zone. You can also specify that the installation should be performed in text mode, which make it faster and more reliable.
  • Installation Method lets you choose whether to perform a new installation or an upgrade. You really shouldn't perform unattended upgrades with Kickstart, because often user input is necessary and server upgrades usually differ. Here you can also specify the installation source – CD-ROM, NFS, FTP, HTTP, or hard drive.
  • Boot Loader Options lets you specify the usual boot options. The default values are optimal for most setups.
  • Partition Information While this seems like a simple configuration menu, it can cause a disaster if it's incorrectly configured. For example, suppose you have a SAN attached to the server. It will take priority over the local disks, and with the default options Kickstart will try to wipe it out in order to perform the installation there. You need to carefully consider the partition information options.
  • Network Configuration By default Kickstart does not configure the network interfaces. Obviously it's not wise to put the same IP address on every server, so this option is a little bit tricky. We'll talk about it more in a moment.
  • Authentication By default Kickstart specifies use of standard shadow passwords. Larger deployments will probably want to use a centralized authentication system. Kickstart supports NIS, LDAP, Kerberos, Hesoid, SMB, SMB, and Name Switch Cache.
  • Firewall Configuration is where you configure not only the firewall but also SELinux. If you don't want to run SELinux, this is the place to disable it. As for the firewall, if it is a minimal install it is better to disable the firewall too and configure it later.
  • Display Configuration For a server setup on which admins will be working in text mode, all options should be unchecked and disabled.
  • Package Selection This menu provides the familiar wizard that appears during CentOS installation for a targeted software installation, which allows you to select and deselect individual optional packages. Advanced users usually prefer to start with minimum package selections and later install only the packages required for the particular server setup. However, it is faster and more convenient to select a whole group of packages for a specific purpose, such as web server installation.
  • Pre-installation Script and Post-installation Script For advanced processing, you can specify scripts for different interpreters, such as bash, Perl, and Python. More on these scripts in a moment.
You can download my custom kickstart configuration script from HERE.  

The Kickstart file that I am supplying does the following tasks:

  • Sets the Hostname of the VM
  • Sets the root password
  • Disables the firewall and selinux
  • Sets the time zone
  • Sets Boot Loader options
  • Creates HDD Partitions in the form of a boot and root partition
  • Installs packages that I want
  • Sets up the hosts file 
  • Adds a user named Cloud
  • Disables unwanted services like sendmail, iptables etc
  • Prints a Welcome Message when someone launches the Terminal Window

To know about the various options that you can use with kickstart, click HERE

Once you are done editing and customizing your kickstart, you need to add its reference in the default file present at /tftpboot/pxelinux.cfg directory as shown:

NOTE: This kickstart file is going to be used only for CentOS installation. You can have similar such kickstarts for RHEL, Fedora etc.

LABEL Centos 5 (DVD - 64-BIT)
KERNEL images/rhel/5/x86_64/vmlinuz
APPEND ks=http://192.168.10.128/ks/centos58-ks.cfg vga=normal initrd=images/rhel/5/x86_64/initrd.img
ramdisk_size=100000
ksdevice=eth1
method=http://<YOUR PXE SERVER IP>/centos ip=dhcp
url --url http://<YOUR PXE SERVER IP>/CentOS

NOTE: There is no "enter" in the APPEND line.. its a continuous statement

Save the file and exit.



Restart the DHCP, the Apache and the PXE Service

# service httpd restart
# service dhcpd restart
# service xinetd restart


Power On a Test VM as described in the EARLIER POST
Select the Centos 5 (DVD - 64-BIT) Option and hit Enter Key


The anaconda installer starts up as shown


The necessary files are received


And now, without specifying any information what so ever, the installer quietly starts up !!


The installer will retrieve necessary info from the kickstart file about the Installation and Configuration process and then go on its merry way !!


If you have specified any packages to be installed in your kickstart, then the Installer also checks dependencies for them and installs them out.


Soon you shall see the Packages getting installed as shown below.
NOTE: No manual task has been performed so far !!


Once the Packages are installed, the Installer will run any Post-Install script that you might have provided in the kickstart file


The VM reboots automatically as well.. (Provided you have specified that in your Kickstart file !!)


Once it reboots, the VM will undergo changes and customization as mentioned in the kickstart file

 
The VM starts up and has all of the configurations set as specified in the kickstart file.


Thats it !! Your Kickstart is ready to be deployed on your network !!

In large deployments it's important to have a standard server setup to ensure that all servers are configured in the same fashion, with the same security mechanisms, filesystem layouts, and services running. Not only is this good practice, it's also a requirement for some government agencies and financial companies as well.




No comments :

Post a Comment