Re: (ITS#4375) MOD operations not being logged

[h.b.furuseth@usit.uio.no]

Howard Chu writes:
> I don't see any processing error here. The mod operation is
> rejected before the Statslog statement is reached. The same can
> occur for all of the operation types if input validation fails
> before reaching the Statslog. In other words, Statslog only
> records properly formatted requests.

(The following is partly a repeat of some talk about ITS#3281).

It would however be nice if slapd were more consistent about which
errors would prevent a statslog message.  Statslog(<request>) is
not done until slapd has collected all the information it wants to
log with the request, and that varies.

Statslog(ADD, SRCH, DELETE, BIND, ABANDON, UNBIND) are done early,
in do_<operation>().  For these and some extended operations, IIRC
a rough rule of thumb is that requests getting protocolError,
invalidDN and unavailableCriticalExtension are not logged.

But this is a schema error, not a malformed request.
Statslog(MOD, MODRDN, CMP, <extended>) are done quite late: In
fe_op_<operation>() (frontendDB->bd_info->bi_op_<operation>).  I'd
like to have a "backup" Statslog statement for these:

As soon as the code reaches the point where ADD & co would have
done Statslog, set a "statslog wanted" flag for the operation.
Reset it when Statslog is done.  Check it before sending a
response (and maybe a few other places), and if still set, do a
mini Statslog which just logs the basic info about the operation
but not everything which would normally be logged.

This would need mapping of operation -> operation name, but IIRC
that would be nice to have anyway because it could simplify
Statslog of results.

For that matter I'd like to do the same with other kinds of errors
that prevent Statslog, like unknown critical controls and maybe
invalid DNs.  If someone dislikes that, maybe we could have a
config option about when to set the "statslog wanted" flag.

-- 
Hallvard