Thank you, William. I currently don’t have MMR set up, but I think it should not be a hard to do. Currently, I just spun up a VM and installed 389-ds on it. The reason why I want to simulate this is because I don’t quite understand the technique Redhat employs to resolve the conflict. If you look in that section (14.23.1.1), you will see that they first rename the nsunique+uid attribute to uid=NewValue keeping the old RDN and then delete the uid=NewValue along with the conflict marker. The deletion is done under the new dn of uid=NewValue,….
I think I now understand why the rename has to happen first. Since there are in that scenario two “adamss” users, if we just rename the second into “new” and delete the old RDN, it will delete the first “adamss” as well, right? Also, and this is more of a general LDAP question, in the same article they talk about removing dangling RUVs. They do a search for: dn:cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config But the ldapsearch command doesn’t specify the whole path. Instead, it’s just -b cn=config cn=replica. How does the server find replica under mapping tree if we only specified the base of cn=config? Thank you again, Sergei > No problem. I think there is an easier way to simulate this. > > Make sure you have MMR setup (IE agreement from M1 -> M2, and M2 -> > M1). > > Then on both, there is an agreement object, something like: > > cn=ExampleAgreement,cn=replica,cn=dc=example\,dc=com,cn=mapping > tree,cn=config > > To that object on *BOTH* masters add: > > > nsds5ReplicaEnabled: off > > This will pause all replication. > > > Now, add your "user1" to both M1 and M2. Try to make them have the same > DN, but different attributes like: > > uid=user,ou=People,.... > ... > description: m1 > > uid=user,ou=People,.... > ... > description: m2 > > > Next, on both masters set: > > > nsds5ReplicaEnabled: on > > > This will trigger a replication update. You should have conflict > entries on your servers now :) > > > Anyway, in reality, it's rare you'll ever see conflicts like this, but > I'm glad you are researching this so thoroughly,
_______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
