Re: OS Patches
- From: Ozgur Ozdemircili <ozgur.ozdemircili@xxxxxxxxx>
- To: William Muriithi <william.muriithi@xxxxxxxxxxxxxxxxxxx>
- Date: Wed, 17 Feb 2010 15:39:17 +0100
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@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxx <oracle-l-bounce@xxxxxxxxxxxxx>
> To: mzito@xxxxxxxxxxx <mzito@xxxxxxxxxxx>
> Cc: litanli@xxxxxxxxx <litanli@xxxxxxxxx>; pnedeljkovich@xxxxxxxxxxxxxxx <
> pnedeljkovich@xxxxxxxxxxxxxxx>; oracle-l@xxxxxxxxxxxxx <
> oracle-l@xxxxxxxxxxxxx>
> 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@xxxxxxxxxxx> 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@xxxxxxxxxxxxx
> > [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Li Li
> > Sent: Tuesday, February 16, 2010 3:05 PM
> > To: pnedeljkovich@xxxxxxxxxxxxxxx
> > Cc: oracle-l@xxxxxxxxxxxxx
> > 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@xxxxxxxxxxxxxxx> 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
> >>
> >>
> > --
> > //www.freelists.org/webpage/oracle-l
> >
> >
> > --
> > //www.freelists.org/webpage/oracle-l
> >
> >
> >
> --
> //www.freelists.org/webpage/oracle-l
>
>
>
Other related posts:
