[Snort-devel] "stuck at RHEL5"?

JP Vossen jp at ...629...
Tue Jan 25 03:05:46 EST 2011


On 01/24/2011 10:44 AM, Castle, Shane wrote:
 > CentOS != RHEL. If you think otherwise you are mistaken.

That is certainly true.  RHEL is fully supported by Red Hat, and is 
compiled in certain ways in a certain environment.  CentOS's goal is to 
be as close to that as possible [1], but there are certainly differences.

Nevertheless, for many purposes, and I would argue specifically for the 
purpose of hosting a Snort sensor, CentOS is "close enough."  At the 
very least, in this context snort compiled for CentOS-5.x ought to run 
on RHEL-5.x and vice versa.


Related, see the following for an interesting article about "eating your 
own dog food" and why Fedora does not.  http://lwn.net/Articles/422710/

That's what I was talking about when I argued against using Fedora for a 
Snort sensor OS in http://marc.info/?l=snort-devel&m=129448514222862&w=2.


On 01/24/2011 04:31 AM, Crusty Saint wrote:
> @JP
>
> I totally do NOT get 70% of what you're complaining about.
>
> Without any prior snort knowledge i got it to run 100% on a Centos EL5
> installation. RTFM first, everything you need is in there. Based on the docs
> it is quite easy to build a script that automatically gathers your
> dependencies for building from source, though admittedly this is something
> sourcefire could have done themselves.

But I'm not talking about building from source, I'm talking about 
supplying RPMs that work, for OS's that are (or seem to be, or should 
be?) supported.

Sure, in many ways building from source is easier, and you can argue 
better.  Personally, and in production as far as possible, I really 
*hate* to go outside of the packaging system.  That's what it's there for.

Yes, I can build my own RPMS, and I did.  That's not the point either, 
keep reading.


> There are offered external repo's that do supply libpcap and many but not
> all required libs. Not satisfied with these because they don't offer the
> same warranty RH/CO do offer ? Then don't use RH-based distro's, the base
> support for libs on this platform is plain poor. I never get why people
> bother to even offer rpm's and they do require quite a load of extra work to
> support them.

There's a double-edged sword here.  If you do not offer binary packages, 
your barrier to entry is higher (potentially much higher, depending on 
your project) and uses will go elsewhere.  If you do offer binaries, you 
get smacked around when they don't work.

As Joel and I discussed elsewhere, you can't leave it up to the distros 
themselves or else you end up with totally obsolete versions floating 
around, which goes triple for something as fast moving as Snort.

So if you are packaging software you need to do the work so your
users don't have to.  And to circle back around, I was arguing that the 
work isn't done for CentOS/RHEL 5.

But that also begs the question, should it be done?  I originally 
thought yes, it should, because a lot of people are "stuck" using 
RHEL/CentOS 5.  Since there has been only silence about that, either I 
was wrong, or those who do use it have already reinvented the wheels or 
otherwise just don't care about this issue.  So I should probably stop 
wasting time and bandwidth on it.  (I solved my problems with it weeks 
and weeks ago now.)


> Debian-based distro's deliver a much wider supported base from
> a single repo, as this distro is alive and not beaten flat by corporate
> interest and focus.

As I said, personally I'd rather use Debian, but larger shops have 
standards, and lots of them have standardized on RHEL/CentOS in my 
experience.  Yours and current Snort users may differ, since again 
everyone else has been silent.

(Though perhaps the "dev" ML is not the best place to find that answer? 
  I thought it was, but...  And I still think Joel should poll the 
community to find out what should be supported, but I understand that 
he's swamped...)


> No offence, but i've had the same objections and found only it took about 4
> hours to resolve most of it once and for all. It is also possible to build
> snort in /opt and use it's own separate directory of libs under /opt

It's not a show-stopper for me, and there are certainly a number of 
work-arounds.  But why should I have to work-around something or 
reinvent a bunch of wheels that the vendor should be solving in the 
first place?


Having said all of that, I think we should just let this thread die.  It 
doesn't seem like this is a big deal for anyone, which surprises me. 
But unless a lot of RHEL/CentOS 5 users suddenly come out of the 
woodwork asking for support, we might as well put the time and effort 
into something else since this seems like a non-issue.


> 2011/1/12 JP Vossen<jp at ...629...>
>
>> I'll comment in-line (with trimming) on both Joel and Nigel's replies.
>>
>> Thanks to you both for the useful and informative answers.
>>
>>
>> On 01/08/2011 01:57 PM, Joel Esler wrote:
>>> On Sat, Jan 8, 2011 at 5:53 AM, JP Vossen<jp at ...629...>   wrote:
>>
>> [...]
>>>> Main point up front:
>>>> Who else votes for better RHEL5/CentOS-5 support and longer
>> life-cycles?!?

<lots trimmed, go see 
http://marc.info/?l=snort-devel&m=129480325111952&w=2 for details.

Later,
JP
_________________________________________
[1] http://centos.org/
"CentOS is an Enterprise-class Linux Distribution derived from sources 
freely provided to the public by a prominent North American Enterprise 
Linux vendor.  CentOS conforms fully with the upstream vendors 
redistribution policy and aims to be 100% binary compatible. (CentOS 
mainly changes packages to remove upstream vendor branding and artwork.) 
  CentOS is free."

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




More information about the Snort-devel mailing list