[ale] How do people deal with RHEL?

[Damon L. Chesser]

On Thu, 2011-03-24 at 13:48 -0400, James Sumners 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.
> 
> 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).

On GCC we agree.  I worked for a hosting company that would install gcc
on all the servers and compile from source all the newest httpd and what
have you.  They could not understand why you would not want gcc on a
server "how are you supposed to compile if you don't have gcc?".  Of
course the answer is "you don't".  You use a dev server for that and
make an rpm.  Perhaps this would fix your issue?  Make an RPM of ntop to
match your 5 servers software. 
> 
> 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
> 
> 
> 
> 

-- 
Damon
damon at damtek.com