| 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: 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. |
_______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
