Tips for optimizing RHEL/CentOS kickstart workflow
I'm working in an environment that consists of CentOS systems located in multiple data centers and office locations. I've been using a reasonable kickstart with a solid post-install script, but want to streamline and expand the process. We have our own yum repo and I have control over the range of hardware in use (it's usually HP ProLiant hardware or VMWare) Let's say I build or redeploy one server every week. Following the steps needed for hardware preparation, I begin the OS setup. The issues I have now are:
1). A nice way of booting systems into the network installer. I've been using the 10mb boot.iso/netinstall.iso available in CentOS distribution. I mount this either via VMWare vCenter (for VMs) or HP ILO (usually over SSH, pointing to the URL of the ISO) to kick off the installations. I can't use PXE in most cases because the data center locations do not have DHCP available. Is there a clean way to get the boot.iso onto a USB key, for instance?
2). Sometimes I need to set a static IP for the kickstart. Is there a better way to input that info other than typing it on the boot: command line at the installer prompt?
3). A good method for customizing the kickstart. Right now, I have most of what I need, but sometimes need to alter the partition scheme to account for different RAID setups (e.g. two SmartArray controllers). Right now, I'm basically creating a separate kickstart file for each system (or group of system's) settings. I end up with a directory full of old *.cfg files. I know there's a more elegant way of doing this. PHP perhaps?
4). Help with the install method. As-is, the full build from prompt to completion takes 5-10 minutes. I've noticed that the install method matters, depending on location. HTTP works well local to the yum server, but is poor over our high-bandwidth low-latency connections to other sites. NFS works better in those cases. I'd appreciate any nifty tricks used to preload settings or system parameters before the kickstart process.
5). The post-install script works well. It pulls additional packages, sets some initial settings, trims the services list down and populates a few users/passwords/SSH keys. I'd like to get this environment running with a proper configuration management (I'm used to CFEngine, but think that Puppet or Bcfg2 are probably a better choice nowadays). Do I pare-down the post-install script and move those functions into CFEngine? That's probably a different question, though.
Here's a an example of the kickstart file I've been using:
install
text
url --url http://yum.abc.com/5.6/os/x86_64/
#nfs --server=yum.abc.com --dir=/yum/5/os/x86_64
lang en_US.UTF-8
langsupport --default=en_US.UTF-8 en_US.UTF-8
keyboard us
network --device eth0 --bootproto dhcp
rootpw --iscrypted $encryptedpassword
firewall --disabled
selinux --disabled
authconfig --enableshadow --enablemd5
timezone --utc America/Chicago
bootloader --location=mbr
clearpart --all --initlabel
part /boot --fstype ext3 --size=200
part /usr --fstype ext3 --size=8192 --asprimary
part / --fstype ext3 --size=12288 --asprimary
part /var --fstype ext3 --size=4096
part swap --size=8192
part /tmp --fstype ext3 --size=2048
#part /opt --fstype ext3 --size=100 --grow
#part /scratch --fstype ext3 --size=61440
%packages
@ admin-tools
@ editors
@ system-tools
@ network-server
@ mail-server
@ server-cfg
@ development-tools
yum-fastestmirror
rpm-devel
e2fsprogs
grub
kernel-devel
net-snmp-utils
-subversion
-xdelta
%post
exec < /dev/tty3 > /dev/tty3
chvt 3
echo
echo "################################"
echo "# Running Post Configuration #"
echo "################################"
(
/usr/bin/wget http://ks.abc.com/post/post-install-abc.sh -O /root/post-install-abc.sh
/bin/chmod 755 /root/post-install-abc.sh
/root/post-install-abc.sh
) 2>&1 | /usr/bin/tee /var/log/post-install.log
chvt 1
Have a look at Cobbler - https://fedorahosted.org/cobbler/ - I use it in a PXE environment but it should work for you.
I would recommend the Foreman over cobbler, as it will replace cobbler/Satellite in the future.
The foreman is far more flexible, and once you have set it up properly, you can delegate host building to others.
It ia also deeply integrated with Puppet, ie you can manage classes, certificates, view puppet reports etc.