From mboxrd@z Thu Jan 1 00:00:00 1970 From: LC Bruzenak Subject: Re: question Date: Sun, 02 Nov 2008 12:25:37 -0600 Message-ID: <1225650337.9388.425.camel@homeserver> References: <200810311550.12429.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <200810311550.12429.sgrubb@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com 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@magitekltd.com