Audit DB support.........

Audit DB support.........

[kunal chandarana]

[-- Attachment #1.1: Type: text/plain, Size: 584 bytes --]

Hey people I am planning to add DB support in audit functionality in linux.
I have some queries so if u ppl could reply to this then it will help me a
lot.

1) Should each name/value pair be turned into fields with a record?
2) Should each record be a table?
3) Should each event be a table?
4) Should event and its subrecords be reworked into one record that pulls
out only the important data?
5) what kind of reports will be useful to run from the database. ?
6) what kind of reporting user will find useful. ?
7) What are the main reports and what information should they contain?

[-- Attachment #1.2: Type: text/html, Size: 742 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Audit DB support.........

[John Dennis]

kunal chandarana wrote:
> Hey people I am planning to add DB support in audit functionality in 
> linux. I have some queries so if u ppl could reply to this then it will 
> help me a lot.
> 
> 1) Should each name/value pair be turned into fields with a record?
> 2) Should each record be a table?
> 3) Should each event be a table?
> 4) Should event and its subrecords be reworked into one record that 
> pulls out only the important data?
> 5) what kind of reports will be useful to run from the database. ?
> 6) what kind of reporting user will find useful. ?
> 7) What are the main reports and what information should they contain?

It's kind of hard to answer some of the questions without knowing what 
type of analysis you'll be doing. But having written some audit analysis 
code and a backend to store it, here would be my suggestions.

* You should be able to search by record type

* You should be able to query an event and get all its records, and 
given a record it should be easy to get to the event it's contained in.

* Breaking records into name/value pairs is probably too fine grained. 
Searching by record type is a good level of granularity. Not all record 
types have complete name/value pairs or are well formed and regular.

* The event id (includes the timestamp) is shared between all records of 
one event. The serial number of the event id is not all that important, 
but one should be able to search on the timestamp.

* Host information has recently been added. The searching by host will 
be critical.

-- 
John Dennis <jdennis@redhat.com>