Thursday, January 18, 2024

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

I completed this last night. I found that deleting the active entry did not automatically promote the conflict entry. I still had to perform the modrdn operation.

Also, in addition to deleting the "nsds5ReplConflict" attrbute, I also manually deleted the "ConflictCSN" attribute, and the "ldapsubentry" value from the "objectclass" attribute.

And it didn't magically get added to the groups that the formerly active entry and the same entry in the other IdM replicas was in. I had to add them manually, using IdM utilities, on the replica where this change took place. (I actually only had to add one group; the other memberships were based on that one group, so adding it to that group added it to the others.)

After that, though, the entry on this server matched the entries on the other replicas except for "entryusn", "entryid", and "modifyTimestamp", which I believe are all normal variances.

Thanks for your help.

By the way, Red Hat support spent four days failing to even understand the question that you answered for me in half an hour: that deleting the active entry here wouldn't delete it on the other replicas. I asked them three or four times, each time getting a response that either explained to me how to delete the conflict entry, or failing to address the idea that it might delete the entry on the replicas, until I was finally told that it was impossible to promote the conflict entry, despite the documentation providing a procedure exactly for that, and that I would have to reinitialize the data on that replica.

If anyone has any suggestions for a vendor that can provide decent IdM support, I'd love to hear it.

Again, many thanks to everyone here.
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