On Monday, August 09, 2010 12:59:50 pm [email protected] wrote: > I had been using logrotate to rotate the logs (in order to get them named > with a date extension, bzipped a day after being rotated, etc.) I thought > that restarting the daemons each night might be causing issues with many > clients trying to reconnect at once, so I tried using copytruncate in > order to avoid restarting. This appears to make auditd crash, so I'm > looking at using its built-in rotation.
Yes, this is the preferred way. > However, "service auditd rotate" does not do anything. It should. I just double-checked the code and I can't see how it doesn't work without writing something to syslog on error. > The man page says this "will consult the max_log_size_action to see if it > should keep the logs or not", but I'm not sure what that means; It means that if you set the action to rotate, then it will delete any log that results in a number higher than the num_logs. > there is "max_log_file_action", which I have set to "ignore" as the FAQ > specifies. That means do nothing when the size of the log file exceeds max_log_file in megabytes. But this has no effect on rotation by the "service auditd rotate" technique. Its working like its supposed to on my system. > 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? > I would really like the clients to make more of an effort at reconnecting. I > have the configuration options set like so on the clients, but maybe I'm > misunderstanding what they do: > > network_retry_time = 30 ^^ time to delay in seconds between retries > max_tries_per_record = 60 How many time to retry > max_time_per_record = 5 Maximum time before doing the network failure action. > remote_ending_action = reconnect > > Finally, if anyone has any recommendations for setting tcp_listen_queue on > the server (I'm not sure if this is supposed to indicate a number of audit > messages or clients) and queue_depth on the clients when using a few > hundred clients, that would be great. If you have a few hundred clients, you will want to set the number higher. This is the queue size in the kernel for pending connections. How high ? Experiment. But 25 would be a good start and go higher. -Steve -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
