"stuck at RHEL5"?

[JP Vossen <jp () jpsdomain org>]

OK, I've been trying to keep my mouth shut on the larger issue, but I 
just read 
http://blog.snort.org/2011/01/rpms-for-rhel5-are-available-from.html and 
I just can't let that one go.

Seriously?  You seriously used the phase "stuck at RHEL5" twice in a 5 
(counting generously) paragraph blog?  (Fair warning: pent-up rant alert!)


Main point up front:
Who else votes for better RHEL5/CentOS-5 support and longer life-cycles?!?

And who else votes for actual support of RHEL6 (and CentOS-6 whenever it 
finally gets here) that conforms the the RHEL life-cycle not the SF 
whatever-the-hell-the-devs-feel-like-this-week Snort life-cycle?

For whatever it's worth, I vote for both.  :-)


<rant on>
Maybe I'm the only one--based on all the recent "guides" I am--but I 
need to use RHEL (well RHEL & CentOS) at work.  I'd love to use Debian, 
or would reluctantly use an Ubuntu LTS, but I will avoid Fedora or god 
forbid OEL like the plague.  Aside from how I loath Oracle (yeah, I know 
OEL is really RHEL, I just loath Oracle), the Ubuntu, Fedora and Snort 
life-cycle is simply too short for an Enterprise pace.  I am not happy 
about this, I'd like to move faster and keep up too.  But that simply 
does not happen at the Enterprise level (at least where I've worked and 
esp. now).

So basically, I am "stuck at RHEL5" or CentOS.  (And I really don't 
believe I'm the only one, speak up out there!)  This isn't SF's fault.

Due to NDAs if we want certain rules we *have* to use the pre-compiled 
ones.  OK, I get it.  I don't like it, but I get it.  Also not SF's fault.

So let's go look at the options in a tarball I have laying around:
$ tar tvzf snortrules-snapshot-2901.tar.gz | grep 'precompiled' | cut 
-d'/' -f4 | sort -u
Centos-4-8
Centos-5-4
Debian-Lenny
FC-11
FC-12
FC-9
FreeBSD-7-3
FreeBSD-8-1
OpenSUSE-11-3
RHEL-5.0
Ubuntu-10-4
Ubuntu-8.04

Huh?!?  FC9, 11, 12, but not 10, and all of which are obsolete and 
unsupported.  But not F13 (that Snort is actually compiled for) or F14 
(current), not CentOS-5.5 (current).  RHEL-5.0, also unsupported but not 
RHEL-5.5 (or just use the CentOS).  And why "8.04" (correct) but "10-4"? 
  WTH is "10-4?"  (80's flashback: 10-4 good buddy! :)

OK, I'd love to use Lenny (or I guess Ubuntu 10.04), but I can't.  We 
use RHEL for almost everything and I can't (and shouldn't) fight that. 
BSD is great, but same problem.  Fedora is coming nowhere near anything 
I touch for production at work [1].  But I can live with Centos-5-4. 
It's not current, but then again I was the one whining about the slow 
enterprise pace above, right?

Off to get the engine...  But wait!  What do I see at 
http://www.snort.org/snort-downloads?  F13.  The one that was obsoleted 
2 months ago by F14 [2].  Where are the CentOS or RHEL binaries?  You 
know, the major enterprise Linux distro version released in 2007 but 
supported to 2014 (or 2017 depending) [3] and for which there are 
pre-compiled rules.  That one.  Where is it?  My head hurts!


Sure I can compile the RPMs myself, and I did.  You can even argue that 
someone who can't compile the RPMs (or binaries) themselves has no 
business running Snort in an enterprise environment and I might even 
agree.  But the folks in smaller shops don't want to upgrade the OS on 
their Snort sensors every 6 months either, and those folks might not 
have the time or resources needed to do the compiles.  (I am staying out 
of any "buy the SF appliance" or use the "ET" rules areas.)

To be honest, the little inconsistencies just really bug me.  And the 
idea that only a few folks are "stuck at RHEL5" and that that's not a 
big deal *really* bugged me.  I actually *am* "stuck at RHEL5" but I 
don't mind all that much and it's better than many alternatives (e.g. 
Windows or OEL).  Maybe I'm wrong.  Maybe I really am the only one.  But 
I kinda doubt it.  And I wonder how the other folks are doing.  Based on 
the chatter on the MLs over the last few months wrt to DAQ and pcap on 
RHEL5, they aren't doing too well.  (Except for Vincent :).

OK, rant over.  (If anyone actually read this far... :)
<rant off>

Maybe Joel could do a vote on the blog, like the recent classification 
discussion, and collect more info on who is really using what.

Finally, kudos-in-a-rant to Joel for having to put up with nuts like me, 
and for the new blog, which I have found to be excellent.  And also 
kudos to Vincent Cojot for his excellent RPM work, especially the 
CentOS-5 libpcap compatibility trick.  That saved me a lot of effort, as 
I've already told him.

Sincerely,
JP
________________________________________________
[1] Maybe I'm old fashioned, but I find the concept of using Fedora in 
any kind of production environment completely insane.  Even ignoring the 
fact that it is arguably more-or-less the alpha & beta for RHEL, the 
following quotes from 
http://en.wikipedia.org/wiki/Fedora_%28operating_system%29 should bring 
any self-respecting sysadmin to the brink of madness:
"One of Fedora's main objectives is [...] to be on the leading edge 
[...]" and "Fedora has a comparatively short life cycle: version X is 
maintained until one month after version X+2 is released. With 6 months 
between releases, the maintenance period is a very short 13 months for 
each version."  No, that's not going in my production data centers.


[2] 
http://en.wikipedia.org/wiki/Fedora_%28operating_system%29#Version_history

[3] https://access.redhat.com/support/policy/updates/errata/
----------------------------|:::======|-------------------------------
JP Vossen, CISSP            |:::======|      http://bashcookbook.com/
My Account, My Opinions     |=========|      http://www.jpsdomain.org/
----------------------------|=========|-------------------------------
"Microsoft Tax" = the additional hardware & yearly fees for the add-on
software required to protect Windows from its own poorly designed and
implemented self, while the overhead incidentally flattens Moore's Law.

------------------------------------------------------------------------------
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl 
_______________________________________________
Snort-devel mailing list
Snort-devel () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-devel