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!
Hi,
I am a fresher for Fedora and a linux beginner. I need to install oracle 10g on Fedora 15 but unable to find a right version for it. Is there any way I can install Oracle 10g on Fedora15? I’ll really appreciate your help.
I get following error message when i run runInstaller.
[root@localhost database]# ./runInstaller
Starting Oracle Universal Installer…
Checking installer requirements…
Checking operating system version: must be redhat-3, SuSE-9, redhat-4, UnitedLinux-1.0, asianux-1 or asianux-2
Failed <<<<
Exiting Oracle Universal Installer, log for this session can be found at /tmp/OraInstall2011-06-26_11-24-23AM/installActions2011-06-26_11-24-23AM.log
Thanks.
First thing to say is that both 10gR2 and 11gR2 Oracle versions install perfectly well on Fedora 14 and Fedora 15. So that’s the good news.
The bad news, as you’ve discovered, is that Oracle does not like being installed on anything other than a small handful of “official”, Enterprise-class distros. Therefore, the installer bombs out whenever it sees a non-official distro -which is exactly what you’re encountering. Installing onto these sorts of distros therefore becomes a bit of a game of who-can-fool-the-oracle-installer.
If you don’t want to run my Gladstone preinstaller script to do all of that for you, then at least read the script to see what it does (because you’ll have to do it too, even if you choose to do it by hand yourself). To deal with this specific issue, take a note of lines 646 to 651 in particular: by fiddling with the contents of the /etc/redhat-release file, or by setting a DISTRIB environment version, you can persuade the Oracle software that it’s actually being run on a “proper” distro.
Thank you for the excellent blog post. Now how does one go about making .imgs that can be accessed by the virtualization software (I’m using vmware workstation)? I made a few changes on the kickstart file and made it into a .img under Windows 7 using ImgBurn, but it gives me an error when trying to download the kickstart file.
Unix-based tools to build the .img works too.
“Now how does one go about making .imgs that can be accessed by the virtualization software”.
Excellent question. In VMware Workstation (excellent choice, too, btw!), just edit the settings for an existing VM. Click the ‘Floppy’ item in the hardware list. Tick the ‘Use floppy image’ checkbox, then click the ‘Create’ button. Navigate to an appropriate place, and give it an appropriate name: you’ve just created a ‘.flp’ floppy image (that Virtual Box can use, too, if needed).
As an alternative, you can go here and download the “BFI” tool (runs on Windows). It’s just a simple ZIP file, no installation necessary. Unzip it somewhere (I ended up creating a …Desktopbfi10 directory). At a command prompt, navigate to the unzipped directory and then issue the command:
That will net you a blank standard 1.44MB floppy image which you can then attach to a VM and start copying files to. Disconnect it from the original VM when your file copying is finished and you’ll be able to attach the same image file to any other VM of your choosing.
And as a third alternative: simply use the image files I’ve provided and format them with whatever tools your VM’s operating system supplies. Then save your modified kickstart files back to that newly-fresh image file, disconnect and connect it to your new VM (i.e., so long as the contents are modifiable from within one VM, maybe you don’t actually need to know how to create image files from scratch).
Hope that helps, anyway.
That does help, thank you! I ended up going with the third alternative, as I’m already developing my kickstart files inside a vm.
Great job !
I started from your kickstart file, put off all the GNOME stuff (Xorg’s embedded twm is enough) and added the rlwrap wrapper which provides a command history and editing of keyboard input for any other command. This is a really handy addition to SQL*Plus and RMAN on Linux. As this app is very thin, it is suitable to be include in this kickstart script imo.
Thank you for that post
Yup, rlwrap is great (and I wrote about it back in 2003, long before anyone else was blogging about it, but I digress!).
The only trouble with sticking it in the kickstart file, though, is that last time I checked (and it could well have changed, in which case just ignore me!), it’s not in the standard repositories (for Scientific Linux or Centos). Nothing to stop you adding additional repositories in a Kickstart file, either, of course, but it was a bit beyond the scope of what I was attempting to document here.
It is, though, a must-have (imho) for any Oracle Linux server: SQL*Plus is a pain to use without it, that’s for sure.
Is there any way to specify a kickstart file in local file system. I tried the option hd: but it does not seem to support raid device such as md0/md01.
Somewhere I also read that it should be in initrd image or the file system should be vfat or ext2.
I have ext4 LVM2 raid.
Yeah, I doubt you’d get an installer to recognise software-RAID partitions properly. The only kickstart options I am really aware of are ks=hd:… (for hard drive, which does indeed need to be vfat or ext2… see https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Installation_Guide/s1-kickstart2-startinginstall.html for evidence of that); ks=nfs:… and ks=http:/….
None of those are going to do the trick, I think. I haven’t personally ever tried ks=bd:/, where “bd” is “short for BIOS device” and allows you to point to a kickstart file housed on a BIOS-managed software raid. Even that, however, doesn’t sound as if it’s what you’re after, because you really need mdadm to be running for your RAID partitions to become visible. https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/s1-kickstart2-startinginstall.html is the link that mentions that, though, if it’s of any use.
Other than that, I think you’re going to be stuck. All I can suggest is a USB stick, really, if it has to be a locally-stored file.
(The file doesn’t *have* to be in the initrd image, btw. It’s just that if it is, you can use ks=file:/ option).