Hello William,
I am sorry to read you had a not so ideal support experience, I located a case number that seems to match this thread, and we will look into what can be improved, and maybe even we should try to discuss the situation with a meeting.
I think it is important to ring an alarm in the support ticket system when there is some sort of dissatisfaction in the resolution, timing, or environment awareness that is related to the reported issue and particular technology, so the case can be presented to a next level, or somebody with a specific knowledge, or escalated if needed.
This would be a different topic, but being able to reach the creators and developers of a software directly, those with the best knowledge of very specific features, freely, is amazing, those developers are not support engineers, but till spend time here, so I am very glad to see a thriving community of users in this list, from newbies to what I call "power users" with operational experience ( the "real world").
Thanks all for participating,
M.
On Thu, Jan 18, 2024 at 8:50 AM William Faulk <d4hgcdgdmj@xxxxxxxxxxxxxx> wrote:
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 -- 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-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
