<quote who="Pierangelo Masarati">

Gavin,

from the preamble, one may infer that monitoring is optional in the sense it can be optionally built. That's how it used to be;

In 2.3. I see. Thanks.

however, in 2.4, it is always enabled, but it still must be explicitly exposed in slapd.conf/slapd.d by using "database monitor".

Ah, understood.

I would replace "enabled" with "exposed", and possibly explicitly indicate that in 2.4 it is no longer an option to build the monitor interface.

Yes, that sounds fine.

No global directive should occur after "database monitor", as it represents a database instantiation like any other. Although most global directives wouldn't complain if appearing __after__ a database instantiation, such use should be considered at least "bad practice".

OK. But I was right with the fact you can put rootpw directly beneath it, or is that what you are saying about bad practices?

About access control, it may be worth stressing that some attributes can actually be written; this requires to protect them and, at the same time, to grant the desired identities write privileges on them.

Only with the rootpw defined?

If so;

What attributes can be written to? What are their purpose/effects? What ACL example can we show to protect them? Are they used by any overlays/backends?

Sorry I haven't time to go into too much detail. Anyway, it seems you're doing a great job.

Thanks, p.

Your thanks is much appreciated.

Gavin.