“With the recent public release of Red Hat Enterprise Linux 5 beta 1, system administrators like myself (and their IT managers) may face major system upgrades in the near future. Given that I’ve got until 2012 before maintenance support for RHEL 4 ends, I need to see real value to convince me to upgrade, especially when you consider RHEL 4 has proved to meet the needs of my organization nicely. So, the question is why should enterprises upgrade from earlier releases of Red Hat Enterprise Linux when RHEL 5 is officially released?”
RHEL 4 is stable, works, and is supported. There is absolutely no reason why you should upgrade any server. I can guarantee you that there will be no cost savings associated with it. Instead, look into deploying new solutions and new infrastructure with RHEL 5. When 2011 comes along and you are faced with having no support, only then does it make sense to see what to move to. In the meanwhile, I can guarantee you that there wasn’t a single technology that has been released within the last past two years that will make it worthwhile for your company to upgrade existing servers.
Edited 2006-09-25 22:16
What about improved performance provided by the new kernel, apache, and the new features of the new php?
“What about improved performance provided by the new kernel, apache, and the new features of the new php?”
If you manually installed php5 on a RHEL4 installation, then I have to say you surely don’t know what to do with all that cash on hand. You pay RedHat so that they worry about patching and making sure everything works. If you are going to do it yourself, you might as well have installed one of the many free distributions.
In terms of “improved” performance of the kernel and apache, I think people are as interested in it as they were when Apache 2.0 first came out. While nice, noone ran out and immediately upgraded. Also, in regards to scalability, if you really need to upgrade because RHEL 4 does not scale on that 32 CPU monster, then you installed the wrong operating system to begin with. You should have installed something that would scale and that you would not need to touch for another 5 years at least.
Again, I am talking about “upgrading” currently running systems, not “installing” new systems. And I still stand by my original belief that if you need to upgrade existing systems, then Microsoft has gotten into your brain too deep and you are doing things very wrong. In addition, you are a liability not an asset to your company.
Edited 2006-09-26 00:13
“Again, I am talking about “upgrading” currently running systems, not “installing” new systems. And I still stand by my original belief that if you need to upgrade existing systems, then Microsoft has gotten into your brain too deep and you are doing things very wrong. In addition, you are a liability not an asset to your company.”
Specifically replying to the above quote — I believe you are correct, especially in the case of small office or home users. The beauty of most Linux distributions is you don’t always have to upgrade simply for the sake of upgrading. This is especially true of the enterprise distributions like RHEL where they are used as servers.
However, never underestimate the kind of enterprise customers that companies like Red Hat have broken through to. When I attend conferences, I invariably meet sysadmins who are constantly pushing the envelope in system performance. Upgrading, or redeploying to RHEL 5 when it ships will be necessary for them.
Please be careful when making blanket comments regarding upgrading and provisioning. For the “average” Linux user, an upgrade to RHEL 5 will probably not be warranted — agreed. But then, as I think you seem to indicate, RHEL might not be the right choice for some of those users anyway.
“””There is absolutely no reason why you should upgrade any server.”””
What’s a server?
Some of my servers are XDMCP desktop servers.
All in all I have about 50 users logging in via XDMCP or NX to do all the usual desktop things. Browsing, wordprocessing, spreadsheets, email, etc.
I’m quite happy with CentOS 4.4. But it is now 2 years old and getting slightly stale. OO.org 2.0 will be nice. Gnome 2.16 will be nice. Lot’s of details will be nice. Finally having a kernel for which heavy writes don’t starve reads will be nice.
I am looking forward to the upgrade.
But, you may be referring to LAMP servers. OK. I have some of those. And as the article references, I *have* had to custom upgrade certain packages to get particular features, and now I am saddled with the responsibility of keeping those packages patched. So I’m looking forward to upgrades there, too.
The one type of server that I am *not* in a hurry to upgrade are accounting servers running proprietary Cobol packages from companies who still think of glibc as “that new ‘c’ library Linux has now”.
Edited 2006-09-25 23:35
Aha! I think this is right on with what I’ve tried to point out, both in comments here and in my original tip.
The tip is a tour of new features previewed in RHEL 5 Beta 1. This new public preview release will mean something different for every sysadmin. Certainly, the real news-maker is the inclusion of Xen. Probably not a reason for anyone to upgrade, but a big reason for some to consider deploying RHEL 5 when it is released.
When faced with maintaining many systems on a limited budget with limited staffing, there is something to be said for relying on prepackaged software whenever possible.
I disagree, I think unless you have a good reason not to, keeping your servers running current (stable) software is the better way to go.
Think of it this way, right now you’re happy running version 1.x of daemon foo. Now, version 2.x comes along, you pass, stick with what you got. Same with 3.x. But then, 4.x some years down the road comes along, and for whatever reason you _really_ need to be running that (security, important features, customer demand, whatever). Well now, you’ve skipped out on major releases already, as well as umpteen of other packages that are dependencies on that, and for that. So, now the upgrade (and for the major stuff an upgrade just about always means much, much more than just doing some rpm -Uvh on your running distro) is a major undertaking fraught with risk, peril and pain (oh great, my version of glibc doesn’t have the right symbols for the latest version of foo). If only you’d stayed more on top of the releases, in which case one could expect more of a smoother transition…
If only you’d stayed more on top of the releases, in which case one could expect more of a smoother transition…
You’re talking about desktop vs server OSes. Desktop Oses tended to require the latest now, server OSes are the opposite.
As pointed out above, why bother paying for RHEL if you’re going to want to download and install the latest and greatest? Stick with an open distro that updates frequently then.
But if you’ve got a mission critical infrastructure, no, you don’t want to update frequently. There’s a reason MS has had to extend support for NT 4.0 for those companies refusing to upgrade. You don’t play fast and loose with your core applications; if they work, you don’t change it unless you absolutely have to and only then after you’ve gone through an extensive testing/evaluation process.
RHEL will *always* be behind the finish line as far as flash-of-the-day distros go, but at least you know that everything works, and if something goes wrong you have somewhere to turn to. For corporate customers, an SLA will generally beat forum support support any day.
no, I was talking about servers. granted, their life cycle is slower than that of desktops, but the principle can still stand. As to RHEL 4 -> 5, remember, if your a paying customer, you get access to all the next redhat releases at no extra charge so that bit is not a factor.
it’s not playing loose and fast with your core infrastrure if you do it the right way. that is, you have a beta release tree of your production services, which after the appropriate testing and hardening can get released into your gamma cycle. not an all or not scenario which yes, would be foolhardy.
but yes, I do tend to strongly favour the free distribution idea rather than the support contract ‘enterprise’ ones anyhow. SLA’s may make you feel warm and cuddly, but when you have to tell management, no I can’t provide that “mission critical” feature you’re saying we need, ’cause redhat won’t let me you might not feel so hot.
“I disagree, I think unless you have a good reason not to, keeping your servers running current (stable) software is the better way to go. ”
No, it’s the opposite; unless you have very good reasons to upgrade it is better not to.
Upgrading for the sake of upgrading is nonsense and unprofessional.
where did this idea of running old software == greater stability come from… call it the (now not so true) debian stable syndrome I guess. (before I get modded down, I _like_ debian. I’m glad they seem to have changed routes on this bit of late.)
old software often means unmaintained in the upstream. that means, old security holes fester, bugs that were in the old release don’t get fixed, not to mention you lose when you need the feature of a new version, or worse, another package you need to run has a dependency on a newer release of your old sofware. sure _some_ projects release patches to older releases for the really glaring stuff, but the general attitude seems to be, “why are you still running that old (broken) release. the new one fixes that problem…”
no you don’t go blindly upgrading left and right, but I would consider not tracking (reading, testing, trying, deploying when ready, etc.) new releases in some manner to be the more unprofessional route.
“where did this idea of running old software == greater stability come from”
I think it is a more of a “if it ain’t broke, don’t fix it” thing.
In general, I would agree with this under most circumstances. However, if faced with several new deployments (to RHEL 5 when it ships, for instance), there is something to say for standardizing to a single OS release across the board in an enterprise. I still have RHEL 3 systems in production, but I am predominantly a RHEL 4 shop. In time, I will upgrade or redeploy my RHEL 3 systems to RHEL 4, or perhaps redeploy everything to RHEL 5, just for the sake of continuity and standardization. This despite RHEL 3 still meets most of my needs.
I can’t see anyone on RHEL 3 or 4 wanting to move to RHEL 5 until at least the middle of the next year. Reasons? Well, you have 5 years of support for RHEL for one thing. Also, major OEMs that ship RHEL with servers (e.g. Dell) take 3-6 months to ship the latest RHEL after its initial release (presumably they’re certifying it during that time). Finally, like Windows and its Service Packs, you’re going to want to wait until Update 1 or 2 of RHEL 5 comes out (so that the first waves of serious bugs are fixed) before you contemplate upgrades.
In other words, this article is anything up to a year premature! Yes, you will try RHEL 5 earlier for brand new servers you’re installing from scratch, but this article was about upgrades, not clean installs.
Mind you, when I “upgrade”, I usually clean install the new OS into a new box and then migrate the data/apps from the old box to the new one, running both in parallel for a while (e.g. “www.whatever” for the old OS Web site and “www2.whatever for the new one) until the new box has proven to work fine – only then do I switch over. Snag with RHEL though is that you’d have to buy 2 licenses to do that (which is why I lean towards CentOS myself unless a client insists on RHEL).
“In other words, this article is anything up to a year premature!”
I respectfully disagree. The article is a tour or highlight of key features found in a public *BETA* preview of an upcoming release of Red Hat Enterprise Linux. It is meant to help you start thinking about upgrade possibilities based on early impressions.
Considering upgrading production systems to RHEL 5 Beta 1 (aka RHEL 4.91) would be premature. Upgrading to the official release of RHEL 5 as soon as it is released may also be premature if your specific environment does not warrant it.