question

[LC Bruzenak]

On Fri, 2008-10-31 at 15:50 -0400, Steve Grubb wrote:
> On Friday 31 October 2008 14:21:12 David Flatley wrote:
> ...
> 
> Perhaps we need the capability of switching out partitions used for logging? 
> Maybe that could be solved by using the space left action exec capability to 
> run a custom program that re-writes the audit config file or changes a 
> symlink to point to another config file to point to a new dir and then sends 
> sighup to the parent (auditd).
> 
> Maybe some others have ideas about how they solve the same problem. If we need 
> to make changes to the audit daemon to make this smoother, let me know what's 
> needed.

David, I will have similar requirements and I've been thinking about
this also. Not sure about you, but my audit data has the following
requirements (and others):
* archive to off-site storage
* restore from archive
* search capabilities (mostly covered in ausearch and audit-viewer)
* robust (cannot lose any data received)
* etc.

Like you, I'm planning a periodic shift. This enables straightforward
time-based restore/search for humans. Ideally, it would be totally
automated, as in:

1: shift auditing to a new R/W partition each month.
2: Make the previous month audit data RO.
3: archive the previous month to tape/DVD
4: put the RO partition back into the "available" queue
5: ensure the current audit is also mirrored over to a big storage area
with all the past data on it.
6: Send an email to the administrator that all the above has
successfully occurred.

Steve, as my testing progresses I'll add comments in this area. I had
thought a cron-activated logrotate on the month would cover this, but it
means 2 admin areas; if there is a way to do it inside the audit
structure, that would be preferable to me. It would simplify/consolidate
the config rpm(s) I create. Anything you could do to help facilitate a
scheme as described above would be welcome.

David, a couple of questions for you:
* Have you looked at the audit-viewer, and do you intend to use this?
* I assume "heavy usage systems" means lots of audit data...are your
rules tuned appropriately? This is critical for me - one over-zealous
rule will add a flood of unhelpful info.
* You mention "balancing performance"  - are you talking about
per-machine or network (via aggregation)? When reading your post I
assumed aggregation from my own perspective but you didn't actually
specify so I thought maybe I should ask. I'm aggregating all audit from
several machines to a single audit machine for
storage/review/adminstration. You?

Thx,
LCB.

-- 
LC (Lenny) Bruzenak
lenny at magitekltd.com