10:29 a.m.
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
11:01 a.m.
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(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
12:30 p.m.
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(a)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(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
--
Linux-audit mailing list
Linux-audit(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
3131
days inactive
3131
days old
linux-audit@lists.linux-audit.osci.io
2 comments
2 participants
participants (2)
-
Ed Christiansen MS -
Warron S French