thanks for both of the replies. the script has definitely come a long way. I'm not much of a programmer and I've had TONS of help with this little project, some of which coming from here, months ago as evidenced by that link
So let me get to your questions (thanks for your patience by the way!)
Looking at autosnort-centOS.sh I wonder why you didn't choose to install DAQ and Snort from snort.org? After all it provides RPM packages.
Actually, I poll snort.org directly via this block of code:
echo "acquiring latest version of snort and daq."
cd /tmp 1>/dev/null
wget -q http://snort.org/snort-downloads -O /tmp/snort-downloads
snortver=`cat /tmp/snort-downloads | grep snort-[0-9]|cut -d">" -f2 |cut -d"<" -f1 | head -1`
daqver=`cat /tmp/snort-downloads | grep daq|cut -d">" -f2 |cut -d"<" -f1 | head -1`
cd /usr/src 1>/dev/null
wget http://snort.org/dl/snort-current/$snortver -O $snortver
wget http://snort.org/dl/snort-current/$daqver -O $daqver
Basically what I'm doing here is a quiet check of snort.org/snort-downloads. the grep statement is just looking for part of a snort version string, and the word daq and cutting out the first instance of each, assigning them both to a variable. The testing I did seems to indicate that performing these actions turn up the current stable source of daq and snort as the first lines returned. The cut statments are just to clean them up as variables for the following WGET statements to download the source for both. this code could easily be modified to pull the RPMs, then the code in other portions of the script modified to just rpm -Uvh the rpms... but...
is enabling performance monitoring for rules and preprocessors *that* important on a sensor?
Well, *I* consider it important, because in a previous life I use to work for Sourcefire, the guys who produce the corporate version of snort. I use to do a lot of performance tuning and troubleshooting with customers. having the performance statistic options available and turned on by default comes out of being in the trenches and knowing how useful perfstats output can be when trying to figure out what is wrong with your network -- is it the IPS or is it something else we have to point the finger at for this network outage? okay well we know for sure its the IDS, now what? performance profiling lets you get an idea of which preprocessors and which rules are causing you grief.
Giving users the ability to troubleshoot performance issues (inline or passive deployments) without the need to recompile is a nice benefit to me for what is, on most modern systems maybe an extra few minutes of compile time. If I hear enough complaints about it, or if there is enough of a demand to just install the RPMs for redhat-based derivatives, I will definitely do so -- or if you, or any other users, are so inclined, feel free to write it in and I'll just merge it in and accredit you for your contribution
p.s. thank you and the rest of the linuxquestions forum moderation team for allowing me to post here!