Am Dienstag 02 Februar 2010 23:30:23 schrieb hyc@symas.com:

ralf@OpenLDAP.org wrote:

...

Full_Name: Ralf Haferkamp Version: RE24, HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.208.247) Submitted by: ralf

When using push-based replication (syncrepl-proxy) the entryCSN of the consumer's server's suffix entry (the one that also holds the contextCSN Attribute) is not in sync with the value on the provider. (Other operational Attributes are out of sync as well)

This is because the MOD Operation to update the contextCSN (sent by the provider) does not contain any other operational Attributes. That causes the consumer to add those attributes itself.

I guess the problem is mostly cosmetic, but I'll submit a fix anyway. (not calling slap_mods_opattrs() if the updatedn modifies "contextCSN")

But how did the suffix entry get created without an entryCSN in the first place? The MOD that updates the contextCSN doesn't happen until after the suffix entry already exists.

It wasn't created without an entryCSN. It always had one. But the MOD to update the contextCSN (coming from the provider) doesn't contain one. So bdb_modify() will call slap_mods_opattrs() to add entryCSN to the MOD operation. The easiest fix is probably to never touch the opattrs if "updatedn" is doing MODs, though I am not yet sure if it might break something. Currently my fix (not committed yet) only skips the slap_mods_opattrs() step if "updatedn" it is doing a MOD on contextCSN.