Re: "stuck at RHEL5"?

[Joel Esler <jesler () sourcefire com>]

On Sat, Jan 8, 2011 at 5:53 AM, JP Vossen <jp () jpsdomain org> wrote:

> 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.
>
> Perfectly fine, I appreciate the feedback.



> Seriously?  You seriously used the phase "stuck at RHEL5" twice in a 5
> (counting generously) paragraph blog?  (Fair warning: pent-up rant alert!)
>
> That's also perfectly fine, I'll respond in line.




> 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?
>
> We don't do things "just for the hell of it".  There are reasons for the
decisions we make, and maybe I need to do a better job of explaining those
reasons so our community understands them.

It's a matter of resources to test across many platforms.  Not just Linux,
but we test on a bunch of different things, so our course of action is
generally to build on whatever is the "current" release of RHEL/CentOS and
Fedora platforms when a Snort release hits beta.  We do look ahead in that
planning a little but there are often timing issues with waiting for a new
OS release.

In the case of Snort 2.9, that meant FC13 and would have meant RHEL/CentOS
5.5.  We do not update our platform support for patch releases (i.e.
2.9.0.3) since there is a larger QA effort in terms of reimaging systems
that we simply cannot swallow.  That is one of the many reasons we release
source code in tarball format, so users can build on any platform they
desire.

With Snort 2.9 and the release of DAQ, we now require libpcap 1.0 or higher.
 This is simply not a package that is included in the standard distro build
of CentOS 5.5 (FC13), and the Snort development team are not going to
repackage libpcap within the Snort RPMs, so we're stuck there as well.

There is a plan to build on CentOS 6 for Snort 2.9.1 (our next planned
version) assuming it's available, so there will (read: should) be RPMS for
the RHEL6 platform.  We will not be able to support RHEL 5 because of the
above points.


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).

I understand.


> 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.

Thank you for recognizing that.  We'll make some changes around this soon I
hope.


> 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! :)
Okay, we can correct this, thanks for bringing it to our attention.  The VRT
maintains a separate build environment that is much larger than the Snort
team's build env, simply for the Shared Object rules.  (adding OpenBSD to
that above list very soon as well.)  Maybe we can get to a point in the near
future where we can align the builds for VRT and Snort Dev to make it easier
for the community, but then we'll run into the reverse effect, and we'll
catch scorn for that as well.  So we are between a rock and hard place. But
we'll sit down internally and figure this stuff out.

Personally, I have a box here at the house that is Fedora Core 10.  It's
running the FC-9 Shared Object rules.  They work fine.  Undocumented, but
they work.  That's my own personal work around.   I have to maintain my own
compiles for libpcap, libdnet, and such as well.  Unfortunately that's the
price I pay for not wanting to move my personal box to a higher version.
 Not a realistic expectation in the enterprise world.  But that's the price
of free software for me.


> 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?

We understand that.  It *is* possible to maintain the source builds for
these (libpcap, pcre, libdnet, Snort, DAQ, etc) as well, by downloading the
source code.


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.)
Right, I understand that.  Personally (and not speaking for the company on
this point), I'd rather we don't build RPMs at all. I'd rather we just put
out the tarball and let the package maintainers keep the distros up to date.
 Unfortunately, they don't.  We have some packages way back in 2.6 land
laying around because the package maintainer either stopped doing it, got
lazy, whatever.  Doesn't matter, the point is they are out of date.  So we
put out a few.



> To be honest, the little inconsistencies just really bug me.


And maybe I can fix some of these.


> 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 :).
And it's great that the community stepped up to do that.  I'd love to have
the community do more of that (similar to my previous point with the package
maintainers).  We can't pretend to know every little nuance of every OS.
 The big thing with RHEL 5* is the lack of libpcap 5.0.

The version of Snort that will run on RHEL 5 without libpcap modification is
2.8.6.1.  VRT still maintains rules for this version, and will until the
next point release of Snort comes out (2.9.1) (+90 days) in accordance with
our EOL policy.  http://www.snort.org/vrt/rules/eol_policy


OK, rant over.  (If anyone actually read this far... :)
> <rant off>
JP, it's perfectly fine!  Just understand what I read above.  We don't make
this stuff up on a whim, there are technical reasons for it.  When we
provide new and better functionality, like with DAQ, sometimes that requires
something newer.  We have to release new functionality, so we do, but we get
in trouble there, but if we don't release new functionality, we get accused
of being dead and get in trouble there too and can't detect newer problems.



> Maybe Joel could do a vote on the blog, like the recent classification
> discussion, and collect more info on who is really using what.
Not a bad idea.  It might give us a good foothold on who is using what, etc.
 The classification discussed has turned into something as simple as
replacing the current classifications into something much more comprehensive
and will probably lead to a total redesign of the classification system.
 We'll talk about that later.


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.

Thank you for the kudos.  You are more than welcome to tell me what we are
doing wrong, and I will see what I can do to make it better. If we can't
make stuff better (like release a 2.8.6.2, or support RHEL 5), I'll try and
lay out the reasons for that on the blog/here.  I am trying to make the blog
worth reading, and hopefully I have so far.

Yes, Kudos to Vincent.  He is also going to start signing his RHEL supported
packages for you guys, which is excellent as well.  As far as I know, he did
exactly what I suggested above.  He downloaded the libpcap source code, and
made an RPM out of it.  We can't do it, so the community stepped up. I
appreciate this very much, and I think it's phenomenal that our community is
getting more involved.

Hopefully this helps.

-- 
Joel Esler
Skype:eslerjoel
http://blog.snort.org

------------------------------------------------------------------------------
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