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

[Howard Chu <hyc@symas.com>]

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/