Set up a local Linux installation and update server with Kickstart

http://www.openlogic.com/wazi/bid/265413/set-up-a-local-linux-installation-and-update-server


Setting up Linux on multiple machines can take a lot of time and effort, but it doesn't have to. With Kickstart, you can customize automatic installation of any Fedora-based distribution, including CentOS, on new servers. Kickstart can install not only the operating system but also all the applications you expect to run. And to make everything run as quickly as possible, you can store Kickstart files and Linux packages on a local Apache web server, which then servers as your network installation and update server, saving you bandwidth every time you roll out a new machine.
The server you use as an installation server doesn't need to have a lot of processing power, but it should have ample free space (at least 20GB) to house the CentOS installation DVDs and package updates.
To build your installation server, start by installing a barebones CentOS system. Once the hardware and operating system are set up, make sure the server has a fixed IP address, say 192.168.2.110. Then install the Apache web server with the command yum install httpd.i686, or yum install httpd.x86_64 on a 64-bit installation.
Next, copy over the installation files from the CentOS DVDs to this server:

# mkdir /install
# rsync -arv /media/CentOS_6.3_Final  /install

Ideally you should set up the /install partition on a separate disk or a logical volume for more flexibilty. If you can do that, make sure you also edit the contents of /etc/fstab file to mount the partition or volume when the server boots.
If you create the install directory outside Apache's document root directory (/var/www/html/), you must create a configuration file to point the web server to the correct directory. All Apache custom configuration files are housed under the /etc/httpd/conf.d/ directory. Switch to that directory and create a file called install.conf with the following contents:

Alias /install/ /install/

 Options Indexes 
 AllowOverride None
 Order allow,deny
 Allow from all

This tells Apache where to redirect any traffic that requests the /install directory. Any time you make changes to Apache's configuration you should check them for errors with the command apachectl configtest.
You can start the web server by running service httpd start. To ensure it starts when you reboot the server, add it to runlevels 3 and 5 with the command chkconfig --level 35 httpd on.

Configuring security

Although the web server is up and running, you cannot yet access it from any other machine on the network, because by default CentOS uses SELinux Enforcing mode and allows only incoming SSH traffic through the firewall.
One easy way around the problem is to tune down SELinux to use 'Permissive' mode (with the command setenforce permissive), or turn SELinux off altogether along with the firewall. Don't take the easy way out; even though you may be serving only trusted machines within the protected local network, you still shouldn't turn off important security mechanisms.
Instead, reconfigure the firewall to allow HTTP traffic over Apache's port 80:

# iptables -I INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
# service iptables save
# service iptables restart

To avoid running into issues with SELinux, change the SELinux context on the custom install directory to the SELinux context on the web server's document root directory:

# ls -Zd /var/www/html/
drwxr-xr-x.  root   root  system_u:object_r:httpd_sys_content_t:s0   /var/www/html/ 

The httpd_sys_content_t part in the output is the SELinux context of the directory. Now apply it to the install directory:

# chcon -R –type=httpd_sys_content_t /install

You should then be able to access the web server and the install directory from any machine on the local network. To test this, boot a machine with the CentOS minimal boot CD. When prompted, select the "URL" option to install from the local network server, and enter the install server's URL.

Unattended installation

Now the installation server is set up, but you still need to be physically present on a client machine to complete the installation. To automate the installation process you need to use Fedora's Kickstart installation method. This utility relies on so-called kickstart files that contain all the answers to all the questions asked during the installation process, such as the partitioning scheme, the packages to install, and so on.
You can use different kickstart files to install different types of systems, such as a web server, a mailserver, or a client desktop. When you install a CentOS machine using the normal manual process, Fedora's Anaconda installer saves a kickstart file for that particular installation under /root/anaconda-ks.cfg. You can use this file to install another system with an identical hardware and software configuration.
You can also use a kickstart file to customize and create your own kickstart files. The most convenient way to do that is to use the graphical Kickstart Configurator tool that you can download and install with the command yum install system-config-kickstart.
Besides the package selection, you need to pay attention to two important things in the kickstart files to work with an installation server: the installation method and the network setup.
The server we created, and which we are adapting this kickstart file from, uses a static IP address. If we used it unedited, we'd have multiple machines on the network with the same IP address, which is a good way to give yourself a headache. Instead, we'll assign IP addresses to new machines using a DHCP server on the network. Find the line that starts with the keyword "network" and change it to read:

network --device eth0 --bootproto dhcp

Also, unlike the initial setup, the clients we'll be setting up should fetch packages from the network server instead of the CentOS Installation DVD. To change the installation medium, look for the line that reads "cdrom" and replace it with the location of the installation server:

url --url http://192.168.2.110/install/ 

Place your kickstart files under the web server's document root directory, in a directory such as /var/www/html/kickstarts. YOu might have, for instance, a kickstart file called gnomedesktop.cfg that installs a GNOME-based desktop and another called kdedesktop.cfg that install a KDE-based desktop.
To install a client using the kickstart files, boot from the minimal boot CD, and at the boot screen point to the kickstart file you want to use. For example, to install a GNOME desktop, type:

linux ks=http://192.168.2.110/kickstarts/gnomedesktop.cfg

Presto! The system will now run through all the installation steps automatically.

Set up an update server

It's easy to take the installation server further and also use it as a local update repository. This saves bandwidth, as all clients can be set up to fetch updates from the local repository instead of the Internet.
On the installation server, create a directory structure for the update repo. To keep things simple, use the same directory structure as on the CentOS mirrors:

# mkdir -p /localrepo/centos/6.3

CentOS repos are set up such that they look only at the major release number. To make that work smoothly, create a symbolic link to the current 6.3 repo:

# ln -s /localrepo/centos/6.3/ /localrepo/centos/6

Then, once there's a new point release, such as CentOS 6.4, all you need to do is create a new link to point to the local repository of the new release.
Now head to the list of mirrors on the CentOS website and look for one that's close to you. Here I use the one provided by Georgia Tech and mirror it using rsync:
# rsync --progress -avH --delete --exclude 'isos' rsync://rsync.gtlib.gatech.edu/centos/6.3/ /localrepo/centos/6.3/
This creates an exact copy of the mirror on the local disk, but skips over the directories specified with the --exclude parameter – in this case the isos directory – since we don't really need them. If all your machines are of a particular architecture – say 64-bit – you can exclude mirroring packages for the 32-bit architecture by appending --exclude 'i386'.
You want your local repository to stay current with security patches and updates, so you should set up an automatic update via a cron job. CentOS keeps cron jobs under /var/spool/cron; there you can create a job for the root user that checks for updates at 5:30 a.m. every Sunday:
# vi /var/spool/cron/root 30 5 * * 7 /usr/bin/rsync rsync --progress -avH --delete --exclude 'isos' rsync://rsync.gtlib.gatech.edu/centos/6.3/ /localrepo/centos/6.3/

Changing the update repos

Once you've created a local repo, you need to make the Apache web server aware of it, just as we did with the /install directory. Edit the repo configuration file:

# vi /etc/httpd/conf.d/repo.conf

Alias /repo/ /localrepo/

 Options Indexes FollowSymLinks
 AllowOverride None
 Order allow,deny
 Allow from all

This equips Apache to redirect requests looking for the /repo directory to the /localrepo directory on the web server. The FollowSymLinks directive tells Apache to traverse the directory as directed by the filesystem. Save the file and restart the web server.
Now you must configure the clients so that they fetch packages from the local update server. CentOS keeps all the repositories under the yum.repos.d folder. Head to the folder and open a repository such as CentOS-Base.repo in a text editor. In this file, comment out all the entries that begin with mirrorlist=, then enable the lines that begin with baseurl=, and make sure the URL points to the local update repository:

baseurl=http://192.168.2.110/repo/centos/$releasever/os/$basearch

When you're done making all the changes, save the file and clear the existing Yum cache:

# yum clean all

Automate post-install updates

If you have only a couple of machines, you could go to each machine and manually change each one's repository to update from the local mirror. But a more efficient approach is to create a custom script that replaces the existing repos with your custom repos. You can also use such a script in the kickstart files themselves so that the repos are automatically replaced straight after installation.
First, create a basic custom repo file:

# vi local.repo

[LOCAL Repo] 
name=LOCAL Repo
baseurl=http://192.168.2.110/repo/centos/$releasever/os/$basearch
gpgcheck=1 
enabled=1 
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6 

Place it in a directory under the web server's document root directory – for instance, /var/www/html/post-install/. Also create a script to replace the existing repositories with this new one and place in under the same directory.

# vi local-repo.sh:

cd /etc/yum.repos.d
rm *.repo  
wget http://192.168.2.110/post-install/local.repo
yum clean all
yum -y update

Now open a kickstarter file and scroll down to the %post section, which defines actions that will be performed after a system has been installed, and add the following:

%post 
cd /tmp 
wget http://192.168.2.110/post-install/local-repo.sh 
chmod +x local-repo.sh 
./repo.sh

If you have multiple kickstart files, make sure you change all of them to run the custom script that replaces the default repositories with the custom one.
We've covered a lot of ground in this tutorial. It might seem a bit overwhelming to set this all up – but you don't have to do it all at once. If you have a small network you can just set up an install server. Admins on larger networks that run lots of critical servers and applications and need the latest security updates can also set up an update server.
Once you have everything set up, rolling out new machines becomes just a matter of pointing to the correct kickstart file. You can set up new machines, reset old ones for new employees, or change a web server into a mail server with a single command. And using kickstarter with an installation and update server not only saves you time and effort, it also cut down on your company's Internet bandwidth costs.