From mboxrd@z Thu Jan 1 00:00:00 1970 From: dump@tzib.net Subject: Consolidate Audit's msgs Date: Tue, 10 Jan 2012 18:05:19 -0800 Message-ID: <4F0CEE5F.3080509@tzib.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com (ext-mx12.extmail.prod.ext.phx2.redhat.com [10.5.110.17]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q0B25QQL010932 for ; Tue, 10 Jan 2012 21:05:26 -0500 Received: from insecure.ws (insecure.ws [82.231.161.45]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0B25PLe011828 for ; Tue, 10 Jan 2012 21:05:26 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by insecure.ws (Postfix) with ESMTP id 507653E16CF for ; Wed, 11 Jan 2012 03:05:24 +0100 (CET) Received: from insecure.ws ([127.0.0.1]) by localhost (insecure.ws [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JyuDs0lYRYvf for ; Wed, 11 Jan 2012 03:05:23 +0100 (CET) Received: from [10.251.29.224] (mozilla.vlan426.asr1.sfo1.gblx.net [159.63.23.38]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by insecure.ws (Postfix) with ESMTPSA id E7B813E1693 for ; Wed, 11 Jan 2012 03:05:22 +0100 (CET) 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@redhat.com List-Id: linux-audit@redhat.com Hi, I was wondering if there had already been an effort or solution to consolidate msgs from auditd into a single line. I'm talking about buffering the messages until EOE (or timing out/empty buffer if EOE doesn't come on errors), and concatenating messages with the same ID into a single message. Potentially also transforming the message syntax while at it. I'm asking because some loggers will only accept specific message formats. I looked at the plugins, but, from what I gather, the kernel sends the messages as raw strings and I'm not sure of the performance/memory impact when auditd cranks out a lot of messages. An alternative could be to send all the msgs as text to a remote auditd host using audispd-remote, and processing the log file on that host. It means even more messages to process however and I'm not sure the text file interface will be fast enough/might have too much disk activity and break often, etc. if auditd again, cranks out a lot of messages from many hosts (like several thousand per second). Any insight?