RE: ocfs2/oracleasm on Red Hat 4
- From: "QuijadaReina, Julio C" <QuijadJC@xxxxxxxxxxxxxxx>
- To: Matthew Zito <mzito@xxxxxxxxxxx>, Guillermo Alan Bort <cicciuxdba@xxxxxxxxx>
- Date: Thu, 28 May 2009 14:07:24 -0400
When it comes to security, I try to keep my db servers "behind bars" (I am
borrowing the phrase from an another thread) and not in the open network. I try
to use whatever tools needed to protect them (firewall on the network and the
server itself, listener security, etc.)
Part of me says your model makes sense. The other part of me is not at peace
and says 'well you got vulnerabilities on your systems'. But then again, what
is the likelihood that such vulnerability is exploitable on a security-hardened
system. Like I mentioned, I recently began doing this kind of work on the OS
side. So, I am willing to give different models a try. I can definitely see how
the "if it ain't broke don't fix" model would mean less updates to apply - less
work on that end the job.
And just out of curiosity and a desire to learn, I may do the mix RAC on test.
Or I might just stay on RHEL4 until Red Hat or Oracle don't support it anymore
;-)
Thanks,
-Julio
-----Original Message-----
From: Matthew Zito [mailto:mzito@xxxxxxxxxxx]
Sent: Thursday, May 28, 2009 1:05 PM
To: QuijadaReina, Julio C; Guillermo Alan Bort
Cc: oracle-l@xxxxxxxxxxxxx
Subject: RE: ocfs2/oracleasm on Red Hat 4
I'm a fan of the, "If it ain't broke..." model of doing things.
Periodic updates are fine, but coordinated appropriately, and with
consideration. For example, a patch for the "less" command, or a bugfix
for "sar" - fine, those changes are isolated and restricted to
individual commands.
But anything that touches:
- compiler
- system libraries
- kernel
I'm very resistant to applying unless there's a really good reason -
like there's a bug I've already hit or believe myself very likely to
hit, or a remotely exploitable vulnerability in a fairly open network.
Cause otherwise, you're just fixing bugs you haven't run into yet, which
you are unlikely to ever run into - and possibly introducing new bugs
with their own set of fun problems.
As far as migrating by gradually adding RHEL5 nodes into the mix, I
think that's a supported config, but again, I wouldn't want to be
calling Oracle support and explaining that I have two RHEL4 nodes and
one RHEL5, and they're all down.
Thanks,
Matt
-----Original Message-----
From: QuijadaReina, Julio C [mailto:QuijadJC@xxxxxxxxxxxxxxx]
Sent: Thursday, May 28, 2009 12:59 PM
To: Matthew Zito; Guillermo Alan Bort
Cc: oracle-l@xxxxxxxxxxxxx
Subject: RE: ocfs2/oracleasm on Red Hat 4
Updating the OS kernel has been a best practice for me as I am also
doing the Sys admin work. Any specifics as to why you discourage it?
My thought on 'upgrading' was to first add an RHEL5 server to the
cluster and then take RHEL4 nodes out.
-Julio
-----Original Message-----
From: Matthew Zito [mailto:mzito@xxxxxxxxxxx]
Sent: Thursday, May 28, 2009 12:43 PM
To: QuijadaReina, Julio C; Guillermo Alan Bort
Cc: oracle-l@xxxxxxxxxxxxx
Subject: RE: ocfs2/oracleasm on Red Hat 4
For sure, both Oracle and Red Hat are encouraging people to go to RHEL5.
However, they can encourage all they like, it's still technically a
supported OS by both organizations, so they don't have a lot of choice
if you press the issue.
If you're looking at upgrading to RHEL5, I guess my question would be -
why are you looking at upgrading the kernel version? If it's just as a
best practice, I'd discourage you from doing so. If it's for a specific
bug, then you may not have any options.
But RHEL4->5 has a number of changes in a number of areas, notably the
iSCSI stack, the required kernel parameters for Oracle, a different
kernel scheduler model, etc. I'd be very leery of upgrading between
major RHELs if possible.
The last option is that you could make your own ASMlib and OCFS2 modules
compiled against the updated red hat kernel - probably a shorter
turnaround time vs. oracle and you don't have to deal with them.
However, does put you in the business of rolling your own software,
which some folks are quite resistant to.
Matt
--
//www.freelists.org/webpage/oracle-l
Other related posts:
