[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#6469) push replication entryCSN of database suffix out of sync
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#6469) push replication entryCSN of database suffix out of sync
- From: hyc@symas.com
- Date: Wed, 3 Feb 2010 08:39:19 GMT
- Auto-submitted: auto-generated (OpenLDAP-ITS)
rhafer@suse.de wrote:
> Am Dienstag 02 Februar 2010 23:30:23 schrieb hyc@symas.com:
>> 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.
Ah, got it. Yes, sounds like your fix is fine. Historically the updatedn user
(e.g. slurpd) has always provided all of the operational attributes in its
updates.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/