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!

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.

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.

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!

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.

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.

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).

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.

Bad News: Centos 6.0 still hasn’t been released.

Good News: Scientific Linux 6.1 has a network install boot ISO (as SL 6.0 did, but SL 5.6 didn’t)

Bad News: the Scientific Linux network install boot ISO is over 200MB in size -so you almost might as well install from the original CDs or DVDs! By way of comparison, the Centos 5.6 netinstall boot ISO was only 10MB in size. Maybe not so important when $4 USB drives come in 2GB sizes and up, but annoying nonetheless. I notice Fedora 15′s net install ISO is similarly huge… progress, I guess!

Even Badder News: you can’t use the Centos 5.6 netinstall boot ISO to kick off a Scientific Linux 6.1 install. (At least, I’ve not managed it yet!)

Good News: Gladstone has been updated to work with the 6.1 version of Scientific Linux.

The new article takes you from building a virtual machine, installing the operating system using Kickstart configuration files, running Gladstone to get all the Oracle prerequisites right through to getting Firefox displaying Flash properly and setting a fixed IP address.

Available in the usual place.

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 is obviously not far away (the beta I linked to above is incredibly stable), 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. I have mentioned this before, but now I’m getting serious about it: there will be no more Centos-compatible releases of Gladstone, even if they finally get version 6.0 out in the next couple of weeks.