From mboxrd@z Thu Jan 1 00:00:00 1970 From: Warron S French Subject: audit.log with logrotate on CentOS Date: Thu, 26 May 2016 15:29:38 +0000 Message-ID: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4756260251502432072==" Return-path: Received: from mx1.redhat.com (ext-mx04.extmail.prod.ext.phx2.redhat.com [10.5.110.28]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u4QFdNZA003269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 26 May 2016 11:39:23 -0400 Received: from email5-west.aero.org (email5-west.aero.org [130.221.16.30]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1F49C85547 for ; Thu, 26 May 2016 15:39:22 +0000 (UTC) Content-Language: en-US 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 --===============4756260251502432072== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_BY1PR09MB0887EE63A6F82A957AADC6AAC7410BY1PR09MB0887namp_" --_000_BY1PR09MB0887EE63A6F82A957AADC6AAC7410BY1PR09MB0887namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I am using CentOS-6.7 and I have implemented the audispatch configur= ations and they are working pretty nicely. One of the requirements I have to satisfy, somehow, is 7 years retention of= logdata. That is an enormous amount of data to store on /var/log/audit fi= lesystem - even for a single server and 6 workstations combined. I have a = 2.0TB sized filesystem in place already - but it won't be enough to satisfy= the retention of 7 years of data. So, my plan is a tiered approach to managing the log files if someone could= please advise on how best to implement the following: Rotate log files every single Monday morning at 12:01am. When I rotate them place the dateext extension (for example 20160523) to in= dicate all date is up to that date extension. When I rotate them, I also want to bzip2 compress them (I have the binaries= on the server). Only keep at most 15 of those rotated (date-string extension applied) compr= essed files so that I can once a month take over a DVD burner and burn the = files to DvD; however, I want to ensure that the files never grow any large= r than the size of a normal (not dual-layer) DvD media which is typically 4= .70GB (so I am estimating a 4.0GB limitation) that is after rotation and co= mpression. Can someone help me figure out how to most appropriately (and more importan= tly) and successfully implement this configuration? Warron French, MBA, SCSA --_000_BY1PR09MB0887EE63A6F82A957AADC6AAC7410BY1PR09MB0887namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello, I am using CentOS-6.7 and I have implemented = the audispatch configurations and they are working pretty nicely.

 

One of the requirements I have to satisfy, somehow, = is 7 years retention of logdata.  That is an enormous amount of data t= o store on /var/log/audit filesystem – even for a single server and 6= workstations combined.  I have a 2.0TB sized filesystem in place already – but it won’t be enough to satisf= y the retention of 7 years of data.

 

So, my plan is a tiered approach to managing the log= files if someone could please advise on how best to implement the followin= g:

Rotate log files every single Monday morning at 12:0= 1am.

When I rotate them place the dateext extension (for = example 20160523) to indicate all date is up to that date extension.=

When I rotate them, I also want to bzip2 compress th= em (I have the binaries on the server).

Only keep at most 15 of those rotated (date-string e= xtension applied) compressed files so that I can once a month take over a D= VD burner and burn the files to DvD; however, I want to ensure that the fil= es never grow any larger than the size of a normal (not dual-layer) DvD media which is typically 4.70= GB (so I am estimating a 4.0GB limitation) that is after rotation and compr= ession.

 

Can someone help me figure out how to most appropria= tely (and more importantly) and successfully implement this configuration?<= o:p>

 

 

 

 

 

Warron French, MBA, SCSA

--_000_BY1PR09MB0887EE63A6F82A957AADC6AAC7410BY1PR09MB0887namp_-- --===============4756260251502432072== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============4756260251502432072==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ed Christiansen MS Subject: Re: audit.log with logrotate on CentOS Date: Thu, 26 May 2016 12:01:55 -0400 Message-ID: <57471DF3.50907@ll.mit.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; Format="flowed" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mx1.redhat.com (ext-mx01.extmail.prod.ext.phx2.redhat.com [10.5.110.25]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u4QG1v3O025308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 26 May 2016 12:01:57 -0400 Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by mx1.redhat.com (Postfix) with ESMTP id 45A557F6B9 for ; Thu, 26 May 2016 16:01:56 +0000 (UTC) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u4QFxrD0009124 for ; Thu, 26 May 2016 11:59:53 -0400 In-Reply-To: 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 probably the easiest way to do that is: 1. remove logrotate from /etc/cron.daily and put into root crontab: 1 0 * * 1 /usr/bin/logrotate 2. write a script that implements the other logic and run it from root = cron a few minutes later. I'd run a few tests with the logrotate to see how long it actually = takes, but that's because I can be a little extra paranoid. There really isn't a way to ensure that you always get less than 4GB if = you rotate weekly. You can approximate this with this: maxsize 4G, = which will rotate when the logfile reaches 4GB. On 5/26/2016 11:29 AM, Warron S French wrote: > Hello, I am using CentOS-6.7 and I have implemented the audispatch > configurations and they are working pretty nicely. > > One of the requirements I have to satisfy, somehow, is 7 years retention > of logdata. That is an enormous amount of data to store on > /var/log/audit filesystem =96 even for a single server and 6 workstations > combined. I have a 2.0TB sized filesystem in place already =96 but it > won=92t be enough to satisfy the retention of 7 years of data. > > So, my plan is a tiered approach to managing the log files if someone > could please advise on how best to implement the following: > > Rotate log files every single Monday morning at 12:01am. > > When I rotate them place the dateext extension (for example *20160523*) > to indicate all date is up to that date extension. > > When I rotate them, I also want to bzip2 compress them (I have the > binaries on the server). > > Only keep at most 15 of those rotated (date-string extension applied) > compressed files so that I can once a month take over a DVD burner and > burn the files to DvD; however, I want to ensure that the files never > grow any larger than the size of a normal (*not dual-layer*) DvD media > which is typically 4.70GB (so I am estimating a 4.0GB limitation) that > is after rotation and compression. > > Can someone help me figure out how to most appropriately (and more > importantly) and successfully implement this configuration? > > *Warron French, MBA, SCSA* > > > > -- > Linux-audit mailing list > Linux-audit@redhat.com > https://www.redhat.com/mailman/listinfo/linux-audit > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Warron S French Subject: RE: audit.log with logrotate on CentOS Date: Thu, 26 May 2016 17:30:41 +0000 Message-ID: References: <57471DF3.50907@ll.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com (ext-mx04.extmail.prod.ext.phx2.redhat.com [10.5.110.28]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u4QHUk4S005151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 26 May 2016 13:30:46 -0400 Received: from email5-west.aero.org (email5-west.aero.org [130.221.16.30]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7D4E48553E for ; Thu, 26 May 2016 17:30:45 +0000 (UTC) In-Reply-To: <57471DF3.50907@ll.mit.edu> Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Ed Christiansen MS , "linux-audit@redhat.com" List-Id: linux-audit@redhat.com Hi Ed, thanks for your input. You have basically confirmed my suspicion. Apparently I failed to mention (I asked to this forum yesterday the same question and never saw a response even that my post made it) that I am asking in the CentOS Forums as well. Currently there is no direction from the CentOS Forums; but they have engaged my question and attempted to start looking into this issue. Someone mentioned that there is a known bug for logrotate in CentOS-6.7, and of course that the version that I am running. I am liking your approach to the solution a little more though. Maybe set max_log_file to 4096 in /etc/audit/auditd.conf and then run a script that looks for all... /var/log/audit/audit.log files not already ending in .bz2 already. Warron French, MBA, SCSA -----Original Message----- From: linux-audit-bounces@redhat.com [mailto:linux-audit-bounces@redhat.com] On Behalf Of Ed Christiansen MS Sent: Thursday, May 26, 2016 12:02 PM To: linux-audit@redhat.com Subject: Re: audit.log with logrotate on CentOS probably the easiest way to do that is: 1. remove logrotate from /etc/cron.daily and put into root crontab: 1 0 * * 1 /usr/bin/logrotate 2. write a script that implements the other logic and run it from root cron a few minutes later. I'd run a few tests with the logrotate to see how long it actually takes, but that's because I can be a little extra paranoid. There really isn't a way to ensure that you always get less than 4GB if you rotate weekly. You can approximate this with this: maxsize 4G, which will rotate when the logfile reaches 4GB. On 5/26/2016 11:29 AM, Warron S French wrote: > Hello, I am using CentOS-6.7 and I have implemented the audispatch > configurations and they are working pretty nicely. > > One of the requirements I have to satisfy, somehow, is 7 years > retention of logdata. That is an enormous amount of data to store on > /var/log/audit filesystem - even for a single server and 6 > workstations combined. I have a 2.0TB sized filesystem in place > already - but it won't be enough to satisfy the retention of 7 years of data. > > So, my plan is a tiered approach to managing the log files if someone > could please advise on how best to implement the following: > > Rotate log files every single Monday morning at 12:01am. > > When I rotate them place the dateext extension (for example > *20160523*) to indicate all date is up to that date extension. > > When I rotate them, I also want to bzip2 compress them (I have the > binaries on the server). > > Only keep at most 15 of those rotated (date-string extension applied) > compressed files so that I can once a month take over a DVD burner and > burn the files to DvD; however, I want to ensure that the files never > grow any larger than the size of a normal (*not dual-layer*) DvD media > which is typically 4.70GB (so I am estimating a 4.0GB limitation) that > is after rotation and compression. > > Can someone help me figure out how to most appropriately (and more > importantly) and successfully implement this configuration? > > *Warron French, MBA, SCSA* > > > > -- > Linux-audit mailing list > Linux-audit@redhat.com > https://www.redhat.com/mailman/listinfo/linux-audit > -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit