Way back in October last year, I announced that I wouldn’t be developing my Gladstone pre-installation script for Oracle any further, although the script itself would remain available (and it still is).
Back then, I promised a “son of Gladstone” replacement, “soon enough”. Little did I think it would take me six months to honour that promise! Such is life, I fear…
But Gladstone’s successor is now here… and, in keeping with (near) historical fact, that successor is to be called “Salisbury”. (That’s him on the right, looking suitably Victorian and bushy-bearded).
So, what exactly is Salisbury and how does he work?
Well, it’s a slight extension of the work I’ve been documenting in the previous dozen or so posts here: the idea of using Kickstart to automate the construction, the correct configuration and the Oracle software installation of Oracle servers. Additionally, it’s the use of a Kickstart-built server to supply all necessary network and shared-storage capabilities that Oracle Servers might need -especially if they run RAC.
In terms of tangible ‘product’, Salisbury actually consists of a single ISO download, just 27MB in size.
You use that ISO to kickstart the building of a Salisbury Server -a small server runningthat I’ve referred to in previous weeks as a ‘Linux toolbox’. Once your Salisbury Server is up and running, you use it to build your Oracle Servers. Those Oracle servers can run Oracle versions 18.104.22.168 or 22.214.171.124 in standalone or RAC mode. If you choose a standalone build, the Salisbury Server will automatically install the Oracle software for you, and create a simple shell script that will create a database when run post-install. If you instead choose to create a RAC-capable server, Salisbury will copy across all necessary software (and get users, groups, kernel parameters and so on correctly configured), but it won’t attempt to install anything automatically (because working out whether all the component parts of a cluster are up and running is a bit tricky!)
I present Salisbury here as, more or less, a fait accompli -but how it works and why are all things I’ve discussed in considerable detail over recent weeks, so if you’ve been following along, there shouldn’t be too many surprises (and if you haven’t, you can always step back to this post, which started it all, and read forward from there). I will try to pull it all together into a single, long article before long, though.
Building a Salisbury Server
The quick version of getting the Salisbury Infrastructure™ to work for you is this:
- Build a new server with at least 512MB RAM and 60GB free hard disk space. Ensure it has two DVD drives.
- Load your distro-of-choice’s full installation disk into the primary drive
- Load the Salisbury ISO into the secondary drive
- Boot your server and hit <TAB> at the boot menu. Make your build process Kickstart-defined by adding ks=hd:sr1/salisbury.ks to the bootstrap line.
- Sit back and let the installation process complete.
Your new Salisbury Server will have only a root user account (password: dizwell). You can change that password with the passwd command, of course.
The Salisbury Server will automatically be a web server, complete with all sorts of useful files and packages which it can distribute to client Oracle Servers. However, the really important stuff is Oracle’s database server software -and, much as I’d like to, licensing restrictions mean I can’t provide that for you. Instead, you have to source that yourself, either from OTN (for free, but only at version 126.96.36.199), or from edelivery (if you have a proper, paid-for subscription and want to download version 188.8.131.52 or better).
However you source it, you should obtain both database zips AND the grid zip and copy all three files to the /var/www/html directory of your Salisbury Server (FTP transfer with Filezilla or a similar tool is probably the easiest way of doing that).
In their wisdom, Oracle Corporation saw fit to name their software multiple different ways, depending on how you sourced it and what version you’re dealing with. This is a recipe for Salisbury Confusion™ -but it’s easily avoided by renaming whatever you download in a consistent way, as follows:
Replace the “x” in those names to reflect the actual version in use, of course. There is no flexibility about this: the Oracle software components must end up being named in this way if the Salisbury Server is to be of any future use to you in building Oracle Servers.
By renaming files in this way, it’s perfectly possible to have one Salisbury Server be able to create both versions of Oracle database: just download all 6 files (the 11201 three and the 11203 equivalents), and rename them all according to the above-mentioned scheme. When both versions are possibilities, you’ll be able to specify which one to use for any particular Oracle Server at build time, as I’ll explain shortly.
So, after building your Salisbury Server, you just have to copy Oracle software to it (and rename it as appropriate), just once. After that, it’s ready for duty.
Note that the Salisbury Server build involves copying its own installation media to disk. If you build your Server using OEL 6.3, for example, then a /var/www/html/oel/63 directory will be created and populated on it automatically. Such a server can then only help build other OEL 6.3 servers. If you want to be able to build CentOS or Scientific Linux Oracle Servers, maybe mixing up versions 6.3 and 6.4 as the mood takes you, you can do that provided you create /var/www/html/centos/63, /var/www/html/sl/64 and similar directories yourself. The directory names have to be of the form /centos, /sl or /oel and the version directories have to be either /63 or /64. After creating any additional directories in this way, you can then simply copy over the contents of the full install media for that distro/version combination. Make sure you use the full installation media, not the “Live CD” versions. There is, however, no need to copy the second DVD into the directories where one is available: disk 1 will suffice.
Build an Oracle Server with Salisbury
Once your Salisbury Server is up and running, you can use it to construct new Oracle servers. An Oracle Server must have at least 2GB RAM and 25GB of free hard disk space.
You boot a new Oracle Server with the netinstall boot disk of your distro of choice. At the boot menu, you invoke the Kickstart process by pressing <TAB> and then adding a ks=<URL> string to the bootstrap line. That <URL> element will be formed from the following elements:
- Salisbury Server’s IP address
- kickstart.php filename
- five possible URL variables
- Two possible Kickstart parameters
It is assumed that your Salisbury Server has an IP address of 192.168.8.250 (if not, you’ll have to edit various files on the Salisbury Server itself).
The Kickstart filename is simply kickstart.php
The seven possible URL variables are:
- distro (one of either centos, sl or oel)
- version (one of either 63 or 64)
- hostname (pretty much anything you like, so long as it’s a valid host name)
- domain (pretty much anything you like, so long as it works as a domain name)
- rac (one of either y or n, depending on whether you expect to be running a RAC or standalone database on the finished server)
- ip (the IP address of the server, in a.b.c.d form)
- ic (the IP address of the cluster interconnect, in a.b.c.d form, assuming one exists)
The two possible Kickstart parameters are:
- ksdevice=<name of network interface to use initially, if there are 2 or more network cards present, such as eth0 or eth1>
- oraver=<11201 or 11203, depending on which version of the Oracle software you want to use; can also be set to none to mean ‘don’t copy any Oracle software at all’… useful for second and subsequent nodes of a cluster>
You must supply a distro and version, but if you miss out any of the other parameters or variables, defaults will kick in. If you fail to supply an “oraver”, for example, 184.108.40.206 will be assumed; if you don’t say whether “rac” should be ‘y’ or ‘n’, a standalone, non-RAC installation will ensue, and so on.
At a minimum, therefore, you will initiate your Oracle Server build by typing something like the following at the bootstrap line:
A complete bootstrap line, leaving nothing to chance, would look more like this:
ks=http://192.168.8.250/kickstart.php?distro=oel&version=64&hostname=alpher&domain=dizwell.home&rac=y&ip=192.168.0.35&ic=10.0.0.1 ksdevice=eth0 oraver=11203
Notice that the URL variables are present as one, continuous string, begun with a “?”, separated by “&” and without any spaces. The Kickstart parameters, however, are supplied as space-separated keyword/value pairs at the end of the URL.
Of course, if you specify variables which imply software choices that your Salisbury Server does not have available to it, you can expect the Oracle Server build to fail. If you say oraver=11203, for example, when you’ve only stored 220.127.116.11 software on the Salisbury Server, then your finished server will have no Oracle software on it at all. If you’ve prepped your Salisbury Server to host all possible distro and Oracle versions, though, then you can specify any of the available options in whatever combination and expect a completely automated O/S and Oracle software installation accordingly.
Oracle Servers built via Salisbury will end up with a root user (password dizwell) and an oracle user (password oracle). You can change either or both of these passwords after installation, of course.
Non-RAC Oracle Servers will have a version of the Oracle software installed. No database will exist, but a createdb.sh shell script will have been created in the /home/oracle directory. Running that (as the oracle user) will result in the automatic creation of a database called orcl. SYS, SYSTEM and other administrative passwords will be set to oracle, but these can be changed using standard database commands at any time.
RAC Oracle Servers will have no software automatically installed, but an /osource directory will have been created, within which are database and grid directories containing the appropriate unpacked Oracle software. The software is therefore immediately ready for installation, whenever you’re satisfied that the entire cluster is up and running.
All Oracle Servers will be built with mounts of NFS shares made available by the Salisbury Server itself. There are two such mounts: /gdata and /ddata, which correspond to the Salisbury Server’s /griddata and /dbdata directories. Non-RAC Oracle Servers can just ignore the existence of these shares, but RAC Oracle Servers can make use of them during the Grid and Database software installs to store grid and database components on a shared file system. It is assumed that RAC Servers will use their own, local, non-shared file systems for storing the Oracle software components.
Both Salisbury and Oracle Servers can be managed remotely with Webmin (point a browser to it at port 10000). Both can also be monitored at the command line with nmon.
Oracle Servers will have rlwrap capability baked-in, so local SQL*Plus sessions will make use of it to provide a scroll-able command line history (that is, you can hit the up- and down-arrow keys in SQL*Plus to retrieve previously-typed SQL statements). Should anyone have ideas for what other software components would be useful to add to either the Salisbury or Oracle servers (or both), please feel free to drop me a line. If it’s useful and do-able, I’ll do it!
Note that both the Salisbury and Oracle Server builds are fatal to anything that might already be sitting on the hard disk of the servers involved: Kickstart is used to simply wipe all partitions it finds. Don’t point Salisbury at pre-loved servers that contain vitally-important data, therefore: you will lose it all if you do.
Salisbury is obviously a lot more complicated to describe than Gladstone! In practice, though, you should find it hands-free, highly automatic and, basically, a piece of cake to use.
The complexity arises because it’s an infrastructure, not a script -though it’s an infrastructure that bootstraps itself into existence courtesy of Kickstart scripts.
It depends on several version-dependent components, of course: Kickstart scripts designed for version 6.xdistros won’t work with version 5.x distros, for example. Similarly, response files that perform perfect 18.104.22.168 Oracle installs blow up spectacularly when confronted with 22.214.171.124 software. I don’t expect Salisbury to cope with arrival of Red Hat 7 and Oracle 12 without a degree of pain, therefore! I do believe, though, that its underlying techniques and technologies are flexible and extensible enough to be able to cope as the future does its worst.
It’s taken quite some weeks to get it to this state: I hope someone out there finds it as useful as I have!
|10th April 2013||Prerequisite failure in 126.96.36.199 (possibly 188.8.131.52 also) concerning compat-libcap1-1.10. This can be ignored, like all the other prerequisite failures, and the Grid software will still compile and install correctly.||Fixed|
|11th April 2013||RAC Install on 184.108.40.206 fails to start ohasd with “inappropriate ioctl for device” error. This is a known bug with 220.127.116.11 on 6.x distros, and the fix was documented in my earlier RAC-on-Linux article (see section 6). Fix must be applied before you run the root.sh script.||Workaround Available|
|11th April 2013||RAC on 18.104.22.168: both the Grid and Database installs fail at prerequisite check for ‘resolv.conf integrity’ (PRVF-5637: DNS response time could not be checked). This is a known bug: see MOS 1480242.1. The workaround is to click the ‘Ignore All’ button.||Workaround Available|
- Response file scripts for Grid and Database installations (22.214.171.124 only)
- Shell script to automate the fix for 126.96.36.199 RAC on 6.x distros