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
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@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-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
