From mboxrd@z Thu Jan 1 00:00:00 1970 From: LC Bruzenak Subject: Re: [PATCH] Add auditd listener and remote audit protocol Date: Thu, 14 Aug 2008 18:50:23 -0500 Message-ID: <1218757823.7022.266.camel@homeserver> References: <200808142143.m7ELh0MP028560@greed.delorie.com> <1218751136.7022.206.camel@homeserver> <200808142216.m7EMGILI029666@greed.delorie.com> <1218756409.7022.255.camel@homeserver> <48A4C1BC.3060309@redhat.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <48A4C1BC.3060309@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: John Dennis Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Thu, 2008-08-14 at 19:37 -0400, John Dennis wrote: > This is why the IPA project has selected AMQP (www.amqp.org) as the > transport for centralized loggiing (included audit logs). AMQP will > queue in persistent storage messages which do not reach their > destination until delivery is assured. The thinking was AMQP was too > heavy weight a dependency for a simple centralized audit log but makes > sense in an enterprise deployment such as IPA. > I see; thanks for the info John. Steve did mention this previously to me but I didn't get all the implications I guess (dense!). I do require centralized auditing and I also require (more importantly) not losing any. I cannot speak for other end-users...but my guess is that if they are using audit and aggregating they probably care about not dropping it, whereas others can just syslog the events if the auditd isn't enabled and then use centralized syslog, right? AMQP may be heavyweight, however if you start down the road of trying to not lose networked audit data you probably end up somewhere near there anyway... Thx, LCB. -- LC (Lenny) Bruzenak lenny@magitekltd.com