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

["Wright, Jonathon S CTR (US)" <jonathon.s.wright.ctr () mail mil>]

Classification: UNCLASSIFIED
Caveats: NONE

Wow, good stuff here J, thanks!

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

Well, thankfully, I'm a lazy 'maker', the only thing I remove is the tarball
file. And very true, I do miss the package manager of BSD in this scenario
=) I'll probably try and run a 'make deinstall' since I do have the builddir
still. 


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

I like that first sentence / idea, simple yet effective. May not be needed
since I have the builddir, but it's a good concept that I should keep in
mind. Having said that, using the old pcre and being stuck building my own
rpms is not something I have time for. Here is my situation / analogy:

Boss: "Here is your bag of apple seeds!"
Me: "Okay, I'll start laying out the plan for purchasing land, building an
orchard, scheduling tasks, prioritizing milestones, etc.". 
Boss: "Fine. But we must have baked apple pie by next week"


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

Didn't know that, thanks! I'll do something like this then:

1. PCRE 8.34 - Build and put it to a specific directory 
mkdir /usr/local/bin/snort/pcre834/lib && mkdir
/usr/local/bin/snort/pcre834/bin
./configure --prefix=/usr/local/bin/snort/pcre834 && make && make install

2. Snort 2.9.5.6-1 - Build and specify the pcre 8.34 libraries to use 
./configure --with-libpcre-libraries=/usr/local/bin/snort/pcre834
...(etc.,really long configure options) && make && make install

Hows that look anyway?

Not sure what to do about /usr/lib/64 libs, it sounds as if snort puts libs
there even if I have a --prefix? Or is this information still pertaining to
the 'if' I don't have the builddir and am not able to run a 'make
deinstall'? 


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

I love learning this stuff, and I did a lot in that last part as well, many
thanks for the information J!


-----Original Message-----
From: Joshua Kinard [mailto:kumba () gentoo org] 
Sent: Friday, December 27, 2013 2:09 PM
To: Wright, Jonathon S CTR (US); snort-devel () lists sourceforge net
Subject: Re: [Snort-devel] RHEL 6 with Snort 2.9.5.6-1 and PCRE 8.33 install
issue (UNCLASSIFIED)

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

Classification: UNCLASSIFIED
Caveats: NONE

Attachment: smime.p7s
Description:

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