Re: OS Patches

From: William Muriithi <>
Date: Wed, 17 Feb 2010 07:56:23 -0600
Message-ID: <>


A local repository would not have helped him here. His issues started because the system restarted in the middle of an update, leaving it in incoherent state. None of the operating system out there could survive that especially if something critical was being patched. I know windows will not allow updates on battery for the same reasons.

A couple of months ago, someone on this list should a way of updating a production system from redhat repository with the same binaries that were applied on the test environment. It was yum related and I tested it and it worked like a charm. Will post the link if I can find it. I thought that was the best way to go around redhat ever changing repository

I am surprised though there is still a lot of changes on RHEL4. That version is already in the 3rd phase of redhat support and receive just critical updates. I would therefore consider it prudent to apply them unless its not a connected to public network

  • Original Message ----- From: <> To: <> Cc: <>; <>; <> Sent: Wed Feb 17 04:56:24 2010 Subject: Re: OS Patches

Hi all,

Actually I find using up2date directly from the Redhat not so secure. I think the best way to do it, which I try to do, is:

  • Finding out why do you want to patch the systems? (Security, stability, bug?)

-Creating your own Redhat satellite or using satellite of Redhat and making the packages to be upgraded (Im talking about very very critical ones),

-Testing them in pre production environment(identical pre prod / prod environment needed)

Though I seem to avoid the fact that your systems may not have the same setup and/or your directors may/may not invest the money needed for Redhat satellite/ Redhat support, this shall surely secure the process better than up2date.

Özgür Özdemircili

On Tue, Feb 16, 2010 at 9:25 PM, Matthew Zito <> wrote:
> Up2date -u is definitely not the way to upgrade your linux machines.
> You should move to phased releases for your database boxes - 4.7, 4.8,
> 5.3, etc.
> Matt
> -----Original Message-----
> From:
> [] On Behalf Of Li Li
> Sent: Tuesday, February 16, 2010 3:05 PM
> To:
> Cc:
> Subject: Re: OS Patches
> we had an incident last month when patching one of the RAC nodes (RHEL
> 4.6). when one of our engineers was runing "up2date -u", the server
> automatically rebooted on its own to kernel panic. We have been
> working with redhat support with no luck. We ended up having to drop
> that node out of the cluster because it prevents us from doing RMAN
> clone due to bug 8367313.
> I am now very nervous about Redhat patching. My understanding is
> Redhat releases RPM patches on a daily basis and no matter how you
> test the patches in your non-production, you might get a new RPM fix
> when you patch your production on a later date. In our case, we tested
> it in our non-production boxes with no issue, but it caused problem
> when patching production boxes.
> I am wondering how you all handle OS patches? one thing I can think of
> is to only patch to a Redhat native release, ie, only patch to 4.7,
> 4.8 etc, instead of running "up2date -u".
> Thanks,
> -Li
> On Tue, Feb 16, 2010 at 7:45 AM, Peter Nedeljkovich
> <> wrote:
>> We've got a 4 node RAC 11gR1 on Linux 4.7 with ASM. We need to bring
> the
>> latest patches into the OS and I was wondering what the best practice
> would
>> be. I realize that we could do a rolling patch if we were patching CRS
> or
>> the databases but can that be done for the OS? Would it be better
> (Safer?)
>> to shutdown the whole RAC and do the OS patch to one node at a time or
> can
>> we leave 3 nodes up while patching one?
>> Peter Nedeljkovich
>> DBA
>> Georgian College
>> 705-728-1968 Ext. 1217
> --
> --


i0zX+n{+i^ Received on Wed Feb 17 2010 - 07:56:23 CST

Original text of this message