Snort mailing list archives
Re: "stuck at RHEL5"?
From: Joel Esler <jesler () sourcefire com>
Date: Sat, 8 Jan 2011 13:57:37 -0500
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
Current thread:
- "stuck at RHEL5"? JP Vossen (Jan 08)
- Re: "stuck at RHEL5"? Joel Esler (Jan 08)
- Re: "stuck at RHEL5"? Nigel Houghton (Jan 08)
- Re: "stuck at RHEL5"? JP Vossen (Jan 11)
- Re: "stuck at RHEL5"? Crusty Saint (Jan 24)
- Re: "stuck at RHEL5"? Castle, Shane (Jan 24)
- Re: "stuck at RHEL5"? JP Vossen (Jan 25)
- Re: "stuck at RHEL5"? Crusty Saint (Jan 25)
- Re: "stuck at RHEL5"? onelson (Mar 23)
- Re: "stuck at RHEL5"? Joel Esler (Jan 08)