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.