Tag Archives: Kickstart

Salisbury, plain

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 running RCSL that 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 11.2.0.1 or 11.2.0.3 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 11.2.0.1), or from edelivery (if you have a proper, paid-for subscription and want to download version 11.2.0.3 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:

oradb-1120x-1of2.zip
oradb-1120x-2of2.zip
oragrid-1120x.zip

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, 11.2.0.1 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:

ks=http://192.168.8.250/kickstart.php?distro=centos&version=63

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 11.2.0.1 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.

Conclusion

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.x RCSL distros won’t work with version 5.x RCSL distros, for example. Similarly, response files that perform perfect 11.2.0.1 Oracle installs blow up spectacularly when confronted with 11.2.0.3 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!

Known Issues

Date	Issue	Status
10th April 2013	Prerequisite failure in 11.2.0.3 (possibly 11.2.0.1 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 11.2.0.1 fails to start ohasd with “inappropriate ioctl for device” error. This is a known bug with 11.2.0.1 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 11.2.0.3: 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

Forthcoming Attractions

Response file scripts for Grid and Database installations (11.2.0.3 only)
Shell script to automate the fix for 11.2.0.1 RAC on 6.x distros

Conditional Kickstart (Part 2)

Leave a reply

Last time, I discussed how you can make different bits of the %post section of a Kickstart file behave conditionally, by specifying key/value pairs on the bootstrap line when starting a Kickstart-managed O/S install.It works nicely and lets me do different things depending on what version of Oracle I’m installing at the time.

I pointed out, however, that you couldn’t use this capability to get different parts of the command section of the Kickstart script to behave conditionally. And that’s a nuisance because the command section is where you include things like the url command that tells your Kickstart script where its source O/S can be found -so, if you have half a dozen OSes to choose from, you can’t just create one Kickstart script with a conditionally-evaluated url bit in it.

So much remains true.

However, as one of the regulars here was quick enough to point out, it ought to be possible to get the Kickstart server to do conditional evaluation and to dynamically construct a Kickstart file accordingly. Indeed, I wrote a PHP script for my Kickstart Configurator on this very site not so long ago that did precisely that; so good point, Colin!

So let me explain how I ran with this idea of getting the Kickstart server to do some dynamic, conditional evaluation, particularly of this annoyingly-important url bit of the command section. First thing was to add PHP to my Kickstart server. Because it has no Internet connection, I had to install the necessary software from the CentOS install DVD, mounted at /media:

cd /media/Packages
rpm -Uvh php-5.3.3.-22.el6.x86_64.rpm php-cli-5.3.3-22.el6.x86_64.rpm php-common-5.3.3-22.el6.x86_64.rpm

That’s three packages installed in one hit, because they’re dependent on each other.

Next, I had to get the toolbox’s Apache web server to realise it ought to be handling PHP:

nano /etc/httpd/conf/httpd.conf

Scroll through that file and around about line 202, you can add this:

LoadModule php5_module modules/libphp5.so

And around line 788, you add this:

AddType text/html .php

This just tells Apache where to find the php software and that it’s able to handle files with a .php extension. Save the modified file, then re-start Apache like so:

service httpd stop
service httpd start

Now, take the alpher-sl64.ks file I talked about last time and copy/rename it:

mv /var/www/html/alpher-sl64.ks /var/www/html/alpher.php

This just means that your original Kickstart file is now regarded as a PHP file. Of course, it doesn’t contain any PHP code just yet, but that’s not important.

Around line 25-33 in the copied/renamed file, you’ll see this:

#  =======================================================================
#  The source distro software (obviously distro and version specific) 
#  =======================================================================
url --url http://192.168.8.250/centos/63
#url --url http://192.168.8.250/sl/63
#url --url http://192.168.8.250/oel/63
#url --url http://192.168.8.250/centos/64
#url --url http://192.168.8.250/sl/64
#url --url http://192.168.8.250/oel/64

This can now be replaced as follows:

#  =======================================================================
#  The source distro software (obviously distro and version specific)
#  =======================================================================
url --url http://192.168.8.250/<?php echo $_GET["distro"]; ?>/<?php echo $_GET["version"]; ?>

Instead of 6 lines of code, 5 of which need to be commented out to leave just one, distro-specific “active” line, we now have just one line of code that includes some PHP code. The code simply parses the URL by which this file is called for two arguments: the first is the distro being used and the second is the version of that distro.

In other words, if you simply opened up a browser and entered in the URL:

http://192.168.8.250/alpher.php?distro=centos&version=64

…you would see the garbled text of the Kickstart file displayed -but, if you looked closely enough, you’d see that there is now a properly-formed, but dynamically-constructed url –url http… line of text in it, like so:

And the point is that if your browser can get this result, so can a Kickstart bootstrap line when constructing a new Oracle server. I’m still using the conditional execution I discussed last time, of course, so adding this new sort of conditionality to the mix means my complete Kickstart bootstrap command now looks like this:

By simply altering the value of the distro and version components of the URL that’s pointing to the Kickstart script, plus supplying different values for the separate oraver=xxxx parameter, I can now have a single Kickstart file to do duty for any combination of RCSL distro and Oracle 11gR2 I can think of. Handy!

It would be possible to use the same technique to make all sorts of other bits of the original Kickstart scripts behave dynamically: you could pass in IP address parameters, for example, or passwords for the root user, or specific disk partitioning instructions. But my needs are simple and, at this stage, all I really need is the ability to create that pesky url… command, which this does nicely. I also don’t want it to become a pain in the neck typing in the Kickstart bootstrap line in the first place, which adding a fistfull of parameters would, inevitably, do.

So, after several weeks of telling this particular story bit-by-bit, and building up the necessary components layer by layer, I think we’re finally in a position to pull all these threads together into a single, coherent package. Watch this space!!

Conditional Kickstart

2 Replies

Consider lines 25 to 30 from the Kickstart script I linked to in the last post:

#url --url http://192.168.8.250/centos/63
#url --url http://192.168.8.250/sl/63
#url --url http://192.168.8.250/oel/63
#url --url http://192.168.8.250/centos/64
url --url http://192.168.8.250/sl/64
#url --url http://192.168.8.250/oel/64

There are six possible combinations of distro and version, and therefore there are six possible values for the ‘url’ parameter. Is there a way to have a Kickstart file say (for example) “install from this URL if you are Scientific Linux 6.4, but that URL if you are CentOS 6.3″?

The answer is,sadly, no.

The basic principle to conditionally doing things in Kickstart is that you would pass a parameter value to the installer at the bootstrap command line; you then parse that in a “%pre” section of the Kickstart script and then you can conditionally execute stuff depending on what you parse by using an %include directive.

For example, instead of booting a server with ks=http://192.168.8.250/alpher.ks, you could boot it with ks-http://192.168.8.250/alpher.ks distro=sl64. Then, you stick this sort of stuff in the %pre section of the Kickstart file:

#!/bin/sh
if grep -i -q "distro=[a-z0-9]" /proc/cmdline
then
    MYDIST=`cat /proc/cmdline | sed 's/.*distro=\([^ ]*\).*/\1/'`
else 
    MYDIST=centos63
fi

Variables and their values which you pass on the bootstap line are readable from /proc/cmdline. This code simply uses sed to split the variable from its value, then assigns a value to the $MYDIST environment variable depending on what bootstrap value it finds has been passed.

The theory is that you’d then be able to do this sort of thing:

if [ $MYDIST == "sl64" ]; then 
  echo "url --url http://192.168.8.250/sl/64" > /tmp/urlfile
else
  echo "url --url http://192.168.8.250/centos/63" > /tmp/urlfile
fi

So you output different things to a file in the /tmp directory, depending on the value your environment variable has been set to. Instead of then having the url section of the Kickstart file I showed earlier, you would then replace that with:

%include /tmp/urlfile

This causes the Kickstart file to read in the contents of that urlfile, and thus pick up the distro-specific URL value I desire.

Brilliant …except it doesn’t work. The reason is simple: the bit of the Kickstart file which contains the url… directive (usually called the “command section”) is evaluated before the %pre section. The documentation is quite explicit about it, too:

Note

The pre-installation script section of kickstart cannot manage multiple install trees or source media. This information must be included for each created ks.cfg file, as the pre-installation script occurs during the second stage of the installation process.

So, as far as I know, there’s no way to conditionally determine the source of the software you’re about to install on your new server using this key/value pair technique. Shame: it means that if there are 6 different distro/version combinations, you need six different Kickstart files, each with the url directive set uniquely to one particular software source.

However, you are not so constrained if there are bits of the %post section you want to perform conditionally, because that’s definitely evaluated after the %pre section. For example, you know that an Oracle response file is highly version-specific: an 11.2.0.1 response file won’t work for an 11.2.0.3 Oracle install. So why not pass in the Oracle version as a bootstrap keyword/value pair, evaluate it in a %pre script, then do stuff differently in the %post section depending on the value passed?

For example, in my Alpher Kickstart script I linked to last time, I have line 473 as this:

wget http://192.168.8.250/standalonedb.rsp -O /osource/standalonedb.rsp

But suppose on the Kickstart server, I have two different response files, called standalonedb-11203.rsp and standalonedb-11201.rsp.

I add this to the beginning of the Kickstart script:

%pre
#!/bin/sh
if grep -i -q "oraver=[a-z0-9]" /proc/cmdline
then
    ORCVER=`cat /proc/cmdline | sed 's/.*oraver=\([^ ]*\).*/\1/'`
else 
    ORCVER=11201
fi
if [ $ORCVER == "11201" ]; then
    echo "wget http://192.168.8.250/standalonedb-11201.rsp -O /osource/standalonedb.rsp" > /tmp/standalone
elif [ $ORCVER == "11203" ]; then
    echo "wget http://192.168.8.250/standalonedb-11203.rsp -O /osource/standalonedb.rsp" > /tmp/standalone
fi

So we create a /tmp/standalone file which contains the instructions to download a version-appropriate response file, depending on the value of the oraver=<something> parameter we supply on the bootstrap command line.

Instead of the original line 473, therefore, I now have this:

%include /tmp/standalone

…so that we read in the version-dependent command to execute from the temporary file previously created. All I have to do to get this functionality to work is type something like:

ks=http://192.168.8.250/alpher-sl64.ks oraver=11203

…when I boot the server. There’s no practical limit to the number of these key/value pairs you can pass to a Kickstart script, providing only that you have code in your %pre section that can parse them out, write different files to /tmp depending on the values passed, and use %include commands wherever conditional execution needs to take place.

Hands-free Oracle Installs

Leave a reply

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:

Centos 6.3	http://mirror.aarnet.edu.au/pub/centos/6.3/isos/x86_64/CentOS-6.3-x86_64-netinstall.iso
Centos 6.4	http://mirror.aarnet.edu.au/pub/centos/6.4/isos/x86_64/CentOS-6.4-x86_64-netinstall.iso
Scientific 6.3	http://mirror.aarnet.edu.au/pub/scientific/6.3/x86_64/iso/SL-63-x86_64-2012-08-02-boot.iso
Scientific 6.4	http://mirror.aarnet.edu.au/pub/scientific/6.4/x86_64/iso/SL-64-x86_64-2013-03-18-boot.iso
Oracle 6.3	V33412-01 from edelivery or http://mirror.aarnet.edu.au/pub/oraclelinux/OL6/U3/x86_64/x86_64-boot.iso
Oracle 6.4	V37088-01.iso from edelivery or http://mirror.aarnet.edu.au/pub/oraclelinux/OL6/U4/x86_64/x86_64-boot.iso

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 11.2.0.1, this is the file you want; if you’re intending to install 11.2.0.3, 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:

ks=http://192.168.8.250/alpher-sl64.ks

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:

./createdb.sh

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.

7. Conclusion

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

Add a dash of software…

Leave a reply

In my last-but-one post, I explained how you could build a ‘Linux toolbox’: a RCSL server that acts as web server, DNS lookup server, NFS server and more. I also showed how you could do all of that with barely any manual intervention, thanks to the magic of Kickstart scripts.

Well, now I want to suggest a couple of additions to really round out your toolbox’s functionality. These can’t really be automated, because they involve agreeing to licences and export restrictions and so forth.

1. Add some useful binaries

Your toolbox server is lacking a GUI, so monitoring its CPU, disk I/O and memory usage might be tricky. Fortunately, nmon is a command-line utility that monitors all these things easily. So adding that to your toolbox server might be a good idea. It can be obtained as an rpm suitable for all of the RCSL 6.x, 64-bit distros from this site.

You may also feel you need a graphical way of re-configuring things like hostnames, IP addresses, DNS settings and so on. A useful tool for that is webmin, which is a browser-based way of doing precisely that. There’s an rpm suitable for all RCSL distros available on this page.

Once you install it, just fire up a browser in a client PC and point it at your toolbox server’s IP address, specifying port 10000. In my case, that means typing into a browser’s URL bar something like http://192.168.8.250:10000

After that, it’s just a matter of logging on (as root) and then clicking around seeing what is available.

I’m going to suggest two additional binaries you might want to download and store in the toolbox’s /var/www/html directory -not because they are useful to the toolbox itself, but because they might prove useful later on. First, the public domain korn shell is largely redundant these days, but happens to be a prerequisite for Oracle installs on RCSL distros, If you don’t install it, you can therefore get annoying warning messages from the Oracle installer. Fortunately, a version of it is available for download as an RCSL 64-bit compatible RPM from here.

The final binary I suggest you download is rlwrap. You can download it as a tarball, extract it and then compile it if you like, but there’s an RPM version available for download which is a bit simpler to get working, so I’m going to suggest you get that and store it in your toolbox server’s web document root directory instead.

Of course, if you’ve been following this series of posts, you’ll know that my toolbox server, by design, doesn’t have a network connection to the Internet, so downloading those things using the toolbox itself is not possible. That’s why I download them all on a different machine that does have an Internet connection and then burn them onto an ISO (a virtual DVD). (I use Brasero to do that, but any DVD burning software will do the job). Once the four binaries (nmon, webmin, pdksh and rlwrap) are stored on the virtual DVD, it’s trivial to get the toolbox server to mount the ISO and copy them all off to the /var/www/html directory. Once there, you can install nmon and webmin on the toolbox itself:

rpm -Uvh nmon-14f-1.el6.rf.x86_64.rpm
rpm -Uvh webmin-1.620-1.noarch.rpm

The other two will come in handy later on. If you can’t burn your own ISOs, here’s one I prepared earlier…

2. Add some Oracle files

The other software which it would be useful to copy to the toolbox, so it can be served up to clients later on, is the Oracle database software itself. I can’t give you a handy link to those: you’ll have to get them from either Oracle’s own otn or edelivery sites.

If you have paid-for support, you could obtain the 11.2.0.3 version of the Oracle database: you’ll have files called things like “p10404530_112030_Linux-x86-64_1of7.zip” and “p10404530_112030_Linux-x86-64_2of7.zip”.

If you download the freebie versions from OTN, you’ll have to make do with the 11.2.0.1 version, and you’ll end up with file names like “linux.x64_11gR2_database_1of2.zip” and “linux.x64_11gR2_database_2of2.zip”.

If you do your downloads from edelivery without a paid-for support contract, you’ll again be limited to the 11.2.0.1 version of the database, but this time you’ll end up with file names such as “V17530-01_1of2.zip” and “V17530-0_2of2.zip”.

Since all the versions and file name variations can get confusing, I’m going to suggest that whatever files you download, you rename them to be in the form: oradb-1120x-1of2.zip, where “x” is the relevant bit of the version number. So, having paid-for support, I’m going to end up with oradb-11203-1of2.zip; if I were only able to access OTN freebies, I’d end up with oradb-11201-1of2.zip, and so on.

Once you’ve download and re-named your Oracle files, again burn them onto a virtual DVD iso file, get your toolbox server to mount it, and copy all the zips it contains to the /var/www/html directory. Once there, the zip files will be able to be used by other servers you build that need them.

3. Conclusion

Having done all of the above, when I list the contents of my toolbox server’s /var/www/html directory, here’s what I see:

The “sl” directory (in blue) is there because, you’ll remember, my Kickstart script causes the toolbox to copy its own installation media to disk -and this happens to be a Scientific Linux box.

The four files in red are the little utilities that the toolbox itself, and any server it’s later used to help build, might find useful. Obviously, there are no Oracle database files there yet, but a bit of downloading and renaming as described earlier results in this:

Now you see the 2 Oracle database zip files sitting there (these are the freebie versions, so they’re 11.2.0.1).

The significance of all this? Well, you’ve now got yourself a toolbox that is almost ready to do completely hands-free Oracle installations on other RCSL servers. I’ll explain the extra ingredient needed next time…

Putting it all together

Leave a reply

In the previous sequence of posts, I’ve documented how you can build a RCSL server that can act as a DHCP, DNS, NFS, Web and Time server.

But why do each one in isolation? Why not build a single server that is configured to be all of those things, so that when all is done, it acts as giant ‘toolbox’ of network services to your entire network? Actually, there is a good reason not to do that, called “single point of failure”. But in a home network/test lab environment, I don’t think that’s an important consideration. So the all-in-one toolbox approach sounds good to me!

You’ll notice from all those previous posts, though, that setting up each of these network services often takes a lot of typing -and thus has a high risk of getting something wrong.

So can we automatically build a single server that can provide all these services, configured correctly ‘out of the box’? Sure we can: and it’s our old friend Kickstart that will work this particular brand of magic. And here is a Kickstart script that will do everything discussed in the previous 6 posts, all in one, completely automatically:

#  =======================================================================
#  This Kickstart script written by Howard Rogers. 
#  Copyright (c) 2013 Howard Rogers,Dizwell Informatics
#  The script is supplied "as-is" with no warranties or guarantees of 
#  fitness of use or otherwise. Neither Dizwell Informatics nor 
#  Howard Rogers accepts any responsibility whatsoever for any 
#  damage caused by the use or misuse of this script.
#  =======================================================================

install
text
cdrom
lang en_US.UTF-8
keyboard us
network --onboot yes --device eth0 --bootproto static --ip 192.168.8.250 --netmask 255.255.255.0 --noipv6 --nameserver 192.168.8.250 --hostname marconi.dizwell.home
firewall --disabled
authconfig --enableshadow --passalgo=sha512
selinux --disabled
timezone Etc/GMT
bootloader --location=mbr --driveorder=sda --append="crashkernel=auto rhgb quiet"
clearpart --all
part / --fstype=ext4 --size 20000 --grow
part swap --size 1024

%packages
@base
@core
@nfs-file-server
@network-server
@system-admin-tools
@web-server
@server-platform
bind
dhcp
nfs-utils
ntp
crypto-utils
-vconfig
-setuptool
-kexec-tools
-sos
-wireless-tools
-system-config-network-tui
-mdadm
-dmraid
-hunspell-en
-tcsh
-abrt-cli
-scl-utils
-systemtap-runtime
-fprintd-pam
-dosfstools
-smartmontools
-rfkill
-blktrace
-pinfo
-system-config-firewall-tui
-words
-abrt-addon-kerneloops
-abrt-addon-ccpp
-bridge-utils
-mtr
-pcmciautils
-usbutils
-ledmon
-hunspell
-abrt-addon-python
-man-pages
-b43-fwcutter
%post
chkconfig iptables off

# Configure NFS Server
mkdir /griddata
mkdir /dbdata
echo "/dbdata 192.168.8.0/24(rw,sync,no_wdelay,insecure_locks,no_root_squash)" > /etc/exports
echo "/griddata 192.168.8.0/24(rw,sync,no_wdelay,insecure_locks,no_root_squash)" >> /etc/exports
chkconfig nfs on
service nfs start

#Configure DHCP Server
echo "option domain-name            \"dizwell.home\";" > /etc/dhcp/dhcpd.conf
echo "option domain-name-servers    192.168.8.250;" >> /etc/dhcp/dhcpd.conf
echo "default-lease-time   600;" >> /etc/dhcp/dhcpd.conf
echo "max-lease-time 6000;" >> /etc/dhcp/dhcpd.conf
echo "authoritative;" >> /etc/dhcp/dhcpd.conf
echo "subnet 192.168.8.0 netmask 255.255.255.0 {" >> /etc/dhcp/dhcpd.conf
echo "range dynamic-bootp 192.168.8.200 192.168.8.240;" >> /etc/dhcp/dhcpd.conf
echo "option broadcast-address 192.168.8.255;" >> /etc/dhcp/dhcpd.conf
echo "}" >> /etc/dhcp/dhcpd.conf
chkconfig dhcpd on
service dhcpd start

#Configure DNS Server
echo "options {" > /etc/named.conf
echo "    directory \"/var/named\";" >> /etc/named.conf
echo "    dump-file \"/var/named/data/cache_dump.db\";" >> /etc/named.conf
echo "    statistics-file \"/var/named/data/named_stats.txt\";" >> /etc/named.conf
echo "    memstatistics-file \"/var/named/data/named_mem_stats.txt\";" >> /etc/named.conf
echo "    allow-query { localhost; 192.168.8.0/24; };" >> /etc/named.conf
echo "    recursion yes;" >> /etc/named.conf
echo "    dnssec-enable no;" >> /etc/named.conf
echo "    dnssec-validation no;" >> /etc/named.conf
echo "    dnssec-lookaside auto;" >> /etc/named.conf
echo "    /* Path to ISC DLV key */" >> /etc/named.conf
echo "    bindkeys-file \"/etc/named.iscdlv.key\";" >> /etc/named.conf
echo "    managed-keys-directory \"/var/named/dynamic\";" >> /etc/named.conf
echo "    };" >> /etc/named.conf
echo "    logging {" >> /etc/named.conf
echo "        channel default_debug {" >> /etc/named.conf
echo "       file \"data/named.run\";" >> /etc/named.conf
echo "       severity dynamic;" >> /etc/named.conf
echo "         };" >> /etc/named.conf
echo "    };" >> /etc/named.conf
echo "    zone \".\" IN {" >> /etc/named.conf
echo "         type hint;" >> /etc/named.conf
echo "         file \"named.ca\";" >> /etc/named.conf
echo "    };" >> /etc/named.conf
echo "    zone \"dizwell.home\" IN {" >> /etc/named.conf
echo "        type master;" >> /etc/named.conf
echo "        file \"dizwell.hosts\";" >> /etc/named.conf
echo "    };" >> /etc/named.conf
echo "    include \"/etc/named.rfc1912.zones\";" >> /etc/named.conf
echo "    include \"/etc/named.root.key\";" >> /etc/named.conf

echo "\$TTL 86400" > /var/named/dizwell.hosts
echo "@ IN SOA marconi.dizwell.home. hjr.dizwell.com. (" >> /var/named/dizwell.hosts
echo "2013030501 ;Serial" >> /var/named/dizwell.hosts
echo "3600 ;Refresh" >> /var/named/dizwell.hosts
echo "1800 ;Retry" >> /var/named/dizwell.hosts
echo "604800 ;Expire" >> /var/named/dizwell.hosts
echo "86400 ;Minimum TTL" >> /var/named/dizwell.hosts
echo ")" >> /var/named/dizwell.hosts
echo "" >> /var/named/dizwell.hosts
echo "        IN NS   marconi.dizwell.home." >> /var/named/dizwell.hosts
echo "        IN A    192.168.8.250" >> /var/named/dizwell.hosts
echo "" >> /var/named/dizwell.hosts
echo "marconi         IN A    192.168.8.250" >> /var/named/dizwell.hosts
echo "alpher          IN A    192.168.8.101" >> /var/named/dizwell.hosts
echo "bethe           IN A    192.168.8.102" >> /var/named/dizwell.hosts
echo "alpher-priv    IN A    10.0.0.1" >> /var/named/dizwell.hosts
echo "bethe-priv    IN A    10.0.0.2" >> /var/named/dizwell.hosts
echo "alpher-vip      IN A    192.168.8.111" >> /var/named/dizwell.hosts
echo "bethe-vip       IN A    192.168.8.112" >> /var/named/dizwell.hosts
echo "racscan         IN A    192.168.8.200" >> /var/named/dizwell.hosts
echo "racscan         IN A    192.168.8.201" >> /var/named/dizwell.hosts
echo "racscan         IN A    192.168.8.202" >> /var/named/dizwell.hosts
echo ";; end of zone" >> /var/named/dizwell.hosts
echo ";;" >> /var/named/dizwell.hosts

echo "search dizwell.home" > /etc/resolv.conf
echo "nameserver 192.168.8.250" >> /etc/resolv.conf
chown named:named /var/named/dizwell.hosts
#service named start
chkconfig named on

#Configure NTP Server
echo "server 127.127.1.0" > /etc/ntp.conf
echo "fudge 127.127.1.0 stratum 2" >> /etc/ntp.conf
echo "driftfile /var/ntp/ntp.drift" >> /etc/ntp.conf
echo "statsdir /var/ntp/ntpstats/" >> /etc/ntp.conf 
echo "filegen peerstats file peerstats type day enable" >> /etc/ntp.conf
echo "filegen loopstats file loopstats type day enable" >> /etc/ntp.conf
service ntpd start
chkconfig ntpd on

#Configure Web Server

if [ `lsb_release -d | grep 6.4 | wc -l` -eq 1 ]; then
  VERSION=64
elif [ `lsb_release -d | grep 6.3 | wc -l` -eq 1 ]; then
  VERSION=63
else
  VERSION=6
fi

DISTRO=$(lsb_release -is)
if [ $DISTRO = "CentOS" ]; then
  mkdir -p /var/www/html/centos/$VERSION
  DISTRO=centos
elif [ $DISTRO = "OracleServer" ]; then
  mkdir -p /var/www/html/oel/$VERSION
  DISTRO=oel
elif [ $DISTRO = "Scientific" ]; then
  mkdir -p /var/www/html/sl/$VERSION
  DISTRO=sl
else
  mkdir -p /var/www/html/unknown/$VERSION  
  DISTRO=unknown
fi

mount /dev/sr0 /media
cp -rvf /media/* /var/www/html/$DISTRO/$VERSION
umount /media
service httpd start
chkconfig httpd on

%end

This script works with any of the mainstream 64-bit RCSL distros: it’s been tested on 64-bit CentOS 6.3 and 6.4, Scientific Linux 6.3 and 6.4 and Oracle Enterprise Linux 6.3 and 6.4,

To use it, obviously you first need appropriate O/S installation media. Use the full DVD media that allows fully-functional installs from a single DVD, because the script can’t cope with changing DVDs half-way through an installation. Here are where I sourced my test ISOs from:

Centos 6.3	http://mirror.aarnet.edu.au/pub/centos/6.3/isos/x86_64/CentOS-6.3-x86_64-bin-DVD1.iso
Centos 6.4	http://mirror.aarnet.edu.au/pub/centos/6.4/isos/x86_64/CentOS-6.4-x86_64-bin-DVD1.iso
Scientific 6.3	http://mirror.aarnet.edu.au/pub/scientific/6.3/x86_64/iso/SL-63-x86_64-2012-08-02-Install-DVD.iso
Scientific 6.4	http://mirror.aarnet.edu.au/pub/scientific/6.4/x86_64/iso/SL-64-x86_64-2013-03-18-Install-DVD.iso
Oracle 6.3	V33411-01.iso from edelivery or http://mirror.aarnet.edu.au/pub/oraclelinux/OL6/U3/x86_64/OracleLinux-R6-U3-Server-x86_64-dvd.iso
Oracle 6.4	V37084-01.iso from edelivery

(Red Hat installation media are only available to paying customers, so I figure you’ll already know where to go on the Red Hat portal to get the appropriate ISO!)

The Kickstart script itself then needs to be copied to somewhere that your “toolbox server” can find it during O/S installation: a floppy disk is good, but they are getting a bit thin on the ground, physically, these days! A USB stick might do the job, too. But, for my money, the simplest approach is to burn it onto a CD (or ISO CD image). If 700MB or 4.7GB for a single text file seems a bit extravagant, so be it: at least it works.

Here is an ISO file containing the above script. Burn it to a physical CD/DVD if you like, or use it as an ISO file to help boot a virtual machine. Of course, the Kickstart file it contains is hard-wired to build a server called Marconi with an IP address of 192.168.8.250, as per my previous posts. If you want a different configuration, you’ll have to build your own ISO having edited the script, first.

This Kickstart-on-DVD arrangement would mean, of course, that your physical server would need two DVD drives installed: the first to hold the O/S DVD media and the second to hold the Kickstart file. That might be a tall order on a physical server (though USB external DVD drives could potentially come to the rescue), but it’s easy on a virtual machine: just add the extra hardware at the time you create the new virtual machine:

That’s in VirtualBox: note that the full Linux installation disk is listed before the toolbox.iso: that’s important, because the boot disk has to be the first in order of boot priority. If the toolbox disk is listed first, you’ll be trying to boot from a text file… and that won’t work! Just alter the “IDE Primary/Secondary Master” and “IDE Primary/Secondary Slave” drop box against each disk until your boot disk is primary master and your toolbox ISO is listed as primary slave or secondary master/slave.

After that, you just have to intervene briefly at boot time:

As for any Kickstart installation, you simply press TAB when the boot welcome menu appears. That displays some existing text (vmlinuz initrd=initrd.img) and all you have to do is, as you see here, append a bit of information to say where your Kickstart file is. Mostly, that just means correctly identifying the device it’s stored on.

If your Kickstart file was stored on a floppy disk, the device identifier would be hd:fd0 (that’s a zero, not an oh). Since mine is on a secondary CD drive, my device identifier is as you see it here: hd:sr1. In either case, the Kickstart file itself is called “toolbox.ks”, so you just stick that on the end of the appropriate device identifier. In my case, I end up with:

hd:sr1/toolbox.ks

The hardest part is working out your device names -and that might take a bit of trial and error. But once you get it right, your involvement in the rest of the installation will be absolutely minimal:

You may be prompted to agree to having your hard disk wiped, but only if it’s a completely new hard disk that has never been partitioned before. If you’re re-using a pre-loved hard disk, it will be wiped without any prompting.
You will be prompted once for a root password (typed in twice).

Other than that, the entire installation will complete automatically, and all the network services discussed over the past 6 posts (DHCP, DNS, NFS, NTP and Apache) will be auto-configured without any manual intervention on your part. At the end of the installation, therefore, you’ll be owner of a self-contained, highly functional Linux ‘toolbox’.

Remember, if you’re doing this in a Virtual Machine, that I’m expecting your toolbox to have just 512MB RAM, at least a 25GB hard disk and to be using Host-only networking.

To show you how painless it all is, here’s a video of me doing practically nothing! (I’ve cut out nothing, but I suggest you play it back at 2x or 3x speed, so that it’s not quite as boring as it was originally!).

Key features of the movie:

At ~0:38, I am asked to re-initialise the disk, because this one had never been used before. I select the Re-initialize all option.
At ~0:44, I supply a root password (twice)
At ~3:33, the installation process ends and the post-installation scripts are run. This involves copying the installation media itself from DVD to hard disk. Since about 4GB of data is involved, it takes a while to complete.
At ~5:00, I am asked to reboot. Once the machine does so, I log on as root and demonstate that all the network services are up and running -after precisely three bits of user input.

Assuming you can view the toolbox.ks file in a text editor that can display line numbers, here are a few observations about the file, referenced to the various lines.

Line 11: The RCSL install that uses this Kickstart file will do a text-mode install. This is good, because a server providing all the network services I’ve mentioned only needs around 512MB of RAM -but that’s not enough memory to do a graphical installation.

Line 15: The Server will end up part of the dizwell.home domain (you can obviously edit this to suit), and have an IP address of 192.168.8.250.

Line 16: The Firewall is disabled. It’s a blunt approach: we should more properly open up ports 80, 53 and so on. But this is simpler: and it works!

Line 18: SELinux is disabled. SELinux afficionados will disapprove, but again, simply disabling it means everything works without fuss.

Lines 21 – 23: The server will expect a hard disk of at least ~25GB. Most of that will be assigned to a single root partition at least 20GB in size (but it can grow bigger than that if the disk space is there); a 1GB swap partition is also created. Note that this will wipe any hard disk it’s pointed at… making it lethal. If you don’t want a hard disk wiped, don’t use this script!

Lines 25 – 70: The bare minimum of software is installed. You’ll note that NFS, Apache, Bind (DNS), DHCP and NTP are all added to the mix, though.

Lines 73 – 79: Pretty much a re-hash of my recent ‘quickly build an NFS server’ post

Lines 81 – 92: Pretty much a re-hash of my recent ‘quickly build a DHCP server’ post

Lines 94 – 155: Pretty much a re-hash of my recent ‘quickly build a DNS server’ post

Lines 157 – 165: Pretty much a re-hash of my recent ‘quickly build an NTP server’ post

Lines 195 – 196: Getting the Apache webserver running and ensuring it runs at every server reboot thereafter, as explained in the ‘quickly build a webserver’ post.

Lines 192 – 194 Potentially the most important lines of the lot, because they ensure that the server copies its own installation DVD to hard disk -thus making it able to host future over-the-network installs of other RCSL servers. As future posts here will explain, that capability is going to become significant.

Automatic Portland

Leave a reply

Ah, automation! Where would we be without it? (It is a little-known fact that the total mileage of railway line in England did not exceed the total mileage of canals in England until 1861 -some 80 years later than is commonly supposed, and proof that the Industrial Revolution never really happened -except in Germany, funnily enough. Britain, though, had an Industrial Evolution).

Anyway, I digress. Automation is good, and it helps produce nicely-standardized things which are therefore more predictable and more stable than their chaotic hand-built equivalents.

This goes for operating system installs, too.

Having got Gladstone doing his thing to hand-built servers, ensuring a level playing field when it comes time to install Oracle; having then got Palmerston working overtime to do the same thing for a Kickstart-automated server build; it is now time for me to introduce Portland: the script you run to standardize and automate your RCSL builds when you don’t want to install Oracle.

Perhaps being a little more positive, I should say that Portland is the script to run when you want the Gimp, VLC, Eclipse, Java, Apache Directory Studio, Opera, Rhythmbox, Handbrake …and all those other good productivity programs (like Solitaire and Chess)… added to an otherwise standard and minimal RCSL server installation. Preferably without all the hassle and confusion that the bazillion-and-one ‘how to do a perfect desktop’ articles out there seem to want to inflict on you!

Portland turns RCSL servers into usable desktops, in other words (including switching from OpenOffice to LibreOffice).

I particularly like it because it makes continued and almost-exclusive reference to mirror.aarnet.edu.au (and, indeed, changes the standard yum repositories so that they point there too). That mirror happens to be (a) close to Australians and (b) completely unmetered in use for us poor Telstra ~~customers~~ shmucks. For me, it means I can install RCSL servers until the cows come home without running up huge ISP bills or excess download consequences. For others, it will be a disaster, of course, since it will be using perhaps the remotest, non-free repositories in (their) existence. I’ll work on that for a future update! Meanwhile, you could do a global search-and-replace of the mirror URL before running it.

So, to sum up:

Build a minimal-desktop RCSL server, then download portland.sh to it.
Provided you have a functioning Internet connection, you log on as root and invoke that script (a simple sh /portland.sh will do it).
20 minutes later, your server build will complete. including a nice set of top-panel application launchers for all the apps I consider to be vital (you might disagree with my choice of launchers, but that’s life!)
There are two interactive prompts throughout the entire process: Dropbox asks you if it’s OK to close all Nautilus windows (the answer is ‘yes’), and Calibre says it’s going to install to /opt (press Enter to accept). If I can get those two working in a non-interactive mode, I will.

There are still a couple of things I definitely won’t automate, the most significant of which is the installation of proprietary graphics drivers: I can’t find a reliable way of working out what graphics card is installed in a PC, so can’t automate the installation of the right binary blob. Install the wrong one, however, and the PC may well refuse to display anything at its next reboot. I’ve therefore decided to leave well alone for now!

But for the most part, I can now roll out a bundle of RCSL servers in double-quick time and have them all look as I want them to, without really having to do anything. And that’s the sort of automation I can live with!

Footnote 1: because I know literally tens of thousands of people will be asking, William Henry Cavendish-Bentinck was the 3rd Duke of Portland and served as British Prime Minister twice (in 1783 and 1807-1809, which is the longest gap between ‘turns’ of any British Prime Minister. If Margaret Thatcher wanted to achieve the same thing, she’d be making a fresh run for office right about now). The Portland Vase (see left, being peered at in the British Museum by yours truly, circa 2010) gets its name from the Duke’s family, since his mother bought it from the British Ambassador in Naples. Don’t ask how he came to be selling in the first place, though!

Footnote 2: Portland installs an, er, “eclectic” mix of software that suits my needs -which may not suit everyone or anyone else’s. I’ll take comments/suggestions on what ought/ought not to get included, if it helps make the script as a whole more useful. Suggestions need to be in the repositories (and thus a yum install away), or easily obtainable with wget (which rules out Oracle and VMware Workstation, for example).

Footnote 3: The complete list of packages/applications Portland installs currently is as follows:
alacarte, alltray, ApacheDirectoryStudio-linux-x86_64-2.0.0, brasero, calibre-ebook reader, cheese, cuetools, dia, dropbox-0.7.1-1, dvd95, dvdbackup, easytag, eclipse, ekiga, evolution, gftp, gimp, gnome-games, gnome-games-extra, gnote, gstreamer-plugins-ugly, gthumb, guake, handbrake-gui-0.9.5-1, hardinfo, keepassx-0.4.3-1, libdvdcss, libreoffice 3.5.0, mencoder, mozilla-vlc, ntfs-3g, openjava, opera-11.61, pidgin, rhythmbox, rlwrap, shntool, sound-juicer, soundconverter, stellarium, thunderbird, transcode, transmission, tsclient, VirtualBox, xsane

Watch your bits!

Leave a reply

This is what happens when you start up a server with a Scientific Linux 6.2 32-bit netinstall disk and expect it to be able to continue with a 64-bit network installation:

The clue is buried in the error text: Exec format error means “you’re trying to execute a 64-bit executable when I was expecting 32-bit ones, so that format/bit-architecture is wrong”.

The references to “anaconda failed” and “backtracing /lib/lib.s.6″ are just red herrings, really, potentially diverting your attention from the real issue: You can’t mix your architectures. If your Kickstart Server is dishing up 64-bit distros, you need to boot with a 64-bit netinstall boot disk. Obvious, really, but I’d never accidentally mixed-and-matched before, so I never quite knew what to expect.

Now I do!

Look Ma! No network…

Leave a reply

I was installing some servers in Seattle recently, when I was informed that it was not company policy to allow their servers to have Internet access, of any sort, ever. This was a bit of a blow for me, because my Gladstone script (which I use to configure production Red Hat boxes as Oracle database servers) relies on being able to do various “yum install …” commands to get the software prerequisites correct.

It was irritating, though quite understandable -and we worked around the issue by giving me temporary access to the Internet, swiftly revoked once the installs were complete. But the incident made me realise that Gladstone’s reliance on Internet connectivity was misguided.

In fact, it’s never been strictly necessary for Gladstone to have Internet access at all: every one of the software prerequisites are available on the DVD installation media for RCSL distros, so it’s always been possible to install entirely from locally-available media. I used the ‘yum install’ method simply because it was easier: for one thing, it ensured all software dependencies were satisfied automatically.

Well, I have now resolved that particular issue.

My new Kickstart Configurator tool will now output a kickstart file which will perform a completely local installation (i.e., no Internet downloads) that nevertheless satisfies all Oracle software prerequisites. Of course, there’s still the Palmerston script which needs to be downloaded and run to finish things off in an interactive fashion, but if you download that ahead of time and store it on your Kickstart server, you can transfer that internally, still without recourse to the wider Internet.

Kickstart + Palmerston… perfect results every time, and not an external network in sight. My man in Seattle would be happier, I think!

Did I mention Palmerston?

Leave a reply

I have just released a new article explaining how to set up a Kickstart server as a way of achieving speedy, reliable and standardised RCSL server installations.

In some ways, it’s just a rather more Kickstart-focussed version of my existing ‘how to build an Apache web server’ piece.

However, it’s a little bit more than that, because it introduces two things:

The Dixnix Kickstart Configurator; and
Palmerston (the post-Gladstone shell script)

The Kickstart Configurator is just a little something I threw together to avoid the tedium of having to remember to alter the network details in a Kickstart file before re-using it. It will additionally do most of the Oracle prerequisites for you, if you ask it to.

Palmerston is simply a version of my Gladstone Oracle pre-installation script that omits the downloading/installing of software packages… because the Kickstart configuration script generated by the Configurator will have already handled all software prerequisites for you, if you asked it to. It also ditches all support for non RCSL distros, because only an RCSL user will ever be invoking it (everyone else will still be invoking Gladstone).

Together, they make building RCSL servers in general and Oracle servers in particular just that little bit easier. (Well, they do for me, anyway!)