OK: if you’ve been following along the last dozen or so posts, you will have by now automatically built yourself a “Linux toolbox” -a minimalist server running a variety of network services. You would then also have dropped a bunch of additional rpms onto its /var/www/html document root. And now it’s sitting there, waiting to be useful.
Time, therefore, to make it so. We need just four additional things: a network boot ISO for your chosen RCSL distro; a Kickstart file that’s suitable for building Oracle servers; a response file that’s suitable for automating the Oracle software installation; and a bunch of scripts that can automate the creation of an Oracle database.
Taking each of those in turn, therefore:
1. The O/S Network Boot ISOs
If your toolbox server runs Scientific Linux, you’ll need the Scientific network boot ISO; if it runs CentOS, you’ll need the CentOS network boot ISO… and so on. You also need to match versions: a 6.3 netboot ISO won’t be any use if your source distro is version 6.4, and vice versa. Here are where I source my network boot ISOs from:
Download the appropriate boot ISO and burn it to DVD or CD (or just use it in its ISO form if you’re booting a virtual machine).
2. The Kickstart File for an Automated, Standalone Oracle Server
Any Oracle server you build needs at least 2GB memory and around 25GB of hard disk -so any Kickstart file you use to automate its build should assume those resources are available to it. A suitable Kickstart file is extremely long and would look entirely out of place if I pasted it in here… so here’s a link to one I made earlier.
The name of that specific download is “alpher-sl64.ks”, because it’s been written to look for software in the /var/www/html/sl/64 directory -you can tell I’m using Scientific Linux 6.4 for this post! The exact same file can be used for CentOS and OEL installs though: just edit lines 25 to 30, uncomment out the one line that describes where your distro software has been copied to and comment out all the others. You’d probably then want to rename the Kickstart file suitably, too (so you might end up with alpher-centos63, or alpher-oel64 and so on).
I’ll go through that file in detail at the end of this post, but for now, just copy it to your toolbox’s /var/www/html directory (maybe via ftp transfer; otherwise, burn it onto a CD/DVD (or an ISO), mount it and copy it from there).
3. An Installation Response File
When you install Oracle’s database software by hand, you usually use the GUI Oracle Universal Installer (OUI), which involves clicking [Next] lots of times and typing in various things like passwords and installation paths as required. For many years, though, it’s been possible to save the outcome of making all these choices in a response file -and then point the OUI at that response file on second and subsequent servers. In this way, it’s possible to achieve an automated, GUI-less installation that’s identical to your first.
You could create your own response file in exactly this way, therefore: do one manual Oracle installation and save the results.
Naturally, I’ve done this for you already, so you can simply download an appropriate response file now. Unfortunately, response files are highly version-specific, so if you’re intending to install 184.108.40.206, this is the file you want; if you’re intending to install 220.127.116.11, though, you’ll want this one instead.
In either case, rename the download to be just standalone.rsp and then copy it to your toolhox’s /var/www/html directory.
4. Database Creation Scripts
When you manually create an Oracle database, you generally do so with the GUI (and Java-based) Database Configuration Assistant (DBCA). You click [Next[ lots of times, pick the various options you want your database to use, type in things like database names and then it goes off and does the magic.
It’s long been possible, though, to save the set of instructions it follows as a bunch of database creation scripts -and then to execute those scripts from the command line. The DBCA then executes in silent, non-GUI mode, yet still performs exactly the same steps as before, resulting in the creation of an identical database each and every time.
So, to automate database creation, you could do it manually yourself once, and save the necessary scripts… or you could just download the set of scripts I’ve already created for you and zipped up. Note that my script defines the SYS, SYSTEM, DBSNMP and SYSMAN passwords identically as oracle: you can change passwords after the database has been created, of course.
Just transfer that zip file over to the /var/www/html directory of your toolbox server. If you build your own scripts, zip them up into something called “scripts.zip” and do the same.
So, when you’ve got this far, what does your toolbox’s /var/www/html directory now look like? Well, here’s mine:
Taking that lot in the order shown:
- sl -> the directory where the full distro software is stored (could be “centos” or “oel”, of course, depending on which RCSL distro you’ve decided to use)
- alpher-sl64.ks -> the Kickstart script for the soon-to-be Oracle server
- oradb… -> two files which are the Oracle 11g software, in zip form
- pdksh -> the public domain Korn shell rpm
- rlwrap -> the read-line wrapper rpm
- scripts.zip -> the bunch of scripts needed to create a database at the command line
- standalone.rsp -> the response file needed to install Oracle
- webmin -> the webmin rpm that gives you a browser-based server admin tool
If all those things are there, then we can begin…
5. Boot the Server
I’ll assume you’ve already built your Oracle server (or created a virtual machine that will do duty as one, anyway): so long as it’s got a 25GB hard disk and (a minimum of) 2GB memory, it will do fine. Just boot it up using the network boot ISO you downloaded at Section 1 earlier …and then press <Tab> when the boot menu appears.
That causes a command prompt to appear, already containing some textual commands. You add on to the end of what’s there just this:
That is, you tell the boot process that you’d like O/S installation to be governed by a Kickstart file called “alpher-sl64.ks” which is available from the 192.168.8.250 server acting in its capacity as a web server. (If you’d renamed the file as I mentioned earlier, so that you could use CentOS or OEL, then obviously change the command here to match).
The whole thing looks like so:
Press Enter, sit back and watch.
If your hard disk is brand new and has never been partitioned before, you will see a screen that prompts you to re-initialise it:
As you can see, the correct response is to agree to ‘Re-initialize all’. If your hard disk already has partitions, then you won’t be asked about this: they will all be automatically wiped without intervention from you (so don’t try this out on a computer whose disk contents are in any way important to you!)
6. What Happens Next…
If all goes according to plan, the O/S will now be installed without prompting you in any way. It’s a minimal sort of install (no GUI, for example), but with networking set up correctly and with all the software prerequisites required for a successf4ul Oracle install taken care of. On my laptop (which is pretty modern with a decent i7 processor and lots of RAM, but no solid-state hard disk), that takes all of 5 minutes to complete.
Immediately the basic OS is installed, the “post-install scripts” will be run:
During this phase of the installation, the Oracle software is being copied across from the toolbox and being unzipped. Since that’s about 3GB-worth of data to transport and unpack, it can take quite a while to complete! You’ll just have to be patient about it, since no progress indicator is displayed. (On my laptop, it took another 5 minutes).
After that, the screen will go black and the Oracle software installation will start:
This phase takes the longest time: on my laptop, around 15 minutes. At the end of it, the installer will switch back to “blue mode” and ask you to reboot the server: the job is almost done!
The final thing you do, once the server reboots, is to log on as the oracle user (using my Kickstart file, the password for that user is oracle; the root password is dizwell). Now comes only the second bit of typing you’ll have been asked to do for the past 30 minutes: you invoke the database creation script, like so:
This will scroll quite a bit of text up the screen as it runs, but crucially it will ask you what the SYS password is: remember, that’s been defined in my script as being oracle, so type that in when prompted and then the whole database creation process will begin. Lots of instance bounces later, you’ll be prompted to supply the same password as part of the EMCA (Enterprise Manager) configuration process. At that point, too, you’ll be asked to type in the same password for both the DBSNMP and SYSMAN users. Again, it’s oracle in the script I’ve supplied, so if you’re using that, wait until after the database creation process has finished before trying to change them.
The entire database configuration process completes in about 10 minutes on my laptop. At the end of it, you’ll see a text message appear like this:
And at that point, you’re really all done. You might like to type reboot and get the server to do one last bounce: when it’s back up, you should be able to log on as the oracle user, fire up SQL*Plus and connect immediately to a running database -proving that auto-startup of instances is working OK.
So, 40 or so minutes after you began, you’ve typed one command to launch the O/S installation process; you’ve possibly had to say to re-initialise a disk; and you’ve had to invoke a createdb shell script.In return for that minimal investment of keyboard prowess, you get a complete RCSL server, configured properly; a complete and proper Oracle 11gR2 installation; and a fully-functional database called “orcl”,that can be managed remotely by opening a browser on a client PC and visiting https://192.168.8.101:1158/em.
It’s not completely hands-free, then. But it’s pretty close …and not bad for a morning’s work.
By the way, because the Kickstart script installs rlwrap, you’ll also find that you can simply up- and down-arrow in SQL*Plus to recall a command line history, which is a neat trick ever since I first wrote about it in 2003.
Of course, you may now want to spend some time altering the root and oracle passwords. But those things are pretty trivial, so this remains (in my view) a painless way of quickly and reliably creating pre-configured Oracle database servers.
Detailed Explanation of the Kickstart File
Lines 1 – 18 : Standard stuff simply indicating that the text-mode installer should be used.
Line 23 : How the new server will have its network configured. In this case, it will be assigned a static IP address and be called “alpher” (if you’re interested, here’s why).
Lines 25 – 30 : The same Kickstart script can be used to build a CentOS, OEL or Scientific Linux server …except that the source path of the necessary distro software on the toolbox server will be different in each case. This section lets you comment out those directories which don’t apply and leave active the one line which does.
Lines 36 – 41 : The root password is set to the encrypted form of the word dizwell. SELinux is switched off, as is the Firewall. The server ends up in the Australian time zone.
Lines 43 – 45 : These lines will, without warning, cause the new O/S installation to wipe the existing disk partitions and set up new ones: a 4GB swap partition and the rest of the disk will be assigned to the root mountpoint.
Lines 47 – 135 : These lines govern what software will be installed. It’s pretty minimal, in fact, but all the stuff needed to run Oracle properlyOf course, you may now want to spend some time altering the root and oracle passwords. But those things are pretty trivial, so this remains (in my view) a painless way of quickly and reliably creating pre-configured Oracle database servers. gets added to the mix.
Lines 144 – 156 : Gets a bit of NFS stuff organised, though this isn’t used by the subsequent Oracle installation.
Lines 162 – 170 : Gets NTP settings correct, making this new server look to the toolbox as its source of reliable time.
Lines 176 – 182 : Copies Oracle database software off the toolbox server and onto the local disk, in a directory called /osource. Then unzips the software and tidies up.
Lines 188 – 194 : Gets the /etc/hosts file right and also edits a couple of other network-related files (possibly redundantly in the case of /etc/selinux/config, but you can never be too careful!)
Lines 201 – 221 : Creates an oracle user (called “oracle”, password “oracle”), assigns him to appropriate groups and gets his local environment variables set correctly.
Lines 227 – 242 : Configures pluggable authentication modules to set security and resource limits for the oracle user, as recommended by Oracle.
Lines 248 – 455 : A long section which is simply setting kernel parameters to Oracle’s recommended values. We could hard-code minimum values in just a few lines, but that would be a bit redundant, since many parameters are set to defaults which are already perfectly adequate. So these lines first tests a parameter to see what it’s already set to.Only if it’s below the minimum recommended by Oracle does the script them set it to a recommended minimum. If it’s already at or above the recommended minimum, we just skip it.
Lines 461 – 467 : Installs rlwrap and pdksh. Pdksh is not really needed these days (though the Oracle Universal Installer gets upset if it doesn’t find it), but rlwrap is certainly useful when you’re using rman or SQL*Plus. It gives you a scrollable command line history for those tools.
Lines 473 – 484 : The real meat of the business! Here is where we perform the Oracle software installation. This takes a long time to complete, of course, and if we did nothing special, you’d be stuck looking at a ‘running post-installation scripts’ message for long minutes on end, with no clue as to what was going on. So, instead, we chuck in a chvt command to change the virtual terminal you’re looking at. That is why the screen flips to black when this starts, which is a bit awkward… but at least you can see the Oracle Universal Installer’s output and know (roughly!) what’s going on.
When the Oracle software install is finished, at line 558, we change terminals back to terminal 1 -the blue one, which will then display a message telling you to reboot.
Lines 490 – 539 : This just creates an init script that ensures that the listener, the database and the Enterprise Manager console is automatically re-started whenever the server itself reboots.
Lines 541 – 555 : It’s a shame that you can’t actually create a database at this point, but we’re in the wrong run-level and DBCA will crash out if you were to try running it now. Therefore, at this point the Kickstart script simply creates a little shell script which, when it is invoked manually post-O/S-install, will run DBCA in silent or non-interactive mode. It’s this shell script you invoke once you’ve rebooted the new server and logged on as the oracle user