Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
From: Darren Spruell (phatbuckettgmail.com)
Date: Wed Aug 29 2007 - 23:43:04 CDT
On 8/28/07, Jason Dixon <jasondixongroup.net> wrote:
> >> ERROR: Unspecified source: Unable to initialize the Prelude library:
> >> Permission denied.
> >> Fatal Error, Quitting..
> >> # echo $?
> >> 1
> > I think that jdixon has reported the same problem, try to change the
> > permissions of /var/run/prelude-manager/ (i.e. 770 with _snort in the
> > _prelude group).
> Even after you fix permissions, I think you will still hit another
> unresolved error with the old net/snort. I had an initial patch from
> someone on the prelude-users group. It worked fine once... then it
> stopped working after an unrelated system crash.
I've still been tinkering with this, and I can't see what the
permissions have to do with really, as
- changing the permissions have no noticeable effect.
- that directory wouldn't even exist if e.g. you were running snort on
a different box.
- I can't fathom a reason why snort (or any other prelude sensor)
would need access to the prelude-manager directory. Communication to
the manager should be over TCP socket: - "Connecting to
127.0.0.1:4690 prelude Manager server."
- That permissions error goes away if I change my current working
directory to /tmp and launch snort-prelude. I suspect this has
something to do with a failed _cwd call that I can see in ktrace when
I try to start it in my home directory.
> Short story, don't use the existing snort in ports. I've been
> updating the port to Snort-188.8.131.52 and will have it out to the list
> today. I'm currently building/testing it on alpha, but there might
> be some hurdles left with sparc64. It has already been tested on
> i386 and fixes the startup problems with the prelude FLAVOR.
I updated also to the snort.org 184.108.40.206 version and can't really see
any difference in the behavior. I still have to start the daemon in a
"public" area on the filesystem, and it still fails to properly detach
from my terminal when I launch it with -D.
Got your updated port? I can try it out on i386 and test in my
situation, or I can also probe the prelude-users group.