Calgary RHCE

In our DevOps environment, we’ve got a lot of developers who regularly build VMs.  Sometimes they’re built locally on their workstations, or sometimes in the data center when they’re ready to formally move code.  Admittedly, the IT VM provisioning process can be slow at times and we often see them get frustrated and take matters into their own hands.  While this self-build method gets them their VM faster, they don’t always get IT’s supported “base image”.  This can lead into integration and support problems later on when they’re trying to move this code into production that was developed against a non-standard OS.  What to do?

OpenStack, or even OpenShift, is the long-term solution to this problem.  However, until our OpenStack environment is stood up, we will need something else to address it right now.  What if we could provide them an ISO that has our standard build integrated into it?  Well!  We are going to do just that.  Read on…

Lets make our own ISO file with our standard kickstart image build into it. We’ll change the ISO boot menu options to only allow one install selection, and let the developers get to work! You will need the CentOS install images, and a workstation running an RPM anaconda based distribution.  I used CentOS 6.5 for both.

Set up your build environment:

You will need the createrepo, isomd5sum, and genisoimage packages:

Setup a mount point for the DVD ISO, and mount it:

Next, make a working directory for what will be the new ISO image:

Copy the mounted DVD ISO files into the working directory:

You’ll need a comps.xml file. This file describes the package groups included in the ISO. You can grab one from a CentOS repo:

Create the kickstart file. You can use system-config-kickstart to build a new one, or copy one from an already installed server’s /root/anaconda-ks.cfg file. If you don’t have system-config-kickstart, use yum to install it. The RedHat knowledgebase provides a list & explanation of all the available kickstart options. You should create the kickstart file as /export/media/centos_build/kickstart/ks/ks.cfg:

Now, add any packages you’d like to include on the ISO. If you’ve got in-house RPMs, or are sourcing them from somewhere else (epel, fedora, cfengine, puppetlabs, etc.), place the .RPM file in the kickstart/CentOS/ directory. In my case, I’m going to include two in-house developed CFEngine packages. The first package installs the CFEngine agent, and the second package bootstraps CFEngine. My goal is to have this ISO & kickstart file to automatically provision the VM into the centralized configuration management tool –> CFEngine. CFEngine will then take care of adding all the admin accounts, setting up NTP, SSH, etc. (This is the real advantage with creating this custom ISO!)

In your kickstart file, be sure to have these package names listed in your %packages section. This is also a good time to add/remove any other packages you want. My %packages section will look like this:

Now that we have our kickstart file finished, lets modify the ISO boot menu to use the kickstart file by default:

My file looks like this. Be sure not to typo your kickstart file directory, otherwise it won’t work:

Now, if you’ve added packages into /export/media/centos_build/kickstart/CentOS/ directory, we will need to update the comps.xml file to reflect your changes. First, make a backup copy of comps.xml. Open the file for editing with your favourite XML editor. I’d suggest using an editor that can collapse groups of XML code as the comps.xml file is quite long. I use sublime text for this:

After the last <group>, but before the first <category> tag, add your new group entry. Mine looks like this:

You’ll need to add a new category as well. I made my entry at the end of all the <category> tags, but before the </comps> tag. This category is going to reference the previous group you just created, so be careful not to typo or use different case.  The field you need to get accurate here is groupid. Mine looks like this:

Use an XML syntax checker to make sure you didn’t make any errors. xmllint is a good one:

Building the ISO:
We’ll now need to re-initialize the repo list:

And build the ISO:

Now my boot menu looks like this and will automatically use my ks.cfg file for installation:

And although I didn’t provide this option in the boot menu, if you boot the graphical installer, you should see a new section for the packages you specified:

And that’s it!  Put the ISO up on a file store or web server, and be satisfied that the developers are using a supported base OS install!