Scientific Revelations

Continuing my recent theme of “CentOS is now not very useful”, I thought I should check up on how Scientific Linux version 7 was getting on… and got a bit of a surprise.

Scientific Linux was a joint project of CERN (the European atom-smashers) and Fermilab (the American equivalents) and dates back to the days of Red Hat Enterprise Linux 3 in 2004. So it’s venerable -and supported and developed by two prestigious and highly-trustworthy organisations. In the past, that’s been important -because the lack of transparency shown by the CentOS developers at times meant that there was precious little trust to be had in that particular distro!

In January this year, however, Red Hat announced it was ‘going into partnership’ with CentOS: it hired some of their lead developers, for example. If it’s possible to buy-out an open source project, Red Hat can fairly be said to have bought out CentOS. This announcement caused the CERN part of the Scientific Linux team to decide not to bother developing their own SL7 distro: instead, they said, they would adopt CentOS 7 and seek to become a ‘CentOS Special Interest Group’, giving them the chance to customise the basic CentOS installation.

Only the Fermilab developers decided to pursue their own, independent Scientific Linux distro into its version 7.x incarnation.

I’m glad someone is still pursuing a dedicated Scientific Linux distro: the competition and point of comparison with CentOS has been quite important in the past (especially when the CentOS team appeared to have completely lost the plot, around the time that version 6.0 was released). If all Enterprise Linux distros were just to be respins of CentOS (which is now, remember, essentially a not-paid-for subsidiary of Red Hat itself), we would be much the poorer for it. I don’t fancy a world in which I only have a “choice” between Red Hat and Oracle, for example.

Happily, Fermilab have indeed pushed on and a release of their version 7.0 is nearly upon us: the second beta was made available last Friday, for example. Here’s to their continued development efforts: we need them to succeed and to keep on wanting to succeed.

Scientifically 6.4

You may have missed the announcement, since it was made just before Good Friday. I was certainly in New Zealand at the time… but, no matter: Scientific Linux 6.4 has been released.

I’ve been using the beta since early March, and I see no significant difference between it and the new, final release. I also don’t see a hell of a lot of difference between SL6.4 and SL6.3 …but that’s about par for the course on RCSL point releases. The change log indicates that some under-the-hood stuff has been improved, though.

Anyway: downloadable at the usual places.

Firefox 10 on Scientific Linux 6.2

Red Hat recently decided that they would jump from Firefox 3.6.26 (which is pretty long in the tooth) straight to the 10.x series: the relevant packages are therefore available automatically to proper Red Hat Enterprise Server users.

It takes a while, of course, for ‘official’ Red Hat packages to make their way onto Centos and Scientific Linux repositories -but Centos got them anyway on or about February 25th (they’re in the updates repository) and Scientific Linux has had them in the fastbugs repository since about the same time.

For Scientific Linux 6.2 x86_64, therefore, here’s what you do to get the latest Firefox (all done as root, of course):

  • nano /etc/yum.repos.d/sl-other.repo
  • set enabled=1 for the sl-fastbugs repository
  • yum update firefox

That should trigger a 33MB-or-thereabouts download, after which you should be set to go. Personally, I’d then edit the repo file once more and put the enabled back to ’0′ so that you don’t keep being bombarded with suggestions for new updates to things.

Bear in mind that, eventually, the Firefox packages will make it into ‘standard’ repositories (potentially, within days), so this approach is only if you are truly impatient (like me!) and want the latest Firefox right now.

New Science…

Am happy to report that Scientific Linux 6.2 is properly and finally out, thus completing the ‘set’ of RHEL 6.2-compatible freebie distros. (CentOS 6.2 was released just before Christmas).

As a content user of the Scientific Linux 6.1 release on my desktop since around the start of December 2011, the new release means either I have to sit there pretending I don’t care about having the latest and greatest, or I can just upgrade and be done with it. I rather suspect the latter will be the course I take!

Not that there’s a huge difference between the versions, of course.

Anyway, the relevant ISOs are available here.

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:

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:

name=RHEL/CentOS-$releasever / $basearch - VirtualBox

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, click 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.

Stellarium on Scientific Linux 6.1

I have updated my recent article on how to configure Scientific Linux 6.1 to be your desktop operating system in one crucial respect: the original instructions on how to install Stellarium (the world’s best astronomy program bar none) didn’t work properly.

The original instructions were to add the repoforge repository to the list of available respositories and then simply do a yum install stellarium.

This technique is very convenient and appears to work -but, unfortunately, it installs version 10.2 of Stellarium …which has a known bug whereby its display is garbled when using recent NVidia graphics drivers (I have no idea if ATI or Intel drivers are similarly a problem, but from my reading it appears they might be). You end up with this nonsense when you run the program:

Note the garbled text menus, the complete lack of stars in the main part of the window and the ‘fuzzy’ display of the various toolbars. The solution is, I’m afraid, to uninstall the version of Stellarium that comes from the repositories and, instead, to download source code and compile it. Normally, I’d run a mile from self-compilation, but in this case it is (a) necessary and (b) simple. It also, not incidentally, (c) results in a fully working version of Stellarium.

The details are as follows (do all the following as root):

yum remove stellarium

(which cleans out any existing Stellarium installation).

Then: Download the source code from, saving it to (say) your Desktop directory. Next, right-click the downloaded tarball and select the Extract Here menu option. That will create a directory called something like /home/hjr/Desktop/stellarium-11.1. Change to that directory and create a couple of new sub-directories, as follows:

cd stellarium-11.1
mkdir -p builds/unix
cd builds/unix

Again as root, and at a command prompt, type the following commands:

yum install gcc gcc-c++ libstdc++ cmake cmake-gui gettext gettext-devel mesa-libGL-devel mesa-libGLU-devel zlib-devel libpng-devel freetype-devel boost-devel libjpeg-devel qt-devel doxygen graphviz subversion make

That gets the software dependencies installed. Then you can (again as root) issue three simple commands:

cmake ../..
make install

Note that the cmake command is issued whilst you’re sitting in your stellarium-11.1/builds/unix directory. Hence the use of ‘..’ to reference other directories, relative to that.

Now you have the latest version of Stellarium installed and can (as yourself) simply type the command stellarium to launch the thing. This time, it should all work as expected:

You’ll probably want to create a new launcher for the program on your top panel because the self-compile route doesn’t create nice menu options to launch the program. If you’d like to edit the Applications menu and add an item that points to your freshly-installed application, you’ll need to install alacarte (easily done with a simple yum install alacarte). In either case, you’ll end up configuring an application launcher to simply run the command stellarium.

A scientific desktop

Following my recent decision to chuck over Fedora 16 in favour of Scientific Linux, I’ve put together a short(ish) article detailing how I knocked Scientific Linux 6.1 x86_64 into usable shape as a desktop environment. It’s tailored very much to the way I want my desktop to be, I guess, but there may be stuff in there that someone else will find of use at some point.

Good News/Bad News

Good News: Scientific Linux 6.1 is out in (very stable) Beta. I get mine from

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.

Scientifically Flash

Red Hat Enterprise Server 6 was released a couple of months back (in November 2010, if memory serves). I liked the look of it (basically, Fedora 12 with a lot of Enterprise-class stability added), but was looking forward to trying it out for free when Centos 6 was released. Two months later, however, and there’s still no real sign of an actual Centos 6 (though this post on the developer’s list suggests that there should be a beta available Real Soon Now).

Not wanting to wait any further, therefore, I installed Scientific Linux 6 the other day. It’s only available as an Alpha version (number 8 or 9, I believe) and I got my copy here. Alpha or not, it seems pretty stable to me, and I recommend it.

Scientific Linux is another one of those distros which are built from the original Red Hat source code, once various trademarks and logos have been removed. It’s therefore practically binary-equivalent to the “real thing”, but is made available for zero cost, and updates are available from standard repositories without payment. If you care about such things, the distro gets its name from the fact that CERN and Fermilab (amongst others) use it: true geekdom indeed!

Oracle installs on it fine, incidentally.

Getting Flash working is a bit of a trial (nothing new there, then). Basically, the download from Adobe is a 32-bit library (called which you unzip and then copy (to /usr/lib/mozilla/plugins). But you also have to issue (as root) the following command:

yum install nspluginwrapper.i686 alsa-plugins-pulseaudio.i686

Once you re-start Firefox (version 3.6.13 after a yum update, if you’re wondering), you’ll be able to watch the videos on (for example) the BBC News website -my standard Flash test!- without a problem.

To install other packages to the thing which aren’t in the “standard” repositories, such as Stellarium, I simply followed the instructions here about adding the RPMForge repository. Binary compatibility is a wonderful thing -it means the instructions, though ostensibly meant for Centos, apply to Scientific Linux perfectly well, too.

Anyway: Scientific Linux. If you’re at all concerned that CentOS seems to be losing a bit of its mojo, it’s a viable alternative!