Hello Flo! Thank you for checking this quickly. Are you saying that I need to upgrade the source server's 389-ds version? I'm not entirely sure yet, but it looks higher than the version you mentioned. - 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 Currently, there are restrictions on checking the contents of https://access.redhat.com/solutions/7135993, so additional verification will be available tomorrow. Below are the details of the version currently in use.
Our source server information * Rocky Linux 8.8 (Green Obsidian) * ipa-server-4.9.13-21.module+el8.10.0+40089+03bf3c1f.x86_64 * ipa-client-4.9.13-21.module+el8.10.0+40089+03bf3c1f.x86_64 * ipa-server-dns-4.9.13-21.module+el8.10.0+40089+03bf3c1f.noarch * ipa-server-trust-ad-4.9.13-21.module+el8.10.0+40089+03bf3c1f.x86_64 * 389-ds-base-1.4.3.39-23.module+el8.10.0+40135+69dd2a79.x86_64 * 389-ds-base-libs-1.4.3.39-23.module+el8.10.0+40135+69dd2a79.x86_64 Our replica server #1 information * Red Hat Enterprise Linux 8.10 (Ootpa) * ipa-server-4.9.13-21.module+el8.10.0+23944+84561300.x86_64 * ipa-client-4.9.13-21.module+el8.10.0+23944+84561300.x86_64 * ipa-server-dns-4.9.13-21.module+el8.10.0+23944+84561300.noarch * ipa-server-trust-ad-4.9.13-21.module+el8.10.0+23944+84561300.x86_64 * 389-ds-base-1.4.3.39-23.module+el8.10.0+24085+b368a310.x86_64 * 389-ds-base-libs-1.4.3.39-23.module+el8.10.0+24085+b368a310.x86_64 Our replica server #2 information * Red Hat Enterprise Linux 9.8 (Plow) * ipa-server-4.13.1-3.el9_8.2.x86_64 * ipa-client-4.13.1-3.el9_8.2.x86_64 * ipa-server-dns-4.13.1-3.el9_8.2.noarch * package ipa-server-trust-ad is not installed * 389-ds-base-2.8.0-6.el9_8.x86_64 * 389-ds-base-libs-2.8.0-6.el9_8.x86_64 Thanks, Seongho Park ________________________________ 보낸 사람: Florence Blanc-Renaud <[email protected]> 보낸 날짜: 2026년 5월 26일 화요일 오후 10:04 받는 사람: FreeIPA users list <[email protected]> 참조: 이철구 <[email protected]>; 박성호 <[email protected]> 제목: Re: [Freeipa-users] FreeIPA replica install fails after initial replication: one-level search under cn=masters returns 0 until userRoot reindex [email protected]에게서 전자 메일을 받지 못하는 경우가 많습니다. 이 문제가 중요한 이유<https://aka.ms/LearnAboutSenderIdentification> 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]<mailto:[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<http://idm.example.com/> - Realm: IDM.EXAMPLE.COM<http://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. [고객의소리열기]<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]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[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 [고객의소리열기]<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
