Automatic CentOS 6.0 Installation With Kickstart

  

 Email Article  

Tweet  

  

Automating Linux server installation promotes better security, stability, and performance through standardized setup, saves administrators' time, and decreases the chance of human mistakes. You can use Kickstart on Red Hat-based operating systems to create a custom boot configuration with just the software and options you want. Here's how to get Kickstart working with CentOS 6 installations.

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.

Kickstart uses a text file to answer all of the CentOS installer's questions. The file may live locally or over a network, so long as it's available during the installation. Because it uses the standard Anaconda installer, Kickstart can configure everything in a new installation, including hard disk partitioning, networking, and usernames and passwords.

A general good practice states that if your servers differ greatly throughout a deployment, the Kickstart configuration directives should specify only a minimal installation, which can be customized later for each server's specific needs. On the other hand, if the servers you're deploying are similar (as in the case of, for instance, a web hosting company with cloned virtual machines) you can adjust Kickstart's directives to handle a complete installation.

Even in the most homogeneous deployments not all servers have the same basic setup, down to such details as hostnames and network addresses. That's why Kickstart has powerful options for specifying custom scripts in the pre- and post-installation processes that can do things like prompt for each server's IP address and hostname.

Kickstart Installation File

There are a few ways to create a Kickstart installation file. First, such a file is created automatically after each new CentOS installation, and can be found at /root/anaconda-ks.cfg. This file contains all the information about the new installation and can be reused for new installations. It can be a good starting point if you need to clone an existing server.

Another way to create and edit the Kickstart file is by using the graphical tool found in the CentOS menu tree under Applications -> System Tools -> Kickstart. Its options are divided in sections via a menu in the left pane, as follows:

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

A sample Kickstart file might look like this:

#Simple Kickstart Configuration for a minimal installation
#Adjusted by Anatoliy Dimitrov

# Firewall configuration
firewall --disabled
# Install OS instead of upgrade
install
# Use CDROM installation media
cdrom
repo --name="centos" --baseurl=file:///mnt/source --cost=100
# Root password – 'testpass', encrypted
rootpw --iscrypted $1$pcafN9bo$lueZDdCQMz8fc/brhDa1J1
# Network information. Later we'll adjust it.
network  --bootproto=static --device=eth0 --gateway=1.1.1.1 --ip=1.1.1.111 --nameserver=1.1.1.2 --netmask=255.255.255.0 --onboot=on
# System authorization information
auth  --useshadow  --passalgo=sha512 --enablefingerprint
# Use text mode install
text
# System keyboard
keyboard us
# System language
lang en_US
# SELinux configuration
selinux --disabled
# Do not configure the X Window System
skipx
# Installation logging level
logging --level=info

# System timezone
timezone  America/New_York
# System bootloader configuration
bootloader --append="crashkernel=auto rhgb quiet" --location=mbr --driveorder="sda"
# Clear the MBR. Helps avoid problems with MBR.
zerombr
# Partition clearing information
clearpart --all  

%post
#Here we will specify add a script later for changing the static IP of each new installation by accepting input
%end

%packages
@base
@core
@server-policy

%end

This file tells Kickstart to perform a complete, automatic installation with a minimum of software packages.

Loading a Kickstart File

To invoke Kickstart, you specify a Kickstart file in the installation media boot options with the parameter ks. To change this parameter at boot time you have to press Tab in the first installation menu, where the installer asks whether it's going to be a graphical or text-mode installation. You can then edit the boot options and add a Kickstart parameter. Here are a few possible scenarios:

• ks=http://example.org/ks.cfg – Get the Kickstart file from an http address. This is the easiest and simplest way to get started without editing the installation medium. It requires that your server have network connectivity.

• ks=cdrom:/ks.cfg – This instructs Anaconda to search for the installation file on the cdrom installation media. While it can be handy to have the Kickstart file there, that requires that you rebuild the installation image first. When rebuilding the image you have to copy the Kickstart file inside it. For convenience, you can put the file in the top level directory so that it can be found easily.

• Booting with BOOTP/DHCP and loading the installation files from NFS is the fastest way to perform an automated install of a large number of installations. With this approach your installation media does not have to be physically placed in each server, and the boot options are automatically acquired. However, setting up a BOOTP/DHCP and NFS server takes some time, which you may not be able to justify for a small number of installations.

Advanced Use

One of the most useful features in Kickstart is its ability to use pre- and post-installation scripts. Consider the previous simple Kickstart file. By default all of its installations will have an IP address of 1.1.1.111, which is obviously not a good practice. Instead, you can ensure that each new installation has a unique IP address by running a post-installation script that takes user input:

#!/bin/sh

#Switch to virtual terminal 3 so that user's input is accepted
chvt 3
exec < /dev/tty3 > /dev/tty3

#Get the input
echo "Please specify IP address:"
read ip

#Substitute with sed the hardcoded IP address with the one we've specified
sed -i "s/1\.1\.1\.111/$ip/" /etc/sysconfig/network-scripts/ifcfg-eth0

#Switch back to virtual terminal 1 for the installation to finish
chvt 1
exec < /dev/tty1 > /dev/tty1

Alternative Methods for Automatic Installations

Kickstart performs an installation in a similar way to a manual one, installing and configuring everything for the server's specific environment. Because of this, its installation process is slower than just copying the files of a Linux system would be.

As an alternative to Kickstart, you can use the files and filesytem image of an operating system in a few possible ways. The simplest option is to use the common Linux program dd:

dd if=/dev/sda of=/media/backup_device/sda_image.img

This command creates an exact image of the sda hard disk to a backup device. Because the dd command works on the byte level, it copies all partition information, along with the master boot record, thus ensuring that you can restore this image (again with dd) on a similar server and have the same server installation there.

You can simplify installations even further in virtual environments. In VMware, for instance, the datastores hold the guest operating system disks as simple files, which means the fastest way to clone a machine is to just copy its datastore directory. You can then create a new virtual machine, specifying for a hard disk the copied vmdk file. For a more sophisticated way of doing this, use the VMware Export / Import template. This feature ensures better compatibility in case you'd like to install the same template on a different VMware server.