[389-users] Re: Solving naming conflicts in replicated environment

I was prepping to make this change and realized there's a part of the documentation I don't understand.

It says to delete the active entry, then perform a modrdn on the conflict entry, then delete the old RDN value of the naming attribute.

That last step can't be correct in this case, right? The naming attribute isn't changing.

Their actual example is:

# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x
dn: nsuniqueid=66446001-1dd211b2+uid=adamss,dc=example,dc=com
changetype: modrdn
newrdn: uid=NewValue
deleteoldrdn: 0

# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x
dn: uid=NewValue,dc=example,dc=com
changetype: modify
delete: uid
uid: adamss
-
delete: nsds5ReplConflict
-

But if you're trying to promote the conflict entry to replace the bad active entry, the naming attribute value isn't changing. That is, the "NewValue" in their example is the same as the old value: "adamss". Surely following these directions naively is going to result in deleting the naming attribute altogether. Unless maybe the schema prevents it from deleting the last value?

Am I correct in thinking I should just skip that part, while continuing to delete the nsds5ReplConflict attribute?
--
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue