Dealing With The End Of Life Of Red Hat Linux 7.x, 8.0 and 9

By Kurt Seifried, kurt@seifried.org

January 1, 2004.



Red Hat Linux versions 7.0, 7.1, 7.2, 7.3 and 8.0 hit their end of life December 31, 2003. Red Hat Linux version 9 hits end of life on April 30, 2004. As you are reading this paper on or after January 1st, 2004 the support for Red Hat Linux 7.x and 8.0 is already ended.

This paper is not intended to reach any specific “solution”, rather it is intended to provide a list of alternatives, their benefits and problems, and help users make the transition.







Why Red Hat Linux 7.x, 8.0 and 9 matter

Simply put there is a huge installed base of Red Hat Linux 6.x, 7.x, 8.0 and 9 of several million if not tens of millions of systems. Universities have deployed huge numbers of Red Hat Linux systems, for desktops workstations and cluster systems. Numerous vendors have certified applications for the various Red Hat Linux versions, as have hardware and service vendors. Businesses have invested a huge amount of time and money in Red Hat Linux, abandoning this investment is not an option in most environments.



Some points to consider

There are more aspects then simple functionality of software that users need to worry about.

Certification and vendor backing

Typically the first decision made by a user it what applications they need to use to fulfill business requirements. Then we work backwards, what operating systems will this application run on, are there any certified operating systems we can use, and ultimately what hardware do we need, and again is there any hardware certified to work with the operating system, and possibly with the application we need.

Businesses generally can't afford to find out on their own if a critical application works or not on a given operating system and hardware, they simply want to buy a solution (the application), and whatever is needed to support this solution. Long term support costs can also be a factor, if a user goes their own way with the operating system and hardware chances are the vendor will not officially support them, or if they do there will be a lot of blame placed on “non-standard operating system/configuration/etc.”.

Business software cycles

Most businesses operate hardware and software on a multi-year cycle. Hardware costs are typically amortized over 3 years, and virtually any business will try to get as much as they can out of a given hardware and software platform. Additionally the cost of updating or replacing hardware and software is often not insignificant. Purchasing new software, arranging for testing to ensure the software inter-operates with everything else, arranging for administrators to do the upgrade or install and arranging for a maintenance window all take time and money. Of course if something goes wrong you can then incur significant cost trying to fix it.

Of course upgrades are often not an option, but a requirement, usage of services often grows, but the servers themselves don't grow, unless of course they get upgraded. Replacing old hardware with new hardware is often a non-trivial task, as the existing software must be loaded. After a few years this can become quite a problem, older operating systems, while maintained at some point are dropped. For example with Serial ATA about to hit mainstream in future systems will use Serial ATA rather then the older parallel ATA standard, and getting systems with older parallel ATA drives may not be possible with some vendors. Many current operating systems do not support Serial ATA, in several years you will not be able to install older operating systems on new hardware without great difficulty. A perfect example of this was the problems with getting Linux and Windows loaded onto ATA-100 and ATA-133 hard drives, as many Linux distributions and Windows simply did not support the controllers. This problem becomes more and more apparent with higher end servers that use RAID controller cards and other hardware that is often upgraded in products released by the vendor.

If it isn't broken most often people won't want to risk “fixing” it.

Software changes and updates and using the latest stuff

Most of us are not interested in running the latest “greatest” software. We simply want software that will fulfill a business requirement(s) and require a minimal amount of hand holding. Upgrading software is always a difficult proposition. Do you trade potentially solved bugs and new features for a new crop of bugs and incompatibilities, or do you keep using the old one. Even if the old one is broken chances are you know how it is broken and have learned to deal with the issues. The potential for new, and possibly worse issues is always a risk when upgrading software. For this reason the majority of major vendors back port security fixes, rather then updating the entire package. This greatly reduces the possibility of breaking things on a customers end, and also makes the QA job for the vendor much simpler (“Did any of the API's and methods change? No? We probably do not need to worry much then.”). This also makes tracking software relatively easy for customers: “We run version 0.1.0, which has known security issues A, B and C. Let's check the vendor patches, oh look, a 0.1.0 with fixes for issues A, B and C called 0.1.0-1.”. This strategy also reduces the cost for the vendor and the consumer, by maintaining fewer versions of a given product administrative, training and troubleshooting costs are kept down. I'm sure many of us remember painful learning curves and deployment issues for things such as as Bind 4 to 8, Apache 1.3 to 2, Linux Kernel 2.2 to 2.4, and so on. Another problem is that existing applications lag behind in terms of what they are certified to run on. Oracle version X may be certified on Red Hat Linux Y, but not yet certified on Red Hat Linux Y+1. Even if Oracle X is certified on Red Hat Linux Y+1 the hardware may not be certified with Red Hat Linux Y+1 yet. In general terms these issues provide a strong reason for administrators to let sleeping dogs lie.

Setting passwords

One major issue with moving to a new version of an operating system or a different operating system entirely is transferring user account information. Passwords are often stored in an encrypted format, MD5 hashed on Red Hat Linux 9 for example. Unless the replacement for Red Hat Linux 9 supports this format you will need to reset every single user password, this can incur a significant amount of cost, on the other hand this can be used to validate all accounts and to enforce strong password policies. To avoid this problem sites may wish to consider authentication backends such as LDAP, however moving to these systems can also incur significant costs.

Hardware support

An increasing problem with older hardware is support and drivers. In general this is less of an issue with Linux as vendors tend to leave in all the older drivers that only a small percentage of users use. However it is critical to test older hardware extensively when installing newer software as problems may crop up that are not easily solved since the hardware is not really supported anymore (except by legacy drivers).



The solutions

There are a number of possible alternatives to Red Hat Linux 9 and prior. Generally speaking deploying any product with a less then 2 year supported life cycle will create problems similar to those of Fedora Linux (Red Hat Linux 10.0 in effect).

Red Hat, SuSE and Mandrake Linux have essentially similar products lines. A free/cheap version aimed at home use with a short life span (Fedora, SuSE Linux Professional, etc.), an enterprise workstation product lacking server components, and a server product. Costs vary but are roughly the same for comparable products. Life spans for the enterprise products are generally 5 years.



Red Hat Linux 7.x and 8.0

Potentially users of Red Hat Linux 8.0 and 7.x can continue to use the software after it's end of life support is reached. This will of course require security updates and other critical bug fixes to be either handled by end users or some other third party. It is likely that in large deployments (such as web server farms) supporting it in-house is possible. It is also likely that people will release third party updates publicly, however the quality and trust-worthiness of these updates is unknown. Currently there is one company, Progeny, that is offering extended updates for Red Hat Linux 7.x, 8.0 and 9, their web page lists a cost of $5 per month per system. This allows time for the transition and ensure that things are not rushed. Information on Progeny's Transition service is available at http://www.progeny.com/products/transition/.

Of course no matter how long Progeny is willing to support Red Hat Linux with security updates at some point an operating system upgrade will be needed to correct bugs, or lacking features.



Description: Red Hat Linux is typical Linux product with a variety of enterprise oriented and home oriented features. Runs virtually all standard UNIX OpenSource software with no real issues.

Remote administration: Typically done via OpenSSH, the command line allows all operations. Operations can easily be scripted and automated. Various GUI tools available.

Support policy: Red Hat Linux 7.x and 8.0 are supported until December 31, 2003.

Software upgrade procedure: Software as RPM packages, installation/updating is relatively trivial.

OS Upgrade / install procedure: Updating to Fedora should be relatively painless however Fedora ships much newer versions of some software which may cause issues.

Transition: No transition required.





Red Hat Linux 9

Potentially users of Red Hat Linux 9 can continue to use the software after it's end of life support is reached. This will of course require security updates and other critical bug fixes to be either handled by end users or some other third party. It is likely that in large deployments (such as web server farms) supporting it in-house is possible. It is also likely that people will release third party updates publicly, however the quality and trust-worthiness of these updates is unknown. Currently there is one company, Progeny, that is offering extended updates for Red Hat Linux 7.x, 8.0 and 9, their web page lists a cost of $5 per month per system. This allows time for the transition and ensure that things are not rushed. Information on Progeny's Transition service is available at http://www.progeny.com/products/transition/.

Of course no matter how long Progeny is willing to support Red Hat Linux with security updates at some point an operating system upgrade will be needed to correct bugs, or lacking features. Red Hat Linux 9 currently has about 4 months of vendor support left, and then several months (possibly a year or two) of solid support from Progeny.



Description: Red Hat Linux is typical Linux product with a variety of enterprise oriented and home oriented features. Runs virtually all standard UNIX OpenSource software with no real issues.

Remote administration: Typically done via OpenSSH, the command line allows all operations. Operations can easily be scripted and automated. Various GUI tools available.

Support policy: Red Hat Linux 9.0 is supported until March of 2004.

Software upgrade procedure: Software as RPM packages, installation/updating is relatively trivial.

OS Upgrade / install procedure: Updating to Fedora should be relatively painless however Fedora ships much newer versions of some software which may cause issues.

Transition: No transition required.





Progeny Transition Service

One possibility is to use the Progeny Transition service, however this service is not yet available and has not been tested, the quality and promptness of the updates is unknown. Information on Progeny's Transition service is available at http://www.progeny.com/products/transition/.





Addendum: Sept 1, 2004:

Fedora Legacy Project

I can't believe I forgot to add this sooner. The fedora legacy project provides security updates for Red Hat Linux 7.3 and 9.0, support for 6.x and 8.x has been dropped apperently due to lack of support (testing of updates prior to release). The project's website is available at: http://fedoralegacy.org/







Red Hat advanced workstation

The problem with attempting to deploy Red Hat advanced workstation as a server is that it would still require users to create and deploy their own server packages. This would also require them to support them. It may be possible for example to download source RPM's meant for Red Hat server products, compile and use them on Workstation, however this too would involve some considerable effort.



This is probably not the option Red Hat wants people to take with their servers, but it is possible. I had considered this except for one problem. The cheapest I can get Red Hat Enterprise Linux ES is $179 US (about half of what the lowest end server product costs).

Unfortunately in the Terms and conditions it states:

If Customer wishes to increase the number of Installed System, then Customer will purchase from Red Hat additional Services for each additional Installed System. During the term of this Agreement and for one (1) year thereafter, Customer expressly grants to Red Hat the right to audit Customer's facilities and records from time to time in order to verify Customer's compliance with the terms and conditions of this Agreement.

Ignoring the fact I'd be legally required to let Red Hat do an audit of my facilities it quickly becomes clear that for each system I install Red Hat Enterprise Linux WS I must purchase a support contract in one year increments.

Furthermore I'd somehow have to build my own server packages since they do not ship with the workstation edition. This could in theory be done from the source RPM's provided by Red Hat for the server product, but this is unclear in both technical terms and licensing terms. This would incur many of the problems as staying with Red Hat Linux 9 and supporting it myself.

While this would solve my problem of using a familiar, and supported OS it would incur significant costs. Additionally the updates are only released quarterly, and while Red Hat has been quite prompt on some security fixes for Enterprise products not all updates have been as prompt as I would like (there is nothing like wondering if your server is being broken into).

This option has been discarded because:

  1. I would need to manually create server software packages and maintain them myself, incurring the same problems as staying with Red Hat Linux 9.

  2. Cost factors, for each server I must buy a support contract in one year increments, assuming I use it for 3-5 years that is a considerable sum across multiple servers.

  1. Licensing issues, one of the reasons I continue to use Linux is that I am not required to allow a third party the ability to audit me, or granting them the right to revoke my license to use software I depend on.





Red Hat advanced server

This is the option Red Hat probably wants people to take. Stop using the “free” versions of Red Hat's products and pony up some money for the “real” thing. I had considered this except for one problem. The cheapest I can get Red Hat Enterprise Linux ES is $349 US.

Unfortunately in the Terms and conditions it states:

If Customer wishes to increase the number of Installed System, then Customer will purchase from Red Hat additional Services for each additional Installed System. During the term of this Agreement and for one (1) year thereafter, Customer expressly grants to Red Hat the right to audit Customer's facilities and records from time to time in order to verify Customer's compliance with the terms and conditions of this Agreement.

Ignoring the fact I'd be legally required to let Red Hat do an audit of my facilities it quickly becomes clear that for each system I install Red Hat Enterprise Linux ES I must purchase a support contract in one year increments.

While this would solve my problem of using a familiar, and supported OS it would incur significant costs. Additionally the updates are only released quarterly, and while Red Hat has been quite prompt on some security fixes for Enterprise products not all updates have been as prompt as I would like (there is nothing like wondering if your server is being broken into).

Personally I have decided not to use Red Hat Linux Enterprise Server, however for many customers, especially those without a huge amount of technical resources or those that heavily rely on the servers this is probably the best solution. The cost of the product is equivalent to 3 or 4 hours of an administrators time (once you include overhead), as such it will easily pay for itself in most environments when you consider the cost of moving to an alternative solution. As well the extended lifespan of the product (5 years) and the support for new hardware on a quarterly basis make the product easily transferable to new hardware using the same software.

It should also be noted that several projects have created “cloned” version of Red Hat Linux (such as WhiteBox Linux). They have essentially removed any copyrighted material from Red Hat, built the source and are distributing it. Personally I am leery of these efforts, it remains to be seen how well they will be supported. Please do not email me asking for URL's, use Google to find them.



Red Hat Fedora



Upgrade to Fedora, essentially “Red Hat Linux 10”

Another option is to bite the bullet and upgrade to Fedora. Hopefully you can execute an OS upgrade as opposed to an entire install \, however this may not work in all situations. While I realize that Fedora is “free” (in both a licensing sense and a cost sense) people do expect certain levels of commitment and support from the vendor (be it a company or a non-profit organization).

However after having read up on Fedora I noticed a number of problems. To quote the FAQ available at http://fedora.redhat.com/about/faq/:

Q: What is the errata policy for The Fedora Project?
A: Security updates, bugfix updates, and new feature updates will all be available, through Red Hat and third parties. Updates may be staged (first made available for public qualification, then later for general consumption) when appropriate. In drastic cases, we may remove a package from The Fedora Project if we judge that a necessary security update is too problematic/disruptive to the larger goals of the project. Availability of updates should not be misconstrued as support for anything other than continued development and innovation of the code base.

Seeing as how I have no idea whether Red Hat or some third party maintainer will be in charge of any particular package I need I ultimately am left in the woods as to any guarantees things will be fixed in a timely manner (if at all). While I suspect this won't be an issue for the majority of packages such as the Kernel, libraries and important network daemons it does leave one to wonder.

Furthermore a large number of objectives stated for the Fedora project clash with business needs, from http://fedora.redhat.com/about/objectives.html:



Build the operating system exclusively from open source software.

It is not known how far this policy will be taken, for example Debian has a strict “free” policy with “non-free” software being distributed separately. It is not clear if Red Hat will distribute “non-free” software separately or not at all.

Addendum (Sept 1, 2004): This policy is quite strict, for example the Pine email client and the WU-IMAPD mail server are not included in Fedora Core 2.



Do as much of the development work as possible directly in the upstream packages. This includes updates; our default policy will be to upgrade to new versions for security as well as for bugfix and new feature update releases of packages.

This means that instead of back porting bug fixes (largely what Red Hat has done in past) they will correct the upstream version (i.e. the source code) and then release updates based on a new version of the software. This means that a minor fix required for security will result in a significantly newer/different version of a package. Configuration files may not be completely compatible, default behaviors may have changed, the list of potential problems is endless. In practice this will require end users to do more testing if they wish to be assured that an update will not cause problems. In past this was accomplished by Red Hat, and minimized by back porting fixes, but now all bets are off.

Addendum (Sept 1, 2004): This policy is relatively strict, for example kernel updates, Fedora Core 2 has gone from 2.6.5 to 2.6.8 in several months.

Be on the leading edge of open source technology, by adopting and helping develop new features and version upgrades.

Like many business users I do not want to be on the leading edge. I want to install and maintain servers that work and let me do my work. I do not want to be forced to engage in constant beta testing of new software.

Addendum (Sept 1, 2004): This policy is relatively strict, for example kernel updates, Fedora Core 2 has gone from 2.6.5 to 2.6.8 in several months.

Promote rapid adoption of new releases by maintaining easy upgradeability, with minimal disturbances to configuration changes.

This is a laudable goal, but not practical in all cases. Red Hat is adopting a policy of using the latest software in Fedora releases, this will result in significant changes in software packages included, resulting in increased testing requirements (as mentioned above).

Addendum (Sept 1, 2004): This policy has been relatively successful, due to the fact most OpenSource projects do not make huge changes in their configuration files (many are stable), however in some cases this has been an issue.

Produce robust releases approximately 2-3 times per year, using a time-based release model: A time for a feature freeze is set in advance, and an expected schedule for test releases is produced before the feature freeze date. (Important feature schedules will be taken into account when setting the schedule for Fedora Core releases.)

Based on Red Hat dropping Support for Red Hat 9 a year after it was released one can only assume that support for Fedora releases will be even shorter. In all likelihood support for older Fedora releases will not exist, with the intended update path a complete OS upgrade or re-installation. Again like many businesses I just want my servers to work, I do not want to upgrade the OS or re-install it 2-3 times a year, especially with machines at remote locations (such as co-hosting facilities).

Addendum (Sept 1, 2004): Red Hat has committed to supporting the last two releases of Fedora Core, thus when Fedora Core 3 is released Oct 25, 2004 it is expected Fedora Core 1 support will be dropped, after less then a year.

Provide timely (though not guaranteed — no Service Level Agreements apply) updates for robust releases, over a useful release lifetime.

At this point I think I'm beating a dead horse. I have no idea what “timely” means (a day? a week? a month?). I can only assume support for a release is stopped shortly after (if not immediately after) a new release of Fedora comes out. Like many businesses I do not like such uncertainty when it comes to my servers.

Addendum (Sept 1, 2004): Red Hat has been quite good about releasing and testing updates, so far no major issues requiring a re-release of updates have occurred.

This option has been discarded because:

  1. Lack of security updates after new releases of Fedora, necessitating OS upgrades or re-installs on a regular basis (2-3 times a year)

  2. Unclear policies on “non-free” software

  3. Being forced to play on the bleeding edge of Linux and applications, incurring testing costs and possible downtime

Addendum (Sept 1, 2004):

    Clear policies on “non-free” software, it is not included

    Being forced to play on the bleeding edge of Linux and applications, incurring testing costs and possible downtime

The security updates issue has been removed.



WhiteBox Linux (dead?)

WhiteBox Linux is essentially Red Hat Linux 3.0 Advanced Server compiled from modified source RPM's with all the Red Hat logos/etc stripped out. It provides essentially the exact same functionality as Red Hat 3.0 Advanced Server as far as packages go, however in support it is severely lacking. For updates the WhiteBox Linux project essentially waits for Red Hat to release updates, they then download the source rpm's for the updates, modify them if needed and compile them. It is unknown how much testing will be done (likely none) and of course the trustworthiness of the updates is questionable.

WhiteBox Linux is suited for small deployments with trained and competent administrators or for larger deployments that have identical systems (such as a web hosting farm).

Description: WhiteBox Linux is typical Linux distribution with a variety of enterprise oriented and home oriented features. Runs virtually all standard UNIX OpenSource software with no real issues.

Remote administration: Typically done via OpenSSH, the command line allows all operations. Operations can easily be scripted and automated.

Support policy: This release of WhiteBox Linux will in theory be supported by Red Hat indirectly for 5 years, however sites will need to find the compiled source rpm's or compile their own source rpm's.

Software upgrade procedure: Software as RPM packages, installation/updating is relatively trivial.

OS Upgrade / install procedure: It is not known if newer versions of Red Hat Linux Advanced Server will be modified, however with a theoretical 5 year lifespan this is not a serious concern right now.

Transition: Identical to Red Hat Linux.





Centos Linux

Centos Linux is essentially Red Hat Linux 3.0/4.0 Advanced Server compiled from modified source RPM's with all the Red Hat logos/etc stripped out. It provides essentially the exact same functionality as Red Hat 3.0/4.0 Advanced Server as far as packages go, however in support it is not as good. For updates the Centos Linux project essentially waits for Red Hat to release updates, they then download the source rpm's for the updates, modify them if needed and compile them. It is unknown how much testing will be done (likely none) and of course the trustworthiness of the updates is questionable.

Centos Linux is suited for small deployments with trained and competent administrators or for larger deployments that have identical systems (such as a web hosting farm).

Description: Centos Linux is typical Linux distribution with a variety of enterprise oriented and home oriented features. Runs virtually all standard UNIX OpenSource software with no real issues.

Remote administration: Typically done via OpenSSH, the command line allows all operations. Operations can easily be scripted and automated.

Support policy: This release of Centos Linux will in theory be supported by Red Hat indirectly for 5 years, however sites will need to find the compiled source rpm's or compile their own source rpm's.

Software upgrade procedure: Software as RPM packages, installation/updating is relatively trivial.

OS Upgrade / install procedure: It is not known if newer versions of Red Hat Linux Advanced Server will be modified, however with a theoretical 5 year lifespan this is not a serious concern right now.

Transition: Identical to Red Hat Linux.





SuSE Linux

Description: SuSE Linux is typical Linux distribution with a variety of enterprise oriented and home oriented features. Runs virtually all standard UNIX OpenSource software with no real issues.

Remote administration: Typically done via OpenSSH, the command line allows all operations. Operations can easily be scripted and automated.

Support policy: Releases are supported for approximately 2 year after release and 5 years for Enterprise products.

Software upgrade procedure: Software as RPM packages, installation/updating is relatively trivial.

OS Upgrade / install procedure: Minor revisions can be updated via packages, major point releases may require a re-installation.

Transition: Relatively similar to Red Hat Linux, similar layout of configuration files.



http://www.suse.com/us/private/support/index.html



Mandrake Linux



Description: MandrakeSoft Linux is typical Linux distribution with a variety of enterprise oriented and home oriented features. Runs virtually all standard UNIX OpenSource software with no real issues.

Remote administration: Typically done via OpenSSH, the command line allows all operations. Operations can easily be scripted and automated.

Support policy: Releases are supported for approximately 1.5 year after release.

Software upgrade procedure: Software as RPM packages, installation/updating is relatively trivial.

OS Upgrade / install procedure: Minor revisions can be updated via packages, major point releases may require a re-installation.

Transition: Relatively similar to Red Hat Linux, similar layout of configuration files.

“With the release of Mandrake Linux 9.1, we will put in place a cycle that customers can easily anticipate. MandrakeSoft will provide 12 months of "desktop" updates for distributions, and 18 months of "base" updates for distributions. This means that applications such as window managers, desktop environments, browsers, etc. will have a 12 month package update life, while applications such as the kernel, Apache, and other "base" components will have a support life of 18 months. At certain times, MandrakeSoft may choose to extend updates support for certain versions of Mandrake Linux.”



OpenBSD

Description: OpenBSD is a *BSD style operating system heavily oriented towards security. Runs virtually all standard UNIX OpenSource software with no real issues.

Remote administration: Typically done via OpenSSH, the command line allows all operations. Operations can easily be scripted and automated.

Support policy: Releases are supported for approximately 1 year after release. OpenBSD releases a new version every 6 months on a fairly reliable schedule. Upgrading OpenBSD to a new version is will documented in the OpenBSD Upgrading Mini-FAQ. Some upgrades are painful, especially with recent additions such as W^X, and library changes, however this has largely settled down.

Software upgrade procedure: The ports tree contains preconfigured “make” files for most software packages that make it relatively simple and quick to install or update software. Source code is downloaded (via CVS, as a tarball, etc.) and then compiled and installed, this is accomplished with a minimal number of commands (typically “make && make install”).

OS Upgrade / install procedure: Accomplished online via updating source code and then recompiling, some manual changes are typically needed between OS releases (adding new user and group for example). Compiles of the kernel and system can sometimes take several hours depending on the hardware available. A clean install can be done very quickly, configuration file changes are minor to non-existent, and held in a separate package specifically to make updates or customized installs easier.

Transition: Requires familiarity with *BSD or OpenBSD, however documentation is excellent. Many configuration files can be transferred with relative ease.



FreeBSD

FreeBSD has two major benefits over OpenBSD for replacing Red Hat Linux. The first is a longer support cycle for releases, typically 1.5 to 2 years, and the second is a program that allows for remote installation of FreeBSD onto Red Hat Linux systems.

This code and process is currently not 100% reliable, it is strongly advised that sites test it first on mock-up systems before doing it remotely. The tool is available at:

http://www.daemonology.net/depenguinator/

It appears to consist of overlaying the first 40 megabytes of a system's primary disk with a bootable FreeBSD install that can be accessed remotely. Typically the first 100 megabytes of a Linux installation is the /boot section, overwriting this improperly can render the machine completely unusable.



Description: FreeBSD is a *BSD style operating system heavily oriented towards stability. Runs virtually all standard UNIX OpenSource software with no real issues.

Remote administration: Typically done via OpenSSH, the command line allows all operations. Operations can easily be scripted and automated.

Support policy: Releases are supported for approximately 2 years after release.

Software upgrade procedure: The ports tree contains preconfigured “make” files for most software packages that make it relatively simple and quick to install or update software. Source code is downloaded (via CVS, as a tarball, etc.) and then compiled and installed, this is accomplished with a minimal number of commands (typically “make && make install”). Several thousand packages are supported in this manner.

OS Upgrade / install procedure: Accomplished online via updating source code and then recompiling, some manual changes are typically needed between OS releases (adding new user and group for example). Compiles of the kernel and system can sometimes take several hours depending on the hardware available. A clean install can be done very quickly, configuration file changes are minor to non-existent, and held in a separate package specifically to make updates or customized installs easier.

Transition: Requires familiarity with *BSD or FreeBSD, however documentation is excellent. Many configuration files can be transferred with relative ease.





Solaris For Intel and Sparc

One advantage of Solaris for Intel is it's relative cheapness (free for less then 99 licenses) and the long term product life and support offered by Sun (also again for free). Several issues should be noted however: hardware support is not as complete as Linux, older, more exotic and less mainstream hardware may not be supported (however standard items like Intel and 3Com networks cards will be). As well performance issues may occur, Solaris on Intel is generally not as fast as Linux on the same hardware. Solaris (at least the current versions) really are meant for Sparc hardware, and do better on this platform.



Description: Solaris is a “classic” UNIX style operating system with heavy backing from Sun. Runs virtually all standard UNIX OpenSource software with no real issues.

Remote administration: Typically done via OpenSSH, the command line allows all operations. Operations can easily be scripted and automated.

Support policy: Releases are supported for a very long time (over a decade in some cases). Sun has a relatively slow release cycle, updates can take a long time for the vendor to release.

Software upgrade procedure: Installation and updates of server software often require source code to be downloaded, configured manually, then installed and against configured manually. Some packages available in binary format however updates may not be available.

OS Upgrade / install procedure: Binary update packages are released by the vendor, relatively easy to install via command line.

Transition: Requires familiarity with general UNIX, good documentation available, many configuration files can be transferred over.



Mac OS X Server

I mention Mac OS X for completeness, as it does not run on Intel hardware. However sites looking to replace hardware (especially in lab environments) may consider it, the newer G5 systems offer 64 bit hardware, that should also soon be supported in the Mac OS X operating system. Unfortunately for rack based server environments you will need to buy mounting adaptor kits for desktops, or use the 1U mac servers, which while powerful are somewhat limited expansion wise.

Addendum Sept 1, 2004: Apple has made rack mount Mac OS X servers available, and from all reports they are pretty nice, several models are available including a “standard” server (cpu, drive, network interfaces), a “computational” server (with multiple CPU's) aimed at the cluster market, and a disk array product.



Description: Mac OS X Server is based on *BSD with a very nice GUI interface and tools for management.

Remote administration: Can be done via OpenSSH, the command line allows most operations however access to GUI is generally advised.

Support policy: Releases are supported for a year or more, however Apple has shown disdain for previous version, for example security updates included in 10.3 have not yet been released as updates for older versions of Mac OS X. Security updates can be very slow from Apple.

Software upgrade procedure: Binary packages provided by vendor for many common applications (such as Apache). Otherwise software requires source code to be downloaded, configured manually, then installed and against configured manually. Some packages available in binary format however updates may not be available.

OS Upgrade / install procedure: Binary update packages are released by the vendor, installed via GUI tool.

Transition: Requires familiarity with Mac OS X, some configuration files can be transferred.



Windows 2003

When I began writing this I dismissed Windows 2003 out of hand. However after running an evaluation versions of Small Business Server for a few days I was impressed with it's capabilities (they include everything, and the kitchen sink). The cost is also not to bad once you factor a Red Hat workstation at almost $900 US for 5 years, and a server at a minimum of $1,750 for 5 years. Depending on client licensing needs Windows 2003 may actually be cheaper (this is most likely to occur in web hosting and other similar low user license requirement situations). Windows 2003 now includes remote administration tools that are actually usable, however it is likely sites will still need to purchase PCAnywhere or similar products.

Description: Windows 2003 is the latest of Microsoft's Windows line.

Remote administration: Remote administration tools becoming available however often requires services such as RPC and DCOM to be enabled which pose a security risk.

Support policy: Releases are supported for several years, security updates can take some time to be released by Microsoft Corp. however.

Software upgrade procedure: Binary packages released by respective vendor, bad track record for stability of updates.

OS Upgrade / install procedure: Binary packages released by Microsoft, bad track record for stability of updates. Updates often require a reboot to take effect due to Windows file locking issues.

Transition: Requires familiarity with Windows 2003, configuration files cannot be transferred, many software packages available for UNIX are not available for Windows 2003. Generally difficult to disable components and secure services.



Summary

What solution to choose is a decidedly non-trivial solution for most people. Generally speaking for most businesses I think going with Red Hat Enterprise products is the best solution, both from pure cost and also to ensure a smooth transition. Switching to another Linux vendor has very little benefit, significant cost will be incurred in the transition, retraining, and the cost of the product.



Cost matrix

I have made a simple cost matrix for time and money for each solution so that all the data can be presented in one chart that is relatively easy to understand. While the numbers are not 100% correct (they never could be as it varies for each environment) they are relative to one another giving some idea of what is involved.

Several assumptions are made:







Name

Initial purchase

Year 1 support

Year 1 install

Year 1 maint.

Year 2 support

Year 2 install

Year 2 maint.

Year 3 support

Year 3 install

Year 3 maint.

Year 4 support

Year 4 install

Year 4 maint.

Year 5 support

Year 5 install

Year 5 maint.

Admin hours

Notes


Red Hat Linux 9

Free

Free

Major

Minimal to medium
















Red Hat Linux 9 with Progeny

Free

$40.00

Major

Minimal to medium

$60.00



$60.00



Unlikely to continue



Unlikely to continue






Red Hat Linux Fedora

Free

Free

12-24 hours

Minimal to medium

Free

12-24 hours

Minimal to medium

Free

12-24 hours

Minimal to medium

Free

12-24 hours

Minimal to medium

Free

12-24 hours

Minimal to medium

Medium to Major 60-120 hours for install alone



Red Hat Enterprise Linux WS

$179.00

Included

4-8 hours

Minimal

$179.00

None

Minimal to medium

$179.00

None

Minimal

$179.00

None

Minimal

$179.00

None

Minimal

Minimal

Need to install and support server products


Red Hat Enterprise Linux ES



$349.00

Included

4-8 hours

Minimal

$349.00

None

Minimal

$349.00

None

Minimal

$349.00

None

Minimal

$349.00

None

Minimal

Minimal



SuSE Linux Professional 9.0

$79.95

Included

4-8 hours

Minimal

$79.95

4-8 hours

Minimal

Included

None

Minimal

$79.95

4-8 hours

Minimal

Included

None

Minimal

Minimal to medium



SuSE Linux Desktop

$99.00

Included

4-8 hours

Minimal

$99.00 [1]

None

Minimal to medium

$99.00 [1]

None

Minimal to medium

$99.00 [1]

None

Minimal to medium

$99.00 [1]

None

Minimal to medium

Minimal to medium

Need to install and support server products


SuSE Linux Standard Server 8

$449.00

Included

4-8 hours

Minimal

$350.00

None

Minimal

$350.00

None

Minimal

$350.00

None

Minimal

$350.00

None

Minimal

Minimal to medium



Mandrake Linux Corporate Server

$749.00


4-8 hours

















Windows Server 2003

$600.00

Included

8-16 hours

Minimal to medium

Included

None

Minimal to medium

Included

8-16 hours

Minimal to medium

Included

None

Minimal to medium

Included

8-16 hours

Minimal to medium

Minimal to medium

Highly exposed with services


Mac OS X Server

$499.00


4-8 hours

















OpenBSD

Free/$40

Included

4-8 hours

Minimal

Free/$40

4-8 hours

Minimal

Free/$40

4-8 hours

Minimal

Free/$40

4-8 hours

Minimal

Free/$40

4-8 hours

Minimal

Minimal





[1] Please note that SuSE workstation support packages can be purchased in 5 packs (at $500) or more according to their website, however the average cost is $99.





My conclusion

What is Kurt doing? My initial reaction was to switch to SuSE Linux Professional 9.0, but they only have a 2 year support cycle (I had though it was longer). I then did some testing with OpenBSD, and have decided to use it on my two remote servers. I ruled out using Red Hat Enterprise Server as an option narrowly, the cost to me would be $1050 USD per year for the three servers I need. As I am self employed this is a significant amount of money for me. Since I already spend some time administering my servers (updates, tweaking configurations, adding new things, etc.) of probably 1-4 hours a week in total that would not change significantly going to Red Hat Enterprise Server so I would not realize much of a savings in my time. I then looked at WhiteBox Linux, however ongoing support issues (who will provide updates?) make me nervous there. For both Red Hat Enterprise and WhiteBox Linux there would still have been the major one-time expenditure associated with installing it (backup, install, restore, configure, etc.) which also exists for other solutions such as OpenBSD. I ruled out Windows 2003 quickly for the remote systems (DNS software availability, remote administration, the requirement for reboots, security updates, etc, etc.) and Mac OS X due to the need to buy new hardware and install a new version every year or so if 10.1, 10.2 and 10.3 are any indication. FreeBSD and NetBSD don't really give me any significant benefits over OpenBSD, although they have extended lifespans I find tracking OpenBSD STABLE and updating between versions relatively painless.


As for my local file server I will likely be using Fedora Core 1, with a 2.6 kernel. I find the 2.6 kernel actually supports Serial ATA really well (upgrade the kernel, reboot, kudzu finds my Serial ATA drive) which is critical since I'm buying several large Serial ATA drives to replace the collection of 120 and 80 gig drives I currently use to store data. As well since the machine is local to me I can do major upgrades once in a while, but I suspect once Core 2 comes out next year with a 2.6 kernel I will not go beyond that since the fileserver lives in a heavily protected network and only trusted clients can access it.


Addendum Sept 1, 2004: I am now running Fedora Core on my file servers and it works quite well, when I need to upgrade I can simply upgrade the secondary, make sure everything works as expected, and then do the primary, I recently added new boot drives and re-installed the OS, it took less then 2 hours per machine in total to get them completely installed and configured from backups. My colocation servers undergo a similar procedure however I did the update remotely (after testing it on an identical setup locally).


For most people with small installations that are not overly exposed or for large homogenous installations I think WhiteBox Linux will be a solid winner. For Academic environments you can get academic pricing on Red Hat Enterprise products, a relatively easy choice at $25 to $50. For larger environments using products such as Oracle the best choice is most likely Red Hat Enterprise, with it's 5 year life span, certifications, vendor backing and support it will likely pay for itself in saved administrative overhead. As always however you should conduct you own analysis and tests to find out what is right for you.



A call to Red Hat

Finally I think there needs to be a public call to Red Hat to provide critical security updates for Red Hat 7.x, 8.0 and 9. While I realize that there are services like the Progeny transition service, and that providing updates will not create any revenue for Red Hat (quite the opposite, it will reduce short and medium term revenues as customers will continue using “free” products) I believe it is the correct thing to do for several reasons:



Ultimately I expected Red Hat to kill off Red Hat Linux 7.x, 8.0 and 9. They do not generate much revenue, and the customers most likely to use them or similar alternatives are unlikely to pay Red Hat Inc. for products in any event, so they are not much of a loss.



Update history:

Dec 30, 2003 – Added FreeBSD, general notes, changed layout

Dec 11, 2003 – Added Progeny update service

Jan 1, 2004 – Released updated paper

Back

Last updated 28/10/2003

Copyright Kurt Seifried 2003