Michael Ströder wrote:
Pierangelo Masarati wrote:
So, the only reason to have slapo-accesslog(5) built and loaded **BUT NOT INSTANTIATED** on the __consumer__ (doesn't sound such strikingly resource intensive a requirement) is to have this attribute defined in the schema. If this sounds so unreasonable, please suggest (and code) a better strategy.
My feeling always was that hard-coding the schema elements into slapd and/or the overlays was the wrong approach.
In many cases it is the only possible approach. Especially for operational attributes that may have particular semantics or side-effects, relying on an external schema definition that may go out of sync is error-prone and downright dangerous.
I would have rather required the inclusion of particular schema files in slapd or loaded overlays by showing a error message about a missing schema element during start-up. So one would not have to enable a somewhat active component (even without explicitly instantiating it).
There is no such requirement. Especially in a situation like this, you can simply extract the schema definition from the provider and manually load it into the consumer.
Rather one would have to simply define the static schema element (by including appropriate schema file or schema entries in case of back-config being deployed).
Personally I think that's clumsy; whenever you have to touch more than 2 places in a configuration to activate a single feature, something is broken in the design. But if you like manually loading schema elements, there's nothing stopping you from doing so.
I'm open to everything (including zapping auditContext at all, unless anyone out there finds it useful and is actively using it).
web2ldap has a special plug-in class for this particular attribute. It displays a short-cut link for listing the audit trail of a particular entry by searching the access log database (reqDN=<entryDN>).