Keepass on Linux

I mentioned several posts ago that my old Yahoo account had been hacked and that, as a result, I was madly changing passwords on everything I’d ever touched. I’m happy to report that this seems to have done the trick: no more dodgy sign-ins from the likes of Peru or Slovenia, for example, and no more spam (as far as I can tell) being sent from my old yahoo email account.

I also mentioned earlier that I was now keeping all my passwords in the completely zero-cost password manager called Keepass. Not only do I store the passwords there, I also get Keepass to generate the passwords in the first place… properly randomised, upper- and lower-case, plus numerals, plus special characters: you get the idea! In fact, I now don’t know what my passwords are to anything! If I need to log in to something, I simply run Keepass, copy the encrypted password into the clipboard (from which it is auto-cleaned after 30 seconds) and paste it into the password field. I know my Gmail password is 64 characters long, therefore, but I don’t know anything else about it and, so long as I can run Keepass, I don’t need to.

It’s a little fiddly, perhaps. But it’s definitely a more secure way to do things.

Provided I can run Windows, that is, because Keepass is a Windows-only application. (Yeah, a security product running on Windows… quit the laughing already!)

I only realised this flaw in my methodology when I got stuck on one of my old PCs which happened to have Fedora 15 x86_64 installed on it and found I couldn’t log in to anything!

Happily, there is a (fiddly) workaround: there’s an equivalent product, called KeepassX, which will run on Linux, provided you compile it from source. Doing that is just a little trickier than I’d like, so here’s the Fedora 15 64-bit recipe for doing that, should it be needed in future:

  • Download the KeepassX software. Save it to a convenient place: I use my Desktop folder.
  • Right-click the downloaded .tar.gz file and select ‘extract here’. You should end up with a directory called keepassx-0.4.3
  • As root, issue this command to install a necessary prerequisite: yum install libXtst-devel
  • As root, cd to the new keepassx-0.4.3 subdirectory and run the command: yum install mingw32-qt-qmake
  • Still as root, run the command: /usr/lib64/qt4/bin/qmake
  • Still as root, run the command: make
  • Still as root, run the command make install

You should now be able to type the command keepassx in a terminal session as yourself and have the software run correctly.

The only other issue you’ll have is that if you’ve used the latest version of Keepass on Windows (version 2.something or other) to create your password ‘vault’, you won’t be able to open it in the Linux version (which is compatible only with version 1.x) because of file format changes between versions. Happily, if you go back to the Windows version and select File → Export, you’ll be able to output a copy of your vault in 1.x format, which KeepassX will then be able to read without drama.

Which only leaves the small matter of saving the password vault (and its 1.x equivalent) on an encrypted USB thumb drive. On Windows, I use Truecrypt Veracrypt to encrypt the entire device (and to subsequently mount and unmount it) -and, happily, it’s available for Linux as well. Installation is  straightforward -it’s usually in most distro’s repositories.

You now just run Veracrypt, which behaves exactly as it does under Windows. The only slight twist is that when you mount your thumb drive, Veracrypt will first prompt you for the encrypted device’s master password, which is fine. But it will then prompt you for your Linux user account’s password -which may well not have the necessary privileges to mount devices. If that’s the case, it will complain that it ‘Failed to obtain administrator privileges: hjr is not in the sudoers file’.

Which, finally, prompts the inevitable question: how do I add myself to the sudoers file, then?! Easy: as root, issue this command:

echo ‘hjr ALL=(ALL) ALL’ >> /etc/sudoers.

(Use your own username, obviously, unless you too happen to log on to your OSes as ‘hjr’!) As soon as you’ve done that, re-run Veracrypt as yourself and you should be able to mount and dismount the encrypted thumb drive at will.

Fedora 15 Released

Fedora 15 has finally been released and is available in all the usual places, including here.

Naturally, Gladstone has been tested on it (it’s been working on the Alphas and Betas for a while now), and works just fine (with a slight pause when it first runs, because it has to download the lsb_release package before it can really get going).

There is a nasty linking error for 11g, of course, as previously described -and the workaround is exactly the same as before, too. Namely, Gladstone outputs a new shell script in the oracle user’s Desktop directory ahead of time, and this script can then be run when the Oracle Universal Installer linking error occurs, after which you can click the OUI’s ‘Retry’ button and all will be fine. (You run the second shell script as the oracle user, not as root).

The only real problem now, which I mentioned before too, is that in Gnome 3, the contents of the Desktop directory are not displayed on the, er, actual Desktop! So, you have to know that second shell script is there, because you won’t actually be able to see it as such.

If that’s as clear as mud, well… stick with Scientific Linux for an easier ride, I guess!

Also, I noticed an extremely long pause between the conclusion of the linking phase and the start of the Database Configuration Assistant that wasn’t there in the Alpha or Beta versions. The pause happened on three different physical servers, so although your mileage might vary, I think it’s definitely real. You have to be very, very patient therefore -but it does get there eventually.

Anyway, I also have prepared a Kickstart script for Fedora 15 (and a floppy image containing said script for those that don’t have a web server onto which the plain script can be dropped). If you use that script to perform the initial installation (it’s invoked in exactly the same way as for Scientific Linux 6, which I discussed here), you’ll end up with a substantially slimmed-down O/S (no Evolution mail client, for example; and 890-ish packages installed instead of the default 1200+) that’s still Oracle-friendly.

Oracle IS for Newbies

I’m not sure where all these “Senior DBAs” with 17 years’ experience who think that “Oracle is f*cking complicated” and “not for newbies” as a consequence actually learnt their trade, but I’ll take a stab in the dark and suggest that it was, as newbies, by installing it, playing with it and, occasionally, stuffing up whilst doing so.

I suppose it’s true that those same senior DBAs will concede, eventually, that all they really mean is that “a week long course is not going to get someone up to speed”, but if their headline basically says “go away newbies, this stuff’s too complicated for you”, the damage has already been done, I think.

In any case, I think a week-long course might well get someone “up to speed”, though it’s obviously not going to make them the world’s leading Oracle DBA expert. For what it’s worth, I taught my first DBA course at Oracle Corporation six weeks after having first set eyes on the software and, though I say it myself, it wasn’t a bad course and the technical content was all that was required. It can be done, then; if not in one week, then half-a-dozen or so. Competence, at least, if not expertise.

It all depends on the person involved, really, doesn’t it? If you happen to be inquisitive, diligent and with a logical frame of mind, you’ll take to Oracle very well. If you’re intellectually lazy, casual in your study methods and find strict logic tricky, you’re not going to be very good at Oracle, no matter how long you study it. It also, I think, depends on the person doing the teaching: if their teaching style or materials leaves willing students bewildered, that’s the teacher’s (or her materials’) fault, not the student’s. But either way, the point is that “it depends”… and dismissal of entire swathes of people as mere ‘newbies’ doesn’t get us meaningfully closer to what’s really going on.

For the record, I don’t think database administration is particularly difficult -nor that Real Application Clusters are especially more difficult than single-instance Oracle to manage effectively. It’s an acquired skill, of course… but we all had to acquire it somewhere, sometime; and I don’t think it’s anything particular more skilful than the wizardry my local car mechanic performs every time he fixes my car. Anyone that tells you this stuff is so complicated that it’s for the eyes of Senior DBAs only and you might as well not bother is basically doing the old High Priest trick: only they are privy to the Great Mysteries and you are unworthy. Which is simply not true… and is otherwise known as “being patronising”.

New Scientific Gladstone (5.6)

My Gladstone pre-installation script for those intending to install the Oracle 10gR2 or 11gR2 RDBMS has been updated to take account of the fact that there is now a beta version of Scientific Linux 5.6 out.

I downloaded the O/S itself from here, and a modified version of Gladstone that can cope with the new O/S is available from the usual place.

It’s interesting to see how the cloners are handling their release schedules, what with Red Hat having just released version 6.1 of the “real” Enterprise O/S. CentOS decided to concentrate on getting version 5.6 out of the door and worrying about getting a version 6 later; Scientific Linux did exactly the opposite. Their version 6 has been out quite a while whilst their 5.6 is, as this post has already mentioned, still in beta.

Where the Scientific Linux community gets my vote is that their 5.6 has been produced speedily, and their 6.0 has been a pleasure to use for months. CentOS, meanwhile, managed to be late with their 5.6 release and still hasn’t got a 6.0 release planned for, as far as anyone can tell, any time soon.

From the outside, it looks like CentOS as a project is really struggling -from internal politics? lack of developers? lack of other resources? I don’t know, and they’re not exactly communicative. But the net result from my perspective is that I’ve given up on CentOS and will be using Scientific as my RHEL clone of choice from here on.

The case of VMware and the missing SCSI ID

When you’re setting up Oracle’s Automatic Storage Management feature (ASM), you have to ensure that the ‘raw’ devices that you have added to your server for ASM’s use are assigned the correct device names and usable permissions every time the server bounces.

In the dark days of Red Hat 3 and 4, we generally arranged for that to happen by creating raw device mappings -but that’s no longer supported on RH5 or RH6. Instead, you’re supposed to create new udev rules which do the job of declaring which devices exist and which permissions they should at every server boot.

And one of the first things you have to do to write a decent udev rule is to correctly identify the hard disks that exist: you can’t apply a permissions rule to something which you can’t uniquely identify in the first place, after all.

So when this happens, you have a bit of a problem:

That’s four SCSI hard disks, previously added to my VMware Workstation virtual machine and partitioned, resolutely failing to respond to the scsi_id command, which is what you’re supposed to use to get a unique ‘id string’ returned for a device. This happens when I use virtual machines built on VMware’s ESXi 4.1 server, too.

But, funnily enough, it doesn’t happen if you use VirtualBox as your virtualization platform:

Now, I’m not going to say this proves VirtualBox is better than VMware (because it’s not), but I am going to point out that, by default, all VMware virtual machines exhibit this behaviour, which will stop you dead in your tracks if you’re trying to build a virtual ASM or RAC machine. Without that ID string, you can’t identify your ASM disks uniquely -and that means you can’t get those disks correctly discovered by the operating system …and it’s downhill all the way after that.

Lucky, then, that this is all fixable with a modest bit of re-configuration!

If you were running ESXi 4.1, that bit of re-configuration consists of

  • shut down your virtual machine
  • right-click the VM’s entry in the left-hand panel and select Edit Settings
  • click the Options tab
  • select the Advanced → General item on the left and click the Configuration Parameters… button you then see displayed on the right
  • click the Add Row button
  • add disk.EnableUUID as the name of the new row, and the word TRUE as its value (don’t use quotation marks around either of these entries).
  • click OK to make the new parameter addition ‘stick’.

You can then reboot your virtual machine.

Sadly, VMware Workstation has no interface like this that allows you to add this new configuration key to your VMs. Instead, you are reduced to having to do it yourself, by hand, using a text editor. It’s easy enough, however.

First, find the directory where the files representing your virtual machine are stored. One of them will be called the name of your VM, with an extension of .vmx. In my case, for example, the file is called sl6.vmx, because when I created my VM, I called it “SL6″. The file will be 3 or 4KB in size. Open it in the text editor of your choice and at the very end of the file, add this line:

disk.EnableUUID = "TRUE"

The quotation marks around the word “TRUE” here are important and must be typed. Now save the edited file and reboot your virtual machine. You should find that scsi_id is now capable of returning perfectly usable values:

As you can see from this screenshot, my VMware virtual machine is now displaying SCSI IDs for my hard disks just fine. The values being returned are quite different from those shown earlier in my VirtualBox VM, of course, because VMware and VirtualBox handle virtual disk identification quite differently. Whatever the specific values might be, though, the important point is to be able to see a value of any sort!

Kickstarting your Linux Installations

If you install Oracle enough times, you will probably soon become sick of having first to install the same Operating System over and over again, every time remembering to take the same options, type the same info and configure things identically! If only you could automate and standardise the O/S installation!

Well, of course, you can -so long as you’re using Red Hat Enterprise Server (or one of its clones, such as Oracle Enterprise Linux, Scientific Linux or Centos). The mechanism to use is called kickstart and it’s been around for years (and it’s available for Fedora, but nothing in this article should be taken to apply there, because it’s a very different beast compared to “proper” server OSes).

In a nutshell, kickstart is simply a text file that contains a stored list of configuration options taken from a previous, manual OSinstall. When you come to do your second and subsequent installs, you boot from the OS DVD as normal but then point the installer to this kickstart configuration file to ‘auto-fill’ in all other aspects of the new installation process. From that point on, there’s little or no interaction required: the install just polishes itself off.

Kickstart, in short, makes Red Hat-like operating system installs predictable, reliable, repeatable -and a lot faster!

The kickstart configuration file required for a Red Hat 6-based distro (i.e., Red Hat itself, or a freebie clone like Scientific Linux) is slightly different than that required for a Red Hat 5-based distro, so I have download-able examples of both types here:

You could download those, see how they work and then edit them to suit. Alternatively, just do a regular, manual install and check out the /root/anaconda-ks.cfg file (which is automatically generated every time you do a Red Hat-a-like installation) and go from there.

One of the nice things about Kickstart is that it gives you an easy way of slimming down your distro installs… you’ll notice from my example files, for instance, that I add lines such as -evolution or -sendmail: the minus sign means “don’t install”, so you end up with an O/S install that’s mercifully free of a lot of the cruft that otherwise tends to clog them up. It’s trivial, of course, to edit the configuration file to add back anything I’ve taken out that you think is important.

You’ll note from my example files, too, that I’ve taken a fairly generic approach to things: a server installed using these files will end up being called oraclebox.dizwell.home, for example. Again, if that’s not suitable for you (and I doubt that it would be!), feel free to edit the file before you use it. Similarly, I set my root password to dizwell and I configure networking with DHCP (because I know what I should use as a static IP address in my own home, but what works for me might not work for you). I also use Greenwich Mean Time as my time zone. These are all configurable by means of a simple text edit, but you should at least be aware of the need to look at these options!

I suppose the only slight difficulty with kickstart is how you tell the O/S installer where to find the kickstart configuration file in the first place. There are basically two options I use: if I’m at home, I point the machine being installed to the feeble Apache web server I run on an old, vintage 2003 laptop. If I’m anywhere else, I point it to a floppy disk image containing the configuration files (or to an actual floppy disk created from that image).

Again, the procedures involved differ slightly between RH5 and RH6. Here’s an example of me telling Centos 5.6 to use my web server’s copy of the right file:

Where it says “boot:”, you simply type the word linux followed by ks= and then the location and name of the kickstart configuration file. In my case, my web server is running on 192.168.0.1, and it’s called “rh5.cfg”. Once you get that location/name right, press Enter… and that should be the last time you have to interact with the O/S installer: everything else will happen automatically.


Here’s how you do it in Scientific Linux 6 (you get here by hitting the TAB key when the installation menu is first displayed):

That can be a bit difficult to read, given SL’s choice of boot wallpaper! So let me spell it out: when you hit TAB with the first menu option highlighted (to ‘install or upgrade an existing system’), you’ll see the command vmlinux initrd=initrd.img already sitting there. So this time, you don’t have to type the word “linux”: all you have to do is to add on the bit which says where the Kickstart file can be found …which again involves typing ks= followed by the correct location and name of the kickstart configuration file.


If in either the Red Hat 5 or 6 cases you’d instead stored your Kickstart files on a floppy disk (or on a floppy image which is behaving as a floppy disk), instead of typing something like **ks=http://192.168.0.1/name-of-config-file.cfg**, you’d type:

ks=hd:fd0/name-of-config-file.cfg

The only real change, therefore, is the device-name bit: hd:fd0 is how you say “floppy”, and http://w.x.y.z is how you say “web server”.

Incidentally, if you’re using virtual machines to practice with, you can simply add a floppy drive to your VM and point it to an image of a floppy disk. I have the two Kickstart configuration files saved on such a floppy image, which you can download here. So just point your VM’s floppy disk to that download. How you do that depends on your choice of virtualization software. Here’s how you’d do it in VMware Workstation, for example:

…after which, you just click through the wizard and browse to the floppy image in the standard way. The same sort of process works in VirtualBox, too. Happily, the same floppy image works just as well in VMware (Workstation, Server and ESXi) as in VirtualBox.

Note that in all these case, the O/S actually gets installed from a local DVD (or DVD iso, in the case of my virtual machines!). The only bit that gets pulled across from the web server is the kickstart configuration file itself. It doesn’t have to be like that, though: it’s possible to write a kickstart file so that the O/S itself is pulled across the network. But that’s way outside of scope for this little blog piece! Indeed, kickstart is incredibly flexible and full of interesting options, and I’ve really only just scratched its surface here.

Hopefully, though, this has been enough to show you how kickstart can play a really useful role in simplifying, standardising, speeding up and slimming down your O/S installations -which is where all Oracle RDBMS installers need to start, I think!

Screwed

Back in, oh… I forget: sometime in around 2002 or so, probably, I had a fit of paranoia about not using one password for everything but needing to be able to remember them all by storing them in a single on-line repository of passwords. (Yup, you’re right: it sounds stupid already). I therefore signed up with Lastpass.

I entered a couple of my account/password details, including the one for ye ancient Yahoo! email account which I’d already not used in about 2 years ([email protected] …the name alone gives you an idea of how old it is).

I then never used it again and promptly forgot all about it.

Until a week or so ago, when I got an email warning me about this. Basically, the keeper of the keys just got hacked.

Now, they say they have no definitive proof that the security of their data has been compromised, but I think I have… my ancient Yahoo! account now tells me I’ve logged in from a few interesting places:

I don’t even actually know what ‘yahoo mobile’ is, and I’ve sadly never even been to Slovenia or Peru… so those last few logins are definitely not mine and definitely the result of someone having found my Yahoo password… which I’ve only ever stored once in Lastpass’s not-so-safe keeping.

Unfortunately, although I’ve not used the Yahoo account for about a decade, there were a lot of emails in it which I stored as a kind of online archive… and all of those have been mined for email addresses. I know this because a handful of people, some of whom I’ve not written to since the late 1990s, have been in touch to say they couldn’t quite understand why I was writing to them informing them that a support ticket I’d raised with “mochasupport.com” was waiting to be processed. There was no support ticket, of course, and I’d not written to them… but someone using my Yahoo account was doing so, presumably trying to find out which of the archived email addresses to which they now had access were still valid.

It means that quite a lot of spam has been sent out lately in my name (and, indeed, from my email account). The fact that it’s all originating from an old Yahoo email account is the giveaway: if it doesn’t come from dizwell.com or diznix.com, it’s not from me really.

If you’ve been receiving cryptic communications from [email protected], I can only apologise and try to explain that it wasn’t really my fault! In the meantime, I’ve changed every password on every account I have or can remember having, including the Yahoo! one, and hopefully that will see things die down (or at least the spam will have to start coming from someone else’s hacked account).

How small can you get it?

My blog post title naturally refers to “the size of one’s CentOS installations”, in case it wasn’t obvious!

Centos (and therefore Red Hat and its other clone cousins) installs a dirty great big Gnome system by default, complete with software such as OpenOffice.org, which I wouldn’t have said was exactly essential on a server! So how minimal can you get a Red Hat/Centos/etc installation, whilst nevertheless retaining a highly functional OS (so you have a file manager and an Internet browser so on, not just a bare command line?), that is additionally capable of running something like Oracle?

I’ve played around with this question quite a bit over the years, and here’s my not-so-secret recipe for svelte-ish Centos.

The first and most important thing to do is to make sure you customise your list of packages during the OS installation process itself… and de-select absolutely everything, including the Base group.

So, for starters, de-select “Desktop – Gnome” and select “Customize now” on this screen:

Once you click [Next], you’ll be taken to this screen, where you work through the list on the left and de-select anything that’s been selected by default in the right-hand panel:

You’ll notice here that I’m de-selecting the Base package group, but there are about a half-dozen other groups that are selected by default lurking under the Applications and Servers groups, so un-check those, too.

Now you can go ahead and complete the OS install: it should only take around 3 minutes. When you reboot, you’ll have to log on at a command prompt (as root), at which point you can check how slim you’ve managed to get things:

That’s a 677MB installation of Centos 5.6 (64-bit), sitting on a suitably modest 1.9GB root partition – and that’s probably about as small as you’ll ever get a Red Hat-type OS to be (Ubuntu Server can be about half that size, by way of comparison). I’ll therefore call this the “minimal OS” and I’ll use it as the base onto which each of the options described in the rest of this blog piece will be installed.

A 677MB O/S is a good start, I suppose …but it’s not really usable, is it? Not unless you are a command-line loving guru, anyway. So how, minimally, to get a GUI-ish environment added to your 677MB starter OS? Well, there are a couple of options here.

Option 1 : Drastically Minimal

For truly minimal results, having logged on as root, type this command:

yum install xorg-x11-server-Xorg xorg-x11-xinit twm nano xterm

That should prompt you to perform a 34MB download/install, comprising about 40+ packages.

You may now need a quick edit of your default /etc/X11/xorg.conf file: mine had a section which mentioned driver=”vmware”. Because I hadn’t installed guest additions in my virtual machine at this point (because we’re being minimalist, right?!), that would not work. Change it to driver=”vesa”, however, and you’ll be good to go.

Now, you should be able to issue the command:

startx

…which will get you this:

This is the twm window manager, which is as basic (and horrible) as it’s possible to get. Left-click anywhere on the desktop and that sickly-green menu will appear, which contains ‘kill’ options to let you shut something down and an ‘xterm’ option to let you open up a terminal session. From the terminal, of course, everything is possible… indeed, I well recall using exactly this interface back in 2004 to install from scratch a two-node RAC in New York from a Sydney office. So, the functionality is certainly there, if you are able to grit your teeth hard enough. You’ll note from the screenshot that we’re now up to 865MB used on my root partition… still fairly svelte, for Red Hat-based distros, I think.

If you’re going to install Oracle on this box, you may well want to do it by using the Gladstone preinstallation script… and that’s fine. But you’ll first need to issue this command:

yum install redhat-lsb

…which adds another 14MB or so to the server.

Of course, you’ll then be needing an Internet browser to download Gladstone in the first place: the simplest approach, I think, is to do a

yum install firefox

… (though it costs another 75MB of download, including a lot of Gnome-related ‘litter’). You run the browser subsequently by opening an xterm and typing the command firefox, after which everything’s pretty standard fare.

You won’t be able to right-click the downloaded Gladstone shell script to alter its permissions, of course: old timers won’t be surprised to know, however, that a chmod 775 gladstone.sh at the command prompt will achieve the same thing.

Option 2 : Getting Fairly Maximal

If the delights of twm seem a bit too minimalist for you, there is a slim-ish alternative: Xfce. This is the desktop environment that Xubuntu uses (for one): it’s claimed to be lighter on resources than Gnome or KDE and therefore a lot faster than either. However, it uses a lot of the same libraries that Gnome uses, so I’m not really convinced that choosing it over bog-standard Gnome is hugely worthwhile: I mention it here only because it’s a nice way of showing what you can get on CentOS without completely buying into Gnome.

Assuming you’re prepared to give it a whirl, however, you’ll find that it’s very simple to install in your “minimal OS” install. Just issue the commands:

yum groupinstall "XFCE-4.4"
yum install xorg-x11-xinit xorg-x11-server-Xorg

That will trigger a somewhat less-than-svelte 123MB download, involving around 200+ packages. It takes a while, therefore, to get installed. It’s also true that I again needed to edit my /etc/X11/xorg.conf to change the driver from “vmware” to “vesa”; but once I’d done that, I simply had to type the command:

startxfce4

… to get this:

Now that’s a proper GUI, complete with the Thunar file manager and a truly graphical terminal. Any Gnome or KDE user would, I think, feel rapidly at home here. But look at the disk usage figures on the root partition in that screenshot: we’re now using 1.2GB of disk space, which is quite a jump from the 677MB starting-point. It’s a lovely GUI environment, therefore… but it’s not exactly “lightweight”, not in the extreme sense meant in this article, anyway.

Option 3: The Best of Both Worlds?

Happily, there’s no reason why you have to install the entire XFCE desktop environment just to get some of its nicer tools (like the Thunar file manager). If you do the Option 1 route I’ve described above, there’s nothing to stop you simply typing:

yum install thunar

A mere 13MB later and you’ll be able to run the very GUI file manager by issuing the command thunar in an x terminal session. Stick an ampersand on it (i.e., type thunar &) to make it run in the background, freeing your xterm for other work in the foreground.

And that’s pretty much the way I like my Red Hat/Centos/Scientific Linux boxes to run when I use them as an Oracle database server: minimal install, add in a couple of X-related packages, add twm, add Firefox, Thunar and redhat-lsb … done! That all takes up a mere 1.1GB, but makes a perfect platform on which to run Gladstone and then install Oracle.

There are other non-Gnome, non-KDE window managers, of course. Fluxbox is nice; icewm is attractive; ratpoison is ghastly in a 1970s pre-GUI way… but very, very functional. Not all are easy to install on Centos, since they’re not always in the standard repositories, but they’re all do-able with various degrees of difficulty. But I’ll settle for what I’ve described here: it means I can manage the servers when I have to, but know otherwise that nothing’s getting between my databases and my CPU cycles unnecessarily!

Gladstone and the new Fedora

Fedora 15 has been in beta for a while now (make sure you get the x86_64 Install DVD, not any of the ‘Live CD’ downloads).

When I wrote the Gladstone Oracle preinstaller script, it was tested to work with Fedora 15 Alpha -but I’m happy to confirm that it works perfectly well with the beta, too.

One slight niggle is that Fedora 15 Beta uses the Gnome Shell desktop environment -and that means the desktop you see once logged in is not ‘live’. You can’t, for example, drag-and-drop a file onto it and see it appear as a desktop icon. You do still have a Desktop directory, and it can still have things in it… but visually you won’t be reminded that those files exist:

This is a simple example of what I’m talking about: the Nautilus file manager clearly shows three files and a directory are sitting in my Desktop directory, but nothing is actually showing on the blue stripey desktop itself (you’ll have to trust me that there’s nothing hiding underneath Nautilus, either!)

It’s actually a bit more than a niggle -it strikes me as a bloody stupid way of doing things, and I can only hope that the Gnome devs stop this sort of thing happening whilst they’re on the path to world desktop domination.

Anyway, in the meantime, it means that Gladstone can be a little trickier to run on Fedora 15 Beta than it should be, if you are using it to prepare for an Oracle 11g Release 2 installation. That’s because Fedora still suffers from an ‘error in invoking target’ compilation error during the eventual 11g installation -and Gladstone deals with that by creating a short bash script ahead of time. When you encounter the linking error, you just double-click the ‘fixing script’ and let it run (it takes seconds only), after which you can click ‘Retry’ back in the Oracle installation process, and all will be well.

Except that now, of course, you can’t actually see that a ‘fix me up’ script has been created for you, because Gladstone thoughtfully writes it out to…. the Desktop! If you can’t see it, you tend not to know to double-click it -and that means you’re stuck with a flakey Oracle installation process left hanging!

All I can really do at this point is lament the tide of so-called “progress” in the development of a desktop Linux and encourage any Fedora users trying to install Oracle 11gR2 via Gladstone: do what I’ve done in that screenshot above. Open your Desktop folder in Nautilus before you launch the Oracle installer so that you can double-click the fedora-linking-error-fix.sh shell script when you encounter the agent linking error.