The best server option for Red Hat

[Edward Ned Harvey]

> From: Jarod Wilson [mailto:jarod-ajLrJawYSntWk0Htik3J/w at public.gmane.org]
> 
> >> On Dec 2, 2010, at 10:17 PM, Edward Ned Harvey wrote:
> >>> ... RH does proprietary development for Dell etc, regardless of what
> >>> anyone else might tell you.
> >>
> >> Thank you, I needed a good laugh.
> >
> > Not sure what that's supposed to mean,
> > but if you don't believe me,
> 
> Its not that I don't believe you, its that you're WRONG. :)

I've put a little bit of work into this, and here's what I found:

In my vaguely recollected anecdote of a Dell support person identifying my
centos box by virtue of some closed-source library unavailable in centos...
At the time 7 yrs ago it was centos3/rhel3.  So whatever the factual basis
in that memory, it's impossible to reproduce now, using hardware that
doesn't even remotely support an OS so old.  Not like you'd care about
centos3/rhel3 anyway.

In centos3, there are essentially no records of what's different between
centos3 and rhel3.  But in more recent versions, 4 and 5, centos has done a
much better job of documenting the precise differences between centos and
redhat.  If you just look in the release notes for centos4 or 5, they give
you a list of all the packages which they've modified, new packages they've
added, and rhel packages they've deleted.  They say "All changes are
trademark and look/feel related unless otherwise noted under the specific
RPM." ... They list several dozen packages that have been changed, of which,
(centos 4.8 x86_64) 10 packages have substantial changes, and 8 packages
have been added, and none deleted.

All of the 18 packages in question of centos 4.8 seem very harmless.  For
example, changing the path from "/mnt/cdrom/RedHat" to "/mnt/cdrom/Centos"
and adding the SSL Cert Authority which certifies centos packages, and
replacing up2date via yum, and a few other things.  It's pretty hard to
imagine anything running under rhel, being unable to run under centos.

That being said, I created a multi-boot hard drive on dell hardware today,
on a system  which I need to update the firmware.  I ran the firmware update
and OMSA installer on centos 4.8, rhel 4.8, centos 5.5, and rhel 5.5.
Naturally, all the RHEL versions work flawlessly, but the question is
centos...  And the answer is "sometimes."

I don't know if Dell is employing their own software engineers, or if redhat
is doing development work for them, or any variation in between.  But as far
as I can tell, the source code for these dell installation packages is
closed source, so it's very difficult to pinpoint the root cause of centos
failure.  In some cases, I just edit an installation script, find the place
where it detects the RHEL os by /etc/redhat-release, and modify the script
to think it's the related version of RHEL... and problem solved.  In other
cases, I literally have an ELF binary, which behaves differently for no
apparent reason, if I run it on centos versus redhat.

One more thing:  On the centos4 installation, I simply overwrote the
/etc/redhat-release file using the one from rhel4.  And then the binary bios
detection executable worked.  So I can only conclude that the binary has
hard-coded a check for the /etc/redhat-release file, just as some other
scripts have done.

Regardless of centos vs redhat, my system is normally a solaris system, and
solaris is a "supported" os on this hardware ... yet solaris has no option
to apply firmware updates etc...  All I needed to do was call Dell, and they
sent me an ISO for a Dell customized Centos LiveCD, which fully supports all
the firmware update packages and diagnostic tools.

I take this to mean, you can safely assume you're able to apply firmware
updates, via livecd if necessary.  And that basically leaves just OMSA.
Well, the OMSA installer was the one where I only needed to modify the OS
detection if-clause.  It's a trivial modification, but it needs to be done
for both centos 4 and 5.  The OMSA installer fails natively, on both centos
4 and 5.

So in conclusion:

If you are going to use centos, I recommend either (a) overwriting the
/etc/redhat-release file using the supposed equivalent from RHEL, or (b)
you'll have to modify the OMSA installation script by hand, to accept centos
instead of redhat.

If you opt for centos instead of rhel on dell hardware, it is NOT a safe
assumption that you can run OMSA, or firmware update packages natively.  But
some things ARE safe to assume:  (1) You can safely assume you're able to
apply all firmware updates.  Via live CD if necessary.  In fact, DON'T
attempt firmware updates any way other than live CD.  I had a firmware scare
today, centos 4 crashing in the middle of firmware update after I "tricked"
it into thinking it was RHEL4.  Fortunately the system was still bootable,
with signs of instability, and I just flashed it again using genuine RHEL4.
Everything smooth and back to normal.  (2)  I only tested one system, but in
my opinion, you can probably safely assume OMSA and requisite drivers will
run on centos 5, with perhaps a little bit of manual intervention such as
overwriting /etc/redhat-release.  I am less confident about centos 4, if you
care.

It is not clear the reasons why.  In fact, if any of you want, I can give
you the "ldd" and "strace" outputs I obtained from the BIOS version
detection elf binary today.  Suffice it to say:  I examined it thoroughly,
and all I was really able to conclude was that the
bios-version-detection-binary "biosie.bin" (and some other binaries) behave
dramatically different on supposedly identical versions of centos versus
rhel.  It works flawlessly on rhel 4.8, and it fails entirely on centos 4.8.
The end result is inability to update firmware on centos 4.8.  I am required
to use either Dell customized LiveCD, or some other means to apply the
firmware update on centos 4.8.