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
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 <d4hgcdgdmj@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
--
389 Directory Server Development Team
389 Directory Server Development Team
-- _______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
