[ale] How do people deal with RHEL?

[James Sumners]

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.

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.

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