Is RHN the right choice for your business?

It was a misty evening in Issaquah, WA, some time ago. With a brand new RedHat 7.2 installation, I had just finished moving our flagship product from an MS VB/SQL/ASP setup to PHP/PostgreSQL. The euphoria was rampant as we saw how quickly our slow pages were loading on our new platform. “Move us over dude!” said our CEO, referring to the company’s mail server. The Mail move went smoothly as we left Exchange for Postfix. Everybody was set up and happy. We were dancing the victory dance,
unaware of the mess that lay ahead.

The next morning I ran my mail client, and started writing an email to everyone in the company updating them on the move to Red Hat Linux. I hit
the send button, and that’s when reality hit. “Postfix won’t relay my message, why?” I asked. It turns out SMTP does not have authentication
support by default. A fresh newbie coming from the MS world, I expected postfix to have all the pre-configuration needed to handle such a common
task. But I had an open mind. “A check box or a 0 that needs to be set to 1 in some config file probably,” I thought to myself. Little did I
know that my ordeal would last days until I got things fixed.

I discovered that I needed to have SASL (Simple Authentication and Security Layer) installed and postfix compiled with SASL support. Sounds easy? It wasn’t. Red Hat’s package didn’t have SASL support turned on by default, I had to fiddle with a very cryptic SPEC file, and after a while I just gave up. It would not compile citing a string of missing -dev packages with names I never heard of. The Postfix website had a deep buried link to instructions on how to create your own RPMs with
SASL support. A few more searches on RPMFind.net and after collecting a hodge-podge set of RPMs, I finally got it working.

Then came an update notice from RHN. I updated, and you can re-read the two previous paragraphs to get an idea of what happened. So goes my life and many system admins and developers like me who have to deal with what has been appropriately named “Dependency Hell”.

In my case, the correct term would be “Upgrade Hell†because the real issue is not whether you are able to customize these packages with ease
or not. The trick is to maintain a wonderfully choreographed dance between your hand tweaked and customized packages and RedHat’s well integrated package bundling.

Red Hat is the most successful Linux distribution out there and if you are in the Linux world you probably know someone running Red Hat Linux
right now. The fact is that this issue applies to all pre-compiled distributions including Debian, SUSE, Mandrake, and others. But because the popularity of Red Hat Linux on the corporate server is higher than the other distributions (at least in the US), their problems tend to be more visible.

I could also safely state it as fact that if you had a chat with a FreeBSD sysadmin about why she chose FreeBSD, RPM and Ports would have poped up in the conversation eventually if not right away. Ports on FreeBSD solves that problem. So does its closest Linux clone, Portage, from the Gentoo distribution.

Gentoo’s Portage allows you to set keywords (flags) for the features you want in your system globally in a USE environment variable. These flags translate to the appropriate compile options for any package you install. Just by adding the word “sasl†to that variable and “emergingâ€
the postfix package, I would have had a perfectly working postfix mail server compiled for my server. With the appropriate version of SASL
pulled in automatically, it doesn’t matter how many times a patch comes out for postfix. The features my company relies uppon would still be
there. And any other package I installed that had a SASL related feature would automatically be compiled in also. Now that’s integration.

I’m not a Red Hat basher, and I don’t want this article to be about what distribution method is better. I’ve been a Red Hat advocate since v5.0. They have done and still do great things for the future of Linux. What really got me thinking about moving all 10 RedHat servers I manage to Gentoo is
the new RHN cost. Up until now I’ve been describing common problems with RHN for many of us, and many of us have resolved to just live with
them. But to be expected to pay $799 per server for these problems would be asking me to swallow a very large pill.

The gist of the matter (or as we say in Arabic “the butterâ€) is that for my company — and I’m sure many others -– the new deal just doesn’t make
sense. We are getting virtually the same package for which we’ve been paying $60 a year, for a whole lot more money, with only a few bells and whistles that don’t add
any real value for us.

The new RHN deal does make lots of sense for bigger companies that are not known for flexibility and are not required to be very flexible. If the bundled features of the packages that come with Red Hat Linux are all I would ever need, then by all means, Red Hat is very stable and their upgrade process would work very nicely.

But as many sysadmins and developers will tell you, they are required to perform acts of utter magic on a weekly basis for very little pay to keep a Red Hat installation updated with RHN. Maybe
the time has come to do some distribution shopping.