Hi, This is a known issue with 389-ds, you can get more information at https://access.redhat.com/solutions/7135993
The fixes are available: - on 8.10: https://access.redhat.com/errata/RHBA-2026:3126 with 389-ds-base-1.4.3.39-22.module+el8.10.0+24000+b6bfdf3f - on 9.7: https://access.redhat.com/errata/RHSA-2026:3189 with 389-ds-base-2.7.0-10.el9_7 - on 9.8: https://access.redhat.com/errata/RHBA-2026:18956 with 389-ds-base-2.8.0-6.el9_8 - on 10.1: https://access.redhat.com/errata/RHSA-2026:3208 with 389-ds-base-3.1.3-7.el10_1. - on 10.2: https://access.redhat.com/errata/RHBA-2026:18575 with 389-ds-base-3.2.0-6.el10_2 HTH, flo On Tue, May 26, 2026 at 12:11 PM 박성호 via FreeIPA-users < [email protected]> wrote: > Hi FreeIPA users, > > I am investigating a reproducible FreeIPA/IdM replica installation failure. > > Summary: > After initial replication succeeds during ipa-replica-install, local LDAP > subtree searches under cn=masters work, but one-level searches under the > same DN return zero entries. This causes ipa server-find --servrole="IPA > master", ipa server-role-find --include-master, and > dns_update_system_records during replica installation to fail with: > > no matching entry found > > A full userRoot reindex immediately fixes the issue. > > Environment: > - Existing master: RHEL 8.10, FreeIPA 4.9.x > - New replica test 1: RHEL 8.10, FreeIPA 4.9.x > - New replica test 2: RHEL 9.x, FreeIPA 4.13.x > - Domain: idm.example.com > - Realm: IDM.EXAMPLE.COM > > The same behavior is reproduced on both RHEL8 and RHEL9 replicas. > > Failure path from ipareplica-install.log: > > ipa-replica-install > -> dns_update_system_records() > -> server_find(servrole='IPA master') > -> server_role_find(role_servrole='IPA master', status='enabled', > include_master=True) > -> servroles._fill_in_absent_masters() > -> ldap2.get_entries() > -> EmptyResult: no matching entry found > > Before reindex, on the new replica: > > ldapsearch -H ldapi://%2Frun%2Fslapd-IDM-EXAMPLE-COM.socket -Y GSSAPI > -LLL \ > -b "cn=masters,cn=ipa,cn=etc,dc=idm,dc=example,dc=com" \ > -s one "(objectClass=*)" dn cn objectClass > > returns no entries. > > But subtree search works: > > ldapsearch -H ldapi://%2Frun%2Fslapd-IDM-EXAMPLE-COM.socket -Y GSSAPI > -LLL \ > -b "cn=masters,cn=ipa,cn=etc,dc=idm,dc=example,dc=com" \ > -s sub "(objectClass=ipaConfigObject)" dn cn objectClass > > returns the expected master and service entries. > > After running: > > dsconf IDM-EXAMPLE-COM backend index reindex --wait userRoot > > the one-level search works, and ipa server-find / ipa > dns-update-system-records work. > > Things already checked: > - This does not appear to be specific to a RHEL8 or RHEL9 replica target. > - The replicated data appears to exist locally; the issue seems specific > to one-level search/index behavior under cn=masters. > - A full userRoot reindex immediately makes the same one-level search and > FreeIPA commands work. > > Question: > Is this a known 389-ds / FreeIPA replica initialization issue where the > local parent/one-level search index is incomplete immediately after total > init? Is there a supported way to force or verify index consistency before > ipa-replica-install reaches dns_update_system_records? > > Please let me know if this should be reported to 389-ds instead of FreeIPA. > > Thanks. > > > [image: 고객의소리열기] > <https://cppm.singlex.com/public/painpointDirects/C998?mediaSource=EMAIL> > ------------------------------ > 상기 메시지와 첨부화일 내에는 비밀정보가 포함되어 있을 수 있으며, 지정된 수신자에 한하여 조회 및 사용될 수 있습니다. 만약 > 송신자의 실수로 인하여 상기 메시지를 수신하였다면, 송신자에게 메시지를 반송해 주시고, 원본 메시지와 모든 사본을 폐기해 주시기 > 바랍니다. > 상기 메시지의 전체 또는 일부에 대해 무단 열람, 사용, 공개, 배포하는 것은 금지되어 있습니다.(주)LG CNS. > This message and its attachments may contain confidential information, and > they are intended to be viewed or used by only the individuals specified in > the message. If you have received this message in an error from the sender, > please contact the sender immediately to notify the error and delete all of > the message and its copies. It is prohibited to view, use, make public > and/or distribute part or whole of this message without written permission. > -- > _______________________________________________ > 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://forge.fedoraproject.org/infra/tickets/issues/new >
-- _______________________________________________ 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://forge.fedoraproject.org/infra/tickets/issues/new
