Hi William, IMHO, In your case simply deleting the entry should be enough: When deleting the entry, URP (i.e the conflict resolution protocol) should detect that there was an associated conflict entry and rename the conflict entry as the main entry. (Not 100% sure because there are exceptions in case of multiple conflicts, but from what you described, you are probably in the simple case)
FYI: About deleting the naming attribute value. You are right: you should not delete it if you do not change the naming attribute. Anyway you just cannot do it: such the modify operation fails with either schema violation or operation not allowed on rdn Regards Pierre On Fri, Jan 12, 2024 at 10:50 PM William Faulk <d4hgcdg...@liamekaens.com> wrote: > 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-le...@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 > -- -- 389 Directory Server Development Team
-- _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@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
