When a mod/replace operation is replicated, it can cause the consumer to delete the attribute instead. Steps: create two masters m1 and m2 set up agreements between m1 and m2 both ways verify replication is working stop replication (set agmt nsds5replicaupdateschedule to "2358-2359 0") do a mod/replace of "description" with value "desc 0" to m2 wait 5 seconds do a mod/replace of "description" with value "desc 1" to m1 wait 2 seconds do a mod/replace of "description" with value "desc 2" to m1 restart replication (set agmt nsds5replicaupdateschedule to "0000-2359 0123456") What should happen is that the value of the description attribute is "desc 2" since that value has the latest csn - but the bug causes the description attribute to be deleted. A search for the attribute nscpEntryWsi shows this: nscpEntryWsi: description;adcsn-4bb1f944000000010000;vucsn-4bb1f942000000010000;deletedattribute;deleted: description 1 nscpEntryWsi: description;vucsn-4bb1f944000000010000;deletedattribute;deleted: description 2 nscpEntryWsi: description;vucsn-4bb1f93e000000020000;deletedattribute;deleted: description 0 The deletedattribute means the attribute was deleted.
There was sort of a similar bug - 515329. Don't know if they could be of the same type/origin.
Created attachment 403607 [details] 0001-Bug-578167-repl.-of-mod-replace-deletes-multi-valu.patch
To ssh://git.fedorahosted.org/git/389/ds.git 6e839e9..c559982 master -> master commit c559982cddbe09bad1b7717a84c7b0187111d61a Author: Rich Megginson <rmeggins> Date: Tue Mar 30 16:01:58 2010 -0600 Reviewed by: nkinder (Thanks!) Branch: HEAD Fix Description: The server implements a mod/replace operation as a mod/delete if all values, followed by a mod/add of the new values. The mod/delete phase, since it removes all of the values, essentially deletes the attribute, so it must set the attribute deletion_csn. This is even true in the case when you do a mod/replace on an attribute that doesn't yet exist. We have to create an empty attribute on the deleted_attrs list with the deletion_csn set to the csn of the operation. This preserves the semantics of the mod/replace operation. When doing the add phase of the mod/replace, we have to be able to resurrect attributes and values that may have been deleted by the mod/delete phase. We can tell that we need to resurrect a deleted value in resolve_attribute_state_multi_valued, in the deleted_values loop, because the deletioncsn will be the same as the update csn, and the delete_priority flag will be 0. Platforms tested: RHEL5 x86_64 Flag Day: no Doc impact: no To ssh://git.fedorahosted.org/git/389/ds.git 6dec072..71b5bb9 Directory_Server_8_2_Branch -> Directory_Server_8_2_Branch commit 71b5bb925a53ecdc23c584eca9fcc4a86093b7cf Author: Rich Megginson <rmeggins> Date: Tue Mar 30 16:01:58 2010 -0600 Branch: Directory_Server_8_2_Branch
fix verified RHEL 4 version: redhat-ds-base-8.2.0-2010051904.el4dsrv With Replication stopped: On server 2: changed description to "desc 0" On server 1: changed description to "desc 1" and then to "desc 2" [root@jgalipea-rhel4 578167]# ldapsearch -x -h jgalipea-rhel4.idm.lab.bos.redhat.com -p 1389 -D "cn=Directory Manager" -w Secret123 -b "ou=Accounting,dc=example,dc=com" | grep description description: desc 2 [root@jgalipea-rhel4 578167]# ldapsearch -x -h jgalipea-rhel4.idm.lab.bos.redhat.com -p 2389 -D "cn=Directory Manager" -w Secret123 -b "ou=Accounting,dc=example,dc=com" | grep description description: desc 0 After Replication restarted: [root@jgalipea-rhel4 578167]# ldapsearch -x -h jgalipea-rhel4.idm.lab.bos.redhat.com -p 2389 -D "cn=Directory Manager" -w Secret123 -b "ou=Accounting,dc=example,dc=com" | grep description description: desc 2 [root@jgalipea-rhel4 578167]# ldapsearch -x -h jgalipea-rhel4.idm.lab.bos.redhat.com -p 1389 -D "cn=Directory Manager" -w Secret123 -b "ou=Accounting,dc=example,dc=com" | grep description description: desc 2
This is closely related to bz515329