Audit Parsing Library Requirements

[Steve Grubb]

On Monday 13 March 2006 09:35, Michael C Thompson wrote:
> I know this is not likely to change, but is there a reason why we don't
> have a common delimiter?

Personally, I think its a bad idea since it makes the text "darker". Spaces 
make it lighter and more pleasing to the eye. Its too later to make these 
kind of changes.

> Removing inconstancies in the records, such as using '_' in place of spaces
> in field names and removing these commas, would seem like a good thing to
> do, but before anyone does that work, will making that change be acceptable
> from a code point of view?

I would like to fix inconsistencies, but I don't consider '_' to be an 
inconsistency. I would be hesitant to make any other changes besides 
normalizing records. Its unnecessary and unwanted.

> Although it is clear from the code example (and I am sure this is not
> going to be the final version of the document, it would probably be nice
> to mention that auparse will, when not using auparse_next_event, will be
> parsing the record that was found (and is current being pointed to) by
> ausearch_* functions, for example.

But this is not true.

> Your comment in the above, "without regard to any search options that may be
> in effect", is somewhat befuddling on this point.

OK, you put in a search for uid=500. ausearch will find events that have a 
match. You should call ausearch functions to walk these events. So, for 
example, the cursor goes to event 150 on first call, then event 200 next 
call. If you auparse, then it will go to the next event which could be 201. 

This is all common database techniques. One is based off an index and the 
other is sequential access

-Steve