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,