[Date Prev][Date Next] [Chronological] [Thread] [Top]

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.

Another user echoed that he'd like some auditing options, e.g. logging 
connections to the server

I added that logging unusual things like bind/authentication failures would 
be desirable

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.