Where pegs grow legs: hanging ideas on words

I’ve had the unfortunate displeasure of being forced to install and configure Oracle in one of my recent projects to satisfy an application’s requirements. I’ve never used Oracle before, but I have done a lot of work with other databases, particularly on Linux, so I come to the table with some expectations. I had a lot of trouble running through the installer without installing the entire GUI suite of packages that comes with Red Hat Enterprise Linux. I’m sure others have had this question (including a previous project our own contracted Oracle employees couldn’t figure out!), so here is what I’ve done.

In production, my linux builds never have X or any superfluous packages installed. This keeps things simple and more secure. I want a minimalist setup when I’m depending on something day in and day out. I was a little disturbed that the Oracle 10G documentation stated an Oracle install (the universal installer, which is also the recommended installer) required control-center, which has sub-dependencies such as Xsound, and other packages that you’ll never need running on a database server. Luckily, this is not necessary.

Instead of installing an X server and all the related gunk on the database server to do the graphical install, we’re going to use an X server of another machine (could be a Windows laptop running Cygwin/X or a development box running RHEL5 desktop), then installing an “X client” on the database server to allow connectivity between the Oracle installer and the X server displaying the results and providing the input for the installer. I’m not going to show you how to install your X server – if you’re having problems with that, install RHEL5 on another machine with the default packages – it’ll be installed for you.

Background

The X Window System is a much older technology that is rarely reviewed anymore, although it is still used on almost every Unix graphical installation to date. It is a typical client-server architecture, but what is refered to as the client and what is refered to as the server are reversed: our database server runs as the “X client”, and the desktop runs as the X server. The X client is not technically a client, but a set of libraries that permits the interaction of gui applications (with mouse clicks and button presses) on that machine. In the case of the Oracle installer, we will be forwarding the X traffic tunneled over SSH.

The Packages

Beyond a basic build set, here is the list of packages I needed for a successful 64-bit RHEL4 Oracle install. RHEL5 should be a similar set. You may want to check out this forum post if you’re interested in that.

• binutils
• compat-db
• gcc
• gcc-c++
• glibc
• glibc-common
• gnome-libs
• make
• pdksh
• sysstat
• xorg-x11-deprecated-libs.x86_64
• xorg-x11-deprecated-libs.i386 (I had to specify each platform specifically to get the specific platform of the deps installed as well)
• libgcc.x86_64
• libgcc.i386
• compat-gcc-32
• compat-gcc-32-c++
• compat-libgcc-296
• glibc-devel.x86_64
• glibc-devel.i386
• libstdc++
• libstdc++-devel
• zlib
• freetype
• expat
• fontconfig
• xorg-x11-xauth
• xorg-x11-libs
• xorg-x11-Mesa-libGL
• libaio
• (xterm) – not needed, but good for testing

Most of these packages are needed by Oracle to compile and link in its binaries with the underlying OS. X really only needs the xauth package, which translates the auth information for the remote machine (our database server). For whatever reason, the Oracle installer also needed the deprecated-libs packages (this is proof at how outdated this mode of installation is!)

Before we connect, we have to check one last thing. On the database server, edit /etc/ssh/sshd_config so that X11Forwarding is set to “yes” and restart sshd. This allows the ssh daemon to tunnel the X protocol over the wire.

Connecting

If you installed xterm, let’s use it to test first. On the desktop, in the X server, open up a terminal and connect to your database server. Make sure to add the -X flag, as the ssh client does not forward X sessions on by default, just like the ssh daemon above.

ssh -l oracle -X database servername

Running xterm on a remote machine

Last, once you’ve connected, type xterm, and you should see a new terminal open up in your GUI! If so, you’re good to go. Now just run the Oracle runInstaller script and you should be presented the Oracle installer on your desktop, running on your database server. Once you’ve installed the server, you can also use this to install your database graphically (dbca).

./runInstaller
$ORACLE_HOME/bin/dbca

Last thoughts

This was rather difficult to wade through. Unless you understand X or are an excellent trouble-shooter, this is not an easy task without assistance. I’m sure there are plenty of reasons why Oracle has not updated their main installer, which seems to be at least 8 years old now, but it sure does turn people away who expect something a little more modern (like a web install). I guess Oracle thinks their customers will be ok with mediocrity and stagnancy.

At the recent OpenSQLCamp, Brian Aker and Jay Pipes told us about Drizzle: what it is, and what it’s not. Here’s what I picked up from it.

What it is

• A fork from MySQL 6.0
• A redesign of some components of the code
• A pluggable microkernel

What it’s not

• MySQL 7.0
• A replacement for MySQL
• It is _not_ just a pared down version of MySQL

The redesigns

Not everything has been redesigned, nor will everything be redesigned. The general idea of the drizzle OSS project is to take the best of MySQL, and leave behind some of its shortcomings. I’m not an expert in the MySQL code, but one of the more obvious shortcomings is it’s lack of reuse of standard libraries. Instead, in many cases, MySQL rolls its own code, for example with authentication (why are db rights even stored in MySQL?). This breaks one of the fundamental principles of CS: code reuse. I hope I don’t need to argue the merits of code reuse, but from a product perspective (in the OSS/MySQL world), having to constantly reinvent the wheel (because you’re also having to update your code to keep up with the standard libraries) slows progress considerably. Their philosophy is to build a plugable database server “microkernel” that one, reuses existing, well developed libraries (such as libxml), and two, is extendable in multiple places to allow other developers to more easily and more quickly add in useful features they would like to have.