When I volunteered to do this review I quickly realized that I was asked to review ‘Red Hat Enterprise Linux Advanced Server‘ and not just ‘Red Hat Linux’. Then panic set in. How different was this going to be from regular old Red Hat that I’ve used and relied on for years? Is this going to be a whole new Red Hat with a whole bunch of advanced features that I wouldn’t be able to talk about either because I missed them or because I’m not qualified?
Well I realized during my first installation that this simply was not the case. In fact throughout the entire process I felt entirely at home with RHELAS (wow that acronym was a handful). While there is plenty of cool stuff to talk about in this release, I am going to limit the scope of what I’m going to talk about to just relevant issues new to RHEL and issues relating directly to server installations of this product (scalability performance). If you (the reader) is already familiar with recent Red Hat releases or Fedora, then much of this may not be news to you.
So whats new in this release you ask?
What sort of cool features can I expect from this release that I didn’t have in RHEL 2.1. Well there are quite a few features actually. While they are standard in Fedora and older regular Red Hat releases I figured I’d go over a few of them. The first that jumped out at me is that RHEL 3.0 supports Logical Volume Management. This is a way for an administrator to ‘logically’ manage disk space (rather than physically partition the disk) so that resizing file systems is easy. I would have loved to test this feature for this review but sadly I don’t have access to a machine with enough disk space to make this meaningful (but rest assured this is on my to do list 🙂 ).
RHEL 3.0 also adds support for Native POSIX Threading Libraries. This is simply a new implementation of POSIX threads for Linux. From all that I’ve read this promises greater performance than the older implementation in Linux but since I am not much of a programmer and I don’t feel qualified to go into more detail for fear of getting anything wrong.
The last change Red Hat made that I felt was relevant to a review of this product was to the kernel rpm package. The package was separated into 2 packages: normal and unsupported. This makes quite a but of sense to me simply because it would be unreasonable for Red Hat to support every conceivable piece of hardware someone may be using. This way they can ensure that their core kernel is solid while users have the option of using other drivers/features that are not included by default. Although if one of these unsupported features if one that you need, support can be arranged through Red Hat in some situations.
The installation was exactly what I was expecting. Anaconda (Red Hat’s installation program) worked and felt just like Red Hat 9. Except I normally use reiserfs as my file system of preference. I had booted up and where I would have expected the option to format as reiserfs I had nothing. This to me made sense if Red Hat didn’t feel that reiserfs was stable enough for their prime time server OS that they would be expected to support. The only other thing I encountered (or didn’t encounter) that I was used to in the Red Hat install process was the option to install a ‘Personal Desktop’, ‘Workstation’, etc. This again makes sense because the product is named ‘Advanced Server’. The default install included the usual: Gnome, Apache, Samba, and Red Hat’s graphical configuration tools. I accepted the defaults wherever possible for the sake of this review.
Set up a few servers:
First install I did was on my main desktop (AMD T-Bird 1.4, 1 Gig RAM, 60 Gig Western Digital Drive, Sound Blaster Live, nvidia GeForce 4 4600 ti). I had never really used the Red Hat configuration tool for Apache (httpd as Red Hat likes to call it). So I figured that this was as good a time as any my feet wet with this (I had always just edited httpd.conf manually). And since it was installed by default anyway I figured: ‘What the heck?!’. I downloaded the latest phpnuke from the site (www.phpnuke.org). I figured this was was a good test of functionality because it involved apache, php, and mysql to get the entire package working (plus I’ve used it a few times in the past so I knew how it works). I installed the rpm packages required using Red Hat’s graphical package management system. This seemed to go smoothly, but I’m used to the functionality of synaptic and apt, so I was not totally impressed with it, but whatever works. After feeding it the CD’s it asked for the packages were installed. I went to the HTTPD configuration utility and made a few changes to the default document root directory, browsed the rest of the options in the tabs and clicked ‘OK’. Wow that was easy (though I still felt a little weird not editing the con fig file by hand). After creating the necessary database per the phpnuke instructions, restarted the relevant ervices via the handy dandy Red Hat Service Configuration application and my site worked perfect. Just as it had in the past although I must say, it took much less time than when I did in FreeBSD with ports.
I’ve been meaning to test out Squid for some time now too so I took the opportunity to hit 2 birds with one stone and deploy Squid at my house with RHEL. I took an old Dell Optiplex tower I had laying around (PIII 600 with 128 megs, 8 gig drive) to see how RHEL performed on less powerful hardware. The install was basically the same as above accept I didn’t install HTTPD or Samba (since they weren’t necessary). I booted up for the first time and I got a warning that said something to the effect of: ‘Red Hat Enterprise Linux is designed to run on systems with 256 Megs of RAM or more’. The message timed out and it booted up anyway. Everything worked that I used in spite of the warning (I’m not sure what the point of that was because I (and any good Sys admin should) know that the system I was using is under powered). This time found the Squid rpm and installed it manually (I can’t really get used to the Red Hat graphical package manager). I edited the squid.conf file and again, bingo everything worked fine. At the time of me writing this the server is still sitting here and working fine.
What I Liked:
Well using RHEL was very uneventful because everything I tried on it worked fine. That doesn’t mean this is a perfect distribution, I didn’t do anything extremely involved and I have only used it for about 3 weeks now. The system has been totally stable while I’ve used it. While only using it for 3 weeks is hardly a real yard stick for the long term stability of a server operating system, it doesn’t seg fault daily like my desktop running Fedora Core, which I find to be quite refreshing.
Furthermore since I was already familiar with Red Hat jumping into their Enterprise distribution was easy for me. Anyone (well… pretty much any one) who’s comfortable with Red Hat Linux and Fedora should feel totally comfortable using RHEL.
What I didn’t Like:
I felt from the very beginning that the default install of a server should include almost nothing like OpenBSD does. Including Apache and Samba by default I feel is asking for trouble because administrators who may have a lot of Linux experience could leave an unpatched version of Apache on their server and unknowing leave themselves vulnerable. I would have liked to see a more conservative default installation.
Furthermore it by default boots directly into X Windows. This to me again doesn’t make sense for a server operating system. It is simple enough to edit the inittab file, but again I felt like that was an unnecessary step that shouldn’t have to happen on a server operating system.
This is not a desktop distribution. I know I’m stating the obvious because I was using Advanced Server, but I’m sure that someone out there will or has tried this as a desktop, and found the same thing. Finding rpms of applications I normally take for granted was impossible (example gaim). The obvious alternative is to compile from tar.gz or src-rpm but the reason I use Red Hat is so I don’t have to compile all my applications (I’d use Gentoo if wanted to compile everything 🙂 ).
My last grip (although minor and wont’ apply to RHN users) is the lack of public ally available binary patches. I know src-rpms are available but that was one hassle I really didn’t want to deal with. Call me lazy (and I’m sure there are plenty of people out there who think I am at this point) but I would have much rather had binary patches straight from Red Hat.
If you currently use RHL and are looking at RHEL as an upgrade path to a supported system, I think its a great choice (IMHO). This is especially true if you qualify for the educational deal with Red Hat and can obtain it at a greatly reduced rate. I feel that the normal fee for the system ($1500) is pretty steep but if a company were to find that the advantages out way the cost then this is definitely the way to go.
If you’re just a geek like me, or are really cheap and don’t want to pay for anything, then RHEL is not for you. The release cycle is way too long and finding up to date rpms is nearly impossible. Fedora (or whatever else you prefer) is really the distribution for you. Although stability is not its strong point (go ahead argue with this one 🙂 ) Fedora provides a much more cutting edge platform to sink your teeth into.
About the Author:
I’m currently a Senior at Syracuse University majoring in Information Management and Technology. I’ve been using Red Hat since 5.2 and I have been using it as my primary operating system on all my machines for 2 years now. I also have experience using Solaris 2.6-8, FreeBSD, and OpenBSD.