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

Re: commit: ldap/servers/slapd/overlays accesslog.c

Kurt D. Zeilenga wrote:
At 05:00 PM 12/23/2006, Howard Chu wrote:
Kurt D. Zeilenga wrote:
It might be more appropriate to handle this issue on the
consumer than the provider.  An arbitrary LDAP sync client
might want this and other DSA specific attributes included
in the content.  That is, the provider should not assume
the consumer is doing server-to-server replication.
True. The problem was that the auditContext attribute wasn't defined on the consumer. There's no obvious way to configure a consumer to exclude unknown attributes,

Personally, I think this kind of problem is better solved by configuration then by code. Configuration wise, this can be addressed on either consumer side via a narrower attrs list, or on the provider side with an ACL.

Sure, but both of those require new action on the administrator's part. In general we try not to break existing configurations when we add new features. The addition of the auditContext attribute breaks existing configurations for pretty much no benefit.

The other fix I'm leaning toward is making slap_mods_check honor the no_schema_check flag, and use slap_bv2undef_ad for unrecognized attributes in that case. Another option is to pass slap_mods_check a flag that tells it to simply drop unrecognized attributes in these
situations. If the administrator actually wants the attribute replicated, they can load up a schema definition for it. Otherwise they should be able to carry on undisturbed.

  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc
  OpenLDAP Core Team            http://www.openldap.org/project/