RHEL 4 Update Procedure

[Matthew B. Brookover]

This is a case where no matter what you do, you will be wrong.

If you do not patch, you leave your server exposed to security issues or
you may stumble into a bug that has been fixed.  If you do patch you are
at risk of breaking something.

Best solution is to test the patches on an old server before you apply
them to your production servers.  Even then, I recently ran into a
problem that did not show up until the system was under a high load.  I
could not simulate that load on my test machine.  What was worse, the
solution was to recompile the programs in question.  The programs worked
fine, 9,999 out of 10,000 uses, but 1 out of 10,000 the program would
get caught in an uninterruptable sleep, and a recompile seems to have
fixed it.  Very strange!

Matt

On Fri, 2006-08-11 at 09:38 +0100, AB wrote:

> Hello all,
> 
> We run several mission critical RHEL 4 AS servers and we are currently having a
> bit of an internal debate regarding the installation of official RedHat updates.
> 
> Several of my colleagues think that installing the RedHat updates is too
> dangerous because it could potentially break another package and/or another
> piece of our or a third party's software.
> 
> These are my arguing points as to why we should apply the updates. Please
> correct me if I have misunderstood any of the points I make, and feel free to
> add more to the list (the more the better): -
> .	All RHEL updates are exhaustively tested by RedHat to make sure they
> will not break other official components of the OS.
> .	RHEL updates are only ever bugfix / security updates. An API/ABI will
> never be changed as part of an update. If one of our programs was compiled
> against a library which later got updated, the program would not be negatively
> affected by the update.
> .	RHEL updates are tested against most of the large certified applications
> (such as Oracle etc.) before release.
> .	RedHat don't release updates just for the fun of it, they release them
> to fix new security holes to prevent our systems been broken into, and to fix
> known critical bugs to keep our systems stable and our data intact.
> 
> On a slightly different note, does anyone know of a certification framework we
> could develop our applications to, to provide the best possible compatibility
> with the underlying RHEL OS?
> 
> What do most other organisations in our position do? I'd be especially
> interested to hear from other companies using RHEL 4 AS who must provide 24/7
> availability, and what RedHat's official line on the matter is.
> 
> 
> Regards,
> Adam
>