Excellent, thank you! I was going to reach out to you directly but found the mailing list instead. I appreciate your help!
On Mon, Nov 7, 2022 at 12:44 PM Alexander Bokovoy <[email protected]> wrote: > > I'm on mobile, so top post, sorry. > > Schema compatibility tree is not replicated, it is generated on every replica > using the data from the primary tree. So replication check is correct, it was > never replicated in post as well. > > ou=sudoers is handled by the same plugin so the behavior is expected. > > On Monday, November 7, 2022, Steve Huston via FreeIPA-users > <[email protected]> wrote: > > I'm running Springdale 7 (a RHEL derivative). I have three IPA > > servers in a multi-master configuration with schema-compat-plugin > > turned on (old NIS-based netgroup authorization for NFS mounts which > > has carried over to newer file servers as well). > > > > Last week I updated these packages when they became available in the repo: > > Nov 03 10:50:43 Updated: 389-ds-base-libs-1.3.10.2-17.el7_9.x86_64 > > Nov 03 10:50:59 Updated: 389-ds-base-1.3.10.2-17.el7_9.x86_64 > > Nov 03 10:50:59 Updated: 389-ds-base-snmp-1.3.10.2-17.el7_9.x86_64 > > > > This morning I updated these: > > Nov 07 09:51:26 Updated: ipa-common-4.6.8-5.el7_9.12.noarch > > Nov 07 09:51:27 Updated: ipa-client-common-4.6.8-5.el7_9.12.noarch > > Nov 07 09:51:27 Updated: ipa-server-common-4.6.8-5.el7_9.12.noarch > > Nov 07 09:51:27 Updated: python2-ipalib-4.6.8-5.el7_9.12.noarch > > Nov 07 09:51:28 Updated: python2-ipaclient-4.6.8-5.el7_9.12.noarch > > Nov 07 09:51:28 Updated: python2-ipaserver-4.6.8-5.el7_9.12.noarch > > Nov 07 09:51:30 Updated: ipa-client-4.6.8-5.el7_9.12.x86_64 > > Nov 07 09:51:30 Updated: slapi-nis-0.60.0-1.el7_9.x86_64 > > Nov 07 09:51:31 Updated: ipa-server-4.6.8-5.el7_9.12.x86_64 > > > > Others were updated as well, but I don't believe they were relevant. > > > > After updating the group of packages today, I ran a replication check > > from the machine I consider the "primary master", which was not the > > one that I'd updated. 'repl-monitor' completed successfully and > > showed everything was connected and working. However, ds-replcheck > > when involved with the newly-upgraded server reported differences in > > the replication. Specifically everything in the "cn=compat" subtree > > was missing from the upgraded host, and strangely so is "ou=sudoers" > > which is empty anyway but I don't recall it being missing in the > > replication check before. > > > > I eventually checked the directory itself, and found that while > > ds-replcheck reports those replicas as missing, they do exist on the > > updated server and are retrievable. I picked one of the entries from > > the output of ds-replcheck and used 'ldapsearch' to view it on both > > the master and the replica, and got the same answer from both. So it > > appears that the data does exist, but ds-replcheck isn't finding it. > > If I limit the base DN for the replication check to "cn=compat" from > > any of the hosts I get the error that it is not replicated. > > > > After a bit of digging around I see that the slapi-nis upgrade may > > include quite a bit of differences from 0.56.5 to 0.60.0 though I'm > > not sure how many of those were backported to the RPM before. > > > > I've halted updating machines until I figure out this discrepancy > > since I don't want to make things worse. At the moment I'm not sure > > how many (if any) hosts are querying this one server - I don't have > > nearly as many on the network as I used to so the three servers is > > more for redundancy than load balancing - but I'm not seeing errors > > from machines so I'm leaving it up. > > > > Can anyone shed some light on this? Is this a real problem or just an > > indicator of a change in slapi-nis that means ds-replcheck will error > > until I upgrade the other two hosts as well, and then they'll all > > agree? > > > > -- > > Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci > > Princeton University | ICBM Address: 40.346344 -74.652242 > > 345 Lewis Library |"On my ship, the Rocinante, wheeling through > > Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, > > (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' > > _______________________________________________ > > FreeIPA-users mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > 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.fedorahosted.org/archives/list/[email protected] > > Do not reply to spam, report it: > > https://pagure.io/fedora-infrastructure/new_issue > > > > -- > / Alexander Bokovoy > Sr. Principal Software Engineer > Security / Identity Management Engineering > Red Hat Limited, Finland > > -- Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci Princeton University | ICBM Address: 40.346344 -74.652242 345 Lewis Library |"On my ship, the Rocinante, wheeling through Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' _______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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.fedorahosted.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
