Log rotation and client disconnects

[rshaw1 at umbc.edu]

I just realized that my last reply went only to Steve Grubb, and not the
list.  Sorry about that.  This Webmail client is pretty awful, but at the
moment, I have to use it.

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.  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.

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?

>> I'm also having separate issues with some clients disconnecting from the
>> server, retrying twice in about a 40 second interval, and then giving
>> up.
>> The server isn't going down, and this isn't even happening at the same
>> time I was restarting auditd.
>
> Anything written to syslog on either end?

Nothing is on the server, but this is (everything) on the client:

Aug  4 23:12:07 host1 audisp-remote: connection to host2 closed unexpectedly
Aug  4 23:12:07 host1 audisp-remote: Connected to host2
Aug  4 23:12:12 host1 audisp-remote: connection to host2 closed unexpectedly
Aug  4 23:12:42 host1 audisp-remote: network failure, max retry time
exhausted

Thanks,

--Ray