Re: Solving naming conflicts in replicated environment

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Fedora User Discussion]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [Maemo Users]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux