[ale] How do people deal with RHEL?
Lightner, Jeff
jlightner at water.com
Thu Mar 24 14:35:40 EDT 2011
Well there isn't a "general" lack of software in RHEL. In my experience they give hundreds of choices during the install and have hundreds of choices in their repositories. I have more of a problem NOT installing things I don't want than finding things I do.
Everyone has their own favorites and just because you like ntop doesn't mean everyone else does. I don't believe it is as ubiquitously used as say Sendmail or VIM. I personally make sure to exclude emacs on any system I install but there are just as many users on this list that would choose to use emacs exclusively. RHEL lets you have either of those or nano. RHEL teaches Dovecot and Postfix in their classes when talking about mail but we don't use either here. They do continue to provide Sendmail which we do use.
I've seen this kind of preference with many distros and it is often based on their guiding principles. For example "motif" is available in RHEL but not in Fedora because Fedora's rules prohibit it. Instead Fedora provides "lesstif" (IIRC) which provides a truly FOSS library like the one motif does. Note that one could get motif and install it on Fedora - it is simply the package maintainers that won't do it. When I ran up against this I chose to install lesstif rather than rail against the fact motif wasn't available.
It may be there is an alternative RHEL provides since they didn't include ntop. A couple of things you can get from RHEL repositories (at least in RHEL5) are: Wireshark and Iptraf.
The info for Iptraf says:
Summary : A console-based network monitoring utility.
License : GPL
Description: IPTraf is a console-based network monitoring utility. IPTraf
: gathers data like TCP connection packet and byte counts, interface
: statistics and activity indicators, TCP/UDP traffic breakdowns, and
: LAN station packet and byte counts. IPTraf features include an IP
: traffic monitor which shows TCP flag information, packet and byte
: counts, ICMP details, OSPF packet types, and oversized IP packet
: warnings; interface statistics showing IP, TCP, UDP, ICMP, non-IP
: and other IP packet counts, IP checksum errors, interface activity
: and packet size counts; a TCP and UDP service monitor showing
: counts of incoming and outgoing packets for common TCP and UDP
: application ports, a LAN statistics module that discovers active
: hosts and displays statistics about their activity; TCP, UDP and
: other protocol display filters so you can view just the traffic you
: want; logging; support for Ethernet, FDDI, ISDN, SLIP, PPP, and
: loopback interfaces; and utilization of the built-in raw socket
: interface of the Linux kernel, so it can be used on a wide variety
: of supported network cards.
On a Google search I found people suggesting iptraf as an alternative to ntop.
The problem I see with your complaint is it essentially:
1) Asks why RedHat doesn't think what is important is what YOU think is important.
2) Continues to complain despite the fact folks have
a) Pointed out there are ways to get the package what you want.
b) Pointed out you're on a 6 year old OS that is going EOL. You say you don't have a choice about continuing to use it. It seems if you can recognize you have so little voice in your own environment that you'd recognize the futility of attempting make external entities like RedHat come to your way of thinking let alone convince a group as diverse as ALE agree that it should do so.
-----Original Message-----
From: ale-bounces at ale.org [mailto:ale-bounces at ale.org] On Behalf Of James Sumners
Sent: Thursday, March 24, 2011 1:48 PM
To: Atlanta Linux Enthusiasts
Subject: Re: [ale] How do people deal with RHEL?
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
_______________________________________________
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
Proud partner. Susan G. Komen for the Cure.
Please consider our environment before printing this e-mail or attachments.
----------------------------------
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you.
----------------------------------
More information about the Ale
mailing list