On Fri, 2009-02-27 at 10:33 -0500, Steve Grubb wrote: > > During the work for a 2.2 release, I would also like to pull the > audispd program inside auditd. In the past, I tried to keep auditd > lean and single purpose, but with adding remote logging and kerberos > support, we already have something that is hard to analyze. So, to > improve performance and decrease system load, the audit daemon will > also do event dispatching. > > Would this proposal impact anyone in a Bad Way?
Steve, Couple questions: - Right now the audispd remote/prelude plugins have connection-related concerns. For example, with the remote plugin there are timeouts, retries, etc. and parameters to tweak that. With the prelude plugin, it must have been registered with the running prelude-manager correctly or it dies. Do you see that pulling in the dispatching will cause more auditd complexity or is that not a problem? I thought that (one reason) audispd was separate was to allow it to deal with the vagaries of endpoint and delivery issues while the auditd kept doing its thing. - In theory, if everything is still doing roughly the same amount of work, I'd think that moving the functionality would not necessarily decrease the system load. I'm sure you have thoughts on how this would be realized and at some point I'd be interested to hear those. - What do you see as the initial target platform for the 2.0 series in Fedora? In RH I assume it would be the next RH release thereafter? Overall, though, I'd vote that nothing you propose would harm my efforts, since I think I'd be stuck with the 1.8 series for a while anyway. Thx, LCB. -- LC (Lenny) Bruzenak [email protected] -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
