Re: OS Patches

From: Ozgur Ozdemircili <ozgur.ozdemircili_at_gmail.com>
Date: Wed, 17 Feb 2010 15:39:17 +0100
Message-ID: <22df2f891002170639k67271b19lee92d7c242ff243c_at_mail.gmail.com>



Hi actually you have a point there. While we are discussing what should be and should be setup we seem to have ignored Lili`s real problem (bad bad DBA`s :))

To answer Peter`s question; Apart from the fact that we can use Redhat satallite(not sounding like Redhat affiliate) Redhat offer what is server provisioning. Like Opforce you can create a image`s of your systems in case you need to rebuild or/and go back to a stage. Though it is rather complicated process , once you get the hang of it, it makes things very easy.It supports:

Bare metal provisioning
Existing state provisioning
Multi-state rollback (includes snapshot based recovery) Configuration management
RPM based application provisioning
Kickstart configuration writer

For those, who does believe in opensource can easily use Linmin( http://www.linmin.com/site/products.), a limited version of provisioning.

Özgür Özdemircili
http://www.acikkod.org
Code so clean you could eat off it

On Wed, Feb 17, 2010 at 2:56 PM, William Muriithi < william.muriithi_at_epicadvertising.com> wrote:

> Ozgur,
>
> 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: oracle-l-bounce_at_freelists.org <oracle-l-bounce_at_freelists.org>
> To: mzito_at_gridapp.com <mzito_at_gridapp.com>
> Cc: litanli_at_gmail.com <litanli_at_gmail.com>; pnedeljkovich_at_georgianc.on.ca <
> pnedeljkovich_at_georgianc.on.ca>; oracle-l_at_freelists.org <
> oracle-l_at_freelists.org>
> 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 <mzito_at_gridapp.com> 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: oracle-l-bounce_at_freelists.org
> > [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Li Li
> > Sent: Tuesday, February 16, 2010 3:05 PM
> > To: pnedeljkovich_at_georgianc.on.ca
> > Cc: oracle-l_at_freelists.org
> > 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
> > <pnedeljkovich_at_georgianc.on.ca> 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
> >>
> >>
> > --
> > http://www.freelists.org/webpage/oracle-l
> >
> >
> > --
> > http://www.freelists.org/webpage/oracle-l
> >
> >
> >
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

--
http://www.freelists.org/webpage/oracle-l
Received on Wed Feb 17 2010 - 08:39:17 CST

Original text of this message