Re: Audit dispatcher process

On Thu, 2007-01-11 at 09:56 -0500, Steve Grubb wrote: This is all contained in the remote plugin, or do you want a general ACK'ing process all the way back to any input plugins. Ie. input plugin => dispatcher => remote logging plugin => remote server => disk "ACK" => remote server <= remote logging plugin <= -- stop here? -- dispatcher <= -- or stop here? -- input plugin <= -- or even stop here? -- ...even if we just stop at the remote logging plugin level, are we worried about duplicate entries on the logging server? I guess that's better than missing entries if the power fails on the logging server (I just don't want to have to solve the two generals problem :). Yeh, I'm meant to say that with the shipped separately point. One thing I'm not sure about is if there's a requirement to pickup new changes/plugins without having to "reboot" the dispatcher in some way. I'd also thought of having the auditd input be a plugin itself, this way you could quickly reboot the dispatcher while the auditd input plugin spooled the incoming data for a small period of time. This might make signal handling simpler too, although it's certainly not in the spirit of the dispatcher :). Well, if by optional you mean "something doesn't get built". Then, yeh, I'd planned to do that ... but I'm not sure how useful it'll be, esp. with regard to any deps needed for the dispatcher itself. Ahh thanks, I'd looked at the libaudit.h header and worked out most of the above but the clarification is appreciated. One question though: Should I just take the first 4 bytes, and compare to zero then take the next 12 ... or just grab the first 16, I figured from the .h file that the first 16 will always be there but the above page suggests just checking the first 32 bits (note s/32 bytes/32 bits/ to fix the typo). From what I can see of audit.conf and that code, it would be extremely hard to use for what we'd want to do with plugins. IMO the audit daemon and the dispatcher do very different jobs, so a different config. file syntax isn't a problem, and setroubleshoot already has a totally different config. style. The conf code from And-httpd should be very easy to reuse for this (it's used to configure similar types of applications), already supports conf.d directories, already supports building paths from pieces of dynamic information etc. -- James Antill <jantill(a)redhat.com&gt;