Snort mailing list archives
Re: RHEL 6 with Snort 2.9.5.6-1 and PCRE 8.33 install issue (UNCLASSIFIED)
From: Joshua Kinard <kumba () gentoo org>
Date: Fri, 27 Dec 2013 19:09:21 -0500
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-specificparameters (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'sin 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'llneed to pass the same --prefix to Snort's configure script as well so that the configure script sets all the includepaths 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!
Current thread:
- RHEL 6 with Snort 2.9.5.6-1 and PCRE 8.33 install issue (UNCLASSIFIED) Wright, Jonathon S CTR (US) (Dec 27)
- Re: RHEL 6 with Snort 2.9.5.6-1 and PCRE 8.33 install issue (UNCLASSIFIED) Joshua Kinard (Dec 27)
- Re: RHEL 6 with Snort 2.9.5.6-1 and PCRE 8.33 install issue (UNCLASSIFIED) Wright, Jonathon S CTR (US) (Dec 27)
- Re: RHEL 6 with Snort 2.9.5.6-1 and PCRE 8.33 install issue (UNCLASSIFIED) Joshua Kinard (Dec 27)
- Re: RHEL 6 with Snort 2.9.5.6-1 and PCRE 8.33 install issue (UNCLASSIFIED) Wright, Jonathon S CTR (US) (Dec 27)
- Re: RHEL 6 with Snort 2.9.5.6-1 and PCRE 8.33 install issue (UNCLASSIFIED) Wright, Jonathon S CTR (US) (Dec 27)
- Re: RHEL 6 with Snort 2.9.5.6-1 and PCRE 8.33 install issue (UNCLASSIFIED) Joshua Kinard (Dec 27)
- Message not available
- Message not available
- Message not available
- RHEL 6 with Snort 2.9.5.6-1 and PCRE 8.33 install issue (UNCLASSIFIED) Wright, Jonathon S CTR (US) (Dec 27)
- Message not available