Bug 456441 - aureport doesn't understand dates when run from cron
Summary: aureport doesn't understand dates when run from cron
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: audit
Version: 5.4
Hardware: x86_64
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: Steve Grubb
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-07-23 17:28 UTC by Brian LaMere
Modified: 2008-07-24 14:38 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-07-24 14:38:21 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Brian LaMere 2008-07-23 17:28:01 UTC
Description of problem:

Given a single script that runs perfectly from command line, and which specifies
date ranges, that exact same script does not work from cron.

Version-Release number of selected component (if applicable):

audit-1.6.5-9.el5  (fully patched system, all packages)

How reproducible:

always reproducible.

Steps to Reproduce:
1. run following script from shell, and it works:

----------------------------------------

#!/usr/bin/perl -w

use Fcntl;
use Sys::Hostname;

my $audsum = '/root/audsumm.tmp';

my $hostname = hostname();

sysopen(MAILIT, $audsum, O_WRONLY|O_TRUNC|O_CREAT) or die "can't open $audsum
for writing: $!\n";
my @TD=localtime(time);
my @YT=localtime(time-86400);
my $today = sprintf("%02d/%02d/%02d",$TD[4]+1,$TD[3],$TD[5]+1900);
my $yesterday = sprintf("%02d/%02d/%02d",$YT[4]+1,$YT[3],$YT[5]+1900);

my $onhoursy = qx"/sbin/aureport -ts $yesterday 06:00:00 -te $yesterday 20:00:00
--input-logs";
my $offhours = qx"/sbin/aureport -ts $yesterday 20:00:00 -te $today 06:00:00
--input-logs";

print MAILIT "Yesterday during business hours:\n$onhoursy";
print MAILIT "Off hours, last night:$offhours\n";
close(MAILIT);

system("mailx -s '$hostname audit report for $today' root < $audsum");

unlink $audsum;

------------------------------------------

2. same script, when run from cron, does not work.

3.
  
Actual results:

since I am not dropping stderr (on purpose) in cron, I get two emails; one that
should be a report, and the second is the stderr.  The stderr sent is this:

----------------------
Error parsing start date (07/22/2008)
Error parsing start date (07/22/2008)
-----------------------

Considering the following writes that message:

  fprintf(stderr, "Error parsing start time (%s)\n", ti);

The parentheses are not part of the date, and thus the date is in the correct
format.

Expected results:

Expect the script to work the same as it does on the command line; something
that breaks the audit logs into yesterday on-hours, and last night.

Additional info:

I marked this as "low" because I discovered yesterday that the options
"yesterday" and "today" exist as dates, and those work fine.  However, this is
still a bug, and so I thought I'd post it, in case someone wants to run aureport
from cron and using dates that aren't preset as words like "today"

Comment 1 Brian LaMere 2008-07-23 17:30:52 UTC
forgot to mention that I tried switching the dates, thinking it might be some
sort of order issue, and got what I expected:

-------------------------------------------

Invalid start date (21/07/2008). Month, Day, and Year are required.
Invalid start date (21/07/2008). Month, Day, and Year are required.

-------------------------------------------


Comment 2 Steve Grubb 2008-07-23 19:02:45 UTC
aureport and ausearch are localized apps which means that they are sensitive to
the LC_ environmental variables. (try: man 7 locale) You would need to export
LC_TIME="whatever ther correct locale is" before running the command. Cron does
not set the locale.

Comment 3 Brian LaMere 2008-07-23 20:46:50 UTC
so the follows:
-----------------
my $onhoursy = qx^LC_TIME="en_US.UTF-8" /sbin/aureport -ts $yesterday 06:00:00
-te $yesterday 20:00:00 --input-logs^;
my $offhours = qx^LC_TIME="en_US.UTF-8" /sbin/aureport -ts $yesterday 20:00:00
-te $today 06:00:00 --input-logs^;
----------------

No longer has the issue, as you suggest.  Apologies then, and thanks - please
close as "notabug" or whatnot.

Comment 4 Steve Grubb 2008-07-24 14:38:21 UTC
OK, closing it out. I'll doublecheck the man pages and see if that needs some
more work. Thanks.


Note You need to log in before you can comment on or make changes to this bug.