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
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/