RE: [PATCH] Add End of Event record

John, I have debated this in my head for a while, especially when I considered writing my own dispatcher. At a high level, it is starting to sound like these topics might be appropriate: 1. A (pseudo-)RFC describing the dispatcher "protocol" 2. A rigid, easily parsed record format - AUDIT_EOE might keep it easy on the reporting subsystem 3. Administrative records are passed, perhaps at dispatchers startup and at the start of a file when rotated, that documents which version of auditd, uname -r, output of gnu_get_libc_version(), and the local system date/time. The administrative record, when mentioning auditd's version, may even indicate a "backward compatible to version..." so that 1.2.6 might still be able to parse 1.2.12, but as of 1.3 the format changed so backwards compatability is broken. My goal is this: 3 years from now, an employee is being investigated. The investigator makes me pull up all the raw records from my network and analyze them. Now I've interpreted user names, group names, syscalls, and hostnames during capture (ausearch -i), but if the format changed through the years, I need to have analysis tools be aware of the format. This gets back to a previous posting I did on "Offline audit trail analysis." Charlie Todd Ball Aerospace & Technologies Corp. This message and any enclosures are intended only for the addressee. Please notify the sender by email if you are not the intended recipient. If you are not the intended recipient, you may not use, copy, disclose, or distribute this message or its contents or enclosures to any other person and any such actions may be unlawful. Ball reserves the right to monitor and review all messages and enclosures sent to or from this email address.