Converting a Red Hat Linux 5.8 install to CentOS

Recently, we wanted to convert from Red Hat Enterprise Linux to CentOS. CentOS is a build of Red Hat Enterprise Linux from all of the open source packages that are released by Red Hat. There are a number of instructions in this regard, but the overall process is the same. My conversion was a Red Hat Enterprise Linux 5.8 to CentOS 5.8.

I started by following these instructions from saylinux.net (or thuannvn.blogspot.com). However, I had to adjust the instructions for RHEL 5.8 – just look in the directory on mirror.centos.org for the proper version of the packages you need. You won’t be able to use yum to download the packages because you want to pull not from RHEL but from CentOS – and yum will be getting updated as well.

Firstly, do a cleanup:

yum clean all

Then, create a working space where RPMs can be downloaded:

mkdir ~/centos
cd ~/centos

Now download the relevant CentOS key and import it:

wget http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5
rpm --import RPM-GPG-KEY-CentOS-5

Then, get relevant packages from CentOS – note these instructions will pull i386 packages or x86_64 packages depending on your system:

wget http://mirror.centos.org/centos/5/os/`uname -m`/CentOS/centos-release-5-8.el5.centos.i386.rpm
wget http://mirror.centos.org/centos/5/os/`uname -m`/CentOS/centos-release-notes-5.8-0.i386.rpm
wget http://mirror.centos.org/centos/5/os/`uname -m`/CentOS/yum-3.2.22-39.el5.centos.noarch.rpm
wget http://mirror.centos.org/centos/5/os/`uname -m`/CentOS/yum-updatesd-0.9-2.el5.noarch.rpm
wget http://mirror.centos.org/centos/5/os/`uname -m`/CentOS/yum-fastestmirror-1.1.16-21.el5.noarch.rpm

You don’t have to use wget either; you could – if you want – instead use a text browser like elinks to get the same packages. Using elinks allows you to get the most recent version without stumbling over the version number – if the package is updated, you don’t have to guess at the version numbers in the filename.

elinks http://mirror.centos.org/centos/5/os/`uname -m`/CentOS/

Delete unnecessary packages from RHEL – in particular, those that use the Red Hat Network (RHN):

rpm -e yum-rhn-plugin rhn-client-tools rhn-setup rhn-check rhnsd

If there are any other packages that require yum-rhn-plugin or related packages, add it to the list of packages to remove.

Now update all of the packages that were downloaded:

rpm -Uvh --force *.rpm

Lastly, perform an upgrade to fully update the system from the new CentOS repositories:

yum upgrade

For best practices, you probably should reboot here as well – thus loading new libraries, deleting old files, and activating new kernels.

Putting Fedora 16 onto a Dell Optiplex 745

I purchased a Dell Optiplex 745 (ultra small form factor) from a used equipment sale at the local university. I had hoped that it would be low power as well, but that does not seem to be the case – although a more modern computer is always going to be more efficient (or at least you would think so).

First, I had to reset the BIOS as it had been password protected against changes. Resetting the BIOS was simple: remove the password jumper in the system, boot fully once, then replace the password jumper. The full description is available at eHow. The only sticking point was trying to find the jumper in the case; it turned out to be roughly in the center of the board underneath one of the airflow covers. If you are looking at the system from the top – with the front facing you – the relevant cover is in the back left corner, and the jumper (a tiny blue shiny plastic jumper with extended grasping handle) is towards the center of the board.

I’ve not yet found how to reset the “title” that comes up when the system is booted; this does not seem to be in the BIOS settings anywhere. I could fully reset the CMOS entirely (rather than just the password) but that always scares me – what else will be lost?

Trying to use the CDROM, I ran into some difficulties. It appears it may be easy to put the CDROM in incorrectly; be sure to put it in the right way and seat it fully.

I decided I would put Fedora 16 on this system – and went with Fedora 16 64bit. This went quite smoothly and the system runs well. Specifically, I went with the Fedora 16 XFCE spin – which means it runs fast and light. Running a lightweight desktop on a fast machine is even nicer than I would have expected. I did load WindowMaker but haven’t yet tried it. Who knows – I might try 9wm once.

I loaded up everything that one needs for a home desktop: DVD playback, MP3 playback, and so on. I couldn’t get Parole to work with DVDs, so I went with Totem instead. In the same manner, I installed RhythmBox to play MP3s. I also had no problems getting Flash or Java to work. On the web, an excellent resource for all of these steps is at LinuxForDummies. Video and sound were recognized without problem.

This is definitely a nice setup: both the hardware (the Optiplex 745) and the software (Fedora XFCE 64-bit spin) are recommended.

HowTo Fix: “[…] only available with the XS version of Scalar::Util”

Recently, we upgraded our systems, and one of the updates was an update to Perl. After this update, a portion of Bugzilla failed to work as expected; the problem turned out to be in SOAP::Lite:

# perl -MSOAP::Lite -e "print;"
weaken is only available with the XS version of Scalar::Util at /usr/lib/perl5/vendor_perl/5.8.8/SOAP/Lite.pm line 2502
BEGIN failed--compilation aborted at /usr/lib/perl5/vendor_perl/5.8.8/SOAP/Lite.pm line 2502.
Compilation failed in require.
BEGIN failed--compilation aborted.

This is on a machine running Red Hat Enterprise Linux (RHEL) 5.7. The bug (Bug #375621) was initially reported back in November 2007 with RHEL 5.2. The final resolution came with bug #594768, where the problem was explained completely and resolved for good in RHEL 6.

The problem is that the updates to Perl are overwriting files added via CPAN. When this happens, versions that have an XS version are reverted back to their original forms without XS support. This appears to happen with Scalar::Util the most.

The fix is to reinstall the CPAN modules affected by the Perl upgrade. A force will be necessary. For example, this command to install Scalar::Util:

cpan> force install Scalar::Util
Running install for module Scalar::Util
Running make for G/GB/GBARR/Scalar-List-Utils-1.23.tar.gz
Fetching with LWP:
  ftp://cpan.uchicago.edu/pub/CPAN/authors/id/G/GB/GBARR/Scalar-List-Utils-1.23.tar.gz
CPAN: Digest::MD5 loaded ok
Fetching with LWP:
  ftp://cpan.uchicago.edu/pub/CPAN/authors/id/G/GB/GBARR/CHECKSUMS
Checksum for /root/.cpan/sources/authors/id/G/GB/GBARR/Scalar-List-Utils-1.23.tar.gz ok
Scanning cache /root/.cpan/build for sizes
Scalar-List-Utils-1.23/
Scalar-List-Utils-1.23/Changes
Scalar-List-Utils-1.23/lib/
Scalar-List-Utils-1.23/ListUtil.xs
Scalar-List-Utils-1.23/Makefile.PL

Once the relevant modules are reinstalled, the files will be reverted back to the way they were before the upgrade took place – and all should be working again.

Using Meta-packages to Standardize Servers

Both Ubuntu and Red Hat offer meta-packages which have no files of their own, but depend on others – thus requiring a set of packages to be present. You can use these packages to require a set of software to be present on a server, especially those that are not normally installed by the vendor’s install process.

A meta-package can save you time – you don’t have to install each package one at a time. A meta-package can also be included as part of a Puppet environment, so that all servers will be kept up-to-date with the current set of packages. A meta-package can also be a part of an automatic install process, also bringing in all necessary software and simplifying the installation steps.

In Ubuntu, creating your own meta-packages is made easy by using the equivs package. With RPM, you’ll have to create a meta-package using rpm-build and the appropriate SPEC file.

The only way that using a meta-package will truly save time is if you are using a program like APT or YUM to do installations because they will automatically compute the dependencies required and install them automatically when the meta-package is installed.

With a meta-package, you can require a set of packages that should be on every server – as well as force some packages to be removed. You can create a meta-packages that includes all packages that should be on a server, but aren’t usually installed (like gawk, logrotate, sysstate, ntp, logwatch, make, and m4 for instance). When the package server-main is then installed, all of its dependencies will also be installed. Any packages that are listed as conflicting packages will also be removed: packages like unattended-upgrades and command-not-found for instance.

Meta-packages could be created for packages that are from the Ubuntu Main repository, and for those packages that are in the Ubuntu Universe repository. This makes it simple to only include software from the Main repository and preclude those packages that are from the Universe repository.

These meta-packages could then be added to a local repository and added to a system during installation; this simplifies the package installation part of the install process and allows you to update any currently installed systems simply.

As an example, here’s my list for requirements (put into server-main) from the Ubuntu Main Repository:

  • lvm2
  • byobu
  • ruby
  • vim
  • snmpd
  • snmp
  • mlocate
  • postfix
  • ltrace
  • strace
  • wget
  • ntp
  • m4
  • make
  • ifenslave
  • dnsutils
  • procps
  • sysstat
  • logrotate
  • logwatch
  • sharutils
  • pdksh
  • dc
  • bsd-mailx
  • nut
  • finger
  • xfsdump
  • xfsprogs

And from the Universe repository, these are my suggested requirements (used as dependencies for server-universe):

  • iperf
  • jwhois
  • apt-file
  • chkconfig
  • atop
  • dstat
  • maatkit

Log Rotation for MySQL using logrotate

The logrotate utility is a powerful and underrated utility used to rotate logs. It is one of Red Hat’s lesser known utilities; even so, it is available for a number of platforms, including Ubuntu.

However, its set up for MySQL is missing on Red Hat and incomplete on Ubuntu.

For Ubuntu, there is no rotation of the slow query logs. To rotate these logs, just add them to the standard Ubuntu logrotate file for MySQL – that is, /etc/logrotate.d/mysql-server. Add the logs to rotate to the beginning of the file, adding to the list of files already present there.

For Red Hat, a complete MySQL log rotation file is needed as there is none at all. The MySQL logrotation script was removed as part of a security update to Fedora Core 4 back on 17 May 2006, and later removed from Red Hat Enterprise Linux 4 Update 4. The reasoning was detailed in Bug #180639 (not available?) and Bug #182025. Since then, this missing logrotate file has been the subject of several bugs (such as Bug #547007) and also of message threads like this one from Red Hat’s rhelv5-list in July of 2007.

The response to all these queries is that the MySQL logrotate script is broken and it’s up to MySQL to fix it. However, this does not seem to take into account the new FLUSH LOGS command, and admins everywhere are creating their own scripts.

Over at Question Defense, Alex has a fabulous description of the entire process – from enabling logging through implementing log rotation. However, this process uses ~/.my.cnf to automatically log in; better is to use a file like /etc/mysql/maint.cnf the way that Debian (and Ubuntu) does it. In that case, Debian creates a special user and a password to go with it, and puts these into a file /detc/mysql/debian.cnf; here is a sample debian.cnf:

# Automatically generated for Debian scripts. DO NOT TOUCH!
[client]
host     = localhost
user     = debian-sys-maint
password = i5Px6N4SZ9UhfSWa
socket   = /var/run/mysqld/mysqld.sock
[mysql_upgrade]
host     = localhost
user     = debian-sys-maint
password = i5Px6N4SZ9UhfSWa
socket   = /var/run/mysqld/mysqld.sock
basedir  = /usr

For most purposes, only the [client] section is needed, along with the first three entries (host, user, and password). You could also specify the section as [mysqladmin] instead, which would limit the username and password to being used for mysqladmin only – which is the tool used during log rotation.

The critical command is this one:

/usr/bin/mysqladmin --defaults-file=/etc/mysql/logrotate.cnf

…where logrotate.cnf contains username and password details as described above. All the rest of the logrotate file is settings and script-bulletproofing:

# Modified Ubuntu logrotate script for MySQL server
#
# Untested under Red Hat, but should work: filenames will have to be changed
/var/log/mysql.log /var/log/mysql/mysql.log /var/log/mysql/mysql-slow.log {
        daily
        rotate 7
        missingok
        create 640 mysql adm
        compress
        sharedscripts
        postrotate
                test -x /usr/bin/mysqladmin || exit 0
                MYADMIN="/usr/bin/mysqladmin --defaults-file=/etc/mysql/logrotate.cnf"
                if [ -z "`$MYADMIN ping 2>/dev/null`" ]; then
                  if killall -q -s0 -umysql mysqld; then
                    exit 1
                  fi 
                else
                  $MYADMIN flush-logs
                fi
        endscript
}

Turning off NET-SNMP overlogging

In the normal configuration – both on Red Hat and Ubuntu – you’ll find that SNMP is filling your logs with an endless amount of log entries, especially if you have monitoring tools that use SNMP every five minutes. They’ll generate messages like this:

Jan  8 13:45:02 example snmpd[2048]: Connection from UDP: [10.0.0.1]:51890
Jan  8 13:45:02 example snmpd[2048]: Received SNMP packet(s) from UDP: [10.0.0.1]:51890
Jan  8 13:45:02 example last message repeated 2 times

To get rid of these, change the priority levels that are logged by NET-SNMP. This can be done by changing the options sent to SNMP.

Look for a file /etc/default/snmpd or /etc/sysconfig/snmpd or similar. There should be a set of SNMP options – probably with an option like this one:

-Ls d

Change this option to be:

-LS5d

This will log everything at level NOTICE or higher (that is, severity level 5 down to severity 0). The severity levels used are those used by syslog; they are described in syslog(3).

This works because the messages being seen are logged at level INFO; by not logging items at that severity level the log entries no longer clutter the syslog files.

However, there is another set of messages that are common to NET-SNMP logs:

Sep  7 09:47:29 burp snmpd[19242]: diskio.c: don't know how to handle 9 request
Sep  7 09:47:29 burp snmpd[19242]: diskio.c: don't know how to handle 10 request
Sep  7 09:47:29 burp snmpd[19242]: diskio.c: don't know how to handle 11 request

This is the result of a bug (Red Hat Bugzilla #474093 – login required) which causes these “errors” when the SNMP diskIOTable is traversed. Red Hat fixed this bug back in September of 2009.

According to this message by Chris Rizzo, Red Hat stated:

The message that you see here is a result of querying for statistics
that are not available on the linux system. Requests 9, 10, and 11 are
defined as:

#define DISKIO_LA1 9
#define DISKIO_LA5 10
#define DISKIO_LA15 11

You can see where these statistics pop up by querying the SNMP diskIOTable using this command:

snmptable -v 2c -c public host diskIOTable

The output will look like this:

SNMP table: UCD-DISKIO-MIB::diskIOTable

 diskIOIndex diskIODevice diskIONRead diskIONWritten diskIOReads diskIOWrites diskIOLA1 diskIOLA5 diskIOLA15 diskIONReadX diskIONWrittenX
           1         ram0           0              0           0            0         ?         ?          ?            0               0
           2         ram1           0              0           0            0         ?         ?          ?            0               0
           3         ram2           0              0           0            0         ?         ?          ?            0               0
           4         ram3           0              0           0            0         ?         ?          ?            0               0
           5         ram4           0              0           0            0         ?         ?          ?            0               0
           6         ram5           0              0           0            0         ?         ?          ?            0               0
           7         ram6           0              0           0            0         ?         ?          ?            0               0
           8         ram7           0              0           0            0         ?         ?          ?            0               0
           9         ram8           0              0           0            0         ?         ?          ?            0               0
          10         ram9           0              0           0            0         ?         ?          ?            0               0
          11        ram10           0              0           0            0         ?         ?          ?            0               0
          12        ram11           0              0           0            0         ?         ?          ?            0               0
          13        ram12           0              0           0            0         ?         ?          ?            0               0
          14        ram13           0              0           0            0         ?         ?          ?            0               0
          15        ram14           0              0           0            0         ?         ?          ?            0               0
          16        ram15           0              0           0            0         ?         ?          ?            0               0
          17        loop0           0              0           0            0         ?         ?          ?            0               0
          18        loop1           0              0           0            0         ?         ?          ?            0               0
          19        loop2           0              0           0            0         ?         ?          ?            0               0
          20        loop3           0              0           0            0         ?         ?          ?            0               0
          21        loop4           0              0           0            0         ?         ?          ?            0               0
          22        loop5           0              0           0            0         ?         ?          ?            0               0
          23        loop6           0              0           0            0         ?         ?          ?            0               0
          24        loop7           0              0           0            0         ?         ?          ?            0               0
          25          sr0           0              0           0            0         ?         ?          ?            0               0
          26          sda  2840214016     1178369536     8946299      2080062         ?         ?          ? 990682692096     18358238720
          27         sda1      598016         208896          82            8         ?         ?          ?       598016          208896
          28         sda2        2048              0           2            0         ?         ?          ?         2048               0
          29         sda3     2286592        4649984         449          332         ?         ?          ?      2286592         4649984
          30         sda5  2836463104     1173473792     8945636      2079527         ?         ?          ? 990678941184     18353342976
          31          sdb  2960873984     1173473792     1940422      2079476         ?         ?          ? 990803352064     18353342976
          32         sdb1      638976              0          83            0         ?         ?          ?       638976               0
          33         sdb2      798720              0         153            0         ?         ?          ?       798720               0
          34         sdb3        6144              0           2            0         ?         ?          ?         6144               0
          35         sdb5  2958672384     1173473792     1940080      2079284         ?         ?          ? 990801150464     18353342976
          36          md0  3051716608     1727252992       93765      1641387         ?         ?          ?   3051716608     14612154880
          37          sdc  3067452416      425118208     1640751      3638614         ?         ?          ? 101851700224    438511782400
          38         sdc1  3067317248      425118208     1640721      3638613         ?         ?          ? 101851565056    438511782400
          39          sdd      307712              0          76            0         ?         ?          ?       307712               0
          40         sdd1      147968              0          37            0         ?         ?          ?       147968               0
          41         sdd2      131072              0          32            0         ?         ?          ?       131072               0

Towards the right side of center, you can see the metrics diskIOLA1, diskIOLA5, diskIOLA15; these are unsupported on Linux (as marked by the ? in each column). These are the 1 minute average disk load (as a percentage), the 5 minute average disk load, and the 15 minute average disk load respectively.

The three have SNMP OIDs of .1.3.6.1.4.1.2021.13.15.1.1.9 and .1.3.6.1.4.1.2021.13.15.1.1.10 and .1.3.6.1.4.1.2021.13.15.1.1.11 respectively – thus, the logged complaint of not knowing how to handle request 9 (or 10 or 11).

Without changing the code, there doesn’t seem to be any way to eradicate this message if you are querying the diskIOTable. Red Hat fixed the bug, perhaps others will? The bug remains on Ubuntu Lucid Lynx, unfortunately.

Installing Dell OpenManage with Ubuntu and Red Hat Linux

Dell OpenManage Server Administrator is a program for managing Dell machines. Dell provides support for Windows, SUSE Linux Enterprise Server (SLES), and Red Hat Enterprise Linux (RHEL).

There is, however, no support for Ubuntu whatsoever and no support for a Red Hat Yum Repository. Both of these failings are somewhat rectified by kind people working for Dell. Instructions from Dell regarding the Ubuntu APT repository and the Red Hat Yum Repository are available. The Dell wiki has more details on the Red Hat repository as well.

Over at Keith’s Code there is a fantastic tutorial on how to get Dell OMSA running on Ubuntu.

To get the yum repository loaded into Red Hat Enterprise Linux, just pull this file from the web and execute it:

wget -q -O - http://linux.dell.com/repo/hardware/latest/bootstrap.cgi | bash

Note that these directions come from Dell’s repository page and the file itself comes from linux.dell.com. It pulls in some RPMs that load the repository and update the cache with the available files. This is what the execution looked like for me:

Downloading GPG key: http://linux.dell.com/repo/hardware/latest/RPM-GPG-KEY-dell
    Key already exists in RPM, skipping
Downloading GPG key: http://linux.dell.com/repo/hardware/latest/RPM-GPG-KEY-libsmbios
    Importing key into RPM.
Write repository configuration
Downloading repository RPM
Installing repository rpm: http://linux.dell.com/repo/hardware/latest/platform_independent/rh50_64/prereq/dell-omsa-repository-2-5.noarch.rpm
Installing yum plugins for system id
Loaded plugins: rhnplugin, security
This system is not subscribed to any channels.
RHN channel support will be disabled.
dell-omsa-indep                                                                                                                       | 1.9 kB     00:00
dell-omsa-indep/primary                                                                                                               |  87 kB     00:00
dell-omsa-indep                                                                                                                                      655/655
dell-omsa-specific                                                                                                                    | 1.9 kB     00:00
dell-omsa-specific/primary                                                                                                            |  87 kB     00:00
dell-omsa-specific                                                                                                                                   655/655
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package yum-dellsysid.x86_64 0:2.2.26-6.2.el5 set to be updated
--> Processing Dependency: smbios-utils-python >= 2.2.0 for package: yum-dellsysid
--> Running transaction check
---> Package smbios-utils-python.x86_64 0:2.2.26-6.2.el5 set to be updated
--> Processing Dependency: python-smbios = 2.2.26-6.2.el5 for package: smbios-utils-python
--> Running transaction check
---> Package python-smbios.x86_64 0:2.2.26-6.2.el5 set to be updated
--> Processing Dependency: libsmbios = 2.2.26-6.2.el5 for package: python-smbios
--> Processing Dependency: python-ctypes for package: python-smbios
--> Running transaction check
---> Package libsmbios.x86_64 0:2.2.26-6.2.el5 set to be updated
---> Package python-ctypes.x86_64 0:1.0.2-1.1.el5 set to be updated
--> Finished Dependency Resolution
 
Dependencies Resolved
 
=============================================================================================================================================================
Package                                   Arch                         Version                               Repository                                Size
=============================================================================================================================================================
Installing:
 yum-dellsysid                             x86_64                       2.2.26-6.2.el5                        dell-omsa-indep                           16 k
Installing for dependencies:
 libsmbios                                 x86_64                       2.2.26-6.2.el5                        dell-omsa-specific                       1.5 M
 python-ctypes                             x86_64                       1.0.2-1.1.el5                         dell-omsa-specific                       215 k
 python-smbios                             x86_64                       2.2.26-6.2.el5                        dell-omsa-specific                        71 k
 smbios-utils-python                       x86_64                       2.2.26-6.2.el5                        dell-omsa-specific                        63 k
 
Transaction Summary
=============================================================================================================================================================
Install      5 Package(s)
Update       0 Package(s)
Remove       0 Package(s)
 
Total download size: 1.9 M
Downloading Packages:
(1/5): yum-dellsysid-2.2.26-6.2.el5.x86_64.rpm                                                                                        |  16 kB     00:00
(2/5): smbios-utils-python-2.2.26-6.2.el5.x86_64.rpm                                                                                  |  63 kB     00:00
(3/5): python-smbios-2.2.26-6.2.el5.x86_64.rpm                                                                                        |  71 kB     00:00
(4/5): python-ctypes-1.0.2-1.1.el5.x86_64.rpm                                                                                         | 215 kB     00:00
(5/5): libsmbios-2.2.26-6.2.el5.x86_64.rpm                                                                                            | 1.5 MB     00:06
-------------------------------------------------------------------------------------------------------------------------------------------------------------
Total                                                                                                                        222 kB/s | 1.9 MB     00:08
Running rpm_check_debug
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
  Installing     : python-ctypes                                                                                                                         1/5
  Installing     : libsmbios                                                                                                                             2/5
  Installing     : python-smbios                                                                                                                         3/5
  Installing     : smbios-utils-python                                                                                                                   4/5
  Installing     : yum-dellsysid                                                                                                                         5/5
 
Installed:
  yum-dellsysid.x86_64 0:2.2.26-6.2.el5
 
Dependency Installed:
  libsmbios.x86_64 0:2.2.26-6.2.el5 python-ctypes.x86_64 0:1.0.2-1.1.el5 python-smbios.x86_64 0:2.2.26-6.2.el5 smbios-utils-python.x86_64 0:2.2.26-6.2.el5
 
Complete!
Loaded plugins: dellsysid, security
Cleaning up Everything
Done!

Activating the APT repository on an Ubuntu system is even easier; add this file to /etc/apt/sources.list.d/ and do an apt-get update:

# Get latest Dell OpenManage software
deb http://linux.dell.com/repo/community/deb/latest /

Dell’s OMSA works with SNMP traps and with IPMI, so make sure that these are fully supported and enabled. There is a good introduction to IPMI from Intel that is often referenced, but is missing: it is available here (and is referenced as 25133701.pdf in links elsewhere). There’s also a good quick overview of IPMI from Terry Gleidt.

Novell and VMware Team Up

VMware announced in June that Novell’s SUSE Linux Enterprise Server (SLES) will be shipped with every copy of VMware’s vSphere product. In addition, VMware sales staff will have incentives to sell SLES. During the recent sales call by Novell, they expanded on the details of the enhanced partnership.

According to VMware’s page for SLES on VMware, it also sounds as if current vSphere customers would be eligible for a supported copy of SLES as well.

This is incredible news – it means that SUSE may be able to gain some traction in the data center. I’ve been partial to SUSE in some ways ever since I found that XFS (and JFS!) had been supported in SUSE Linux for years before Red Hat did – SUSE has always supported technologies first, providing more value than Red Hat did.

I also supported SUSE Linux in the data center in the past; it has been rock solid (as is Red Hat). SUSE Linux has a lot to offer – as does OpenSUSE (which just recently introduced 11.3).

Red Hat has always done well – as it should – but SUSE has been in the shadows for too long.

It has also been noted that VMware could be a company that buys SUSE and Novell’s Linux business. VMware was bought by EMC not that long ago. Cisco also has a joint venture with EMC that includes VMware products. Is it possible that Cisco will be shipping products with SLES on them?

A New Init for Fedora 14

Apparently, a new project (to replace init, inetd, and cron) named systemd is nearing release and will be used to replace upstart in Fedora 14 (to be released in November – with Alpha Release due today!).

There is a healthy crop of init replacements out there, and the field is still shaking out. Replacing init – or specifically, System V init and init scripts – seems to be one of those never-ending projects: everyone has an idea on how to do it, no one can agree on how.

Let’s recap the current crop (excluding BSD rc scripts and System V init):

I am still waiting for the shakeout – it bugs me that there are dozens of different ways to start a system, and that none of them have taken over as the leader. For years, BSD rc scripts and System V init have been the standard – and both have stood the test of time.

My personal bias is towards SMF (OReilly had a nice article on it) and towards simpleinit – but neither has expanded like upstart has.

So where’s the replacement? Which is The One? It appears that no one is willing to work within a promising project, but rather starts over and creates yet another replacement for init, fragmenting the market further.

Lastly, if the current init scheme is so bad, why hasn’t anything taken over? Commercial UNIX environments continue to use the System V scheme, with the sole exception of Solaris which made the break to System Management Facility (or SMF). Why doesn’t HP-UX or AIX use SMF or Upstart if the current environment is horrible?

Sigh. It’s not that the current choices of replacement are bad – it’s just that there are so many – and more keep coming up every day. Perhaps we can learn something about the causes of this fragmentation from a quote from a paper written about the NetBSD rc.d startup scripts and their design:

The change [in init] has been one of the most contentious in the history of the [NetBSD] project.

Canonical Kills Ubuntu Maverik Meerkat (10.10) for Itanium (and Sparc)

It wasn’t long ago that Red Hat and Microsoft released statements that they would no longer support Itanium (with Red Hat Enterprise Linux and Windows respectively). Now Canonical has announced that Ubuntu 10.04 LTS (Long Term Support) will be the last supported Ubuntu on not only Itanium, but Sparc as well.

Itanium has thus lost three major operating systems (Red Hat Enterprise Linux, Windows, and Ubuntu Linux) over the past year. For HP Itanium owners, this means that Integrity Virtual Machines (IVMs) running Red Hat Linux or Microsoft Windows Server will no longer have support from HP (since the operating system designer has ceased support).

The only bright spot for HP’s IVM is OpenVMS 8.4, which is supported under an IVM for the first time. However, response to OpenVMS 8.4 has been mixed.

Martin Hingley has an interesting article about how the dropping of RHEL and Windows Server from Itanium will not affect HP; I disagree. For HP’s virtual infrastructure – based on the IVM product – the two biggest environments besides HP-UX are no longer available. An interesting survey would be to find out how many IVMs are being used and what operating systems they are running now and in the future.

With the loss of Red Hat and Microsoft – and now Canonical’s Ubuntu – this provides just that many fewer options for IVMs – and thus, fewer reasons to use an HP IVM. OpenVMS could pick up the slack, as many shops may be looking for a way to take OpenVMS off the bare metal, letting the hardware be used for other things.

If HP IVMs are used less and less, this could affect the Superdome line as well, as running Linux has always been a selling point for this product. As mentioned before, this may be offset by OpenVMS installations.

This also means that Novell’s SUSE Linux Enterprise Server becomes the only supported mainstream Linux environment on Itanium – on the Itanium 9100 processor at least.

From the other side, HP’s support for Linux seems to be waning: this statement can be found in the fine print on their Linux on Integrity page:

HP is not planning to certify or support any Linux distribution on the new Integrity servers based on the Intel Itanium processor 9300 series.

Even if HP doesn’t feel the effect of these defections, the HP’s IVM product family (and Superdome) probably will.