RE: Audit dispatcher process

James, Even though the xinetd model for plugins was probably a no-brainer design decision, I still agree that it's an excellent choice. Thanks for using that model. I don't know if you want to have signal (of some kind) that must be issued in order for a new plugin to take effect. Certainly, the addition of a new plugin should be an audited event, so perhaps the CAPP-suggested list automatically includes a write/execute watch on this directory. I have a small suggestion for the local logging plugin that will probably be put in by default: * I recommend a file naming convention similar to that used under Solaris. That is <init_datetime>.<close_datetime>.<host> * <init_datetime> for 11Jan2007 at 3:46pm would be 20070111154632 * <close_datetime> is "not_terminated" when a file is currently being written, although this is doesn't work when the dispatcher dies prematurely * <host> is usually not the FQDN, but allows lots of audit trail files from lots of machines to be in one directory. * Solaris administrators issues a "audit -n" to rotate the logs when it's time, and this is occassionally quite handy when archiving logs * Real-time compression (gzip) is a GREAT idea. If the binary file written by the local logging plugin wrote whole records at a time, then a leading bit could indicate compression. Being able to turn off compression might help in high-load situations. * Also being able to set a max file size before rotation becomes mandatory makes it easy to archive audit logs to fixed-size media. A suggestion I have for the plugin architecture is to allow the plugin to query the dispatcher for internal statistics and system call number-to-name lookups. Some internal statistics might be audit buffer ring size, or other useful information to deal with high-load environments. Most everything else, the plugin can ask the OS (system date/time, system load, etc.) Is the dispatcher responsible for restarting a plugin if the process-killer targets it? A useful plugin for any authors might be a UDP transmitter, with PKE for all packets. This would allow a centralized repository in a trusted environment. Another plugin might be a real-time stream-to-tape so that audit trail retention is as easy as replacing a tape when it's ejected because it was full. By maintaining an open file descriptor at all times, other processes will have a tough time overwriting audit trails. Should anyone approach the Webmin authors once the API and directory structure is locked in so that they can write a module? Of course, I don't expect both of those to make it into the standard distro, but rather maybe spark an interest among the group. Thanks, Charlie Todd Ball Aerospace & Technologies Corp. Ctodd- at -ball.com