Thanks for all the suggestions guys. It looks like we're going to go down the route of having an identical test server to apply all updates to before we put them onto the production machines. At the moment we rely on too many third party apps that are not in RHEL repository, but I hope to gradually reduce this number. Thanks again for the feedback, Adam -----Original Message----- From: David Miller [mailto:millerdc@xxxxxxxxxxxxxx] Sent: 16 August 2006 21:40 To: General Red Hat Linux discussion list Subject: Re: RHEL 4 Update Procedure Like Mathew said there really is no right answer. Especially once you add third party software all quality assurance from Red Hat goes out the window. For example what if you have to use the latest version of Mysql? Once you install that Red Hat is not going to support it. They will only support the back ported old version they offer. There are ways to mitigate problems though. One is to plain for this stuff before setting up a server. Here are a few scenarios that help. 1. Install Red Hat on two different internal drives. get the main drive all up-to date and working with your production stuff. Use rsync to keep the second drive the same. If an update borked something you can always boot off the second drive and be right where you were before the update. 2. Use RAID1 and break the mirror before updates. If everything is fine rebuild the mirror. 3. Have two identical systems. One for production and one for testing. This solution can be very expensive but it is the only true get an accurate test of an update. 4. Try to use some form of virtual machine and replicate your setup. On Aug 11, 2006, at 1:38 AM, 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 > > -- > redhat-list mailing list > unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe > https://www.redhat.com/mailman/listinfo/redhat-list David Miller Systems admin millerdc@xxxxxxxxxxxxxx -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
