Re: RHEL 6 with Snort 2.9.5.6-1 and PCRE 8.33 install issue (UNCLASSIFIED)

[Joshua Kinard <kumba () gentoo org>]

On 12/27/2013 4:38 PM, Wright, Jonathon S CTR (US) wrote:
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> Thanks for the feedback, this is great information. 
>
> > Quick tips:
>
> > 1. Always run ./configure --help and read through the Snort-specific
> parameters (GNU autoconf has default --config-options it includes in
> virtually everything -- you can skip these, like 
> > --prefix, --with-gnu-ld, etc).  You'll spend the most time here.
>
> Good tip. I'm a BSD guy, so the ports tree did all this for us, we had to
> build from source maybe .01% of the time. 

Compared to a lot of Unix/Linux setups that build from source, BSD is going
to be the closest to compiling-by-hand, since they literally use Makefiles
for everything (compared to Debian's shell scripts or Gentoo's ebuilds).
Much to BSD's chagrin, they're still heavily reliant on a lot of GNU stuff
for building.  Though, gcc is getting shown the door soon for clang, but
they still haven't gotten off of autoconf/automake.


> We did talk with Red Hat they indicated as you did in the last question,
> "Our model is designed for a stable server, not a bleeding edge one". They
> also indicated that an rpm would not be created for the reason you stated,
> RHEL 7 is practically here. 

Already?  I wonder if that separate-/usr-is-broken thing got added to that.
 Something to dig up later...


> I noticed that CentOS had an rpm (on the snort.org site no less). Is that
> one viable? If so, whats the best way to remove the current install of snort
> (and its dependencies if necessary) since it was built from source? 

This is tricky.  Some makefiles provide an uninstall method (make uninstall,
make deinstall, etc), but it might only work IF you haven't cleaned up your
builddir, or can re-run configure using the exact same options as what's
installed, so that make knows what files to remove.  This is one area where
package managers simply rock.  Snort in particular, I don't know about, as
I've never tried to clean up behind it in my experiments (I just let it
overwrite stuff in my local testing directory).

One thing you can try is to use --prefix and create a "clean" miniroot
filesystem (basically a directory that looks like /), build the minimum
needed to install Snort and its dependencies, and then use that as your
"todo list" of files to clean out of the real root filesystem.  Very manual
process, though.

As for the RPM on the snort.org site, that does look viable.  It has
"centos6" in the filename, which implies CentOS 6, which is a direct build
of RHEL6's SRPMs.  So it should work, but you'll probably be stuck using the
old pcre library with that approach.

One thing to look for is to see if the pcre package's source tree has an
SRPM/RPM spec file included.  If so, it MAY be possible to generate your own
SRPM/RPM from that spec file against the core libraries in a RHEL6 system,
and then you can deploy that SRPM/RPM to all of your servers.


> > As long as you compiled the pcre source and put it in a directory that's
> in your include path, Snort's configure script should detect and use it
> automatically.  Usually, if you specified --
> > prefix to one package's configure script that Snort depends on, you'll
> need to pass the same --prefix to Snort's configure script as well so that
> the configure script sets all the include 
> > paths up right.  In a pinch, you can specify your own via CFLAGS
> -I/path/to/custom/includedir and -L/path/to/custom/libdir.
>
> This part is very interesting. Since my configure - make - make install
> skills are very low I'll need to do some research in how the --prefix option
> works with configure, specifically snort. And then how to apply that so that
> I have a step by step on making snort use the latest pcre libraries. I would
> assume I'd have to determine where the pcre compiled files (*.so*) went when
> I executed the simple ./configure, make, make install. Then I'd know where
> to point snort too with the --prefix option. 

--prefix is basically a way of stating what the base root install directory
is.  The default is usually "/usr".  Makefiles usually then (but not always)
install things to ${PREFIX}/lib, ${PREFIX}/bin, ${PREFIX}/sbin, and so on,
where ${PREFIX} is whatever the value is that was passed to --prefix.  So if
you supplied your own prefix, e.g., --prefix=/home/myfoo, then Snort's
shared libs would wind up in /home/myfoo/lib, and its binary in /home/myfoo/bin.

Since you want to build the latest pcre library as well, you'd want to pass
--prefix to that package's configure script as well so that you don't
overwrite the system copy (which would only be possible if you did that
final "make install" as root anyways (and had SELinux disabled)).  Oh, don't
forget about lib64 for x86_64 boxes.  Keep that one in mind, cause you'll
have to look through both /lib and /lib64 sometimes.  /lib32 can also
appear.  Repeat for /usr/lib[64|32].


> The last part about a pinch is interesting too. I'll need to do some
> research on the CFLAGS (environment variable or snort variable?) and what
> else uses it, and perhaps how to just set it in the .profile of the user
> that normally starts up snort. 

CFLAGS is a common environment variable used to define custom compiler flags
to gcc (the C compiler).  Handy if you want to override defaults in the
Makefiles.  Although, that only depends if the Makefiles actually allow you
to override them.  There's also CXXFLAGS for the C++ compiler, LDFLAGS for
the binutils linker, and ASFLAGS for the binutils assembler.  Open up one of
the Makefiles in the Ports tree and you'll probably see where CFLAGS get
passed down from BSD's /etc/make.conf (assuming they still use that).

You set those prior to calling the configure script so that they're treated
as local environment variables whose lifetime is that of the configure
script's run:

CFLAGS="-O2 -pipe -march=core2 -fomit-frame-pointer -fomg-its-so-fast"
./configure --prefix=/home/myfoo --with-awesome-foo ...

gcc/binutils have a HUGE library of compiler switches that you can feed into
those variables.  But my advice is don't dive too deep into specifying the
weird and wacky ones.  The defaults in a lot of packages work just fine and
any optimizations you might get by overriding them may be miniscule, since a
lot of hardware is overpowered for most tasks these days.

--J

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Snort-devel mailing list
Snort-devel () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-devel
Archive:
http://sourceforge.net/mailarchive/forum.php?forum_name=snort-devel

Please visit http://blog.snort.org for the latest news about Snort!