ausearch checkpoint question

ausearch checkpoint question

[LC Bruzenak]

I'm using the 2.4.5-3 audit rpm set and I tried using the ausearch 
"checkpoint" option a couple weeks ago.
This was on a moderately busy system (judging by my own 
systems/experience) generating say 300-400MB of data/day.

I tried the checkpoint option in a 5-minute cron job, and I noticed that 
in comparison to the "-ts recent" option, it took far longer to complete.
The "recent" option result was less than a second, whereas the 
checkpoint version took ~20 seconds every 5 minutes.

It's possible there were other factors at play; e.g. it was used on a 
mls-policy machine, and although I saw no AVCs, it's possible there were 
some access issues I didn't have time to investigate.
On my intended application, I'll be on a standard targeted-policy 
machine so this won't be a potential factor.

I need to test this again, as I'm considering using the ausearch 
checkpoint capability for some new requirements, I was wondering if 
perhaps there were any timing results done or if there are any tips and 
tricks to getting the most out of it. Also - the man page section 
describing this is a little confusing to me so if anyone has a script 
segment that would be very helpful.

Thanks in advance,
LCB

-- 
LC Bruzenak
magitekltd.com

Re: ausearch checkpoint question

[Burn Alting]

Lenny,

I typically use

TZ=UTC ausearch -i --input-logs \
	--checkpoint <somepath>/auditd_checkpoint.txt

but I also set auditd.conf to have 9 x 32MB log files so the checkpoint
code only scans the more recent files.

On Thu, 2016-09-29 at 12:30 -0700, LC Bruzenak wrote:
> I'm using the 2.4.5-3 audit rpm set and I tried using the ausearch 
> "checkpoint" option a couple weeks ago.
> This was on a moderately busy system (judging by my own 
> systems/experience) generating say 300-400MB of data/day.
> 
> I tried the checkpoint option in a 5-minute cron job, and I noticed that 
> in comparison to the "-ts recent" option, it took far longer to complete.
> The "recent" option result was less than a second, whereas the 
> checkpoint version took ~20 seconds every 5 minutes.
> 
> It's possible there were other factors at play; e.g. it was used on a 
> mls-policy machine, and although I saw no AVCs, it's possible there were 
> some access issues I didn't have time to investigate.
> On my intended application, I'll be on a standard targeted-policy 
> machine so this won't be a potential factor.
> 
> I need to test this again, as I'm considering using the ausearch 
> checkpoint capability for some new requirements, I was wondering if 
> perhaps there were any timing results done or if there are any tips and 
> tricks to getting the most out of it. Also - the man page section 
> describing this is a little confusing to me so if anyone has a script 
> segment that would be very helpful.
> 
> Thanks in advance,
> LCB
> 

Re: ausearch checkpoint question

[LC Bruzenak]

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

On 09/29/2016 04:34 PM, Burn Alting wrote:
> Lenny,
>
> I typically use
>
> TZ=UTC ausearch -i --input-logs \
> 	--checkpoint <somepath>/auditd_checkpoint.txt
>
> but I also set auditd.conf to have 9 x 32MB log files so the checkpoint
> code only scans the more recent files.

OK; thanks Burn. I store 20 x 100MB files; I need that many for my purposes.
I'll be testing it again under controlled conditions; seems like what I 
need in one instance.

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com



[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3805 bytes --]

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