audit.log with logrotate on CentOS

audit.log with logrotate on CentOS

[Warron S French]

[-- Attachment #1.1: Type: text/plain, Size: 1416 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 3903 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: audit.log with logrotate on CentOS

[Ed Christiansen MS]

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
>

RE: audit.log with logrotate on CentOS

[Warron S French]

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