Posts Tagged ‘Centos’

I’ve been slack.

When it comes to using Oracle-on-Linux, there’s only ever really been one game in town for me -at least, by way of habit over the past five years or so- and that’s Centos. As a compiled version of Red Hat’s own source code, with only a few logo changes to keep the trademark lawyers happy, it’s as close to running a “proper’ Red Hat Enterprise system as you can get without parting with large dollops of real cash. So it’s done the job admirably and I’ve never thus needed to look over the parapet and see what else might be part of the Oracle/Linux landscape.

I’ve never felt any great need or desire, in other words, to muck about with Oracle’s own Oracle Enterprise Linux (OEL). OEL is another of those ‘clones of Red Hat’ along the exact same lines as Centos, Scientific Linux, Tao Linux, Lineox and many, many more… except that it’s provided by a Megacorp and not a band of disputatious volunteers. It also happens to be a supported OS for Oracle installations, whereas Centos is not. So, in a fair fight between Centos and OEL, those two points of differentiation might very well make you think OEL just has the merest smidgen of advantage over Centos. However, to install Oracle on Linux, you tend to need to install rather a lot of ‘prerequisite’ packages -and the quickest, easiest, most convenient way of doing that is to do a few yum install commands. Yum only works, though, if you’ve got access to the required yum repositories. Centos makes a fist-full of such repositories available for zilch… and (the show-stopper) OEL requires that you part with hard cash before you can start downloading patched and upgraded software.

It’s this fact that Centos can yum for free whereas OEL cannot that has tipped the balance for me hitherto: no matter that OEL is supported and backed by the same company that makes the database software you want to run on it, Centos is about AU$144 cheaper to use, which makes all the difference in the world!

Except that that’s not true. In fact, as far as I can tell, it’s not been true since about March 19th this year, when Oracle made available several yum repositories for OEL, completely free of charge. I didn’t notice it at the time, even though people like Frits Hoogland wrote about it then; and as I said earlier, as a happy Centos user, I’ve not had occasion to notice it since! A freely-available yum repository, however, makes all the difference: if you can download what you need for a successful Oracle Database installation on OEL for free, why wouldn’t you use it rather than Centos? I know I would! And indeed, from this point on, that’s exactly what I’ll be doing: OEL becomes the distro of choice chez Rogers for running Oracle databases and goodbye Centos.

There are still just a couple of gotchas with OEL to mention, however.

First, the Oracle yum repository does not supply patches and upgrades to software: it’s really not much more than an online version of the installation DVD.So, if it’s not on the original installation media, you can’t get it via yum. That means you can’t install the latest versions of (say) Firefox via yum. Rather more seriously, if a major security vulnerability is ever found in a program that was supplied on the original installation media, you won’t be able to patch the program to fix it. For that sort of capability, you really do still have to pay Oracle some money and join the Unbreakable Linux Network (or stick to running Centos, I guess!) An Oracle installation on completely-free-OEL, therefore, is not something you’d want to do in a production environment, but for disposable self-learning environments, it’s just fine.

Secondly, OEL ships with no yum repositories enabled by default. So, before you can start yumming, you have to manually add the Oracle freebie repositories to the yum setup yourself. You then have to edit the relevant configuration file to make sure the right repositories are enabled and the wrong ones aren’t. Additionally, you have to switch off the ‘gpgcheck’ functionality for the repositories, otherwise yum will only ever complain that you’re trying to make it download software that’s unsuitable for the platform it’s running on and never actually get around to downloading anything.It’s all rather more complicated than Centos, which has a fistfull of enabled repositories by default, all of which work without manual reconfiguration of any sort. However, because I can’t find a way of telling whether you’re running Centos, real Red Hat, OEL or any other of the Red Hat respins (the /etc/redhat-release file is not a reliable indicator, for example, and I don’t have confidence in the /etc/enterprise-release file always being a sufficient differentiator, either), I’ve had to rejig things a bit on the GOAL download page to accommodate these changes: OEL, basically, gets its own , unique download script, complete with cute (ish) armoured penguin icon -and if you run that OEL-specific GOAL script, everything yum-wise gets configured for you automatically. The eventual Oracle installation then just sails through to completion without a problem.

Anyway: I have been slack and rather “out of it” of late, but I’m ‘with it’ now!

I really do like Citrix’s XenServer, despite my moaning earlier about it’s barely-functional snapshotting capabilities.

Rather more disappointing is the fact that it’s completely floored by the arrival of a new distro version. Specifically, there is (understandably) no ‘template’ for Centos 5.4 -and if you try using the supplied template for Centos 5.3 hoping to slip in the incremental release without too much fuss, you’re in for a big disappointment: the virtual machine loses contact with its source DVD and demands a driver be supplied before it can continue reading from it. No such driver can be supplied, so that’s the end of that. Using a template for an OS installation is important, because it allows the VM guest to be properly paravirtualised. If you try and cook your own (using the Other Install Media template), the installation will succeed, but you won’t benefit from a properly xen-ified kernel and hence performance of the VM will be sub-optimal (posh language for ‘pretty crap’).

The only mechanism I’ve really got to work, in fact, is to create a new VM using the Centos 5.3 template, install Centos 5.3, and then do a yum update so that Centos itself takes care of the business of migrating to version 5.4. No problem if you have unlimited downloads on your broadband link, I suppose… but not exactly an ideal way to go.

I would hope that Citrix would regularly release new templates that could be downloaded and installed… but their forums are full of dark talk of ‘wait until the next release of XenServer next year’. That seems a crazy way of going about things. Despite having put XenServer into production use at work, I think I am going to have to re-evaluate it if it can’t do snapshotting or new distro upgrades properly.

Yesterday, Centos 5.4 was made available. Visually, there’s nothing at all to distinguish it from 5.3, but quite a lot of low-level changes have taken place under the hood (as you might expect). That always raises the spectre that Oracle won’t work on the new release, of course.

Well, my GOAL script has had to be changed very slightly, because it used to check only for version ‘5.3′. It now checks for ‘5.3′ or ‘5.4′, so the revised version now works as intended.

After that, it’s plain sailing: 10.2.0.1 installed without a problem, and upgraded to 10.2.0.4 smoothly, too. I also installed 11g Release 2 via GOAL, and similarly encountered no dramas whatever. So the increment to the distro release number really doesn’t make any difference at all to the subsequnet Oracle experience, which is good news, I guess.

I mentioned last time that Citrix Xen Server was incredibly fast and easy to setup, but a bit of a pain to use, practically, because the Centos VM I created on it insisted on running in strictly command-line mode only. All true enough… but a GUI is do-able, and here’s how I did it.

First, I read the available documentation! The relevant bit is here, which references a bit about installing guest agent software, which is documented here.

The basic outcome is that, in console (text) mode, you install the Xen Agent software for VM Guests first (that’s into the Centos 5.3 x64 virtual machine I’d already built in text mode, of course). You do that by logging on as root at the console, switching  the DVD selector so that it reads xs-tools.iso and then typing the commandmount /dev/xvdd /mnt. You’ve just effectively inserted the Xen Tools CD into your virtual CD-ROM.So now you can launch the relevant installer off that virtual CD by typing the command /mnt/Linux/install.sh. Say ‘yes’ when prompted and then reboot the virtual PC.

Next, you need to edit the Centos virtual machine’s /etc/gdm/custom.conf file (remember, I only deal with Centos 5.3 these days: the file is different for Centos 3 and 4 versions). I edited that file to contain the following:

The [servers] bit is already in the file, but everything else has to be typed in, using your favourite text editor (nano in my case). The command= line continues without a break all the way through to the end -BlacklistTimeout 0 bit. The ‘flexible=true’ stuff is a new line in its own right.

With that file changed and saved, I then had to switch off the Centos firewall -something I’d normally do automatically in a GUI OS install, because the installer prompts you. But in a CLI environment, you have to take that step yourself. Logged in as root, type the command system-config-securitylevel-tui and -using your skill and judgement- press whatever combination of TAB, Space Bar and ENTER switches off the firewall in its entirety. You should also set SELinux to at least permissive if not outright disabled (because Oracle doesn’t interact with SELinux very well). Note that if you set SELinux to disabled, you should reboot the VM so that the new setting can take effect. If you set it to permissive, a reboot is not required.

Finally, you can now launch the Gnome Desktop Manager by simply typing the command gdm. If for some reason it’s already running. just ype  /usr/sbin/gdm-restart instead. In either case, you should see the Switch to Graphical Console button light up in the Xen Management tool on your Windows client PC. Click that, and you’ll be rewarded with  graphical Centos login screen -and a short while later, the glory that is this:

You will note from that screenshot that I’m busy running the Goal script for automated Oracle installations… which gives you a clue that Oracle on-Centos-on-Xen is a piece of cake. And which might, I suppose, be the subject of another post or several in the coming days! (It completes in 19 minutes, which as these things go is pretty darn’d quick, and very close to physical PC installation times. Impressive).

I have to say as a parting note that it’s a shame that Citrix Xen makes having a graphical Centos experience a matter of editing a couple of textfiles and keeping your fingers crossed. But I cannot fault the fact that it is a matter of typing just one or two commands and then the pain is behind you. Given the capability of this software, and its extraordinary price of US$0.00, I can live with it -especially as there are so many other redeeming features!

It’s been a “long weekend” here in Sydney: today is a public holiday (though the occasion for it escapes me… perhaps something to do with Labour Day? Who knows!)

I’ve spent most of the day finalising my server setups. Now that my new desktop has arrived, my old quad core becomes The Other Half’s PC, and TOH’s old PC becomes my new ’spare server’. It’s not bad as these things go: dual core Core 2 Duo, 3GHz, 4GB RAM, 1TB hard disk space. So I thought I’d try a bit of free (as in zero cost) bare-bones virtualisation and see how I got on.

I started with Citrix Xen Server 5, then Citrix Xen Server 5.5 (the current release). I moved on to Vmware’s ESXi 3.5 and then Vmware’s ESXi’s 4.0 (again, the current release). I tried Hyper-V (Microsoft’s offering in this virtual space). And I wrapped up with a dabble with Oracle’s own VM-Server, version 2.5.

I’ll save the gory details for a later post, because it’s worth doing a proper side-by-side comparison of these things. But the short story is: Xen Server 5.0 installed extremely well, but when trying to create a Centos 5.3 x86_64 virtual machine, the Centos installer lost contact with the Xen Server’s DVD drive immediately after booting, rendering further installation impossible. Call that the deadest of dead-ends, then! This didn’t happen with the more recent Xen Server 5.5, however, and I was therefore able to install the Xen Server, its Windows client tools and create a Centos 64-bit virtual machine in precisely 27 minutes flat… which is amazing, I think, as these things go (especially as I was cooking dinner at the time). The only slight problem was that the Centos installation refused to install graphically and subsequently refused to run X at all… so it was a command-line only affair. That’s not the end of the world, of course, since it’s possible to run an X server on your Windows machine and have a graphical experience of a console-only virtual machine. But it’s not ideal.

ESXi Server was an extremely quick install, but it’s another 100MB download to get hold of the Windows remote administration client which is mysteriously called V-Sphere …and which, as it turns out, doesn’t actually run on Windows 7! There are workarounds: they involve downloading a dll which could contain absolutely anything from a website whose trustworthiness you have to take on, er, trust. And then you have to hack around a few XML files and keep your fingers crossed. Eventually, it does all work, but the experience is deeply, deeply nasty and not one I’d recommend.

Hyper-V was a success, in the sense that I had a working Centos 5.3 virtual machine within an hour and a half… but the graphics were all messed up, with the Centos machine needing to be set to an 800×600 display before it would display correctly on an old 1280×1024 monitor. Set it actually to display at 1280×1024 and it looked more like 3856×1900… very, very large and unusable! If you didn’t mind working in a tiny screen, or forever scrolling around an enormous one, I suppose you could call it workable. But yet another download (this time, 200MB+) was needed to get the Remote Server Administration Tools for Windows 7 installed… only then to discover that no matter what one did, you just kept being told that you lacked the permissions necessary to administer the virtual server. Apparently, if you faff around with assorted Group Policies and DCOM permissions, you might get it all working, but I never did. So, if you don’t mind running everything direct off the virtual server itself, no problemo. But if you want to manage it from your Windows 7 desktop, forget it, basically.

Oracle’s own virtualisation server was slick enough… but incredibly fiddly to use, with the need to pre-provision everything (such as the Centos installation disks) made incredibly difficult. (Think of it like having to pre-declare all your variables before being allowed to use them!) It doesn’t help that there’s still no Windows client software for remote administration of the virtual machines: so you’re reduced to creating a virtual Linux machine on your Windows desktop so you can administer a virtual Linux machine on your Oracle VM Server! Pathetic, to be honest, and far more trouble than it’s worth. Especially since installing the ‘client’ software involves an incredibly adventurous and lengthy install of a complete Oracle XE database server, plus a mountain of Oracle Application Server componentry. I kept seeing visions of sledgehammers and nuts, to be honest. After all that, there’s not even the facilty to just say, ‘please install from the DVD what I’ve just installed in the Virtual Server’s physical DVD drive’. Oh no. Nothing that simple. Various import options are available to make an already-obtained ISO usable as a VM installation source, but none of them worked for me. My server just sat there, promising me mountains of virtual pleasure, but denying me any of it. Meanwhile, I’d been forced to create an additional amply-apportioned virtual server simply to act as the managing remote client for the server I’d intended to create. Bizarre in the exteme.

Short story, then: Windows Hyper-V works, but remote administration is a bugger. Xen Server works incredibly simply, swiftly and elegantly…but without X, it’s a more complex command-line only experience (update: but this can be fixed!). ESXi is OK, but seems fiddly, and doesn’t have a good Windows 7 client. And Oracle’s own Virtual Server offering is a complete load of unmanageable nonsense as far as I’m concerned.

A detailed write-up to follow, in other words. Meanwhile, a lot of fun, even more frustration… and some surprising outcomes. (I had expected Oracle’s offering to be a lot more elegant than it was, for example!)

I’m not sure how long this has been necessary, but Windows 7 appears to have broken Samba. Maybe Vista did it before; maybe it’s been this way for a long time. Sharing a Windows share to a Centos machine is not something I’ve done a lot of lately, so I can’t say for sure. But this evening, I wanted to install 10gR2 on my new Centos 5.3 x64 machine -when you buy a new PC, your original PC becomes The Other Half’s PC, and TOH’s PC becomes a new Centos server. And then the music stops! The 10g installation software is now sitting on my Windows 7 file system, shared with one of those Microsoft wizard-y things. Over on the Centos box, I typed the straightforward command mount -t cifs -o username=dizwell //10.42.43.2/software /mnt. Pretty ancient stuff, and it’s always worked before. But not tonight. Tonight I was told:

mount error 12 = Cannot allocate memory
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

Well, if I’d taken the advice offered by that error message, I might have been there a long time! Because it turns out it’s not a cifs (the ‘proper’ name we give smbfs these days!) issue at all, but a Windows one. Specifically, it turns out that if you look at your Windows event log (easier said than done in Windows 7!! It’s buried away in Control Panel -> System and Security -> Administrative Tools -> Event Viewer), in the Windows Log -> System branch, you’ll see the red exclamation-marked Error with a source of “srv”. Drill into that, and you’ll see the message:

The server was unable to allocate from the system nonpaged pool because the server reached the configured limit for nonpaged pool allocations.

The fix for that is to fire up the Registry Editor (click the Start Orb, type in regedit in the search programs and files window and press Enter) and navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanServer\Parameters. Once there, I had to create a new DWORD (32-bit) Value, called IRPStackSize, setting its value to Decimal 15. Reboot the Windows machine at that point, and when it comes back up, exactly the same mount command as issued previously on the Linux machine will now work just fine.

Update: Google reports this same issue going back to at least 2006, so it’s definitely not new. I also found there reports that suggested it was the reboot of the Windows box after the registry change that was the key to the “fix”, rather than the registry change itself. And I also found this site suggesting a completely different registry fix for the same problem. The fact that two different registry entries appears to ‘fix’ the problem does suggest to my mind that it’s the reboot that’s the key, not the registry alteration, but that’s up in the air I guess. For the record, my LanmanServer\Parameters\Size key was set to 1 and remained so despite my change to the IRPStackSize value, and yet my mount command worked just fine second time around. Go figure!

Thanks to a nasty bout of ‘flu-like symptoms, I have been able to experiment with Goal (my graphical oracle all-in-one loader script) and the new 11g Release 2 rather sooner than I was expecting to be able to. I am running a temperature and feeling pretty bloody awful, so apologies if this is not quite as polished and coherent as it should be!

Now, you will remember to start with that Goal seeks to do just one thing: install 64-bit Oracle onto 64-bit Red Hat 5 (or Centos 5 or Oracle Enterprise Linux 5 or any exactly-equivalent recompilation of Red Hat source code). Just so we set expectations suitably low!

The good news is that a new version of Goal is now available which allows for 10g Release 2, 11g Release 1 and 11g Release 2 installations and which works almost perfectly (I’ll come to explain that “almost” in just a moment!) The kernel parameters required for an 11g Release 2 installation have changed significantly since 11g Release 1 days (so when other sites simply re-badge their 11gR1 articles without changing the actual content, be warned!), so that’s why Goal has to allow for two different types of 11g installation: the settings for 11gR1 would be inadequate for 11gR2 and cause the installer to stall you on a page warning of this fact. Anyway, I’ve gone through the official documentation and made sure that Goal sets the recommended values for all the assorted kernel parameters, old and new.

I have, however, encountered what is perhaps 11gR2’s first bug! The documentation (at Section 4.3) clearly says that for Red Hat 5 (and hence Centos 5, which is what I was using), one of the required prerequisite packages is ksh-20060214. I don’t have a problem with that: Goal does actually download and install the package ksh, which is close enough. The bug, however, is that the installer will insist that you don’t have the package pdksh installed. Which is true enough: it isn’t installed because the package doesn’t actually exist in the RH5 repositories! Pdksh is a published requirement for Red Hat 4, however, not Red Hat 5… so it would seem that the installer has been written to deal with both RH4 and RH5 installations with the unfortunate consequence that it demands the installation on RH5 of a package which actually should be demanded of an installation on RH4.

The long and the short of this is that it seems impossible to go through Oracle’s 11gR2 installer wizard without being told at one point that you have failed to install a required package… even though it doesn’t exist for RH5 and even though the documentation itself makes it clear it is not a required package on RH5 at all! It would be nice to have a 100% flawless installation wizard, but this “issue” prevents that from happening -and there’s nothing Goal can do about it. I believe that if you are using “proper” distros (such a true Red Hat Enterprise Server 5 or Oracle Enterprise Linux 5), rather than cheap clones such as Centos, this problem goes away. I have to do some more testing to determine that, though.

Anyway, in the meantime, it’s possible to simply click the ‘Ignore All’ checkbox at this point, and the installation will proceed despite the “missing” package.

And it will proceed smoothly, without errors or alerts about ‘error in invoking target install of makefile such-and-such’. The whole thing succeeds completely, in other words, and without fuss or bother.

Hooray. At last, 11g Release 2 is available for download (and, interestingly enough, for Linux first… and currently only!). Go here if you want it.

It’s been a long time between releases. Much longer than, for example, between 9iR1 and 9iR2 or between 10gR1 and 10gR2. Or maybe it just feels that way! Anyway, 11gR1 was a bit of a dog in my not-so-humble opinion: polished, certainly, but with a curious lot of bugs, too. I’ve certainly kept work at 10.2.0.4 for quite a while, simply because I wouldn’t touch 11g with a long bargepole. But now that release 2 is out, it may be worth re-checking the state of play. Experiments begin at once, of course!!

The first thing that will trip up the unwary is that 11gR2 comes in two parts. That is, there are two zip files to download, each about 1GB big. You need both. What’s more, you need to unzip both into the one database directory before you can use the resulting uncompressed file structure as an installation medium. If you’re using my instructions on how to create ISO images from OTN downloads, for example, you’ll need to do the following:

• Download both zip files to your desktop
• Open a command prompt and unzip the linux_11gR2_database_1of2.zip file. That will create a database directory.
• Now unzip the linux_11gR2_database_2of2.zip file. The contents of this file will be extracted into the already-existing database directory.
• Now you can create your ISO image from the Desktop/database directory, using the command I documented before:

genisoimage -o Desktop/ora11gx64.iso -R -J -hfs Desktop/database

After that’s all done, you’ll be able to burn the ISO to disk as per normal… and then you’ll want to install it onto something!

As far as that goes, I am happy to report that Doris works fine with the new release, provided you’re running on Centos/Redhat/OEL (that is, I haven’t tested anything else). She gets invoked as per normal (i.e., as root from a login shell (so su – root to start with) and then something like ./home/hjr/Desktop/doris1.1g.sh redhat5 11g). The installer sports a radically new look:

…and she’ll complain that various parameters aren’t set correctly and that assorted packages aren’t installed. But if you select the ‘Ignore All’ check box at that point, the installation will nevertheless complete successfully. The path created for the installation by Doris is wrong, of course (11.1.0, rather than -say- 11.2.0), but don’t let that little detail stop you either. Additionally, you’ll get an ‘error in invoking target install of  makefile … ins_ctx.mk’. You can ignore that, too (and I’ll work out what’s causing it and write a proper fix before too long). The point is, you end up with a fully-functional system-plus-database in less time than it takes to make a wallaby drink a cup of coffee.

I haven’t tested Goal yet, because I can’t currently access a 64-bit Centos/Red Hat machine… but I’ll obviously be checking ASAP (and posting back as required!)

Note that there will be an extremely long pause, with nothing very obviously happening, at the point where the installer hits the ‘Oracle Database configuration’ installation item. Just be very, very patient and you’ll eventually be rewarded with the usual sort of ‘create database’ progress bar. But it does take an awfully long time to appear!

I’ve been quite proud of Doris, the ‘Dizwell-Oracle Installation Script’: she was my first attempt at a complex Bash script that would do something useful (namely, help automate the process of preparing a Linux box to be able to run Oracle database software). She worked quite well, too (which is probably the main thing!): downloading the correct software dependencies, creating database auto-start scripts, setting kernel parameters properly and setting all the right environment variables for an appropriate user, too.

Some people carped, of course, that Doris ‘hid’ all the complexities of installing Oracle, which meant you weren’t learning anything. Such people have obviously never quite mastered the ability to read, since merely reading the script would teach you everything you ever needed to know about how to install Oracle on Linux! Additionally, some might argue (I would, anyway) that you tend to install Oracle just a few times but use it hundreds of thousands of times… so maybe learning how to use it is a tad more important than learning how to install it? Just a thought.

Anyway, I know that Doris has helped hundreds of people, so I’d say on balance, she’s been a good thing to have written. Trouble is, she’s a bugger to maintain!

For a start, she was over-ambitious: she attempted to automate 10g and 11g installations on Redhat 4, Redhat 5, Suse10, Suse 11, Mandriva 2008, Ubuntu 7, Ubuntu 8, Fedora 8, Fedora 9 and Fedora 10, Debian 4.0… and even PCLinuxOS. In addition, she coped with both the 32-bit and 64-bit versions of at least three of those distros. Naturally, and inevitably, all of those options made coding her in the first place a complex proposition -but keeping her up-to-date as new distros arrived was a nightmare. By now, she’s getting a bit long in the tooth: no explicit support for Ubuntu 9 or Debian 5, for example (though I happen to know she works on those distros if you simply pretend they’re Ubuntu 8.10 or Debian 4.0 respectively, since my own installations on to both those platforms relied on me doing just that).

Well, all of the above is a long-winded way of saying that Doris is retiring: I’m not going to maintain her or bug-fix her any more.

Instead, I’m going to unveil her replacement: Goal -the Graphical Oracle All-in-one Loader. Goal is different from Doris in two main respects. First, it uses a graphical interface, because a lot of Linux first-timers seem to be a bit nervous around the command line! Second, it focuses on just one distro and one architecture. Out goes PCLinuxOS, for example, and Mandriva, Suse, Fedora, Ubuntu and the rest. Only support for Redhat remains (and its cousins, such as Oracle Enterprise Linux and Centos), largely because that’s the only distro (in my experience) that provides a completely solid, 100% reliable platform on which to run Oracle.

Also gone is the support for 32-bit architectures. I use 64-bit Linux myself and nearly all CPUs produced in the past 4 years are capable of running a 64-bit OS. Meanwhile, anyone thinking of doing any serious database work needs to switch to a 64-bit platform pronto, because running an instance in less than 4GB of RAM is, these days, a mug’s game (and don’t even think of talking to me about PAE!).

In short, Goal will do 64-bit 10g and 11g installations on Redhat 5 (or Centos 5 or OEL 5) only, and I have zero plans to add any other capabilities to her, ever. (Note that I will modify Goal whenever necessary to accommodate new Oracle versions. So, she’s already been amended to allow 10g, 11g Release 1 and 11g Release 2 installations, for example).

Doris will remain downloadable for the foreseeable future, since she clearly does things which Goal isn’t going to do. But she’ll just get quietly older and increasingly irrelevant! Meanwhile, if you want to run 64-bit Oracle on a ‘proper’ server-oriented distro that Oracle has been especially tailored to run on (i.e., basically, Redhat), then you should switch to Goal.

Goal is available for download from here.

You simply download the file onto (say) your desktop. You then right-click the file, select Properties -> Permissions and then set the Allow executing file as program checkbox to ‘on’. Click Close to shut the properties page down -and then simply double-click the file to launch it. When prompted, you select the ‘run in a terminal’ option. You don’t have to become root (though you’ll be prompted for the root password) and you don’t need to run anything manually from the terminal. Follow the prompts and Goal will configure your server appropriately. Once that’s done, you will need to perform the Oracle installation itself -and that will require you to open a terminal and become the oracle user… but there’s nothing I can do to work around that particular requirement, of course!

Goal does everything required for a successful Oracle installation: creating the right user and groups; setting the kernel parameters to appropriate values; downloading all software prerequisites; creating scripts required to automate the startup of databases at a bounce. All you have to do is sit back and let Goal do its thing! A directory called /osource is also created for you, if you require it: it’s where you’d download or copy the Oracle software to if you were going to perform the Oracle installation’off disk’ (that is, you’d invoke the Oracle Installer with the command /osource/database/runInstaller or something similar, depending on the precise directory structure). If you prefer to install straight off a DVD/CD (or a DVD/CD ISO mounted as a loop device so that it looks like a real DVD or CD), then the /osource directory is redundant and you can simply delete it (as root).

Once the Oracle software installation itself is complete, you will need to edit the /etc/oratab file (as root) to get a database to actually re-start each time the server boots up. The edit involves changing the final ‘N’ of the script into a ‘Y’. You also have to edit (as the oracle user) the $ORACLE_HOME/bin/dbstart script so that the ORACLE_HOME_LISTNER variable is set to the full path of the $ORACLE_HOME, instead of the $1 it’s set to in 11g and the bizarre /ade/vikrkuma_new/oracle it’s set to in 10g. Both edits take place around lines 78 to 80, regardless of the version of Oracle involved.

Apart from those edits of two configuration files, however, Goal will have done everything else for you.

You build yourself a virtual (or real, come to that) Centos 5.3 server, on which you plan to install Oracle. You have prepared your Oracle DVD ISO in the manner I described in the last post here. You insert that DVD (or get the virtual machine manger to present the ISO as though a physical DVD had been inserted) and Centos helpfully auto-mounts it. You become the oracle user and invoke the runInstaller script… and you get told

-bash: /media/CDROM/runInstaller: /bin/sh: bad interpreter: Permission denied

What’s wrong? Well, Centos (like a lot of distros before it) has ‘broken’ auto-mount by ensuring that “noexec” permissions are set for auto-mounted CDs and DVDs. The idea is that ordinary users can’t run executables from removable media -and, in most circumstances, that might be a sensible security measure to have in place. But not in this case! In this case, the oracle user (who counts, in this context, as decidedly ‘ordinary’!) must be able to execute that runInstaller script. How then to allow that? Easy:

umount /media/CDROM
mount -o loop /dev/hdc /media

Those two commands (both issued as root) first dismount the automounted CD or DVD and then re-mount it as a loop device. Manually mounting the drive causes the “exec” permission to be set… and thereafter, the oracle user will be able to run the installation script without a problem.

Of course, the specifics of those commands will need to be changed to suit your local circumstances. The DVD drive might not be /dev/hdc, for example, and you might want to mount the contents of your ISO image somewhere other than /media. But hopefully, you get the idea.

Incidentally: if you don’t know what device name identifies your DVD drive, try mounting it after the drive has already auto-mounted. For example, when I ‘insert’ my ISO image, it gets mounted as /media/CDROM. So if I then try, as root, to mount /media/CDROM again, I get told:

mount: /dev/hdc already mounted on /media/CDROM

…and right at the beginning of that error message, there’s your proper device identifier.