RE: logging: audit/error option (not just debugging output)?

["Howard Chu" <hyc@highlandsun.com>]

In our Connexitor product I implemented audit as a separate backend with
hooks
into the top level. In a distributed system like ours where servers are
running
on multiple machines scattered across the world, you can't go around chasing
syslog entries to build up a picture of your system activity. An audit
record contains
a serial number, userID, DN associated with the request, request type, and
result code.
It also logs some of the other request-specific parameters:
bind: records method
add: records the new entry
modrdn: records newrdn, whether deleteold was given, and newSuperior
modify: records all changes
search: records scope, filter, and requested attributes

An audit entry is recorded as soon as the operation is received, before any
other backend gets to it. The result code is written into the entry after
the operation completes. For searches, the count of returned entries is also
logged.

The serial number is an 8-byte number formed by the 32-bit time() value and
a 4-byte counter. This approach is used to insure unique ID numbers are
assigned when multiple operations occur within a single 1-second interval.
The serial number serves as the RDN of the entries in the audit backend.

The actual audit storage is a flat text file, since it is basically only
being appended to. The format is similar to LDIF but extended so that it can
record operation types besides just modifies. This makes it easily human
readable at the local level. An appropriate ACL is set to control who can
read the audit subtree, and the backend only supports a "search" operation,
nothing else.

I really don't see the role of audit being similar enough to debug/logging
to warrant rolling it into the same mechanisms. An audit log has much
different requirements.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc

> -----Original Message-----
> From: owner-openldap-devel@OpenLDAP.org
> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Gary Williams
> Sent: Thursday, July 19, 2001 11:14 AM
> To: 'Peter W'; openldap-devel@OpenLDAP.org
> Subject: RE: logging: audit/error option (not just debugging output)?
>
>
> The original intention was to have debugging/error/auditing, but
> I only got the debugging started, and never got to the rest.  It
> looks like I'm not going to have time to get back to it any time
> soon, either.  Adding the macros to do the error and auditing
> should be pretty easy.  The only real difference between the
> debugging and audit/error reporting is that the debug macro gets
> compiled away if the system is configured to build without debug,
> and the others don't.
>
> The most work really needs to go into thoughtfully placing the
> debug/audit/error messages and setting their levels and output
> classes so they can be controlled in a meaningful and useful
> way.  The number of levels and classes can be expanded quite
> easily to increase the granularity of control over messages.
>
> If anyone has time to devote to this, feel free.
>
> -----Original Message-----
> From: Peter W [mailto:peterw@usa.net]
> Sent: Thursday, July 19, 2001 11:27 AM
> To: openldap-devel@OpenLDAP.org
> Subject: logging: audit/error option (not just debugging output)?
>
>
> On openldap-software I asked about loglevel settings that would make
> OpenLDAP 2.0.11 log only exceptional events, like start/stop/errors.
>  http://www.openldap.org/lists/openldap-software/200107/msg00351.html
>
> Another user echoed that he'd like some auditing options, e.g. logging
> connections to the server
>  http://www.openldap.org/lists/openldap-software/200107/msg00352.html
>
> I added that logging unusual things like bind/authentication
> failures would
> be desirable
>  http://www.openldap.org/lists/openldap-software/200107/msg00353.html
>
> But nobody else chimed in. Is there interest in making/offering some less
> "chatty" logging options? Not to get bogged down in
> implementation details,
> but I imagine this as another compile-time option, so users who
> wanted the
> best performance could compile with no logging, developers might compile
> with debug logging, but others might compile with a new "audit" logging
> capacity. Audit logging could be very simple to add if users were
> not able
> to add both "debug" and "audit" logging. The audit log facility could use
> the same code as the debug log, though perhaps interpreting "loglevel"
> differently, with cpp macros determining which log calls are
> compiled in. Or
> a better solution might be adding an "auditlevel" setting in the
> config that
> acted much like "logevel" so that users could enable both logging types.
>
> Thoughts?
>
> Thanks,
>
> -Peter
>