On Thursday, August 12, 2010 10:02:29 am rshaw1(a)umbc.edu wrote:
I've discovered the issue since I sent it, anyway. If num_logs
is set to
0, auditd will ignore explicit requests to rotate the logs. I guess this
may be intentional, but it's unfortunate as num_logs caps at 99 and I need
to keep 365 of them.
Have you looked at the keep_logs option for max_log_file_action?
I suppose that since I'll have to rename and bzip
them anyway, I may as well just move them to another location (maybe
/var/log/audit/archive) so that auditd doesn't "see" them, unless
there's
a better way to do this.
Yes, you should archive them away since by being in /var/log/audit, they are
used in calculating the log space left.
I'm still not sure what to do about the disconnection issues
(although
hopefully those will be very infrequent once I'm no longer restarting any
of the daemons). If a client does lose the connection to the server for a
while though (say, an hour-long network outage for networking upgrades),
I'd like to be able to tell them to try reconnecting periodically, and the
combination of network_retry_time and max_tries_per_record doesn't seem to
be the way to do that.
Other than checking the logs, is there a way to determine whether or not a
running audispd is connected to the remote server?
It logs this. Also I suppose you could peek into its open descriptors with
lsof or just checking in /proc.
-Steve