From mboxrd@z Thu Jan 1 00:00:00 1970 From: LC Bruzenak Subject: aggregation/viewer question Date: Mon, 13 Oct 2008 12:34:03 -0500 Message-ID: <1223919243.6868.192.camel@homeserver> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: Received: from mx3.redhat.com (mx3.redhat.com [172.16.48.32]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m9DHYJj5027868 for ; Mon, 13 Oct 2008 13:34:19 -0400 Received: from mail.magitekltd.com (rrcs-24-242-137-197.sw.biz.rr.com [24.242.137.197]) by mx3.redhat.com (8.13.8/8.13.8) with ESMTP id m9DHY5ZL030354 for ; Mon, 13 Oct 2008 13:34:05 -0400 Received: from [24.242.137.194] (helo=[192.168.30.40]) by mail.magitekltd.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1KpRIK-0003ea-5b for linux-audit@redhat.com; Mon, 13 Oct 2008 12:33:24 -0500 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Linux Audit List-Id: linux-audit@redhat.com Has anyone been thinking about how to store/maintain the aggregated audit data long-term? In my setup, I will be sending data from several machines to one central log host. After a while, the number of logs/data will grow large. With hundreds of files, the rotate will take more time and the audit-viewer "select source" option becomes tedious. Most of my searches involve time/host/user. Using the prelude plugin helps a lot, because it highlights what is otherwise hidden in the data pool. But pulling out that record from a selection of log files isn't currently intuitive. I would think we'd put these into a RDB or structure them by time directory structure something like year/month/week ... or maybe something else entirely. I'm thinking also about ease of backup/restore with incoming records. I'd hate to shut down all the sending clients just to backup or restore my audit data, so that part will need to operate asynchronously. Before striking out on my own I thought I'd ask the list and see if there are any such plans already in the works. As a suggestion, the prewikka viewer seems like a workable model. I realize that viewer is built around the IDS structure, but as an event search tool it is pretty good and mostly complete. Having network access to it is also a nice feature. So right now I think that feeding the events into a DB and then using a tool with the same capabilities as are in the prewikka viewer would be a viable option. Others? Ideas? Thanks in advance, LCB. -- LC (Lenny) Bruzenak lenny@magitekltd.com