If you install Oracle enough times, you will probably soon become sick of having first to install the same Operating System over and over again, every time remembering to take the same options, type the same info and configure things identically! If only you could automate and standardise the O/S installation!
Well, of course, you can -so long as you’re using Red Hat Enterprise Server (or one of its clones, such as Oracle Enterprise Linux, Scientific Linux or Centos). The mechanism to use is called kickstart and it’s been around for years (and it’s available for Fedora, but nothing in this article should be taken to apply there, because it’s a very different beast compared to “proper” server OSes).
In a nutshell, kickstart is simply a text file that contains a stored list of configuration options taken from a previous, manual OS install. When you come to do your second and subsequent installs, you boot from the OS DVD as normal but then point the installer to this kickstart configuration file to ‘auto-fill’ in all other aspects of the new installation process. From that point on, there’s little or no interaction required: the install just polishes itself off.
Kickstart, in short, makes Red Hat-like operating system installs predictable, reliable, repeatable -and a lot faster!
The kickstart configuration file required for a Red Hat 6-based distro (i.e., Red Hat itself, or a freebie clone like Scientific Linux) is slightly different than that required for a Red Hat 5-based distro, so I have download-able examples of both types here:
You could download those, see how they work and then edit them to suit. Alternatively, just do a regular, manual install and check out the /root/anaconda-ks.cfg file (which is automatically generated every time you do a Red Hat-a-like installation) and go from there.
One of the nice things about Kickstart is that it gives you an easy way of slimming down your distro installs… you’ll notice from my example files, for instance, that I add lines such as -evolution or -sendmail: the minus sign means “don’t install”, so you end up with an O/S install that’s mercifully free of a lot of the cruft that otherwise tends to clog them up. It’s trivial, of course, to edit the configuration file to add back anything I’ve taken out that you think is important.
You’ll note from my example files, too, that I’ve taken a fairly generic approach to things: a server installed using these files will end up being called oraclebox.dizwell.home, for example. Again, if that’s not suitable for you (and I doubt that it would be!), feel free to edit the file before you use it. Similarly, I set my root password to dizwell and I configure networking with DHCP (because I know what I should use as a static IP address in my own home, but what works for me might not work for you). I also use Greenwich Mean Time as my time zone. These are all configurable by means of a simple text edit, but you should at least be aware of the need to look at these options!
I suppose the only slight difficulty with kickstart is how you tell the O/S installer where to find the kickstart configuration file in the first place. There are basically two options I use: if I’m at home, I point the machine being installed to the feeble Apache web server I run on an old, vintage 2003 laptop. If I’m anywhere else, I point it to a floppy disk image containing the configuration files (or to an actual floppy disk created from that image).
Again, the procedures involved differ slightly between RH5 and RH6. Here’s an example of me telling Centos 5.6 to use my web server’s copy of the right file:
Where it says “boot:”, you simply type the word linux followed by ks= and then the location and name of the kickstart configuration file. In my case, my web server is running on 192.168.0.1, and it’s called “rh5.cfg”. Once you get that location/name right, press Enter… and that should be the last time you have to interact with the O/S installer: everything else will happen automatically.
Here’s how you do it in Scientific Linux 6 (you get here by hitting the TAB key when the installation menu is first displayed):
That can be a bit difficult to read, given SL’s choice of boot wallpaper! So let me spell it out: when you hit TAB with the first menu option highlighted (to ‘install or upgrade an existing system’), you’ll see the command vmlinux initrd=initrd.img already sitting there. So this time, you don’t have to type the word “linux”: all you have to do is to add on the bit which says where the Kickstart file can be found …which again involves typing ks= followed by the correct location and name of the kickstart configuration file.
If in either the Red Hat 5 or 6 cases you’d instead stored your Kickstart files on a floppy disk (or on a floppy image which is behaving as a floppy disk), instead of typing something like ks=http://192.168.0.1/name-of-config-file.cfg, you’d type:
ks=hd:fd0/name-of-config-file.cfg
The only real change, therefore, is the device-name bit: hd:fd0 is how you say “floppy”, and http://w.x.y.z is how you say “web server”.
Incidentally, if you’re using virtual machines to practice with, you can simply add a floppy drive to your VM and point it to an image of a floppy disk. I have the two Kickstart configuration files saved on such a floppy image, which you can download here. So just point your VM’s floppy disk to that download. How you do that depends on your choice of virtualization software. Here’s how you’d do it in VMware Workstation, for example:
…after which, you just click through the wizard and browse to the floppy image in the standard way. The same sort of process works in VirtualBox, too. Happily, the same floppy image works just as well in VMware (Workstation, Server and ESXi) as in VirtualBox.
Note that in all these case, the O/S actually gets installed from a local DVD (or DVD iso, in the case of my virtual machines!). The only bit that gets pulled across from the web server is the kickstart configuration file itself. It doesn’t have to be like that, though: it’s possible to write a kickstart file so that the O/S itself is pulled across the network. But that’s way outside of scope for this little blog piece! Indeed, kickstart is incredibly flexible and full of interesting options, and I’ve really only just scratched its surface here.
Hopefully, though, this has been enough to show you how kickstart can play a really useful role in simplifying, standardising, speeding up and slimming down your O/S installations -which is where all Oracle RDBMS installers need to start, I think!