[Snort-users] Snort 126.96.36.199 Now Available
mikelococo at ...11827...
Tue Nov 2 14:13:06 EDT 2010
> How did you get around RHE5 not having libpcap-1.0.0? Did you forcibly
> upgrade it from (say) Fedora? If so, did it break any of the other pcap
> apps like tcpdump,etc?
I've been running with an upgraded libpcap for about 3 years, during
which time I've generally packaged my own version of libpcap 1.x.x and
simply upgraded the stock package. I also rebuild all the libpcap
applications that I care about, including tcpdump. I've since read, but
not tested, that rebuilding applications isn't necessary because libpcap
has been ABI backwards-compatible for quite a few years and so in theory
the apps compiled against the older version find the new one and "just
work". Your newer package would have to "provide" libpcap 0.9.4 so that
packages with explicit version dependencies can find it, but as I've
said this is all untested as I just recompile the apps I want.
Recently I've been testing a parallel installable libpcap 1.1.1 package
that can coexist libpcap 0.9.4 . I'm still testing this setup, and I'm
not entirely clear that it's worth the trouble. It's a relatively
straightforward name-change in the specfile though because none of the
file-locations actually conflict.
> Also, when you say RHE5 - do you really mean CentOS-5? I think you'd
> violate your support agreement with RHE5 shoving a newer libpcap onto
> that? ;-)
I really mean RH. Ostensibly I have support for my libpcap-stack
through Endace, from whom I purchase my capture-cards.
In practice, I really don't rely on support from either of them all that
much and haven't run into (much) trouble directing issues at the
appropriate party. There's a certain inherent risk in multi-vendor
setups like that, but in practice it hasn't been a big issue and my
management is on-board with our perceived level of exposure. I'm sure
that not every shop would find such a configuration acceptable.
More information about the Snort-users