The best server option for Red Hat

[jabr-mNDKBlG2WHs at public.gmane.org (John Abreau)]

You've shown that Dell software behaves differently on CentOS vs RHEL.
You have *NOT* shown any evidence that Red Hat did any proprietary
development for Dell.

Jarod works at Red Hat and is in a postion to be aware of any proprietary
development at Red Hat, if any existed. He has repeatedly asserted that
no such development exists.



On Fri, Dec 10, 2010 at 12:13 AM, Edward Ned Harvey <blu-Z8efaSeK1ezqlBn2x/YWAg at public.gmane.org> wrote:
>> 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.
>
>
> _______________________________________________
> Discuss mailing list
> Discuss-mNDKBlG2WHs at public.gmane.org
> http://lists.blu.org/mailman/listinfo/discuss
>



-- 
John Abreau / Executive Director, Boston Linux & Unix
AIM abreauj / JABBER jabr-iMZfmuK6BGBxLiRVyXs8+g at public.gmane.org / YAHOO abreauj / SKYPE zusa_it_mgr
Email jabr-mNDKBlG2WHs at public.gmane.org / WWW http://www.abreau.net / PGP-Key-ID 0xD5C7B5D9
PGP-Key-Fingerprint 72 FB 39 4F 3C 3B D6 5B E0 C8 5A 6E F1 2C BE 99