Tag Archives: Gladstone

Salisbury, plain

Way back in October last year, I announced that I wouldn’t be developing my Gladstone pre-installation script for Oracle any further, although the script itself would remain available (and it still is).

Back then, I promised a “son of Gladstone” replacement, “soon enough”. Little did I think it would take me six months to honour that promise! Such is life, I fear…

But Gladstone’s successor is now here… and, in keeping with (near) historical fact, that successor is to be called “Salisbury”. (That’s him on the right, looking suitably Victorian and bushy-bearded).

So, what exactly is Salisbury and how does he work?

Well, it’s a slight extension of the work I’ve been documenting in the previous dozen or so posts here: the idea of using Kickstart to automate the construction, the correct configuration and the Oracle software installation of Oracle servers. Additionally, it’s the use of a Kickstart-built server to supply all necessary network and shared-storage capabilities that Oracle Servers might need -especially if they run RAC.

In terms of tangible ‘product’, Salisbury actually consists of a single ISO download, just 27MB in size.

You use that ISO to kickstart the building of a Salisbury Server -a small server running RCSL that I’ve referred to in previous weeks as a ‘Linux toolbox’. Once your Salisbury Server is up and running, you use it to build your Oracle Servers. Those Oracle servers can run Oracle versions 11.2.0.1 or 11.2.0.3 in standalone or RAC mode. If you choose a standalone build, the Salisbury Server will automatically install the Oracle software for you, and create a simple shell script that will create a database when run post-install. If you instead choose to create a RAC-capable server, Salisbury will copy across all necessary software (and get users, groups, kernel parameters and so on correctly configured), but it won’t attempt to install anything automatically (because working out whether all the component parts of a cluster are up and running is a bit tricky!)

I present Salisbury here as, more or less, a fait accompli -but how it works and why are all things I’ve discussed in considerable detail over recent weeks, so if you’ve been following along, there shouldn’t be too many surprises (and if you haven’t, you can always step back to this post, which started it all, and read forward from there). I will try to pull it all together into a single, long article before long, though.

Building a Salisbury Server

The quick version of getting the Salisbury Infrastructure™ to work for you is this:

Build a new server with at least 512MB RAM and 60GB free hard disk space. Ensure it has two DVD drives.
Load your distro-of-choice’s full installation disk into the primary drive
Load the Salisbury ISO into the secondary drive
Boot your server and hit <TAB> at the boot menu. Make your build process Kickstart-defined by adding ks=hd:sr1/salisbury.ks to the bootstrap line.
Sit back and let the installation process complete.

Your new Salisbury Server will have only a root user account (password: dizwell). You can change that password with the passwd command, of course.

The Salisbury Server will automatically be a web server, complete with all sorts of useful files and packages which it can distribute to client Oracle Servers. However, the really important stuff is Oracle’s database server software -and, much as I’d like to, licensing restrictions mean I can’t provide that for you. Instead, you have to source that yourself, either from OTN (for free, but only at version 11.2.0.1), or from edelivery (if you have a proper, paid-for subscription and want to download version 11.2.0.3 or better).

However you source it, you should obtain both database zips AND the grid zip and copy all three files to the /var/www/html directory of your Salisbury Server (FTP transfer with Filezilla or a similar tool is probably the easiest way of doing that).

In their wisdom, Oracle Corporation saw fit to name their software multiple different ways, depending on how you sourced it and what version you’re dealing with. This is a recipe for Salisbury Confusion™ -but it’s easily avoided by renaming whatever you download in a consistent way, as follows:

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

Replace the “x” in those names to reflect the actual version in use, of course. There is no flexibility about this: the Oracle software components must end up being named in this way if the Salisbury Server is to be of any future use to you in building Oracle Servers.

By renaming files in this way, it’s perfectly possible to have one Salisbury Server be able to create both versions of Oracle database: just download all 6 files (the 11201 three and the 11203 equivalents), and rename them all according to the above-mentioned scheme. When both versions are possibilities, you’ll be able to specify which one to use for any particular Oracle Server at build time, as I’ll explain shortly.

So, after building your Salisbury Server, you just have to copy Oracle software to it (and rename it as appropriate), just once. After that, it’s ready for duty.

Note that the Salisbury Server build involves copying its own installation media to disk. If you build your Server using OEL 6.3, for example, then a /var/www/html/oel/63 directory will be created and populated on it automatically. Such a server can then only help build other OEL 6.3 servers. If you want to be able to build CentOS or Scientific Linux Oracle Servers, maybe mixing up versions 6.3 and 6.4 as the mood takes you, you can do that provided you create /var/www/html/centos/63, /var/www/html/sl/64 and similar directories yourself. The directory names have to be of the form /centos, /sl or /oel and the version directories have to be either /63 or /64. After creating any additional directories in this way, you can then simply copy over the contents of the full install media for that distro/version combination. Make sure you use the full installation media, not the “Live CD” versions. There is, however, no need to copy the second DVD into the directories where one is available: disk 1 will suffice.

Build an Oracle Server with Salisbury

Once your Salisbury Server is up and running, you can use it to construct new Oracle servers. An Oracle Server must have at least 2GB RAM and 25GB of free hard disk space.

You boot a new Oracle Server with the netinstall boot disk of your distro of choice. At the boot menu, you invoke the Kickstart process by pressing <TAB> and then adding a ks=<URL> string to the bootstrap line. That <URL> element will be formed from the following elements:

Salisbury Server’s IP address
kickstart.php filename
five possible URL variables
Two possible Kickstart parameters

It is assumed that your Salisbury Server has an IP address of 192.168.8.250 (if not, you’ll have to edit various files on the Salisbury Server itself).

The Kickstart filename is simply kickstart.php

The seven possible URL variables are:

distro (one of either centos, sl or oel)
version (one of either 63 or 64)
hostname (pretty much anything you like, so long as it’s a valid host name)
domain (pretty much anything you like, so long as it works as a domain name)
rac (one of either y or n, depending on whether you expect to be running a RAC or standalone database on the finished server)
ip (the IP address of the server, in a.b.c.d form)
ic (the IP address of the cluster interconnect, in a.b.c.d form, assuming one exists)

The two possible Kickstart parameters are:

ksdevice=<name of network interface to use initially, if there are 2 or more network cards present, such as eth0 or eth1>
oraver=<11201 or 11203, depending on which version of the Oracle software you want to use; can also be set to none to mean ‘don’t copy any Oracle software at all’… useful for second and subsequent nodes of a cluster>

You must supply a distro and version, but if you miss out any of the other parameters or variables, defaults will kick in. If you fail to supply an “oraver”, for example, 11.2.0.1 will be assumed; if you don’t say whether “rac” should be ‘y’ or ‘n’, a standalone, non-RAC installation will ensue, and so on.

At a minimum, therefore, you will initiate your Oracle Server build by typing something like the following at the bootstrap line:

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

A complete bootstrap line, leaving nothing to chance, would look more like this:

ks=http://192.168.8.250/kickstart.php?distro=oel&version=64&hostname=alpher&domain=dizwell.home&rac=y&ip=192.168.0.35&ic=10.0.0.1 ksdevice=eth0 oraver=11203

Notice that the URL variables are present as one, continuous string, begun with a “?”, separated by “&” and without any spaces. The Kickstart parameters, however, are supplied as space-separated keyword/value pairs at the end of the URL.

Of course, if you specify variables which imply software choices that your Salisbury Server does not have available to it, you can expect the Oracle Server build to fail. If you say oraver=11203, for example, when you’ve only stored 11.2.0.1 software on the Salisbury Server, then your finished server will have no Oracle software on it at all. If you’ve prepped your Salisbury Server to host all possible distro and Oracle versions, though, then you can specify any of the available options in whatever combination and expect a completely automated O/S and Oracle software installation accordingly.

Oracle Servers built via Salisbury will end up with a root user (password dizwell) and an oracle user (password oracle). You can change either or both of these passwords after installation, of course.

Non-RAC Oracle Servers will have a version of the Oracle software installed. No database will exist, but a createdb.sh shell script will have been created in the /home/oracle directory. Running that (as the oracle user) will result in the automatic creation of a database called orcl. SYS, SYSTEM and other administrative passwords will be set to oracle, but these can be changed using standard database commands at any time.

RAC Oracle Servers will have no software automatically installed, but an /osource directory will have been created, within which are database and grid directories containing the appropriate unpacked Oracle software. The software is therefore immediately ready for installation, whenever you’re satisfied that the entire cluster is up and running.

All Oracle Servers will be built with mounts of NFS shares made available by the Salisbury Server itself. There are two such mounts: /gdata and /ddata, which correspond to the Salisbury Server’s /griddata and /dbdata directories. Non-RAC Oracle Servers can just ignore the existence of these shares, but RAC Oracle Servers can make use of them during the Grid and Database software installs to store grid and database components on a shared file system. It is assumed that RAC Servers will use their own, local, non-shared file systems for storing the Oracle software components.

Both Salisbury and Oracle Servers can be managed remotely with Webmin (point a browser to it at port 10000). Both can also be monitored at the command line with nmon.

Oracle Servers will have rlwrap capability baked-in, so local SQL*Plus sessions will make use of it to provide a scroll-able command line history (that is, you can hit the up- and down-arrow keys in SQL*Plus to retrieve previously-typed SQL statements). Should anyone have ideas for what other software components would be useful to add to either the Salisbury or Oracle servers (or both), please feel free to drop me a line. If it’s useful and do-able, I’ll do it!

Note that both the Salisbury and Oracle Server builds are fatal to anything that might already be sitting on the hard disk of the servers involved: Kickstart is used to simply wipe all partitions it finds. Don’t point Salisbury at pre-loved servers that contain vitally-important data, therefore: you will lose it all if you do.

Conclusion

Salisbury is obviously a lot more complicated to describe than Gladstone! In practice, though, you should find it hands-free, highly automatic and, basically, a piece of cake to use.

The complexity arises because it’s an infrastructure, not a script -though it’s an infrastructure that bootstraps itself into existence courtesy of Kickstart scripts.

It depends on several version-dependent components, of course: Kickstart scripts designed for version 6.x RCSL distros won’t work with version 5.x RCSL distros, for example. Similarly, response files that perform perfect 11.2.0.1 Oracle installs blow up spectacularly when confronted with 11.2.0.3 software. I don’t expect Salisbury to cope with arrival of Red Hat 7 and Oracle 12 without a degree of pain, therefore! I do believe, though, that its underlying techniques and technologies are flexible and extensible enough to be able to cope as the future does its worst.

It’s taken quite some weeks to get it to this state: I hope someone out there finds it as useful as I have!

Known Issues

Date	Issue	Status
10th April 2013	Prerequisite failure in 11.2.0.3 (possibly 11.2.0.1 also) concerning compat-libcap1-1.10. This can be ignored, like all the other prerequisite failures, and the Grid software will still compile and install correctly.	Fixed
11th April 2013	RAC Install on 11.2.0.1 fails to start ohasd with “inappropriate ioctl for device” error. This is a known bug with 11.2.0.1 on 6.x distros, and the fix was documented in my earlier RAC-on-Linux article (see section 6). Fix must be applied before you run the root.sh script.	Workaround Available
11th April 2013	RAC on 11.2.0.3: both the Grid and Database installs fail at prerequisite check for ‘resolv.conf integrity’ (PRVF-5637: DNS response time could not be checked). This is a known bug: see MOS 1480242.1. The workaround is to click the ‘Ignore All’ button.	Workaround Available

Forthcoming Attractions

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

Fedora Glitch

Leave a reply

One of the consequences of tidying up Gladstone before his retirement has been the discovery that installing 11g Release 2 on Fedora 17 is a variable experience, depending on the Oracle version you’re using. This has revealed a bit of a stuff-up on my part regarding the sort of Oracle installations I do!

To explain: my standard advice when installing 11gR2 on Fedora 17 has been that you should expect to experience a linking error (relating to the $ORACLE_HOME/sysman/lib/ins_emagent.mk makefile). Gladstone knows this ahead of time and therefore writes out a little shell script (in your Desktop directory) which you can run the moment the linking error appears. As soon as it has completed its work, you switch back to the Oracle installer, click Retry …and everything will then complete successfully. A perfect installation in the end, then, with just a minor blip on the way.

However, it turns out that this advice is only true if you are installing Oracle 11.2.0.3!

If you are instead using the 11.2.0.1 version, the advice is wrong …because you will experience a completely different linking error much earlier in the piece. This one relates to the …ctx/lib/ins_ctx.mk makefile …and there’s no fix for it (not one I can work out, anyway). The only thing you can do when this particular error appears is to click ‘continue’ in the Oracle installer. The installer will then carry on linking everything else, bump into the “known” ins_emagent problem as before… and you can worked around that with the fix-up shell script previously described. Overall, you’ll experience two linking errors, only one of which can be fixed. You will therefore complete the installation, but you’ll be left with defective Oracle Text functionality, which may or may not matter to you.

Put it this way, then: if you’ve got paid access to My Oracle Support, you can use the latest version of Oracle and you won’t have an ins_ctx.mk problem. If you’re relying on the freebie downloads from OTN, though, you will.

I should have noticed this much sooner than I did. Trouble is, with access to the latest version of Oracle 11g, I inevitably got into the habit of using it when testing Gladstone, so I never noticed the big difference in the way the two versions behave during installation.

This is particularly bad on my part because, of course, the people most likely to be using Gladstone on non-supported Distros are precisely the people least likely to have access to the higher version. (Home learners, basically).

I should have kept “my audience” in mind, and stuck to working things out on the 11.2.0.1 version only, therefore… which is what I’ll definitely be doing in future. Apologies in the meantime: 11g on Fedora 17 will work, but only with slightly defective Oracle Text functionality and a willingness to accept the first of the two linking errors that result, without trying to fix it.

Gladstone Goodbye

Leave a reply

After nearly three years, I’ve decided that it’s time to say goodbye to Gladstone. I hasten to add, I don’t mean that the script itself will be disappearing any time soon: it’s still here, still available for download and isn’t going anywhere.

What I mean, though, is that I won’t be developing it any further.

In the past couple of weeks, I’ve tidied him up and tweaked all sorts of bits and pieces, ensuring that he works for correctly preparing assorted Linux Mint, Debian, Fedora, Sabayon, Ubuntu, Centos, Scientific Linux and Oracle Enterprise Linux distros for running Oracle 10g and 11g. As far as I know, every one works as intended (you may well have to click ‘ignore all’ on the Oracle Universal Installer’s prerequisite checks page, but actually everything under-the-hood is fine). I’ve even made sure it works with the latest Developer build of Ubuntu 12.10, so I can’t make it much more up-to-date than that. There are just a couple of instrumentation changes I want to make, probably by the end of the coming weekend, but other than that, I think he’s “done”.

Gladstone now therefore deserves a ‘code freeze’, because it’s getting harder and harder to make it work for new distros without stuffing it up working with previous ones. What’s more, it’s silly having to make sure he handles Oracle 10g installs when 10g itself is no longer available for download: that particular dead equine has long since been flogged past the point of useful reward. Additionally, trying to handle the imminent release of 12c in that mass of ancient and straggly code is going to take me way beyond where I am comfortable being, I think!

So this weekend will mark the point where gladstone.sh becomes ‘read only’.

I haven’t abandoned attempts to automate the process of preparing a Linux system for running Oracle, however. It’s just that I need something more maintainable, more modular, forgetting about 10g, but capable of doing 12c when it’s finally here.

Watch this space for ‘son of gladstone’, therefore, which will hopefully be along soon enough.

Gladstone, Oracle 11g and Sabayon

Leave a reply

It’s Gladstone as you’ve never seen him before: sporting a dashing new look in the form of my ‘Jaws’ progress indicator, which allows the various package installations taking place at the time to be done slightly more efficiently than before. Makes my code a bit easier to read, too, at certain points!

In addition, the thing which really gives a gleam to his eye is his new-found support for doing Oracle 11gR2 installations on 64-bit Gnome-based Sabayon. Large and very silly moustaches are entirely optional, therefore.

It’s not perfect: things start out a bit rough when Gladstone produces black text and Sabayon decides to use a black background in its default terminal windows! The result is like looking for a black cat in a coal cellar… and you’ll need to edit the terminal colour profile to something other than the default ‘white on black’ before you can get much further:

Before: and After:

No doubt there’s a clever way for me to auto-detect the colour scheme in use and react accordingly… but until I find out what that is, you’ll just have to deal with it manually!

Curiously, during the ‘software prerequisites’ installation stage, I found that any attempt to install the rpm package caused 580MB of downloads plus a metric crap-tonne of grief in being unable to reboot the PC once it had all finished. I accordingly stopped trying to install it… and its absence didn’t appear to faze the Oracle installation at all, whilst allowing everything else to behave perfectly normally. It reduced my Internet bills, too. It’s odd, since “rpm” is always mentioned as a pre-requisite for every Oracle install, no matter what distro you’re using. Clearly, it’s not that simple!

Anyway: once you get to the point of launching the Oracle Universal Installer, be prepared for it to complain about practically everything! It will even declare that appropriate OS users and groups haven’t been created (though they have). It’s the usual trick with the ‘Ignore All’ checkbox, therefore, and the OUI will proceed without drama:

Like most modern distros, Sabayon will cause linking errors to be thrown quite early on in the piece:

Gladstone will have prepared for this possibility by writing a ‘fix-linking-errors.sh’ shell script to your desktop ahead of time. Just find that file at the first linking error, double-click it and run it as yourself (not as root). After that, you should be able to click the Retry button in the Oracle Universal Installer and no further errors will then occur.

I must say that I really like Sabayon as a distro. It gets nearly everything right that I was looking for during my recent installfest. It’s polished and practical and runs everything I need it to do. In a contest between it and Linux Mint Debian Edition, there’s actually no contest at all: Sabayon knocks LMDE into a cocked hat, in large part because LMDE is using tricks like MAME to hold onto a Gnome 2 codebase (resulting in quite a bit of instability and all-round flakiness, in my view). Sabayon, in contrast, has fully adopted Gnome 3 (though KDE and XFCE versions are available). Though I despise Gnome 3 as a desktop, being on a ‘proper’ codebase does result in greater overall O/S stability, I think. Being able to run Oracle on it without too much pain is then just the icing on the cake.

If only I’d looked into it before Windows 8 was released to manufacturing…

I’ll close by mentioning that whilst re-jigging Gladstone to take account of all this new stuff, I realised that the old code contained a lot of howlers …bugs which ought to have caused anyone using it to install on such old warhorses as Centos or OEL to start beating a path to my door complaining about it. However, no such complaints were received… which makes me wonder if anyone is actually using it any more! If not, fine: I certainly do, and I’m its most important customer -but I could certainly do with more users/testers letting me know if things aren’t right. Anyone with a little patience and a big, fat, fast Internet connection is welcome to do lots of beta testing …and I’d be grateful for the feedback!

Gladstone Refresher

Leave a reply

Whilst the Linux Installfest pauses so that I can try out Fedora KDE, I took the opportunity to do a couple of things with Gladstone, the Oracle pre-installer -to deal with issues arising from me testing a bunch of other distros which I haven’t otherwise touched in a while.

First, Gladstone now works on Centos 6.3 and Scientific Linux 6.3. For some reason, I had forgotten to add these new point-releases to the list of “acceptable distros”. Now fixed.

Second, Gladstone now works on Oracle Enterprise Linux 6.3, using the free update repositories provided by Oracle Corporation. Thanks to Ales for hassling me nicely enough (via the comments pages hereabouts) that I felt it might be useful after all:

I have to say I have seldom installed OEL… and I can confidently assert that I am grateful for that, since my eyes would bleed if it were otherwise. Radioactive Red-on-White is the opposite of calm, soothing… or pleasant! Thank God it cools down quite nicely once the thing’s installed and you’re sitting at the Gnome Desktop! But anyway, Gladstone now does for OEL what it does with the other Red Hat Clones -though it assumes you’ve done a “Desktop” installation (Basic Server, the default, doesn’t come with any X or window managers, and Gladstone’s not going to plug that gap).

Third, I realised that whilst Gladstone claimed to work on Linux Mint Debian Edition (LMDE), and did actually do so about 18 months ago, it has been broken for quite a while, since it sought to download a version 18 library for gcc++ which is no longer available. I have thus refreshed the code so that the newest version of that library (version 25) is downloaded instead. Gladstone (and Oracle 11g) therefore works on LMDE once more:

Finally, I haven’t touched Ubuntu in a long while, so Gladstone has not worked on anything Ubuntu-ish since version 10.10, which is an eternity ago. Thanks to the installfest, that’s now changed, and Gladstone now prepares Ubuntu 12.04 for running Oracle 11g effectively:

The Oracle installations on both Ubuntu and Linux Mint Debian Edition both generate an error at link time, similar to the one experienced at the same point by Fedora. This is a feature of the way newer Linuxes do indirect linking. Gladstone deals with this ahead of time by writing a small shell script to your Desktop. When the linking error happens, you just launch that fix-it shell script (by double-clicking, as yourself) and then you can switch back to the Oracle installer and click ‘Retry’: the thing then sails through to completion without further trouble.

I ran into some interesting problems getting Oracle onto these…, er, “niche distros”, the principle one being that quite often their highly-convenient ability to install in ‘Live’ mode means that they don’t prompt you for everything that a standard installer might. Thus, I inadvertently ended up running LMDE with a DHCP-assigned IP address… which wouldn’t have mattered if the IP address used when Gladstone ran (and wrote into the hosts file) was the same IP address the box got assigned after its Gladstone-triggered reboot. Unfortunately, however, it wasn’t. The net result was that my Oracle installation failed at the point where it tries to start a listener …because it was trying to start it on an IP address which was no longer used by the server.

I’ve therefore added a couple of checks into Gladstone regarding networking. First, it checks you have a live Internet connection by counting packet loss when pinging Google: some packet loss is OK, but 100% loss makes it think no Internet connectivity exists at all and it therefore quits.

Second, it checks if you’re using DHCP. Now this is actually very difficult to do (especially if you try to make it work cross-distro). So difficult, in fact, that it’s actually impossible to do it reliably. You can check for the presence of various lease files, or the contents of various interface files… but no such check can be relied on 100%, especially since you can use tools like ifconfig to switch between a static and a DHCP IP address without causing the contents of those files to change at all. So, Gladstone cheats: it tests for the presence of a DHCP client process (dhclient), and if it finds it running, it will warn you and offer to quit. However, since it’s not a 100%-guaranteed test that DHCP was actually used to acquire your current IP address, you can ignore the warning and continue if you like.

Finally, I took the opportunity to tidy up a host of ‘quirks’. The thing is now a lot more consistent and less prone to flooding your terminal with irrelevant garbage messages.

Anyone experiencing difficulties with the script: let me know and I’ll see what can be done.

Fedora 17 and Gladstone

8 Replies

Somewhat scolded into action by the ever-so-slightly shrill demands of a well-meaning correspondent, I have given Gladstone a little love and attention. It now supports doing 64-bit Oracle 11g installs onto Fedora 17 (provided you’re sticking to a default OS install… I haven’t a clue if it works with a KDE desktop and don’t intend finding out).

There are known issues, as follows:

There is a lengthy pause whilst we install redhat-lsb in order to be able to correctly identify the particular flavour of Fedora in use. If you have a slow Internet connection, the script can sit there for a minute or two appearing to do nothing. Trust it and be patient!
You will be told that settings for two kernel parameters (shmmni and shmall) can’t be determined and that the public domain korn shell is not installed. You can safely click ‘Ignore All’, since none of these warnings are of any significance whatever. (The relevant parameters will have been set correctly, and pdksh hasn’t really been required for years) .
At the 70% installed stage, you’ll get an error message about a failure to link the EM Agents makefile properly. At this point, switch away from the Oracle installer and go find a file called fedora-linking-error-fix.sh sitting in the Desktop directory in the oracle user’s home. Run the script with the command: ./fedora-linking-error-fix.sh and then you can click the ‘Retry’ button back in the Oracle installer. Everything will then proceed without issue.
A feature of Gnome 3 is that the Desktop directory is a bit redundant (you can’t see its contents on the visible ‘desktop’, in other words). Worse, if you create a new user, a Desktop directory isn’t created for them by default in their home directory. Gladstone now, therefore, tests for the existence of this directory and creates it if it can’t find it.
There is zero support for installing Oracle 10g on Fedora 17. If you specify that particular combination, the script will simply warn you of your error and then stop. (Oracle 10g is no longer a supported RDBMS, even by Oracle Corporation themselves, after all!)
Fedora 17 thoughtfully(!) decided to alter the output of the ifconfig command, so the bit where it’s supposed to write the IP address and hostname to the /etc/hosts file couldn’t work with the original code. A modified version now deals with Fedora 17′s unique ifconfig output correctly. (For the record, in every other distro I can think of, ifconfig outputs results with the string inet address:w.x.y.z, which allowed me to use the colon as a delimiter to extract just the IP address components. Fedora 17 instead outputs inet w.x.y.z …no colon, and meaning I now have to use the ‘t’ of ‘inet’ as the delimiter. Let’s hope “inet” is “inet” in languages other than English: and apologies if not).
I’ve tested Gladstone with both the full DVD installation media and a hard-disk installation from the Live CD version of Fedora 17. Both work fine.

I’ve also taken the opportunity to add in support for Centos 5.8, Scientific Linux 6.2 and one or two other mainline versions that appeared to have slipped through the cracks. If I’ve still managed to miss any, let me know. I see Red Hat has recently released 6.3… I am guessing Centos and SL won’t be far behind, so a further update will be required then!

The modified Gladstone shell script is available from the usual place!

Did I mention Palmerston?

Leave a reply

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

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

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

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

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

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

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

A Phoenix?

Leave a reply

There was a time, and not so very many months ago, when it looked as if the CentOS project -producers of a binary clone of Red Hat Enterprise Server- was in technical and social/community disarray.

Red Hat released RHEL 6.0 on 10th November 2010; it took the CentOS developers until 10th July 2011 before they had an equivalent distro available. Red Hat had by then released RHEL 6.1 on 19th May 2011… CentOS achieved a clone of that only on 9th December 2011. There thus appeared to be a systematic technical inability to produce a clone except after a lengthy lag of six months or more.

Over on the social side of things, if someone dared make mention of the fact that the CentOS release dates were lagging the RHEL originals, with no transparency regarding progress or process, they generally got shouted at for their temerity. Not to mention little disasters like the lead developer going missing with the keys to the kingdom.

Meanwhile, Scientific Linux -another clone of Red Hat, this time produced by a small team of developers at places like CERN and Fermilab- appeared to be having no such technical or social problems, managing a 6.0 release on 3rd March 2011 (so, about 3.5 months after Red Hat’s original and four months ahead of CentOS), and a 6.1 on 28th July 2011 (2 months after Red Hat, 5 months ahead of CentOS).

Given these timelines, I don’t think it was much of a surprise that many people appeared to switch away from CentOS to Scientific Linux. I did myself, anyway -and am happily running a bunch of file servers, Oracle boxes, laptops, netbooks and my main desktop PC on SL6.1 as a result.

However, I was pleased (and a bit surprised, to be honest) to note that the CentOS team appear to have sorted out their technical issues, managing to produce a clone of Red Hat’s 6.2 release on December 20th, just two weeks after Red Hat released the original. That is one of their best ‘lag efforts’ since they were producing clones of version 4.x back around 2007. If it is indicative of a generally more capable, streamlined and efficient cloning operation that can achieve similarly effective results as future RHEL releases are made, I for one shall be very happy. And now the developers seem to have mastered the technical arts of cloning RHEL 6+, maybe they’ll become a little less defensive and much more transparent about the whole development process in the future. Fingers crossed, anyway.

As to the new distro itself… well, not really much to report there if visual bling is your thing: all the changes from 6.1 are under-the-hood things which may or may not make much difference to you, depending on the way you specifically use the OS. The introduction of asynchronous writes for CIFS (i.e., Samba shares), thereby improving the performance of network shares by maybe 200%, is pretty significant if you have Windows machines on your network, for example, but is not a new feature that is likely to set the world on fire otherwise. Loads of other such techie changes are listed in Red Hat’s original release notes. The bottom line, however, is that if you are happily running Scientific Linux 6.1, you aren’t missing out on anything particularly major as you wait for the Scientific 6.2 release (probably due in around March or April this year).

Anyway, it’s good to see the CentOS project apparently back in business in earnest, and hopefully it will stay that way for a long time to come. Personally, I’ll be sticking with Scientific Linux for a good while yet: it’s a more placid and predictable experience, I think! But it’s nice to know there are viable alternatives out there.

Oh, and incidentally, the Gladstone Oracle Preinstaller has been updated to work with the new Centos release.

Oracle Article

Leave a reply

As a follow-up to the article on building an Apache box is a new article explaining how you can use it to help automate the build of an Oracle database server.

The new article takes you from building a virtual machine, installing the operating system using Kickstart configuration files, running Gladstone to get all the Oracle prerequisites right through to getting Firefox displaying Flash properly and setting a fixed IP address.

Available in the usual place.

Apache Article

Leave a reply

I haven’t written a full-length article and published it for quite a while, but I’ve recently had some time on my hands and so have finally polished up a guide to creating a minimalist Apache server on Ubuntu. You’ll only need 128MB of RAM, VirtualBox and 15GB of free hard disk space to play along!

Available here.