Obtaining Network Boot media

Only one thing remains to do -and that is to obtain the network installation media for your choice of distros. These are quite small ISOs which contain the bare minimum software needed to allow a server to boot. Once that boot process is finished, you then point the installer to your Kickstart scripts which, using your freshly-unpacked full distro images, is then able to complete the job properly.

In the days of RCSL 5.x, these network installation media were genuinely tiny: 10MB or so, which was wonderfully convenient. Come RCSL 6.x, however, and the network installation media, regardless of specific distro, are all in the 200MB+ bracket, which is decidedly less convenient!

Anyway, the relevant boot media are available from these locations:

• Centos 5.7
• Centos 6.2
• Scientific Linux 5.7
• Scientific Linux 6.2

Those need to become local installation media. That is, you will boot your new RCSL server with one of those images directly available. It’s job is simply to have enough software to power up the network stack so that you can then point the thing at your Kickstart server, distant over the network. Practically, this means burning the ISOs to CD and booting your new RCSL server with one of them physically in its CD tray.

One word of caution!

Just one thing needs to be mentioned before you can put all this Kickstart infrastructure to good use: you must have a DHCP server providing services to your network, somewhere. To make an over-the-network OS installation work, your new RCSL server has to temporarily acquire an IP address, automaticaly, via DHCP. After that, fine: it can be assigned whatever IP address your kickstart script specifies. But to get to that point, the temporary dynamic IP address has to be assigned first.

If you already have a DHCP server to hand, fine: consider this warning irrelevant! If not, then you can very easily add DHCP serving capabilites to your Kickstart server by following the advice in this short article. Essentially, a quick yum install dhcp followed by a bit of tinkering with /etc/dhcp/dhcpd.conf will see you right.

And finally…  boot time!

So, to sum up. We have created a new Apache web server; we have unzipped a bunch of distros on that web server, into sub-directories that are distro-specific; we have created a set of Kickstart files which (thanks to the url line) know where those distro-specific directories can be found; and we can boot our new RCSL server from locally-available, relatively small network boot media, with it being able to acquire an IP address dynamically, at least to start with.

All that remains is to make actual use of your Kickstart server’s ability to, er… serve.

You do that when booting up your new RCSL server from the locally-available netboot media: at the first splash screen, you interrupt proceedings by telling the server where the Kickstart server can be found and which Kickstart script it should use. On any RCSL 5.x server, that simply involves typing the words:

linux ks=http://192.168.0.70/centos57.ks

The specific IP address you use should be that of your Kickstart server, of course. Similarly, the “centos57.ks” bit should reflect the actual names you’ve given to your Kickstart configuration scripts. Here’s a link to a screenshot showing you how it’s done.

On any RCSL 6.x server, you have to first press the TAB key to be able to type anything. Once you’ve done that, you type in pretty much the same as above, but without the keyword “linux”, because that’s already automatically present. So you end up adding just:

ks=http://192.168.0.70/centos57.ks

…to whatever text is already present. Here’s a link to a second screenshot showing you the sort of thing you’ll see.

In either case, so long as the address to the Kickstart server is correct, and the stated name of your Kickstart script is right, the entire operating system installation for the new RCSL server will be completely automatic and require no user intervention at all… with just two exceptions!

• First, if the hard disks on your new RCSL server have never once been used before, then you will be asked if it’s OK to initialise them (to which the answer is Yes).
• Second, you will always be prompted to supply a root password. That can actually be included in the Kickstart script itself if you really don’t want to be bothered by the installer, but I generally think that writing down root passwords anywhere at all is not a great idea. So my Kickstart scripts don’t include them, and hence you get prompted!

Conclusion

In this article, I’ve built a small 32-bit RCSL server which runs the Apache web server. I’ve copied 64-bit RCSL ISOs to it and unpacked them into distinct directories. I’ve downloaded a set of Kickstart configuration files to Apache’s document root directory and edited them so that the network and url lines make sense. For 128MB of RAM and about 40GB of disk space, I therefore have a tool which can help me perform subsequent repetitive RCSL 64-bit server installations in a uniform and highly-automated fashion.

When it’s important to have production servers built in a cookie-cutter fashion -that is, to conform with SOE requirements- it’s important to have a cookie cutter to hand.

A Kickstart server is that cookie cutter.

Have fun with it!