Category Archives: Linux

DLNA and the Media Center of Doom

HDD RecorderIn my never-ending quest to rid the house of anything to do with Microsoft, I decided time was up for the Core 2 Duo, circa 2006, that had been doing Sterling service as our Media Center, first running Windows 7 Media Center and then upgrading to Windows 8 (plus the paid-for Media Center addition).

It’s worked quite well, but has occasionally hung (and inevitably, it hangs just when a really good TV program needs to be recorded). and exhibited other, sporadic and quite rare, weird behaviours. The PC itself was an old rack-mounted monster and was beginning to show signs of its age. All things considered, therefore, I felt it was time to put it out to pasture.

What to replace it with? Well, my first choice might have been another PC running something like MythTV… but ToH has to be taken into account, which rather rules out anything requiring more than an on/off switch, to be honest. I wouldn’t call myself a MythTV expert, either; and the one thing I know about it for sure is that it can be scarily complicated… so no thanks! Something more “consumer electronic good”-like, and less PC-ish. Something that just works. Something that doesn’t cost the earth.

Well, the picture at the top of this post gives the game away: after exhaustive minutes of online research, we bought a Panasonic DMR-HW220. It comes with WiFi built-in, plays MKVs, has a 1TB hard drive, twin HD tuners… and thus seemed to fit the bill perfectly, especially because it was only $340.

If only I’d read the small print (or the online reviews that spell it out!): whilst the machine is Wifi-aware, it has no concept of mapping network drives. It can’t see Samba shares. It’s network capabilities are, in fact, limited to acting as a DLNA server and/or client.

DLNA?? Someone of my age and upbringing probably thinks it’s a splinter Irish terrorist organisation, but in fact it stands for “Digital Living Network Aliiance”, and it’s a set of standards built around UPnP to determine how different electronic media devices play nice with each other. In my home media center context, it means that the Panasonic is a DLNA Client, and that means something on the PC has to be running as a DLNA Server (and Samba or NFS don’t count).

Immediately, therefore, things are more complicated than I’d like: how to run a DNLA server on the CentOS box that’s hosting all my movies, music and photos?

Happily, such a beast does exist and it’s relatively painless to set up: MediaTomb. I could also have installed miniDNLA, which works very simply, too. You can obtain it with a simple “yum install mediatomb” once the RPMForge repository has been added to your list of software sources. Once it’s installed, you need to start the thing with a service mediatomb start -and a chkconfig mediatomb on to make it re-start automatically at every subsequent server reboot. Once it’s running, do a service mediatomb status to find out what port it’s running on: by default, it’s 49152, but a status check will make certain.

Once you know the port, just fire up a browser and type in an address of http://<server IP>:49152 (or whatever port you’ve determined is in use). You should see a pretty bare-bones interface. Select the Filesystem link and you’ll see a tree-like representation of your server’s hard disk structure. Navigate to where your media files are then click the ‘Plus-in-a-Circle’ button on the top right:

mediatomb

Here’s where you get to mark a directory (and it’s sub-directories, if you tick that ‘Recursive’ option) for inclusion in the list of what this DLNA server can, er, serve. Scoot on over to the Panasonic, select the correct option to act as a DLNA client and… bingo! The appropriate directories are now browseable.

Erm… except that none of my MKV files were actually playable! I could certainly see them on the Panasonic, but they were greyed out. I checked the box: “MKV Playback” was definitely there in big, bold letters. So why my MKVs couldn’t be played, I couldn’t quite fathom. Until I read up on DLNA a bit more and discovered that MKV is not a supported container format for DLNA. Some clients can deal with them, but most can’t… and the Panasonic certainly doesn’t.

Had I read the ‘Cons’ column at the top of this product review before purchase, I don’t think I’d have bothered with the Panasonic at all, to be honest: “Can’t play MKV over network”. Plain and simple.

My plans to workaround this awful limitation consisted of copying my MKVs onto a USB hard disk, plugging that in and having the media play from there. Except that when you plug in a USB disk like that, you have to “register” it with the Panasonic device …which means “format” it, and with some sort of file system the likes of which none of my Windows or Linux boxes have ever met before. Once the Panasonic has touched the disk, nothing else can, basically. Too late I discovered that the ability to plug in USB devices is intended to get stuff off the internal 1TB hard disk by way of backup, but not to let you put stuff on to it via a PC, for example. DRM rears its ugly head, therefore, and makes an obvious way of media ‘injection’ non-viable.

(I believe that the on-box claim for MKV playback relates to the ability to play from an SD card. Not exactly what I had in mind, though).

At this point, I fear it’s obvious that I haven’t done my homework, and I am accordingly saddled with a machine which barely meets any of my functional requirements (it can record two TV channels at a time in HD, but that’s about it).

There is one saving grace: MKV is a container, not a video encoding. It’s therefore possible to extract the contents of an MKV and re-pack it in an MP4 container (which the Panasonic does play over the network, because the DLNA spec says it must), without any re-encoding effort. (That’s important, because with a couple of thousand video files to deal with, re-encoding is not an option!)

Various tools can do this re-packing trick: on my Fedora box, perhaps the simplest is Avidemux. You open your MKV, set the Video and Audio Outputs to “Copy”, select “MP4v2 Muxer” as the output format and then click Save. Done locally, a video file is thereby converted from unplayable MKV to playable MP4 in a matter of seconds. Done by pointing Avidemux to my network shares over the wire, however, and it takes a couple of minutes per movie… which is too long to be practical.

The obvious trick is to perform the re-packing on the server itself, for which a command line tool would be good. There is actually an Avidemux command line tool (avidemux3-cli, if you’re trying to yum install it), but scripting it is a nightmare and even invoking it file-by-file is a pain in the butt. So, in the end, I created this little shell script as a file called movieconvert.sh:

#!/bin/bash
SAVEIFS=$IFS
IFS=$(echo -en "\n\b")
f=`ls *.mkv`
ffmpeg -i "$f" -vcodec copy -acodec copy `basename "$f" .mkv`.mp4
IFS=$SAVEIFS

The …IFS… lines are there to deal with the fact that a lot of my movie files have spaces in their names, which would result in ffmpeg trying to convert files called “2001″, “A”, “Space” and “Odyssey” instead of a single file called “2001 A Space Odyssey” (which would be wrong, of course, and thus just lead to runtime errors). Otherwise, the main action is done by invoking ffmpeg with a bunch of switches which demand the video file be copied, not re-encoded, but re-packed as an MP4, not an MKV.

I stuck that in /usr/bin (so it’s in my path), and now I can cd to any directory containing a movie file and do ./movieconvert.sh and everything then just happens automatically. Sure enough, the Panasonic can play the MP4s just fine, too.

So we settle down for the evening to watch one of the movies I’d converted into MP4, and all was going swimmingly. Until suddenly a pop-up appeared informing me that a scheduled TV recording was about to start and therefore the DLNA connection would have to be terminated. What??? Yup. It turns out that you can’t record a program in the background whilst watching a film over the network. Which makes this particular Panasonic a piece of crapola that got taken back to the store that sold it the very next day. Happily, a full refund was received with not too many questions asked.

So what am I using now? Funnily enough, exactly the same kit that the Windows Media Center originally replaced: a Western Digital WD TV Live, which does movies and music very well, using plain old Samba shares to which it connects without drama. And for the live and recorded TV, a relatively ancient Topfield TF-7100 (now about 4 years old, upgraded by yours truly to a 500GB hard disk some years ago, still going strong).

The only pain points in going back to this arrangement are that it would require 4 remote controls (WD TV LIve, the TV, the receiver/amplifier and the Topfield). Happily, a Logitech Harmony all-in-one remote control takes care of that. Which leaves just one real pain-point: the TV listings in Windows Media Center are clear and speedy to navigate. The Topfield equivalent is hopeless, displaying just one channel at a time and taking an age to load or move through. A many-channels-at-a-glance view would be good, but no such beast exists. Not even the paid-for ICE TV gives what is needed. For the moment, I have no answer to this one, then.

Whether we persist with this retro setup, I can’t say. However, I can say that the Panasonic DMR-HW220 is completely hopeless -and, indeed, that anything relying on DLNA is not something I’ll be letting into my house again any time soon! I am really surprised that there isn’t a single box which can do dual-channel live TV, multi-channel recording, Samba connections, MKV and FLAC playback, with a decent, synoptic program guide. But as far as I can tell, there simply isn’t: and that seems a curious gap in the market at this stage of the game!

Building a Balfour Server

Arthur Balfour, Salisbury's nephewArthur Balfour was Salisbury’s cousin and succeeded him as Prime Minister of the United Kingdom in 1903 (which makes him our first non-Victorian PM to grace the name of an Oracle-related project in these pages!!)

His significance to this website is that he represents, as he did in real life, “Salisbury-lite”. That is, we know that a Salisbury Server provides DHCP, NFS, NTP, DNS and other network services to a growing Oracle-focussed infrastructure. Well, if you are setting up a disaster recovery site that is intended to run Oracle in Data Guard mode, you will want most of those same network services provided by a server that looks suspiciously like Salisbury, but which is local to the disaster recovery site. And that’s what a Balfour Server is: it’s a Salisbury server devoid of its DHCP capabilities (you only need one DHCP server on this sort of network, and then only during O/S installation), but otherwise performing a Salisbury-like role for two secondary Data Guard servers, rather than for the two primary RAC nodes.

1.0 Configuration

A Balfour Server therefore has exactly the same technical configuration as a Salisbury Server:

  • 512MB RAM
  • 60GB Hard Disk Space
  • Single CPU
  • One network card
  • One DVD drive

The big difference between Balfour and Salisbury is that Balfour only needs a single DVD drive -because by this time, Salisbury is already built and running and Balfour can therefore get its Kickstart script from there, rather than from a second DVD as Salisbury had to do. (In case it’s not clear, therefore: you can only build a Balfour server after you’ve successfully built a Salisbury Server, version 1.02 or above. The one depends on the existence and successful running of the other).

2.0 Construction

You construct a Balfour Server in what should, by now, be a familiar way. You’ll need the full installation media from your favourite RCSL 6.3 or 6.4 distro. It should really be the same distro as you used to build your Salisbury server in the first place (the point of a disaster recovery site is to mimic production as faithfully as possible, not to try and be different for the sake of it!)

I source my main DVD installation disks from the following ISOs:

Pop a burned copy of one of those into your new server’s DVD drive (or use the ISO direct if you’re working with virtual machines), power on and press <TAB> at the welcome menu.

As you might be becoming familiar with by now, Balfour construction consists of adding a correctly-crafted bootstrap URL to what now appears. In this case, your bootstrap URL is quite simple:

ks=http://192.168.8.250/balfour.ks

That is, you just point the new server over to the original Salisbury Server and ask for the Kickstart install to be governed by the contents of the balfour.ks Kickstart script.

Everything is automated after that. As is usual, if your hard disk has never previously been partitioned, you may be asked to re-initialize it, but otherwise there will be no prompting of you at all as the existing disk contents are wiped and replaced with a minimal server distro installation.

3.0 What you get

When you are prompted to reboot, and after the server comes back up, you’ll find that you now have a new server on IP address 192.168.8.251. It’s name will be balfour.dizwell.home. It will be running NFS and DNS servers, so is able to provide shared network storage to clients that ask for it, and is capable of acting as a DNS server if needed.

That said, it doesn’t want to be a DNS server at all: it’s /etc/resolv.conf still says that it should look to Salisbury for DNS lookups.It’s only there, in other words, should disaster strike Salisbury itself.

Balfour also doesn’t run DHCP, because one DHCP on this sort of Oracle infrastructure network is quite enough.

Similarly, it’s not an NTP server, just a client of Salisbury. But it’s capable of being a time server, should the need ever arise.

No Oracle software or software extras have been copied to Balfour, which is in any case not capable of acting as an Apache webserver. Balfour can provide networked storage to Oracle servers which need it, but it is not intended that it should provide much else to them.

To assist in subsequent administration and monitoring of the server, however, webmin and nmon utilities have both been installed. You can access webmin by opening a browser on a client machine and pointing it to http://192.168.8.250:10000. Nmon can simply be run by typing nmon at the console’s command line.

4.0 Conclusion

Let’s be clear that you don’t need to build a Balfour Server unless you intend to experiment with Data Guard in conjunction with your two-node RAC built using Salisbury Server technology. But if you do intend to go that route, then having an independt NFS Server that can host a copy of the database files that live on Salisbury’s NFS shares is pretty much essential. Building one is trivially easy: a quick pointer to the original Salisbury Server’s balfour.ks and you’r done, basically.

 

Salisbury

The Most Honourable The Marquess of Salisbury KG GCVO PCSalisbury is a method for correctly building Oracle servers, in standalone or RAC configurations, with minimal manual intervention.

You start by building a Salisbury Server -a sort of ‘seed server’, providing multiple network services to the rest of your network -including the Linux operating system to other servers as they are built.

With one Salisbury Server in place, you can then use it to construct other servers intended to run Oracle 11g Release 2, in either standalone (single instance) mode or in RAC (clustered) mode.

It’s a 64-bit only mechanism and only works for CentOS, Oracle Enterprise Linux and Scientific Linux versions 6.3 and above.

Full details on how to get the Salisbury infrastructure working for you are contained in a series of separate articles, as follows:

 

Building an Oracle Server with Salisbury

1.0 Introduction

Once your Salisbury server is built, you can use it to automate the construction of fully-functioning Oracle servers. Each Oracle server built this way will be running Oracle 11.2.0.1 or 11.2.0.3, depending on what Oracle software you placed in the Salisbury server’s /var/www/html document root directory. Each will also either be a ‘standalone’ Oracle server (that is, unclustered and not expected to run RAC), or a RAC server. Standalone servers built using Salisbury will have all Oracle software installed and a database created automatically as part of the build process; RAC servers will have the Oracle software copied to an appropriate directory, but nothing will be installed automatically. RAC Servers will, however, have environment and kernel parameters configured automatically.

By removing the majority of manual interaction in the build process, errors and inconsistency are eliminated, meaning that Salisbury-built Oracle servers will end up being more reliable, more predictable and more standardised than before.

2.0 Requirements

You’ll first need a completed Salisbury server, built according to the instructions in this article. It needs to be running and accessible over the network.

You’ll additionally need a 64-bit-capable server with at least 2GB RAM and 25GB of free hard disk space. Given that it’s going to end up running Oracle database software, more of both RAM and disk space is better, of course! (I’ll just mention that you can’t go much lower than 2GB RAM because the template database won’t be able to start by default if you do).

The bulk of the new server’s operating system will come over the network from your Salisbury server, but you need to first boot your server using an RCSL netinstall boot disk. These are relatively small (~200MB) DVDs that contain just enough software to get the proto-server communicating with the Salisbury server over the network. I source my netinstall disks from the following ISOs:

You need to pick the same netinstall distro/version as your Salisbury server is hosting. If you built a CentOS 6.3 Salisbury server, for example and didn’t copy across any other distro/version software (as suggested in Section 6 of the earlier article) then you can only create CentOS 6.3 Oracle servers and you’ll therefore need the CentOS 6.3 netinstall ISO. If you’ve got other distros and versions hosted on Salisbury, just get the netinstall ISOs that match what’s available.

By default, your Oracle server will be created with an IP address of 192.168.8.101 and with a hostname of Alpher. You will be able to specify different settings for these things, though, at boot time, as I’ll explain below.

3.0 Building a Standalone Oracle Server

You build an Oracle server by making sure the netinstall DVD is inserted in the server’s DVD drive and then powering on. You’ll soon be shown the distro’s welcome menu. When you see it, press <TAB>, and this will cause the bootstrap line to be displayed, like so:

Press TAB when the boot menu appears to display the bootstrap line

You now type a long URL string (with no spaces) on the end of this bootstrap line. The URL will specify :

  • Where to find your Salisbury server and its special kickstart file
  • What distro you’re using to build the Oracle server
  • What version of the distro you’re using
  • What hostname and domain name you want for the new server
  • What IP Address you want for the new server
  • What private IP Address you want for the new server’s interconnect
  • Whether the new server is intended to be part of an Oracle RAC or not

Taking each of these things in turn:

  • The Salisbury server location is provided in the form http://ip-address/kickstart.php. By default, Salisbury runs on 192.168.8.250, so this bit would then be http://192.168.8.250/kickstart.php.
  • The distro is supplied as a keyword/value pair, in the form distro=centos, distro=sl or distro=oel. No other options are allowed and all are specified in lower case.
  • The version is supplied as a keyword/value pair in the form version=63 or version=64. At the present time, no other options are allowed.
  • The hostname is supplied as a keyword/value pair in the form hostname=<something>. The “something” can be any name that would be valid for an RCSL server. If you don’t supply this parameter, the hostname will default to alpher.
  • The domain is supplied as a keyword/value pair in the form domain=<something>. The “something” can be any dotted notation that would yield a valid domain name for an RCSL server. For example (and what you get by default if you don’t supply this parameter), “dizwell.home”.
  • The IP address for the server is supplied as a keyword/value pair in the form ip=<something>, where “something” is any valid IP address. Please note that, at present, the netmask setting for a Salisbury-built Oracle server is assumed to be 255.255.255.0, so an IP address suitable for that should be supplied. For example “ip=192.168.8.101″ is valid (which is what you’d get by default if you were to fail to supply this parameter at all).
  • If you are expecting to run a RAC, your Oracle server will have two network cards and the ip=<something> parameter only sets the IP address for the first of them. You set the IP address for the second card by supplying the keyword/value pair ic=<something>, where the “something” is any valid IP address that correctly identifies the private interconnect network address. By way of example, ic=10.0.0.101 would be valid and is what you get by default if you don’t supply the ic parameter at all. In a non-RAC environment, this parameter has no meaning.
  • If you want an Oracle server that can run RAC, you would suply the keyword/value pair of rac=n. If you expect to run RAC, then you’d supply rac=y. If you don’t supply the parameter at all, “n” is assumed.

You must supply the distro and version parameters. All other parameters are optional, and if you don’t supply them, default values of various degrees of sensible-ness will be assumed. The first parameter is attached to the Salisbury server location by a question mark (?). All other parameters are attached by ampersands (&). The entire bootstap line starts with ks= to indicate that you are invoking a Kickstart installation of the Oracle server.

A minimal bootstrap line would therefore be of the form:

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

A complete bootstrap line for a standalone Oracle server might instead be of the form:

ks=http://192.168.8.250/kickstart.php?distro=oel&version=63&hostname=barney&domain=rubble.com&ip=192.168.8.10&rac=n

In addition to these parameters, you can also supply two space-separated parameters as follows:

  • ksdevice=<name of network interface>
  • oraver=<11201 or 11203, depending on which Oracle version you want installed>

The ksdevice parameter controls which of multiple network interfaces is used to establish initial connection to a Salisbury server. Usually, multiple network cards would be identified as eth0eth1 and so on. It’s that device name you supply as the parameter value. Usually, you’d want the first interface to be considered primary, so you’d most often say ksdevice=eth0. If your server only has one network card, there is no need to specify this parameter. If it has two and you don’t supply it, you will be prompted to declare a primary interface once O/S installation begins.

The oraver parameter specifies which Oracle version you want installed. It can either be 11201 or 11203. If you don’t specify, 11201 is assumed. You must, of course, have prepared your Salisbury server to have the relevant Oracle software files hosted there for this to have any effect. If you say oraver=11203 but haven’t copied the 11.2.0.3 files to Salisbury’s /var/www/html directory then you’ll end up with no Oracle software being installed at all.

Taking these extra parameters into account, therefore, a complete bootstrap line for a standalone Oracle install might look like this:

ks=http://192.168.8.250/kickstart.php?distro=oel&version=63&hostname=barney&domain=rubble.com&ip=192.168.8.10&rac=n oraver=11203

(Ksdevice has not been specified here because, as a standalone install, it’s unlikely that there would be more than one network card available).

Be aware of which keyword/value variables are supplied as part of the bootstrap URL (i.e., no spaces, separated from each other by “&”), and which are supplied as post-bootstrap URL parameters (i.e., space separated). Only ksdevice and oraver are space-separated.

This can sound quite complicated to describe, but after you’ve built your first couple of servers, you’ll find it comes pretty naturally! Here is the bootstrap line I’m going to run with for the rest of this article:

Bootstrapping a Salisbury-managed Oracle installation

Notice how the entire bootstrap line is allowed to wrap across multiple lines. Also note that the order in which you supply the keyword/value variables doesn’t matter: so long as you’ve supplied all the ones that matter, things will work just fine.

When you are sure your bootstrap line is correct, just press [Enter] and then go and have a cup of tea or something: everything else is automated from this point on. When you come back in about 30 minutes, everything will have been done for you.

There is one exception to this ‘go away and let it finish’ approach: if the hard disk you’re using for the new Oracle server has never been partitioned before, you may be prompted with this screen:

reinitialize

…in which case, you should opt to ‘re-initialize all’. If your hard disk does have existing partitions, though, they will all be blown away without you having to say so, and you really will have a completely automatic install from the moment you submit your bootstrap command. (Note that this means that Salisbury-managed Oracle installs don’t play nice with any existing partitions. They are simply wiped, no warning. You cannot therefore have Salisbury-built Oracle servers co-existing with any other partitions on your hard disks).

4.0 What Happens Next

Once you press [Enter] on the completed bootsrap line, and assuming you’ve said rac=n (or haven’t mentioned the rac parameter at all, which amounts to the same thing), here’s what will happen completely automatically:

  • Your Operating System will be installed in minimal, but networked, mode
  • All software prerequisites necessary for Oracle to run on your server will be installed automatically
  • SELinux and the built-in Firewall will both be disabled
  • An oracle user will be created (username=oracle, password=oracle)
  • All appropriate environment and kernel parameters will be set to correct/Oracle-recommended settings
  • A number of useful utilities will be installed for you, principally rlwrap, nmon and webmin.
  • The appropriate Oracle software will be copied across from Salisbury to an /osource directory on the new Oracle server. The zipped software files will be unpacked for you, so you’ll end up with /osource/database and /osource/grid directories.
  • Your Oracle database software will then be installed for you, completely automatically
  • The two post-install root scripts will be run for you automatically
  • A database creation script, called createdb.sh, will be written to the /home/oracle directory

Kickstart cannot create an Oracle database for you directly, because at this stage we’re still technically installing the operating system and are therefore in the wrong runlevel for that. But by creating the createdb.sh shell script for you, that step is enormously simplified too, as you’ll see.

The installation process will be complete when you see the normal blue O/S installation screen appear prompting you to reboot.

5.0 Post-Installation Steps: Database Creation

When your Oracle server comes back from its initial reboot, you can log on either as root (password=dizwell) or as oracle (password=oracle). I would suggest you start by logging on as oracle. If you do so and list the contents of your home directory, you’ll see this:

Post-installation directory listing

You’ll notice the existence there of the createdb.sh shell script. That can be invoked (as the oracle user) by issuing the command:

./createdb.sh

Doing that launches the standard Oracle Universal Installer -though as a command line application, rather than in its rather more usual graphical form (so no X server is required). You will first be asked to supply a password for the SYS user: you must type the password ‘oracle’ (without the quotes) at this point. You can always change the password later on, but if you don’t type oracle now, the database creation process will fail.

You will later be asked to supply the SYS password again, plus the password for the SYSMAN and DBSNMP users: those all need to be oracle once again.

Other than launching the whole database creation process and typing in oracle as the password four times, there will be no further input from you required. You will see the various stages of database creation scroll past on the screen, involving several database restarts. Don’t be spooked if you see messages such as ‘database not opened’ or ‘account locked’: these are all perfectly normal. So long as you get to the end of the whole process, where you see the message telling you that everything has worked OK, you’ll be fine.

At the end of it, you’ll have a fully-functional database called orcl. Connecting to it is as simple as firing up SQL*Plus and doing a standard connect / as sysdba.

6.0 Post-Database Creation Steps

In addition to connecting directly to the database with a tool like SQL*Plus, you can fire up a browser on a PC that can connect to your new server and visit https://a.b.c.d:1158/em. The ‘a.b.c.d’ bit there should be replaced by the IP address of your new Oracle server, of course. This is the URL for the Enterprise Manager database administration tool, which will have been installed for you automatically. If you like the idea of managing your database via a browser, this is the tool to use.

You will probably have trouble browsing to that URL, though, since the security certificate throws errors in most browsers. The basic principle is to use a browser like Chrome or Firefox that lets you select a ‘I know what I’m doing, please trust this certificate anyway, take me to this site’ option. I’ve documented that in a previous article.

Note that in SQL*Plus, when run directly on the server itself (or via a remote ssh connection to the server), you will be able to scroll up and down through your SQL command history. You can, for example, type select * from scott.emp;  then select * from scott.dept; then press the up-arrow key and step back to your original query. In this way, you can recall previous commands instead of having to type them out from scratch. This feature is also available in RMAN, the backup-and-recovery tool for Oracle database, courtesy in both cases of the rlwrap utility which Salisbury installs for you.

Operating System passwords can be changed by issuing the passwd command. Root changes his own password with just the plain passwd command; he changes anyone else’s password by adding the username to the command. So, for example, passwd oracle will let you change the oracle user’s password.

Database passwords are changed by issuing an appropriate SQL command, such as:

alter user system identified by somenewpassword;

The memory structures of the automatically-created database has been deliberately set to be quite modest (no more than 768MB, in fact). If you have lots more memory available than that, you can bump up the Oracle instance’s share of it by issuing these commands in SQL*Plus (as the SYS user):

alter system set memory_target=2g scope=spfile;
startup force

Obviously, you can set the memory_target in that first command to 3g, 4g or whatever other number makes sense for your particular system (you can also set it to things like 1400M or 2350M if you prefer using those sorts of units).

Having done that, though, it is possible that the ‘startup force’ command will fail with a ORA-00845: MEMORY_TARGET not supported on this system error message. If so, the cure is to drop to the operating system as root and issue the command:

mount -t tmpfs shmfs -o size=Xg /dev/shm

..where the “Xg” bit there is replaces by some number of Gigabytes of disk space that is at least equal to (or preferably a bit larger) than your memory_target value. If you’ve set memory_target to, say, 4G, then this mount command should have a size=5G setting (or maybe 4G, but definitely not 3G).If you want to set the size parameter to, say, 1550m rather than a ‘g’ number, that’s fine too.

The point is that Oracle’s memory target feature works because shared memory is mapped to physical disk space in the /dev/shm file system, so that file system needs to be sufficiently large to cope.

The mount command shown is dynamic and will give instant results (check by looking at the output of df -h and seeing what the size of tmpfs is listed as). To make a permanent change, you’ll need to edit /etc/fstab and change the tmpfs line to read something like:

tmpfs                   /dev/shm                tmpfs   defaults,size=3g        0 0

That size parameter (which can again be given in Ms, if you prefer) will take effect at the next reboot.

7.0 Conclusion

In this article, I’ve shown you how to use your previously-built Salisbury server to automate the construction of an Oracle server. That automation extends to launching the standard Oracle software installation process and completing it by running the two required root scripts. It also means that a shell script is created that when run, post-reboot, by the oracle user will cause a small, but completely functional, Oracle database to be created.

The hard part of the process is in invoking the Kickstart mechanism by constructing a valid bootstrap URL. I’ve shown you that this URL always starts ks=http://<ip-address>/kickstart.php? and that you then bolt on an ampersand-delimited set of keyword/value variables, followed by up to two space-delimited parameters. That sound slike a lot of variables, but remember that if you can live with the defaults, only distro and version are required, so it’s not that bad. After your first couple of servers built using this technique, I think you’ll find that forming a useful bootstrap URL comes relatively easy.

With any luck, you’ll find this the easiest Oracle install process you’ve ever encountered!

In fact, I hope you’ll find it so easy to build standalone Oracle servers with Salisbury that you’ll be seriously tempted to take the next step: build an Oracle RAC with Salisbury. But for that you’ll have to read another article entirely :-)

Building a Salisbury Server

1.0 Introduction

A Salisbury Server is a small, 64-bit server (512MB RAM, ~40GB HDD) that runs Apache, NTP, DNS and NFS network services and hosts a bunch of files, including:

  • The distro from which it itself was built
  • Oracle 11g Release 2 (or above) database installation software
  • MIscellaneous RPMs for generally useful software
  • A Kickstart file that is suitable for building Oracle servers

By making these available for sharing over a network, the Salisbury server enables other servers to be built in ‘template’ form. These other servers may run Oracle RDBMS software in either standalone or RAC mode.

Setting up a Salisbury Server is itself mostly automatic, because it too is built using a Kickstart file. The only thing that involves manual effort is to copy the Oracle RDBMS software to it (and name the component files correctly). Apart from that, a Salisbury Server is mostly self-assembling and provides a simple, lightweight way of pumping out standardised Oracle servers on-demand.

2.0 Requirements

To build a Salisbury Server, you will require Salisbury Build ISO, downloadable from this site (26MB).

You will also need the full installation media for one of the RCSL 6.3 or 6.4 distros. You can use Oracle Enterprise Linux, Scientific Linux or CentOS and I download my installation media for each of those from these sites:

As previously mentioned, Salisbury requires your server hardware to be capable of running a 64-bit OS, have at least 512MB RAM and have around 40GB of free hard disk space (I generally like to have 60GB, but anything in that sort of ball-park will do). Salisbury will wipe the hard drive completely, so don’t think it will be able to use some spare partition you might have available: you’ll lost all the data on other partitions if you do.

For the easiest build process, it would be useful for your server to have two DVDs: the O/S installation media goes in the primary and the Salisbury DVD (burnt from the ISO) goes in the secondary.

Salisbury runs well on a Virtual Machine (VirtualBox or VMware), so if you’re doing that, just make sure your Salisbury VM is created with two DVD devices, and assign the right installation media to the right device, like this:

Note how the CentOS ISO is in the first listed DVD and the Salisbury ISO is in the second. This is important, otherwise the VM won't boot correctly.

The Salisbury Server will be built to run on IP address 192.168.8.250. If that’s not a suitable IP address for you, you will need to extract the salisbury.ks file from the Salisbury ISO, edit it, then use ISO burning software to pack the entire set of Salisbury files back up again. The relevant line to edit is line 18. It is possible to change the hostname to something other than “salisbury.dizwell.home” by editing the same line, of course. All other network parameters can be altered at the same time (such as DNS servers and gateways). As it is supplied, the Salisbury server will expect to be its own DNS server and gateway: indeed, Salisbury has been designed to work in a completely self-contained environment (namely, my laptop), without any access to wider networks, including the Internet. In other words, Salisbury will work fine in a host-only virtual network environment (though real, physical networks are OK too, provided you get the IP address and other network details right before you begin).

3.0 Building a Salisbury Server

You build a Salisbury server by making sure the O/S installation media is in DVD 1 and the Salisbury DVD is in DVD 2, and then powering on. The standard boot process will take you to an initial boot menu. Once you see this menu, you press <TAB>. This displays what I will call from this point on the bootstrap line:

Press TAB when the boot menu appears to display the bootstrap line

You now need to type a single command which points the O/S installer to the Salisbury Kickstart file, stored on the Salisbury DVD. This means knowing the device name of the second DVD. In all the installations I’ve ever performed, that second DVD is known as device sr1. Therefore, you type this onto the end of the bootstap line:

ks=hd:sr1/salisbury.ks

The “ks=” bit tells the installer you’ll be using a Kickstart file to standardise this installation; the “hd:” bit means that the Kickstart file is to be found on a (hard)disk device; the “sr1″ bit means that the disk device involved is /dev/sr1, which is the second DVD device. The entire bootstrap line therefore ends up looking like this:

The complete bootstrap line required to build a Salisbury Server

Once you have typed that correctly, just press [Enter] and the installation process will start. If you have never used the hard disk before (such that it is completely unpartitioned), you will be prompted with this screen:

reinitialize

The correct response if you see this screen is to ‘re-initialize all’. If your hard disk has ever previously been partitioned, however, you won’t see even this screen: the O/S installation process will start and end without any further intervention from you. Generally, you can expect it to take 10 or 15 minutes, depending on your hardware capabilities.

4.0 What you get

When the Salisbury installation process completes, your server can be accessed as root, password dizwell. You might like to look around the server to see what you get for your 15 minutes. For example, these commands:

pgrep httpd
pgrep nfs
pgrep named
pgrep ntpd

…should all return results consisting of a bunch of numbers:

Checking which network services are running

Those are process IDs -and therefore you know that Apache, NFS, DNS and NTP servers are already configured and running for you.

Additionally, you should check the contents of Apache’s document root (that is, the place where files are stored if they are to be accessible from a web browser or other tool that is http-aware:

Initial contents of the Apache document root directory

You will see that quite a few RPMs have been copied here for you already; there are also some response files (for doing silent Oracle installs); there’s a kickstart.php (we’ll come to that later); and there’s also a directory called (in this case) centos. If I’d installed OEL or Scientific Linux, I’d see a directory called oel or sl respectively instead.

If you look into the contents of that directory, you’ll see a sub-directory called 63 or 64, depending on what version of the distro you used to install the Salisbury server itself. And if you drop into that directory, you’ll see that the entire contents of the original distro installation DVD have been copied here.

This means that your new Salisbury server is able to act as the source of the same distro software from which it itself was built. As you build client Oracle Servers, therefore, they will each be able to source their installation media from the new Salisbury server.

5.0 Adding Extras

Missing from your freshly-built Salisbury server is any Oracle software. There’s no way to automate getting hold of such software because of the heavy licensing restrictions around it, unfortunately. So the next bit you have to do yourself.

First, obtain Oracle 11g Release 2 software. Since the Salisbury server itself has no nice, GUI browser built in, I expect you will do this from some other PC to which you have access.

If you don’t have a paid-for support contract, you will need to download Oracle 11.2.0.1 database software from OTN. You have to use the 64-bit versions of Oracle, of course, and you’ll need to download the two “Oracle Database 11g Release 2 (11.2.0.1.0) for Linux x86-64″ files, meaning that you’ll end up with two files called linux.x64_11gR2_database_1of2.zip and linux.x64_11gR2_database_2of2.zip.

If you have a paid-for support contract, you can of course download 11.2.0.1 or any later version from edelivery.oracle.com. When I downloaded the 11.2.0.3 software, I ended up with two files called p10404530_112030_Linux-x86-64_1of7.zip and p10404530_112030_Linux-x86-64_2of7.zip.

If you are planning on using Salisbury to help build RAC environments, you will additionally need to source the Grid Infrastructure software. If you’re using freebie 11.2.0.1, that means you’ll end up with a file called linux.x64_11gR2_grid.zip; when I downloaded my 11.2.0.3 equivalent from edelivery, I got a file called p10404530_112030_Linux-x86-64_3of7.zip.

Whatever files you end up with, they all need to be copied over to the /var/www/html directory on the Salisbury Server and renamed. The re-naming is important, and has to be done to the following standard:

Database files end up being called oradb-1120x-1of2.zip and oradb-1120x-2of2.zip. The Grid Infrastructure must end up being called oragrid-1120x.zip. The ‘x’ in the two database file names there should be replaced by ’1′ or ’3′, depending on whether you’ve sourced 11.2.0.1 or 11.2.0.3 software.

The simplest way I know of getting the files onto the Salisbury server is with an FTP tool, such as Filezilla. You make a connection to port 22 on 192.168.8.250, logging on as root/dizwell. You should then navigate to the /var/www/html directory in the right-hand pane and simply drag the software files across from the left-hand pane:

Copying Oracle software to the Salisbury server with ftp

In this screenshot, you’ll see me copying both Oracle versions to the one Salisbury server. That’s because I often need to build 11.2.0.1 and 11.2.0.3 Oracle Servers, so I need both versions present on the Salisbury server for me to be able to do that. If you only host one version on Salisbury, you’ll only subsequently be able to build that version of Oracle server, of course.

Once the files have completed their journey, you can simply re-name them to conform to the naming standard I mentioned above (about which, remember, there can be no flexibility whatsoever).  A directory listing taken at this point of my /var/www/html document root directory therefore shows this:

Contents of the /var/www/html directory after Oracle software upload and renaming

I’ve highlighted the Oracle file transfers after they’ve been renamed. Once your Salisbury server is in this state, it’s ready for duty. You’ll rarely need to do anything to it ever again and can simply leave it ticking away quietly in the background. All the action at this point transfers to the job of building client Oracle Servers -but that’s something I’ll discuss in a separate article.

6.0 Optional Extras

As I say, you don’t need to do anything else to your Salisbury server at this point: it’s able to automate the creation of Oracle servers just as it is. However, you might want -completely optionally- to add a few more files to your server, to make it even more powerful.

In particular, I am thinking of the fact that your Salisbury server can only build other servers using the same distro as it itself was built with. In the case of the server I’ve taken screenshots with for this article, you’ll be able to see that I built it from CentOS 6.4 …and therefore all my Oracle servers would have to be hosted on CentOS 6.4, too.

If you like, however, you can issue this set of commands on the Salisbury server itself:

mkdir -p /var/www/html/centos/63
mkdir -p /var/www/html/centos/63
mkdir -p /var/www/html/oel/63
mkdir -p /var/www/html/sl/63
mkdir -p /var/www/html/oel/64
mkdir -p /var/www/html/sl/64

If you now mount each of the distro DVDs I linked to before you can copy their contents into the appropriate directory. Alternatively, you might use FTP to transfer the files across, if that’s easier for you. On my Salisbury server, for example, I’d do this:

umount /media
mount /dev/sr0 /media
cp -R /media/* /var/www/html/sl/64

…assuming that I’d inserted the Scientific Linux 6.4 DVD in the first DVD device before starting. Repeat as often as necessary with the various different distro/version DVDs. If you copy across the complete complement, your Salisbury server will end up storing around 25GB of software and can be used to build an Oracle server that’s using any of 6 possible distro/version combinations.

Copying all the distros this way is fairly slow and laborious -but the good news is: you only have to do it once!

If, that is, you choose to do it at all …because, remember, that this is an entirely optional step. If you have no need to experiment with Oracle on different distros, then feel free not to bother with this particular step.

7.0 Next Steps

Now that your Salisbury server has been built correctly, it’s ready to become useful! You’ll use it to create ‘cookie-cutter’ RCSL servers that are automatically configured correctly to run Oracle database and RAC software. In the language of Salisbury, these are “client Oracle servers”, and they’re the reason that Salisbury was created in the first place.

But I won’t describe how to create your client Oracle servers here. Instead, there’s a separate article for that.

8.0 Conclusion

In this article, I’ve shown you how to build an RCSL server using the salisbury.ks Kickstart file that’s stored on the Salisbury ISO. That build is entirely automatic and results in a standard, non-GUI RCSL server that’s already running a bunch of useful network services. Additionally, the server will be hosting a copy of its own distro that client servers can use to build themselves over a network.

By manually copying Oracle database and grid software over to the new Salisbury server -and remembering to rename the software files appropriately, you can also turn your new server into a tool that can automate the creation of client Oracle servers.

Finally, I showed you how you can optionally copy across the software from additional distros and different distro versions, so that your Salisbury server can be used to build client servers using any combination of distro and version you like. It’s an optional step, but a useful one for some.

Once your Salisbury server is ready, you can use it to automate the creation of client Oracle servers, as I describe in the next article in this series.

Salisbury, plain

salisburyWay 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)

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:

dynaks

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:

condit

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

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

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:

alpherks

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:

reinitialize

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:

postinstall

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:

oui

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:

finished

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.

line2

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…

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…