Automatic Portland

Ah, automation! Where would we be without it? (It is a little-known fact that the total mileage of railway line in England did not exceed the total mileage of canals in England until 1861 -some 80 years later than is commonly supposed, and proof that the Industrial Revolution never really happened -except in Germany, funnily enough. Britain, though, had an Industrial Evolution).

Anyway, I digress. Automation is good, and it helps produce nicely-standardized things which are therefore more predictable and more stable than their chaotic hand-built equivalents.

This goes for operating system installs, too.

Having got Gladstone doing his thing to hand-built servers, ensuring a level playing field when it comes time to install Oracle; having then got Palmerston working overtime to do the same thing for a Kickstart-automated server build; it is now time for me to introduce Portland: the script you run to standardize and automate your RCSL builds when you don’t want to install Oracle.

Perhaps being a little more positive, I should say that Portland is the script to run when you want the Gimp, VLC, Eclipse, Java, Apache Directory Studio, Opera, Rhythmbox, Handbrake …and all those other good productivity programs (like Solitaire and Chess)… added to an otherwise standard and minimal RCSL server installation. Preferably without all the hassle and confusion that the bazillion-and-one ‘how to do a perfect desktop’ articles out there seem to want to inflict on you!

Portland turns RCSL servers into usable desktops, in other words (including switching from OpenOffice to LibreOffice).

I particularly like it because it makes continued and almost-exclusive reference to mirror.aarnet.edu.au (and, indeed, changes the standard yum repositories so that they point there too). That mirror happens to be (a) close to Australians and (b) completely unmetered in use for us poor Telstra customers shmucks. For me, it means I can install RCSL servers until the cows come home without running up huge ISP bills or excess download consequences. For others, it will be a disaster, of course, since it will be using perhaps the remotest, non-free repositories in (their) existence. I’ll work on that for a future update! Meanwhile, you could do a global search-and-replace of the mirror URL before running it.

So, to sum up:

  • You use the Kickstart Configurator to specify a new non-Oracle server’s details.
  • The last line of the resulting Kickstart script will cause a portland.sh script to be downloaded to the new server’s root directory.
  • When your over-the-internal-network ‘base build’ is complete, and provided you have a functioning Internet connection, you log on as root and invoke that script (a simple sh /portland.sh will do it).
  • 20 minutes later, your server build will complete. including a nice set of top-panel application launchers for all the apps I consider to be vital (you might disagree with my choice of launchers, but that’s life!)
  • There are two interactive prompts throughout the entire process: Dropbox asks you if it’s OK to close all Nautilus windows (the answer is ‘yes’), and Calibre says it’s going to install to /opt (press Enter to accept). If I can get those two working in a non-interactive mode, I will.

There are still a couple of things I definitely won’t automate, the most significant of which is the installation of proprietary graphics drivers: I can’t find a reliable way of working out what graphics card is installed in a PC, so can’t automate the installation of the right binary blob. Install the wrong one, however, and the PC may well refuse to display anything at its next reboot. I’ve therefore decided to leave well alone for now!

But for the most part, I can now roll out a bundle of RCSL servers in double-quick time and have them all look as I want them to, without really having to do anything. And that’s the sort of automation I can live with!

Footnote 1: because I know literally tens of thousands of people will be asking, William Henry Cavendish-Bentinck was the 3rd Duke of Portland and served as British Prime Minister twice (in 1783 and 1807-1809, which is the longest gap between ‘turns’ of any British Prime Minister. If Margaret Thatcher wanted to achieve the same thing, she’d be making a fresh run for office right about now). The Portland Vase (see left, being peered at in the British Museum by yours truly, circa 2010) gets its name from the Duke’s family, since his mother bought it from the British Ambassador in Naples. Don’t ask how he came to be selling in the first place, though!

Footnote 2: Portland installs an, er, “eclectic” mix of software that suits my needs -which may not suit everyone or anyone else’s. I’ll take comments/suggestions on what ought/ought not to get included, if it helps make the script as a whole more useful. Suggestions need to be in the repositories (and thus a yum install away), or easily obtainable with wget (which rules out Oracle and VMware Workstation, for example).

Footnote 3: The Kickstart Configurator has been modified a little so that it now automatically downloads the portland.sh shell script (to the / directory) if you select to create a non-Oracle configuration. Whether you choose to run it after that is up to you, of course, but at least it will be there. If you tell the Configurator you’re building an Oracle server, of course, then its behaviour is unchanged: it automatically downloads the palmerston.sh shell script instead (from your own Kickstart server).

Footnote 4: The complete list of packages/applications Portland installs currently is as follows:
alacarte, alltray, ApacheDirectoryStudio-linux-x86_64-2.0.0, brasero, calibre-ebook reader, cheese, cuetools, dia, dropbox-0.7.1-1, dvd95, dvdbackup, easytag, eclipse, ekiga, evolution, gftp, gimp, gnome-games, gnome-games-extra, gnote, gstreamer-plugins-ugly, gthumb, guake, handbrake-gui-0.9.5-1, hardinfo, keepassx-0.4.3-1, libdvdcss, libreoffice 3.5.0, mencoder, mozilla-vlc, ntfs-3g, openjava, opera-11.61, pidgin, rhythmbox, rlwrap, shntool, sound-juicer, soundconverter, stellarium, thunderbird, transcode, transmission, tsclient, VirtualBox, xsane

Watch your bits!

This is what happens when you start up a server with a Scientific Linux 6.2 32-bit netinstall disk and expect it to be able to continue with a 64-bit network installation:

Loader exited unexpectedly! exec of anaconda failed: Exec format error

The clue is buried in the error text: Exec format error means “you’re trying to execute a 64-bit executable when I was expecting 32-bit ones, so that format/bit-architecture is wrong”.

The references to “anaconda failed” and “backtracing /lib/lib.s.6″ are just red herrings, really, potentially diverting your attention from the real issue: You can’t mix your architectures. If your Kickstart Server is dishing up 64-bit distros, you need to boot with a 64-bit netinstall boot disk. Obvious, really, but I’d never accidentally mixed-and-matched before, so I never quite knew what to expect.

Now I do!

Did I mention Palmerston?

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

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

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

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

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

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

Kickstart and DHCP

Here’s a tangled web to unpick at your leisure!

Back in December, I finally switched off my 7 year-old laptop (a sturdy Thinkpad X40) that had been doing practically nothing except running Windows XP, on which was running my ISP’s Internet Connection software, and also sharing that Internet connection with Microsoft’s built-in ICS (“Internet Connection Sharing”). Effectively, my Thinkpad had been running as a router for years. In its place, I plugged the wireless Internet USB device into a Scientific Linux server and switched on IP forwarding: a little bit of re-configuration of my various clients (laptops, netbooks, desktops) and all could still access the Internet, but now without a flaky laptop (or a flaky XP installation) in the path.

So far so good.

Cut to today, when I’m building a Centos 6.2 virtual machine, using my now-standard technique of “installation over the network” (as described here). Every time I started the installation, it bombed out with a warning that ‘Network Manager couldn’t configure the eth0 interface’. I tried Scientific Linux 6.1, which I’ve used a bazillion times in the past… same story.

So I fiddled. Since it was apparently a networking problem, I switched my virtual machine from “bridged” to “NAT” and tried Scientific Linux 6.1 again: and it worked! I didn’t pause to think why NAT worked when bridged didn’t, but simply ticked it off as ‘fixed’.

Back, therefore, to trying to build a Centos 6.2 VM, this time using the now-proven “NAT” technique. Except that this time, it didn’t work. It started to, sure enough: at least I didn’t get the ‘Network Manager can’t configure’ error again. Indeed, the installation process correctly read my kickstart file and a couple of the installation files as stored on my web server. But then it failed to read the install.img file:

Now that just made no sense to me: the path mentioned was absolutely, 100% guaranteed to be correct… and I checked it multiple times to be certain of that. What’s more, “install.img” is merely the third file read during the installation process (updates.img and product.img are read first). So how come the network was fine for two files but bombed out on the third?!

I spent the best part of a day checking and triple-checking my entire setup: physical host to virtual web server connectivity was fine; paths as specified in my kickstart file were fine; IP configuration as specified in the kickstart file was fine… all dead-ends.

And then, for no particular reason that I can now recall, I decided to do a quick yum install dhcp on my web server. A slightly less quick edit of /etc/dhcp/dhcpd.conf and I had myself a working DHCP server.

And guess what? The Centos 6.2 install worked perfectly!

What’s more, I then went back and tried both Centos 6.2 and Scientific Linux 6.1 installations with the “bridged” network option, and both of them worked fine too!

Apparently, therefore, DHCP is essential for network installs of Linux. Why hadn’t I ever noticed this before? Because of Microsoft, that’s why!! (They have to be responsible for all the bad things that happen, right?) The Internet Connection Sharing software my faithful Thinkpad had been using to act as a router automatically switches on both DNS and DHCP. That ancient laptop had, in fact, been this house’s DHCP server without me ever really worrying about it. When I retired it in December, therefore, I lost DHCP -and although I’d been sharing the Internet connection on the Linux box, I’d not installed DHCP anywhere to take its place. I knew all of that: but it didn’t concern me.

The reason I wasn’t concerned is that we simply don’t use DHCP in this house! (Not knowingly, anyway!!) All my servers, desktops, laptops and what-have-you are carefully assigned fixed IP addresses. I even have a spreadsheet showing which addresses have been allocated and which are free! So, since we don’t use DHCP, losing a DHCP server by retiring ICS really didn’t bother me.

But suddenly, today we have proof that DHCP was necessary after all :-(

Now, thinking about this with 20-20 hindsight , it’s all a bit obvious. How can a server you’re trying to build talk to a remote web server unless it already has acquired an IP address? Sure, the kickstart file it finds on the web server will eventually grant a proper, static IP address… but how does it get to read that file in the first place unless it already has some form of network communication with the remote server on which it’s stored?

That initial IP address is acquired easily in NAT mode: it’s the same address your physical host uses. Hence both builds in NAT mode at least started off fine, and Scientific Linux’s was completely successful. When you run in bridged network mode, though, your VMs have to acquire that initial IP address the same way any physical machine would: from a DHCP server. And since I didn’t have a DHCP server any more, not even a non-obvious one from Microsoft that’s surreptitiously switched on by enabling ICS, all my bridged builds started to fail.

The moral of the story: you need a DHCP server if you’re going to do networked installs of Linux, even if you don’t intend using DHCP after the initial installation has completed.

Now, a trawl around Google tells me that this is not necessarily a cast-iron rule: apparently, there are non-DHCP ways around this. But I’ve not tried the workaround suggested -and DHCP is so trivially easy to get going anyway that it’s not something I’m desperate to avoid using.

Of course, one mystery remains: in NAT mode without a DHCP server, the Centos installation started well enough and then bombed out; in exactly the same configuration, the Scientific Linux install sailed through the whole thing without incident. It would seem as if Centos starts off by using the physical host’s IP address (thanks to NAT) but then tries to switch to acquiring its own address (which, without a DHCP server, it can’t do), whereas Scientific Linux appears to make do with its initial IP address just fine.

Why this difference in behaviour? As I say, it’s a mystery at this stage -which makes this sort of thing fun and infuriating in equal measure, I guess!

VirtualBox Installations on Scientific Linux

I’ve mentioned previously that my preferred virtualization platform is VMware Workstation. That remains true …but VirtualBox does have the distinct advantage of being free-of-charge. So unless I want to insist that my readers find AU$291.50 for VMware’s offering, it behooves me instead, from time to time, to use the virtualization platform I know we can all afford.

So here is my two-minute recipe guide to getting the latest VirtualBox product installed (for zero dollars!) on Scientific Linux 6.1. (You could always just download the relevant rpm and install it directly, but I prefer to do all my package management via yum wherever possible, so that’s the approach described here).

1. Get the gpg key

VirtualBox is supplied as a bunch of rpm packages which have been digitally signed. By checking the signature, you know no-one’s messed about with the packages before they reached you. It therefore makes sense to obtain and install the digital key needed to do that signature check. It’s easy to do, as root, at a command prompt, by issuing these two commands:

wget http://download.virtualbox.org/virtualbox/debian/oracle_vbox.asc
rpm --import oracle_vbox.asc

2. Create the yum repository

Again as root, issue this command to create a new, blank repository file:

gedit /etc/yum.repos.d/virtualbox.repo

Now paste in these contents to the empty file:

[virtualbox]
name=RHEL/CentOS-$releasever / $basearch - VirtualBox
baseurl=http://download.virtualbox.org/virtualbox/rpm/rhel/6.0/$basearch
enabled=1
gpgcheck=1
gpgkey=http://download.virtualbox.org/virtualbox/debian/oracle_vbox.asc

Save the file changes and close down gedit. Just in passing, you might note that I’ve changed this file from the version which Oracle themselves makes available on the VirtualBox website. Specifically, their baseurl uses an environment variable, called $releasever, where I have hard-coded in the number 6.0. The trouble, of course, is that if you are using the latest versions of Scientific Linux or Centos, you’ll be picking up a releasever of 6.1 or 6.2 …and no such directory exists on the VirtualBox servers. You’d need to manually check out those server’s directory structure to see if that situation changes over time.

3. Install the Software

As root once more, the following one-liner will display all the different versions of VirtualBox that are available for installation:

yum search VirtualBox

You might see this sort of output in return:

Loaded plugins: refresh-packagekit
virtualbox | 951 B 00:00
virtualbox/primary | 4.4 kB 00:00
virtualbox 17/17
============== N/S Matched: VirtualBox ==============
VirtualBox-3.2.x86_64 : Oracle VM VirtualBox
VirtualBox-4.0.x86_64 : Oracle VM VirtualBox
VirtualBox-4.1.x86_64 : Oracle VM VirtualBox

This shows that Oracle keeps a couple of older versions of the software alive and available, should you need to use them. Most people, though, will really only need the latest version, so pick that from the list and issue an appropriate “yum install” command. In my case, given the above output, this command will do the right thing:

yum -y install VirtualBox-4.1.x86_64

It’s a 58MB download or so, and as it’s installed you might see this message appear:

Running Transaction
 Installing : VirtualBox-4.1-4.1.8_75467_rhel6-1.x86_64 1/1

Creating group 'vboxusers'. VM users must be member of that group!

This gives you the clue to the last stage of the installation process…

4. Assigning Group Privileges

The software installation has created a new O/S group, called vboxusers, but it won’t have made your user account a member of that group. That needs to be fixed.

From the Gnome top panel, clieck System > Administration > Users and Groups. Find your user details on the Users tab and double-click the entry. Switch to the Groups tab, scroll down and check the vboxusers group name:

Click [OK] to save the change, and you’re done, though you’ll need to log off and back on before the group membership changes take practical effect.

If you prefer doing everything at the command line, just edit /etc/group (as root, of course) and add a :your-username entry to the end of the vboxusers line, which will probably be the last line of the file. In my case, for example, the line ended up reading vboxusers:x:501:hjr -which simply means that user ‘hjr’ is now a member of the vboxusers group. (Again, it’ll take a log off and fresh log on before the new group membership actually takes effect).

Either way, you’re now done and can run the VirtualBox program successfully, with the program launcher being found in Applications > System Tools.

5. USB Support

The version of VirtualBox installed by the above procedure will be unable to access USB 2.0 devices that might be plugged into your physical host. However, this shortcoming can be fixed by installing the “Oracle/VirtualBox Extension Pack”. Download it from the VirtualBox website and then just double-click the file when the download completes. You should see the following appear:

Click the [Install] button there, agree to the license, authenticate as root and all should be done in a matter of seconds. You’re now ready to build and run fully-functional virtual machines.

A Phoenix?

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

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

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

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

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

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

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

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

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

Network Linux Installs

I’ve just put up a short, new article about performing installations of Enterprise-class Linux (i.e., Centos 5.6, Centos 6.0, Scientific Linux 6.1 and so on) via a network.

The basic principle is that you set up your Apache server once to serve up any or all of these distro/version combinations, boot your main server with a small net install CD and then have the main distro install itself by shipping files over the network from the Apache box.

The twist is that if you combine this with Kickstart technology to automate the main installation process, you basically have instant auto-install capability anywhere on the network, with no need to muck about with full-blown installation disks or ISOs. We once had a server at work which only shipped with a CD-ROM drive, whereas I’d downloaded the DVD installation media… this fixes that sort of mess!

As usual, make of it what you will!

An Apache Server on Centos 6

Now that we finally have a complete complement of zero-cost Enterprise Linux 6.0 clones available, I thought it might be time to revisit the idea of building a very small, very lightweight Apache server using nothing but Centos (or Scientific Linux) 6.

My existing article on building such an Apache server uses Ubuntu as its base distro, because I know of nothing that has smaller minimum hardware requirements -but this is a bit annoying, because if you go on to use RHEL-clones for an Oracle server, you have to master both RPM-based and apt-get-based distros. Life would be a lot simpler if you could use the one distro for everything, wouldn’t it?

Well, that’s what I thought too, so here’s my recipe for Apache + PHP talking to an Oracle database with the entire software stack running on two virtual machines running Centos 6 or Scientific Linux 6.

Creating the Server

I won’t detail the actual construction of a suitable web-server-capable virtual machine or the installation of its operating system here. The Ubuntu-based article I mentioned before does that quite adequately, I think. There are a couple of Centos/Scientific-specific issues that arise, though.

First thing to note, then, is that you can’t install Centos 6 (or Scientific Linux 6) in a virtual machine that’s configured with less than 512MB of memory. You can run Centos 6 in just 128MB, but the installer will bomb out at those sorts of RAM allocations. So the basic rule is: install your OS when your VM has 512MB then shut the thing down, reduce the allocated RAM, and re-start.

Second, you only need the 32-bit version of Centos or Scientific: 64-bits for running a trivial web server are completely unnecessary. (Note that the Centos link there has been altered since this article was first written to point to the version 6.1 isos, since version 6.0 is no longer made generally available).

Third, if you’re using Scientific Linux, you’ll have to select to perform a minimal install. If you’re using Centos, that is the default option anyway.

Fourth: once the O/S is installed, make sure the network itself is working (see my last post on how to do this). It won’t be by default, so you need to edit the /etc/sysconfig/network-scripts/ifcfg-eth0 script to make it function properly.

Additionally, and very importantly, you should disable SELinux by editing the /etc/sysconfig/selinux configuration file. By default, it will have a line that says SELINUX=enforcing. Change that to read SELINUX=disabled. You can’t get PHP talking to an Oracle database without doing this. Reboot to make the change take effect.

Finally, the commands you want to install the relevant Apache/PHP software bits and pieces are:

yum -y install httpd php nano unzip make
yum -y install gcc wget openssh php-devel php-pear libaio

The ‘httpd’ bit is the name for the Apache package itself; the other bits and pieces allow Apache to serve up something useful later on!

Configuring the Server

You first need to start the Apache service:

service httpd start

If you ever need to re-start the service (to pick up configuration changes, etc), the command is:

service httpd restart

To make the Apache bits start automatically at every reboot, issue this command:

chkconfig --level 23 httpd on

By default, despite having done all of the above, you won’t be able to connect to your new server from a remote browser: Centos/Scientific slap a firewall on that blocks access. You can completely disable the firewall with the command:

service iptables stop

That only works per re-boot, though, so to switch the firewall off completely, use this:

chkconfig iptables off

The more subtle approach, of course, would be to reconfigure the firewall to allow http traffic through -but that’s beyond the scope of this article and, in any case, I don’t need a firewall when I’m connecting one internal VM to another, so it’s probably overkill at this stage. If you insist on this approach, however, the advice given here would seem useful.

You’ll now be in a position to check that everything is working fine, provided you know your web server’s IP address. Assuming it’s 192.168.0.37 for the moment, then visiting http://192.168.0.37 in a remote browser should net you some sort of “it’s working” page (the Centos version is quite elaborate and is entitled “Apache 2 Test Page”; Scientific’s equivalent is a barebones “it works!” message).

You’ll also need to check that PHP is working OK, and for that I suggest you create a file called phpdata.php in the /var/www/html directory containing the following:

<?php
phpinfo();
?>

…which is just the code needed to display PHP’s configuration data. Then you can visit http://192.168.0.37/phpdata.php and you should see this sort of result:

Connecting the Server to an Oracle database

Installing OCI8 so that you can connect to Oracle via Apache is pretty much the same process as for Ubuntu:

Copy both the instantclient-basic and instantclient-sdk packages (available from the OTN website) to /var/www/html using something like Filezilla. As root, unzip both packages and create a necessary symbolic link:

cd /var/www/html
unzip instantclient-basic-linux32-11.2.0.2.0.zip
unzip instantclient-sdk-linux32-11.2.0.2.0.zip

cd instantclient_11_2
ln -s libclntsh.so.11.1 libclntsh.so

Download the relevant OCI8 library (the version numbers are specific, so check http://pecl.php.net/package/oci8 to make sure you get the latest):

cd /var/www/html
wget http://pecl.php.net/get/oci8-1.4.5.tgz

Install that new download:

pecl install oci8-1.4.5.tgz

This last command will prompt you to specify “the path to the ORACLE_HOME directory…”. At this point, you type in the following:

instantclient,/var/www/html/instantclient_11_2

…which tells the installer (a) that you’re using the instant client and not a full-blown Oracle client; and (b) that the path to the instant client files is /var/www/html/instantclient_11_2. Note that there are no spaces in any of that lot: just a comma separates the two components.

Finish off with some final configuration steps:

echo extension=oci8.so >> /etc/php.d/oci8.ini
echo /var/www/html/instantclient_11_2 >> /etc/ld.so.conf
ldconfig
echo ORACLE_HOME=/var/www/html/instantclient_11_2 >> /etc/profile
export ORACLE_HOME=/var/www/html/instantclient_11_2
service httpd restart

When you now visit your web server’s phpdata.php URL, you should see an OCI8 section appear in the PHP configuration information display.

After that, it should be relatively plain sailing: you just need to create a file which explains how to connect to an Oracle database and fetch some data. I suggest you create a file called oracle.php in the /var/www/html directory, containing this:

<?php
$myselect = "select * from scott.emp";
$oraconn = oci_connect('system', 'password', '//192.168.0.145/lindb');
$doquery = OCIparse($oraconn, $myselect) or die("Couldn't parse statement.");
OCIexecute($doquery) or die("Couldn't execute statement.");

while (OCIfetch($doquery))
 {$surname = OCIresult($doquery, ENAME);
  $salval = OCIresult($doquery, SAL);
  print '<b>'.$surname.'</b> '.$salval.'<br>';
 }
?>

That assumes my Oracle server is running at IP address 192.168.0.145; that my SYSTEM password is “password” (which would be extremely dumb if true!); and that I’ve got the SCOTT schema created within that database containing ye olde EMP table. If you now visit the URL http://192.168.0.37/oracle.php, you should get 14 rows returned in your web browser.

Network Configuration in minimal Linux installs

By default, the new Centos 6.0 distro performs a “minimal” install, as I mentioned last time. This is good because you end up with a very small footprint O/S (no Gnome, for example), leaving the server more resources to run the things you actually use servers for (like Oracle).

The downside to it, however, is that a feature of Red Hat Enterprise Server 6 (and therefore of all its clones -so this stuff applies to Scientific Linux 6, too) is that it defaults to managing your network connections with NetworkManager, which isn’t actually installed as part of a minimal install. The net result (no pun intended) is that your network doesn’t work when you first boot into your new, slimline O/S.

The fix is to run the command system-config-network-tui, which allows you to specify a fixed IP address manually. In Centos 6, however, even this tool is not installed as part of a minimal install (I guess they took the word ‘minimal’ literally), so you’ll end up having to edit by hand the /etc/sysconfig/network-scripts/ifcfg-eth0 file.

You’ll need to end up with something looking like this:

IPADDR=192.168.0.33
BOOTPROTO=none
NETMASK=255.255.255.0
GATEWAY=192.168.0.1
DNS1=192.168.0.1
DNS2=192.168.0.2
USERCTL=yes

Obviously, you replace those specific IP addresses with whatever suits your local environment. The USERCTL=yes line is optional: it lets non-root users control the interface. Once the file has the appropriate entries, a reboot will do to make the new settings take effect.

In Scientific Linux 6, the system-config-network-tui tool exists, so you could use that… or you can achieve all these edits with the nano text editor. The Centos 6 minimal install is less forgiving, however, and you’ll have to use vi (because nano is not installed as part of its minimal install option).

CentOS 6… finally

The first question about when CentOS 6 would be released, contained in this thread on the CentOS forums, was asked on December 2nd 2010. 42 pages and 8½ months later, there is finally an answer: it’s out now.

Of course, Red Hat themselves (and Oracle’s Enterprise Linux equivalent) have moved on in the meantime to version 6.1 -and Scientific Linux already have a matching 6.1 beta out, as I’ve mentioned before. Still, better late than never, I guess.

Personally, I think the CentOS devs have blown this, badly -and the tone of their commentary on the forums has been sniffy, at best: not exactly calculated to win friends and influence people, anyway. There have been ‘defections’ in droves to Scientific (count me amongst them), and I don’t see that being reversed any time soon.

There’s not a lot to say about the OS itself, of course (especially since we’ve been using its Scientific binary equivalents for months!), but I have to say I really dislike the fact that it defaults to doing a “minimal” install (not even a “minimal desktop”). It means you get this once the install has finished:

I realise you could argue this is actually a good thing: very Ubuntu Server-like, svelte and exactly what an enterprise-class Server ought to be doing. None of your fancy GUI stuff required etc. I’d certainly vote for (and my kickstart efforts have tried to create) a very much slimmed-down installation. Oracle users will, however, know that an X Server is pretty much a requirement (yup, I know it doesn’t have to be running on the actual Oracle server, but it’s simpler when it does), short of getting into response files and silent installs, so starting off this svelte is a bit of a problem!

Scientific Linux 6.0, by the way, defaults to a standard Desktop install -and, at this stage, I think that’s an easier way to go than CentOS’ choice. It’s also mildly interesting to note that Scientific Linux doesn’t have a “minimal install” option: they call it a “basic server” install instead. What’s more, that installs 514 packages, which is way more than the Centos 6 basic install does. Why supposedly binary-compatible distros vary like this, I can’t say, but I wish they wouldn’t!

There are other niggles with CentOS, too. The GUI installer has not had the Red Hat trademarks cleaned particularly well. Here’s what you see in Centos:

Notice the weird blank, blue bar stretching across the top of the screen? Compare that to Scientific’s installer:

They got the ‘de-branding’ right, CentOS didn’t… which seems a bit slack. I know it’s not a particularly important thing, but I suspect that when the little details like this are wrong, there are ‘polishing’ problems elsewhere. I could, of course, be wrong (probably).

Anyway, it’s things like this, together with the mammoth amount of time taken for the distro to get even this far, which mean I’m deeply suspicious of the quality of this particular release. (Yeah, I know I don’t pay for it, but my expectations are rational, if not reasonable).

Your mileage might vary, of course. And in the meantime, Gladstone has been updated to work on Centos 6.0.