Friday, January 12, 2024

[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 -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 -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 --
To unsubscribe send an email to
Fedora Code of Conduct:
List Guidelines:
List Archives:
Do not reply to spam, report it:

No comments:

Post a Comment