Re: Audit Parsing Library Requirements
Steve Grubb <sgrubb(a)redhat.com> wrote on 03/13/2006 09:14:22 AM:
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.
Wow, what I wrote is not what I mean. I should say that I am _not_ in
favor of commas, I was trying to point out that spaces between fields (and
only spaces), should be the way to go since its the most common form in
our records and should therefore be made the only form for consistancy -
not to mention all of the reasons you just listed. Sorry for not writing
what I meant.
> 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.
Again, I was not clear, although when I wrote this, I thought I was. I was
saying I am in favor of chaning field names, such as "login uid", and
replacing them with "login_uid". Amazing how much meaning can be lost
between the reader and the writer. Normalizing records is good!
> 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.
It isn't? From the code example that I read, although it does not have any
documentation comments with it, leads me to believe my understanding to be
correct. btw, you forgot to free your memory in that example! See the next
comment for more.
> 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.
OK, we've got a serious breakdown in communication here. Yes, I understand
that ausearch_next_event will get you to the next event that matches your
criteria. And I also understand that auPARSE_next_event will get you to
the next event that falls in chronologial order (in terms of serial number
or time stamp, whatever) and that is _not_ subject to any specified search
criteria. However, my sole point was it would be good to state clearly
that all other auparse_* functions, which concern themselves with parsing
of records and fields, will do so based on the current event they are at,
whether you got to it through an ausearch_next_event call or an
auparse_next_event call.
Mike
Attachments:
- attachment.html (text/html — 4.0 KB)