Posts Tagged ‘GOAL’

OpenSuse got a bit of a facelift a few weeks ago and is now available in version 11.2. The installer looks quite gorgeous (just a shame you don’t tend to install distros that many times, I guess, so you’ll only appreciate the emerald green stuff once or twice!). I was surprised to discover that KDE is selected as the default desktop… Suse’s been Gnome-preferred so long, and KDE 4 has been so beta for so long, it seems a bit of a brave move to me. I am not, in any case, very used to KDE (I barely used 3.5 back in the day; 4.3 seems just very, very peculiar to me, though I guess I could acquire a liking for it eventually), so I found things a bit heavy-going, to be honest (not being able to drag-and-drop a file to the desktop took a bit of getting used to, for example!). And it’s all rather a lot of graphical overkill for an Oracle server, I suppose, in any case!

Anyway, my GOAL instructions say to perform a strictly default OS installation, so just for once I stuck with the KDE suggestion… and watched as GOAL completely failed to run at all! The reason is simple: GOAL depends on the zenity package to do its graphical stuff, and zenity is not installed as part of the default 11.2 KDE installation. So, I had to do a zypper -n in zenity as root, before anything else. Once that was done, though, GOAL did its thing and 64-bit 11g release 2 installed without a hitch (the usual pile of ‘these packages need to be installed’ messages can simply be dismissed with a wave of the ‘Ignore All’ option, of course). The GOAL download page has been amended slightly to reflect the fact that the new distro version has been tested and works fine.

Update: If you select the Gnome desktop option during the Opensue 11.2 install, zenity *is* included by default, so no extra, manual installation steps are required before GOAL can be run properly.

Fedora 12 was released about three weeks or so ago. It’s taken me that long to verify that my GOAL prerequisite installation script works correctly with the new distro. Happily, it does (I needed to make one small adjustment to let the script allow the use of the higher distro version number), so the GOAL download page has been modified accordingly.

I must say, the new Fedora is the first one I’ve ever seen that doesn’t immediately make me want to vomit: the desktop graphics are subdued and subtle, eschewing the balloons, DNA helices and God knows what other nonsense they’ve gone in for in the past. I still wouldn’t pick it as my first distro, however -from the Oracle perspective, for example, it’s the only distro that doesn’t give you the option to switch off SELinux and the firewall as part of the installation process. You have to remember to do that after the installation completes and you’ve performed your first log-in -which is precisely the time you are least likely to remember such niggly details!

Still, Fedora 12 and 64-bit 11g Release 2 work perfectly together, with a completely flawless installation -apart from a list of supposedly missing packages (which aren’t missing at all) which can be dismissed with a click of the ‘Ignore All’ checkbox!

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!

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 have tidied up GOAL and moved things around on the site a little in order to accommodate the changes/improvements. Thus GOAL acquires an entire page all of its own under the ‘Oracle Articles’ banner you see above. If you prefer a simple hyperlink, that’s here!

When you get there, you’ll notice that there are now three GOAL variants: the original for Red Hat (and its equivalents, like Centos); a version just for doing the same thing on openSuse 11.1; and an Ubuntu-specific version (I guess that last one will work for Kubuntu, Xubuntu and the entire *buntu family, come to that… but Ubuntu is the only one I’ve tested it on).

There are still a couple of glitches and gotchas with the two new variants, but nothing terminal as far as getting a functional database at the end of the installation process is concerned. I’ll continue to work on those minor issues over the next few days until (hopefully) they are ironed out.

Hope it all makes sense!

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.

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.