<quote who="Pierangelo Masarati">
Gavin Henry wrote:
<quote who="Aaron Richton"> > In the spirit of starting with the obvious, do you find auditContext > under > cn=Subschema?
I'll check ;-)
But why would this attribute get into the normal data dir?
that attribute is added to the producer to provide a pointer to the database that contains the log. The attributeType itself is defined by slapo-accesslog(5), so the overlay should be present (but does not need to be instantiated; just compiled in or, if built as module, loaded) in the consumer in order to have that attribute defined.
Why would I need to load the accesslog overlay on the consumer? I never have before.
The only thing that mentions accesslog is the normal delta-syncrepl directives:
logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog
etc.
I'm confused here. Is it a 2.4 change?
--On December 4, 2007 5:02:51 PM +0000 Gavin Henry ghenry@suretecsystems.com wrote:
etc.
I'm confused here. Is it a 2.4 change?
Must be, and seems to be a really odd requirement to me. Why does the consumer need to know about it? Why should it be required to load the accesslog module?
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
I'm confused here. Is it a 2.4 change?
Must be, and seems to be a really odd requirement to me. Why does the consumer need to know about it? Why should it be required to load the accesslog module?
As i said, when the __producer__ is configured with the slapo-accesslog(5) overlay, gets the the auditContext operational attribute set in the database's context entry. This may be useful to be able to determine what log context is logging modifications to that context.
As a side effect, syncrepl replicates this attribute as well in the __consumer__. However, if this attribute is not defined in the __consumer__'s schema, odd things could happen.
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. I'm open to everything (including zapping auditContext at all, unless anyone out there finds it useful and is actively using it).
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
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.
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). 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).
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>).
Ciao, Michael.
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>).
I think in this case we're sort of chasing a red herring (is this the right idiom?); in fact, the auditContext only makes sense in the provider. In the consumer it should at least be a referral, since no log context is present, but actually the consumer shouldn't be aware of that context, not that way, at least. The best solution, IMHO, is to remove the auditContext attribute from the replicated attrs.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Pierangelo Masarati wrote:
I think in this case we're sort of chasing a red herring (is this the right idiom?); in fact, the auditContext only makes sense in the provider. In the consumer it should at least be a referral, since no log context is present, but actually the consumer shouldn't be aware of that context, not that way, at least. The best solution, IMHO, is to remove the auditContext attribute from the replicated attrs.
I'm fine with not replicating attribute auditContext.
Ciao, Michael.
Michael Ströder wrote:
Pierangelo Masarati wrote:
I think in this case we're sort of chasing a red herring (is this the right idiom?); in fact, the auditContext only makes sense in the provider. In the consumer it should at least be a referral, since no log context is present, but actually the consumer shouldn't be aware of that context, not that way, at least. The best solution, IMHO, is to remove the auditContext attribute from the replicated attrs.
I'm fine with not replicating attribute auditContext.
Agreed. Since it is in fact a DSA-specific operational attribute, it really doesn't make sense to replicate it. Fixed in CVS, will be changed in 2.4.7.
Michael Ströder wrote:
Pierangelo Masarati wrote:
I think in this case we're sort of chasing a red herring (is this the right idiom?); in fact, the auditContext only makes sense in the provider. In the consumer it should at least be a referral, since no log context is present, but actually the consumer shouldn't be aware of that context, not that way, at least. The best solution, IMHO, is to remove the auditContext attribute from the replicated attrs.
I'm fine with not replicating attribute auditContext.
Likewise.
openldap-software@openldap.org
-
Gavin Henry -
Gavin Henry -
Howard Chu -
Michael Ströder -
Pierangelo Masarati -
Quanah Gibson-Mount