Stuart Jansen wrote: > Keeping a server updated isn't as easy running "apt-get safe-upgrade" or > "yum update" once in awhile. If something important is changing like SSH > or Apache, the changelog has to be read carefully and fully understood. > Maybe even download the source package and pick apart the change. No > matter what, before the production servers can be updated, the changes > have to be validated in a test environment. Only then can it be rolled > out to production. (You do have dev, test and prod environments right?)
For those in "enterprise" (I really hate that word, actually)
environments, change usually means some sort of process migrating from
alpha to development to testing to sqa to pre-production to production.
Finding the right way to make sure production gets the appropriate
updates from pre-prod, etc is a PITA. Further, getting a new dev system
up, so it mirrors pre-prod, so devs can pick up from a certain point is
equally a PITA. Then there is the headache of small updates and patches
that have to be applied across the system. These are things no one ever
thinks about.
> Upgrading a server from one release to another is not as common as you
> think. Most companies never do it. Instead, switching releases coincides
> with purchasing new hardware. Many companies run the same release for 3
> to 5 years, and maybe even until the hardware fails. ("Upgrades cost
> money. Reinstalls cost money. What we've got is working, don't touch
> it.")
We don't do it in development or higher, and this is why: upgrading an
operating system means extensive testing that all the newly updated
software versions, config files and libraries will play nicely with the
development environment. None of us have the time to figure out why
Oracle, Java or Weblogic won't play nice with the new Apache update or
alternatives system. Fact of the matter is, if it works, leave it. New
versions of software really just wets the pants of a developer. A
sysadmin would rather steer clear. As a result, we have a couple RHEL
2.1 servers. Sure, I would love to get them on 5.4, but then I don't
want to deal with stuff breaking when the update is complete.
> You might have a system that works for you, but what about when you
> leave the company? Someone else is going to have to replace you, and the
> stranger your approach to managing servers, the more disruptive and
> destructive your behavior. (Sure, if you're perfectly keyed into the
> Gentoo universe, it might be possible for _you_ to keep a server stable
> with Gentoo, but what about the next poor slob?)
Doing _anything_ out of standard practice is generally heavily frowned
upon for this reason. Sure, you have to make cuts here and there to get
stuff working, but rebuilding the Xen kernel, because you don't like the
way it handles networking, or setting up a mail server with all this
custom database and performance tweaks, just because you can, or that's
the way you like it, doesn't mean you should.
> Want to know the real definition of "enterprise"? Check out HP-UX or
> AIX some time. Rock solid, but most of you would tear your hair out they
> feel so "ancient". Before there was Red Hat, there was Sun. Solaris made
> it's name by being more nimble and cutting edge. Of course, put most
> Linux users in from of a Solaris box and they'll probably gnaw their own
> arm off because it feels so old and different.
Getting my job at the VA, we had several HP-UX and a few Solaris
machines around. Being accustomed to the way RHEL did things, I felt
like I was wading through the '80s with HP-UX and Solaris. However, want
to hear something rather unfortunate? We get much better uptimes with
HP-UX and Solaris than RHEL. Call me wonky, but HP-UX doesn't swap out
as much as RHEL does with the same software installed. Sure, I can tweak
this, and we do, but RHEL can't seem to keep the performance of HP-UX
when swapping, which usually means bouncing RHEL to get the performance
back.
> RHEL is kinda funny. It's the big boy on the Linux block revenue-wise.
> It's fashionable to gripe about RHEL, but the fact is Red Hat must be
> doing _something_ right. Most people complain it changes too slowly. But
> if you sit down talk to an experienced Unix admin, with his six figure
> salary and foot long beard, you'll hear him complaining that RHEL
> changes too quickly.
RHEL is the big box, because it has a corporate backing. Ultimately,
"enterprise" companies don't do Debian, BSD or the like, because there's
no one to turn to for support, because your sysadmins aren't qualified
to do their job. Further, you can't purchase licenses from Debian or
BSD, and the suits don't like that. They want to know that they have
stability and reliability in their hardware when putting millions of
development and support costs into their product. You don't get those
fuzzy wuzzies as a suit if you don't have a piece of paper that says
you're "enterprise". You don't sleep well at night knowing that you have
no one to blame, should the OS tank, an application segfault, or the
kernel panic. That's why RHEL is king. It's why Solaris, HP-UX, AIX and
Windows are king. It's why Debian, *BSD and many of the others take a
back seat in the large corporate world.
> SLES is.. best to pass by quietly. I'll say just two things: (1) Digging
> into SLES has made me realize that when someone says something was built
> with "german [over-]engineering", that isn't always a form of praise.
> (2) Novell buying SUSE was the best thing to happen to SLES, it lead to
> a real improvement in the distro.
I'm pleasantly surprised by openSUSE and SLES/SLED. They've done massive
improvements to not only the SUSE operating system itself, but to GNOME
as well. Not my cup of tea, but I'll tip my hat to it.
> Debian Stable is okay. It can be a real enterprise distro when used
> correctly. Personally, Debian's bureaucracy scares the heck out of me. A
> stubborn DD can do a lot of damage. (Anyone remember the asinine way
> Debian used to package Ruby?) At the moment, Stable is newer than RHEL,
> but that isn't always the case. Once upon a time Stable was known for
> being ancient. (For example, I remember being pissed off at how old
> Debian's OpenLDAP package was compared to RHEL and SLES.) True, Debian
> is doing a better job of releasing on schedule these days. The
> disadvantage of more rapid Debian releases is that if you do the math
> you'll discover RHEL and SLES have a much longer support period.
Debian still only releases when it's ready. It doesn't have solid
release dates like Fedora or Ubuntu. So, Debian Stable is far more
stable than Fedora, Ubuntu, and most others, because of this rule. Those
who are concerned about bleeding edge don't run stable anyway. They run
unstable and the paranoid run testing. This takes the pressure off
stable to release frequently.
> Ubuntu LTS is okay. It can be a real enterprise distro when used
> correctly. But a lot of people confuse "installable" and "supported".
http://pthree.org/2009/02/19/server-migration-from-ubuntu-804-to-debian-50/
> In other words, every enterprise distro sucks, but they're still better
> than the alternatives.
That's because the word "enterprise" sucks. Take that out, and you begin
to judge operating systems at face value for what they are.
> Gentoo is very much not an enterprise distro.
Gentoo is dead. Of course, I heard someone say that recently about BSD. :)
/me ducks
--
. O . O . O . . O O . . . O .
. . O . O O O . O . O O . . O
O O O . O . . O O O O . O O O
signature.asc
Description: OpenPGP digital signature
-------------------- BYU Unix Users Group http://uug.byu.edu/ The opinions expressed in this message are the responsibility of their author. They are not endorsed by BYU, the BYU CS Department or BYU-UUG. ___________________________________________________________________ List Info (unsubscribe here): http://uug.byu.edu/mailman/listinfo/uug-list
