From: Ed Christiansen MS <edwardc@ll.mit.edu>
To: "linux-audit@redhat.com" <linux-audit@redhat.com>
Subject: Re: audit.log with logrotate on CentOS
Date: Thu, 26 May 2016 12:01:55 -0400 [thread overview]
Message-ID: <57471DF3.50907@ll.mit.edu> (raw)
In-Reply-To: <BY1PR09MB0887EE63A6F82A957AADC6AAC7410@BY1PR09MB0887.namprd09.prod.outlook.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 – 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
>
next prev parent reply other threads:[~2016-05-26 16:01 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-26 15:29 audit.log with logrotate on CentOS Warron S French
2016-05-26 16:01 ` Ed Christiansen MS [this message]
2016-05-26 17:30 ` Warron S French
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=57471DF3.50907@ll.mit.edu \
--to=edwardc@ll.mit.edu \
--cc=linux-audit@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.