Snort mailing list archives
Re: [Snort-users] pulledpork question: do not nuke tarball post-processing and some feature requests
From: Tony Robinson <deusexmachina667 () gmail com>
Date: Sat, 8 Dec 2012 15:50:09 -0500
Responses also inline. Also, thanks for the response on a Saturday. On Sat, Dec 8, 2012 at 1:44 PM, JJC <cummingsj () gmail com> wrote:
Inline.... On Sat, Dec 8, 2012 at 10:32 AM, Tony Robinson <deusexmachina667 () gmail com> wrote:Hey fellas, This is a question regarding pulledpork. I would e-mail JJ directly, butIfeel this may be beneficial to future users, so I want to ask here(besides,one of you may know the answer to this or may have done this yourselves!) I'm working on autosnort and dropping in pulled pork integration. I'vegotit to work properly, however I'm running into a problem where it isworking*too* well - pp nukes its working directory after running. I want the tarball in the directory for my script to extract the config files out of the tarball's etc directory (except sid-msg.map and snort.conf -- sid-msg.map is obvious, but I pulled snort.conf directly fromlabs.snort.organd do not want it overwritten during the install). I've got awork-aroundin place that I think will work for now. I read from the pp mailing list that the script *sort of* supports processing from local rule tarballsso Iwanted to try the following as a work-around: 1) call pulled pork with -g to just grab the rules tarball. 2) use my script to untar the tarball, grab the conf files and copy themforthe snort install 3) call pulled pork again with the -n option in addition to otheroptions Iwant for rule processing. let pulled pork work its magic hereThe tarball should remain after PP is done processing, it only nukes it's working directory. This is how the process local tarball workaround works.. simply place the tarball in the path that you have pp defined to store it then run pp and tell it not to check the hash... make sense?
got it.
If you are open for pulled pork feature requests however, I would like to request the following: 1) an option to not nuke the rules tarball post-download --I can see the subroutine where the temp directory is cleaned out,would itbe as simple as defining a variable for do not clean, a flag for do not clean and adding in the 'if' statement where the routine is called, toruncleanup only if this flag is NOT present? Perl isn't my native language,butif its as simple as that, I would be willing to try and write this functionality in, test it out and contribute it.As noted above, the tarball should remain in the temp path that you defined for it to write said tarball to. If it's disappearing then there is another process doing this.
yeah found out what my problem is. my script is removing the files out of /tmp after failing to untar the rule tarball. It was trying to untar the md5 file instead. Afterwards, I have a cleanup routine that is removing everything out the /tmp directory. Hurr. I program gud. Anyhoo, I've fixed that issue and will be doing some testing to make sure it works properly.
2) an option to copy the config files out of the rule tarball's 'etc' directory (with the exception of sid-msg.map (and in my case,snort.conf))-I know how to do this in bash: -untar the tarball -use a for loop to copy the files from /tmp/etc directory listing pipedtogrep -v used to remove snort.conf and sid-msg.map from the directory listing, to the defined etc directory for the actual snort installation -- Have no clue where to even start for doing this in Perl. -Is this considered out of scope since it isn't strictly rule management?Something similar to this was recently proposed, but more as a config file comparison.. PP runs and spits out information about differences between the snortrules tarball snort.conf and your current version. Though there is no formal feature request it is an interesting use-case.. feel free to add the feature request in the bug tracker at pulledpork.googlecode.com
Will do. Thanks for hearing me out.
Cheers, DA -- when does reality end? when does fantasy begin?------------------------------------------------------------------------------LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ Snort-users mailing list Snort-users () lists sourceforge net Go to this URL to change user options or unsubscribe: https://lists.sourceforge.net/lists/listinfo/snort-users Snort-users list archive: http://sourceforge.net/mailarchive/forum.php?forum_name=snort-users Please visit http://blog.snort.org to stay current on all the latestSnortnews!
-- when does reality end? when does fantasy begin?
------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________ 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:
- pulledpork question: do not nuke tarball post-processing and some feature requests Tony Robinson (Dec 08)
- Re: pulledpork question: do not nuke tarball post-processing and some feature requests JJC (Dec 08)
- Re: [Snort-users] pulledpork question: do not nuke tarball post-processing and some feature requests Tony Robinson (Dec 08)
- Re: pulledpork question: do not nuke tarball post-processing and some feature requests JJC (Dec 08)