[ale] How do people deal with RHEL?

Thu Mar 24 14:27:28 EDT 2011

On Thu, Mar 24, 2011 at 1:48 PM, James Sumners <james.sumners at gmail.com> wrote:
> The information on which RHEL I am using is not missing from my
> original post: "Fetching Obsoletes list for channel: rhel-i386-es-4".
> That is "Fetching packages list for RHEL 4 i386." As a Red Hat guy you
> should be able to understand that.

Oh 1000 pardons for my oversight, you're right, I am a moron.  Forgive
me for spending my time responding to the core of your thread which
was BLARG WHY DOES RED HAT DO THIS?!?!?

> I never said I wanted bleeding edge software or even newer versions of
> the software available. I complained that RHEL is woefully limited in
> the packages it offers to the point that it frustrates me every time I
> want to install a new package ("new" as in "not previously
> installed"). You make the assertion that I'm coming from some fast
> moving distribution; have you seen the times between Debian
> releases[1]? They are just as slow as RHEL releases[2]. Also, yes,
> ntop was around in 2005. Its first release was at least as far back as
> 1998. It's not "new" software.

I assumed fast moving, like Ubuntu, but the point was more a distro
where someone compiles everything possible and makes it available via
repos.  Or you were a user who was used to compiling stuff from
source.  Given the crux of your complaint, I didn't think it was a
flawed assumption.  To find out that your a debianista, it just
confirms my assumption.  While Debian may not be a fast moving distro,
people compile a ton of stuff for it, and Debian integrates many
community repos into their distro, where as RHEL certainly does not.

After a little more research, you're welcome BTW, it looks like ntop
was with Red Hat Linux on the Powertools CD, but was removed when Red
Hat moved to RHEL.  Likely because of one of the other items I
outlined earlier on how Red Hat chooses packages for RHEL.  If you
have a RHEL subscription for High Performance Cluster, or HPC, the
ntop package is in that channel, but it's only for RHEL5.  Not that it
really helps you on your RHEL4 box, this second, but Red Hat has
compiled it and made it available.  I think the HPC channel is
included in any RHEL5 Advanced Platform subscription.

It's exchanges like this that cause me to not want to read the ale
mailing list anymore, nor respond to people where I think I could
provide help, so who knows, this might be my last post.

> As mentioned elsewhere in the thread, I know that I could build the
> package from source. I don't want to do that. Not only is that a
> maintenance nightmare (if I wanted the same package on all 5 of my
> RHEL servers then I would have to do the build 5 times), but I would
> have to install extra software just for the purpose of building. GCC
> is not installed on my servers, and there shouldn't be any reason to
> do so. I prefer to only have software installed on my servers that is
> necessary to run, maintain, and diagnose the server. The fact that my
> predecessor allowed X to be installed on these servers bugs me to no
> end (and also another of my gripes about Red Hat -- it installs too
> much crap by default).
>
> I did not know about the EPEL repositories, and I might start using
> them. But they won't solve the problem I face today. Even these repos
> don't contain the package I want[3]. And that's exactly what I was
> bitching about in my original post -- lack of software available via
> the the package manager.
>
> [1] -- http://en.wikipedia.org/wiki/Debian#Release_history
> [2] -- http://linuxmafia.com/faq/RedHat/releases.html
> [3] -- http://download.fedora.redhat.com/pub/epel/4/i386/repoview/letter_n.group.html
>
> On Thu, Mar 24, 2011 at 12:47 PM, scott mcbrien <smcbrien at gmail.com> wrote:
>> James,
>>
>> As others point out, you're missing some really needed information,
>> such as what version of RHEL you're using.  Since you're using
>> up2date, I'm guessing not RHEL5 or 6.  But more importantly, while I
>> can understand your frustration moving from another, faster moving
>> distribution, you're missing the point of a distro like RHEL.
>>
>> Let me precede this with a caveat about bias.  I'm a Red Hat guy,
>> since the very early days, and still use RHEL and Fedora, almost
>> exclusively.
>>
>> But RHEL is an Enterprise distro, hence the E in RHEL.  It's targeted
>> towards customers who don't like change, so if you're using RHEL5, Red
>> Hat selected those packages prior to March 2007, if you're using
>> RHEL4, your distro was created prior to February 2005.  One of the
>> tenants of RHEL is that things DON'T/CAN'T change.  So if you're on
>> RHEL4, you're using the 2.6.9 kernel.  And until RHEL4 is end of
>> lifed, you're always going to be using kernel 2.6.9.  The same holds
>> true for your applications, libraries, programming languages, the
>> whole kit and caboodle.  So my first question is, was there even ntop
>> in February 2005?  If not, then it wasn't even a candidate for
>> inclusion.  Is ntop stable, and does it have an active development
>> community, because if not, either Red Hat will have to do a bunch of
>> backporting to maintain it, or will have to do engineering on their
>> own to fix things that the community isn't taking care of.  Neither of
>> these situations is desirable.
>>
>> Beyond the age of software you might be using on your RHEL box,
>> there's also the selection of software.  Red Hat "Supports every bit
>> we ship", which means if Red Hat puts it in the RHEL distro, they're
>> obligated to answer questions and help people with it.  So if ntop is
>> available, is it a package that enough customers use that Red Hat
>> would feel remiss about not including it, AND, does Red Hat have the
>> expertise in their support and engineering organizations to support
>> this application?
>>
>> Lastly, there are a bunch of other criteria, like does this require
>> kernel hooks or modifications, how does it play with other utilities,
>> are there conflicts with other utilities.  If any of those criteria
>> are deemed show stoppers, then it doesn't get included.
>>
>> So, what if there's a piece of software you want and it's not in RHEL?
>>  Like someone else pointed out, there's EPEL.  EPEL is the Extra
>> Packages for Enterprise Linux yum repository.  It's maintained by the
>> Fedora community.  It turns out a lot of Fedora users also end up
>> using RHEL.  So there's a group of them that compile packages that are
>> in Fedora, but aren't in RHEL, for RHEL.  *** Because these package
>> are maintained by the Fedora Community, they are not supported by Red
>> Hat. ***  To get your package into EPEL, you have to be vetted, you
>> have to maintain it, and it has to be a supplement to the packages
>> that are already included in RHEL.  What I mean by that last bit is
>> that your package can't require a newer version or replacement of a
>> package that _is_ supplied by Red Hat.  That's not the case for some
>> of the other RHEL 3rd party repos like RPMFusion.
>>
>> All this stuff means that if you have a PHP based application that you
>> put on RHEL5 and rolled out to production, in March 2014, that
>> application is still working because the PHP that came with RHEL5 is
>> the same.  And if for some reason you suspect that something has
>> changed, you call up Red Hat and start working a support ticket with
>> them to get it resolved.
>>
>> Stability, Supportability, Static are the mantras of RHEL.
>>
>> Ok, so James, you're obviously used to a faster moving distro, and
>> likely compiling your own software and stuff for it.  RESIST THAT URGE
>> on RHEL.  As a systems administrator, I often have people come up and
>> say "I need a newer version of php for my application to work, can you
>> put it on the system?"  NO.  If I were to do that, then in the future,
>> if I have an issue with apache and php, I call Red Hat and they tell
>> me that my version of PHP is not supported, and that I should use the
>> supported version, reproduce the problem and then they'd be happy to
>> help me.  But of course I can't do that because the app that is having
>> the problem only works with the newer PHP, so ...
>>
>> Another common situation, for those of us who do credit card
>> processing, is that we get scanned by utilities like nessus.  The
>> person running the scan comes running in "ZOMG YOU'RE RUNNING APACHE
>> 2.2.3, ZOMG ZOMG ZOMG HAXX! YOU HAVE TO UPGRADE NOW!!!!!"  No. No I
>> don't.  Red Hat has been backporting stuff from the upstream apache
>> into the 2.2.3 version that is supported on RHEL5.  In fact, if we
>> look at the changelog 'rpm -q --changelog httpd' you'll see that Red
>> Hat calls out the CVE numbers of every vunerability that has been
>> updated and fixed in this version, all the way back to apache's first
>> inclusion with the distro.  So auditor person, please send me the CVEs
>> you're concerned about, and I can verify that they've been fixed
>> without upgrading to a NON-SUPPORTED version of this software.
>>
>> A long response, but I hope that helps your BLARG!!!!!! post.
>>
>> -Scott
>
>
>
>
> --
> James Sumners
> http://james.roomfullofmirrors.com/
>
> "All governments suffer a recurring problem: Power attracts
> pathological personalities. It is not that power corrupts but that it
> is magnetic to the corruptible. Such people have a tendency to become
> drunk on violence, a condition to which they are quickly addicted."
>
> Missionaria Protectiva, Text QIV (decto)
> CH:D 59
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>