On Fri, May 29, 2026 at 6:46 AM Pierre Rogier <progier@redhat.com> wrote: > > Hi Bob, > > The difference between using allids and providing a list of 77 attributes is indeed when determining the list of attributes to send. > i.e calling send_all_attrs instead of send_specific_attrs > > in the first case it walks the attribute list of the given entry > while in the second case for the 77 attributes it iterates on all the attributes to find the searched attribute (i.e performing strcasecmp on the attribute type) > > In you case the 77 lookups spend 25 seconds more while sending less data over the network (because some attributes values are not sent) > > 75682 objects with 870191 attributes means around 12 attributes per entries > ==> most of searched attributes are not in the entry meaning that it loops on all attributes to find them. > so in average something around 75682 * [ 65 * 12 + 12 * 6 ] i.e: 64 M > strcasecmp are performed on 25 seconds > Or 2.5 M strcasecmp per seconds > IMHO that seems a bit low so there is maybe something else than pure CPU bottleneck > paging maybe, or other processes spending the bandwidth ? Thank you for your analysis. I went back to take a closer look at these ~76K objects and indeed there are approximately 77 attributes being retrieved for each object, which makes the total attributes retrieved when specifying all 77 explicitly a bit over 5.8 million. When requesting all attributes the total per object is closer to 87 attributes each. The 870191 number of total attributes I shared initially is clearly wrong, I must have come up with this number by parsing the output through sort | uniq which was incorrect. I'm guessing now that I've clarified the actual number of attributes returned from a query your strcasecmp analysis would indicate a CPU bottleneck. Thank you for sharing these details. Bob -- _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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://forge.fedoraproject.org/infra/tickets/issues/new
Friday, May 29, 2026
[389-users] Re: retrieving 75K objects each with 77 attributes vs. all attributes
On Thu, May 28, 2026 at 3:48 PM Bob Green <wood.green.robert@gmail.com> wrote: > > On Thu, May 28, 2026 at 1:16 PM Mark Reynolds <mareynol@redhat.com> wrote: > > > > Otherwise, in this case the only other option is to make sure your entry > > cache is large enough to hold all the entries. Note - running > > concurrent searches like this is not going to be performant because it > > has to process so many results. So I am not surprised the more > > concurrent searches you run the slower they all get. > > Am I correct that nsslapd-cachesize: -1 under dn: cn=userroot,cn=ldbm > database,cn=plugins,cn=config will "automatically size" the entry > cache? I ask because dsconf INSTANCE backend monitor --suffix > dc=example,dc=com reports: > > currententrycachesize: 2818570021 > maxentrycachesize: 2818572288 > > which is just about at the maximum, though perhaps this will grow in > size as needed? Or should I replace -1 with a larger value? To answer my question, if you want to manually set your nsslapd-cachememsize attribute you must make the following ldapmodify changes: dn: cn=config,cn=ldbm database,cn=plugins,cn=config changetype: modify replace: nsslapd-cache-autosize nsslapd-cache-autosize: 0 dn: cn=userroot,cn=ldbm database,cn=plugins,cn=config changetype: modify replace: nsslapd-cachememsize nsslapd-cachememsize: <new_value> Thanks again, and I apologize for my previous email which was forwarded rather than replied, due to me not noticing I had only replied to Mark and not the list previously. Bob -- _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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://forge.fedoraproject.org/infra/tickets/issues/new
[389-users] Re: Fwd: retrieving 75K objects each with 77 attributes vs. all attributes
The difference between using allids and providing a list of 77 attributes is indeed when determining the list of attributes to send.
i.e calling send_all_attrs instead of send_specific_attrs
in the first case it walks the attribute list of the given entry
while in the second case for the 77 attributes it iterates on all the attributes to find the searched attribute (i.e performing strcasecmp on the attribute type)
In you case the 77 lookups spend 25 seconds more while sending less data over the network (because some attributes values are not sent)
75682 objects with 870191 attributes means around 12 attributes per entries
==> most of searched attributes are not in the entry meaning that it loops on all attributes to find them.
so in average something around 75682 * [ 65 * 12 + 12 * 6 ] i.e: 64 M
strcasecmp are performed on 25 seconds
Or 2.5 M strcasecmp per seconds
IMHO that seems a bit low so there is maybe something else than pure CPU bottleneck
paging maybe, or other processes spending the bandwidth ?
Regards
Pierre
On Thu, May 28, 2026 at 1:16 PM Mark Reynolds <mareynol@redhat.com> wrote:
>
> Hi Bob,
>
> What is in the access log for these searches? I suspect you're doing an
> unindexed search (check access log for notes=A or notes=U).
There are no notes=A or notes=U access events, just notes=P (paged
search) and a smattering of notes=N.
> This is not really an ideal way to test the server's performance. One
> thing to help with this type of search is to adjust the idscanlimit to
> at least 100000 (it might already be set really high)
>
> # dsconf slapd-YOUR_INSTANCE backend config get | grep
> nsslapd-idlistscanlimit
>
> If it's 4000 (or less than 100k) you can bump it up:
>
> # dsconf slapd-YOUR_INSTANCE backend config set
> --idlistscanlimit=100000 (this does not require a server restart to
> take effect)
nsslapd-idlistscanlimit is 2147483646.
> Otherwise, in this case the only other option is to make sure your entry
> cache is large enough to hold all the entries. Note - running
> concurrent searches like this is not going to be performant because it
> has to process so many results. So I am not surprised the more
> concurrent searches you run the slower they all get.
Am I correct that nsslapd-cachesize: -1 under dn: cn=userroot,cn=ldbm
database,cn=plugins,cn=config will "automatically size" the entry
cache? I ask because dsconf INSTANCE backend monitor --suffix
dc=example,dc=com reports:
currententrycachesize: 2818570021
maxentrycachesize: 2818572288
which is just about at the maximum, though perhaps this will grow in
size as needed? Or should I replace -1 with a larger value?
I also increased nsslapd-ndn-cache-max-size, dcsonf INSTANCE config
replace nsslapd-ndn-cache-max-size after seeing this with dsconf
INSTANCE monitor backend:
currentnormalizeddncachesize: 20971440
maxnormalizeddncachesize: 20971440
Thank you for the suggestions.
Bob
--
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@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://forge.fedoraproject.org/infra/tickets/issues/new
389 Directory Server Development Team
-- _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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://forge.fedoraproject.org/infra/tickets/issues/new
Reminder about the sunset of pagure.io
Hello everyone, we aim to decommision our old forge pagure.io around the Flock conference. We encourage you to migrate all your repositories from Pagure to our new forge[1] or to any other Git hosting service. If you have any questions, you can contact us on Matrix[2] or open a ticket with the Forge team [3]. Discussion and feedback can be held in the Discourse topic[4]. New organisation requests can be filed on the Forge ticket tracker[3] On behalf of the Fedora Infrastructure Team Smolík Vít [1] https://forge.fedoraproject.org [2] https://matrix.to/#/#fedora-forgejo:fedoraproject.org [3] https://forge.fedoraproject.org/forge/forge [4] https://discussion.fedoraproject.org/t/decommissioning-of-pagure-io-anticipated-by-flock-2026/181997 -- _______________________________________________ announce mailing list -- announce@lists.fedoraproject.org To unsubscribe send an email to announce-leave@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/announce@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
[389-users] replica RUV communicanting by 389 port
Hello team, I have my replication agreements working on port 636 via LDAPS with SSL/TLS encryption, but I can still see port 389 traffic between consumer and supplier nodes. I suspect that this might be due to RUV traffic between them, as I can see port 389 referenced in my supplier configuration. ObjectClass nsDS5ReplicationAgreement (structural) ObjectClass top (abstract) cn supplier1 cn=consumer1,cn=replica,cn=c\3Des,cn=mapping tree,cn=config nsds50ruv {replica 31 ldap://supplier1.domain.net:389} 588cd5a80000001f0000 69ec217b0359001f0000 nsruvReplicaLastModified {replica 31 ldap://supplier1.domain.net:389} 00000000 Is it possible that RUV communication is going over port 389? If so, is there any way to change this configuration so that RUV traffic uses the secure 636 port instead? Thank you very much in advance for your appreciated help. -- _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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://forge.fedoraproject.org/infra/tickets/issues/new
Thursday, May 28, 2026
[389-users] Re: parentid index mismatch after replica initialization causes one-level search to return no entries
보낸 날짜: 2026년 5월 28일 목요일 오후 5:16
받는 사람: 389-users@lists.fedoraproject.org <389-users@lists.fedoraproject.org>
참조: Thierry Bordaz <tbordaz@redhat.com>
제목: [389-users] Re: parentid index mismatch after replica initialization causes one-level search to return no entries
|
389-users@lists.fedoraproject.org에게서 전자 메일을 받지 못하는 경우가 많습니다. 이 문제가 중요한 이유
|
Hello 389-ds users,
We are investigating a reproducible issue during FreeIPA/IdM replica installation.
After initial replication completes, the replica target contains the expected LDAP entries, but one-level searches under cn=masters return no entries. Subtree searches under the same base return the expected entries.
On the replica target:
ldapsearch -b "cn=masters,cn=ipa,cn=etc,dc=idm,dc=example,dc=com" -s one dn=> returns no entries
ldapsearch -b "cn=masters,cn=ipa,cn=etc,dc=idm,dc=example,dc=com" -s sub dn=> returns the expected master and service entries
At the same time, 389-ds logs the following error:
Backend 'userRoot': MISMATCH - parentid index has integerOrderingMatch configured, but on-disk data uses lexicographic ordering. This will cause searches to return incorrect or incomplete results. Please reindex the parentid attribute: dsconf <instance> backend index reindex --attr parentid userRoot
The issue was reproduced in both cases:
1. Source 389-ds-base 1.4.3.39-23 -> Replica 389-ds-base 1.4.3.39-232. Replica 389-ds-base 1.4.3.39-23 -> Replica 389-ds-base 2.8.0-6
The index configuration differs between the original source and the replicas.
Source server:parentid index has no nsMatchingRule.
Replica servers:parentid index has:nsMatchingRule: integerOrderingMatch
Did you upgraded the replica, so the nsMatchingRule is a leftover from previous install ?
I suggest to remove this matching rule and reindex with the command that is in the error log.
regards
Running a userRoot parentid reindex on the replica target restores the one-level search immediately. However, in the FreeIPA installer flow, this happens after ipa-replica-install has already failed.
Question:Why does the replica target build or retain parentid on-disk index data using lexicographic ordering when the configured parentid index expects integerOrderingMatch? Is this expected after a total initialization from an older index definition, or should the replica initialization rebuild parentid using the target-side matching rule?
Is there a supported way to force or validate parentid index consistency immediately after total initialization and before upper-layer applications rely on one-level searches?
Please refer to the final inquiry sent to the FreeIPA users mailing list for additional technical details and follow-up discussion.
Thanks,Seongho Park
보낸 사람: Rob Crittenden <rcritten@redhat.com>
보낸 날짜: 2026년 5월 28일 목요일 오전 3:55
받는 사람: FreeIPA users list <freeipa-users@lists.fedorahosted.org>; Florence Blanc-Renaud <flo@redhat.com>
참조: 이철구 <cgulee@lgcns.com>; 박성호 <seongho.park@lgcns.com>
제목: Re: [Freeipa-users] Re: FreeIPA replica install fails after initial replication: one-level search under cn=masters returns 0 until userRoot reindex[rcritten@redhat.com 전자 메일을 받지 않는 경우가 많습니다. https://aka.ms/LearnAboutSenderIdentification ]에서 중요한 이유 알아보기
박성호 via FreeIPA-users wrote:
> Hello FreeIPA users,
>
> Is there anyone who can help with the following?
> The same error log was confirmed in both of the below cases.
>
> *Error Logs From (/var/log/dirsrv/slapd-IDM-EXAMPLE-COM/errors)*
> /var/log/dirsrv/slapd-IDM-EXAMPLE-COM/errors:[27/May/2026:11:10:31.315009288
> +0000] - ERR - ldbm_instance_check_index_config - Backend 'userRoot':
> MISMATCH - parentid index has integerOrderingMatch configured, but
> on-disk data uses lexicographic ordering. This will cause searches to
> return incorrect or incomplete results. Please reindex the parentid
> attribute: dsconf <instance> backend index reindex --attr parentid userRoot
>
> *
> Source server #1 (389-ds-base-1.4.3.39-23) => Replica server #1
> (389-ds-base-1.4.3.39-23)
> *
> Replica server #1 (389-ds-base-1.4.3.39-23) => Replica server #2
> (389-ds-base-2.8.0-6)
>
>
> *Our source server information*
> [root@xxxx ~]# dsconf "$INST" backend index get userRoot --attr parentid
> dn: cn=parentid,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
> cn: parentid
> nsIndexType: eq
> nsSystemIndex: true
> objectClass: top
> objectClass: nsIndex
>
> *Our replica server #1 information*
> [root@xxxx ~]# dsconf "$INST" backend index get userRoot --attr parentid
> dn: cn=parentid,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
> cn: parentid
> nsIndexType: eq
> nsMatchingRule: integerOrderingMatch
> nsSystemIndex: true
> objectClass: top
> objectClass: nsIndex
>
> *Our replica server #2 information*
> [root@xxxx ~]# dsconf "$INST" backend index get userRoot --attr parentid
> dn: cn=parentid,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
> cn: parentid
> nsIndexType: eq
> nsMatchingRule: integerOrderingMatch
> nsSystemIndex: true
> objectClass: top
> objectClass: nsIndex
>
> We found a workaround, but we are curious about the underlying reason
> why we need to perform a reindex.
>
> Thanks,
> Seongho Park
>
> ------------------------------------------------------------------------
> *보낸 사람:* 박성호 <seongho.park@lgcns.com>
> *보낸 날짜:* 2026년 5월 26일 화요일 오후 11:33
> *받는 사람:* Florence Blanc-Renaud <flo@redhat.com>; FreeIPA users list
> <freeipa-users@lists.fedorahosted.org>
> *참조:* 이철구 <cgulee@lgcns.com>
> *제목:* Re: [Freeipa-users] FreeIPA replica install fails after initial
> replication: one-level search under cn=masters returns 0 until userRoot
> reindex
>
> 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://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Ferrata%2FRHBA-2026%3A3126&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373262857%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2F6pMM8M8Cgi246yf3tPmbrJ%2FsMBCAndhwnj81wTJo6w%3D&reserved=0 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://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Fsolutions%2F7135993&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373293970%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=w0HudefEfnMp0tIIGwPiiUgxVRVUBBSuGypCvc%2FW7xk%3D&reserved=0,
> 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
This is really more a question for the 389-ds team. They sometimes pop
in here so someone might answer, but you may want to cross-post this to
the 389-users list to be sure they see it.
The parentid index is created by 389-ds directly and not by IPA.
rob
> ------------------------------------------------------------------------
> *보낸 사람:* Florence Blanc-Renaud <flo@redhat.com>
> *보낸 날짜:* 2026년 5월 26일 화요일 오후 10:04
> *받는 사람:* FreeIPA users list <freeipa-users@lists.fedorahosted.org>
> *참조:* 이철구 <cgulee@lgcns.com>; 박성호 <seongho.park@lgcns.com>
> *제목:* Re: [Freeipa-users] FreeIPA replica install fails after initial
> replication: one-level search under cn=masters returns 0 until userRoot
> reindex
>
>
> flo@redhat.com에게서 전자 메일을 받지 못하는 경우가 많습니다. 이 문제가
> 중요한 이유 <https://aka.ms/LearnAboutSenderIdentification>
>
>
> Hi,
>
> This is a known issue with 389-ds, you can get more information at
> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Fsolutions%2F7135993&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373318052%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=rkFIhgxu1FGGyFoL75V5PgEmg54yIJzZ7LJJJAcS9lM%3D&reserved=0
>
> The fixes are available:
> - on 8.10:
> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Ferrata%2FRHBA-2026%3A3126&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373340316%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=zTDmpz8H3uR%2BsSDGe5J7Qx937bLg2gNwIKysbgRpKTQ%3D&reserved=0 with 389-ds-base-1.4.3.39-22.module+el8.10.0+24000+b6bfdf3f
> - on 9.7: https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Ferrata%2FRHSA-2026%3A3189&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373359894%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=qJbhA4z4%2BC2pt4U1H8CMs2wfMRt2hLq5jMlRs8Y%2BYlI%3D&reserved=0 with
> 389-ds-base-2.7.0-10.el9_7
> - on 9.8: https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Ferrata%2FRHBA-2026%3A18956&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373379524%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=v94KwvhN7yrwy9a3148ZxseUfsE65j8a8V1jZRk%2Fnng%3D&reserved=0 with
> 389-ds-base-2.8.0-6.el9_8
> - on 10.1:
> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Ferrata%2FRHSA-2026%3A3208&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373401060%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=JQYIzOSDrJYf%2Bd2ivTMQPJVmqRGKMqY6M61eY7KciUE%3D&reserved=0 with 389-ds-base-3.1.3-7.el10_1.
> - on 10.2: https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Ferrata%2FRHBA-2026%3A18575&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373422008%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=UrqWJfvLu%2Bi0EFhRrfL5%2BBOppnmfVkPhe5BV%2FsL%2BFys%3D&reserved=0 with
> 389-ds-base-3.2.0-6.el10_2
>
> HTH,
> flo
>
> On Tue, May 26, 2026 at 12:11 PM 박성호 via FreeIPA-users
> <freeipa-users@lists.fedorahosted.org
> <mailto:freeipa-users@lists.fedorahosted.org>> 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 <https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fidm.example.com%2F&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373444724%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=I3h0eyB161Eg8gWjpzjJ2QzilKOZeXha3Q6fCgsXUUU%3D&reserved=0>
> - Realm: IDM.EXAMPLE.COM <https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fidm.example.com%2F&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373464870%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=UI2%2F643yBENt%2F7nfdBi1l3320g9raftRHNZH%2FO%2ByEg0%3D&reserved=0>
>
> 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://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcppm.singlex.com%2Fpublic%2FpainpointDirects%2FC998%3FmediaSource%3DEMAIL&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373484115%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=hsjsphHj1VXKWBu3wOYlm3ASQ2A9E%2FlonfpQ7tYIX%2Bs%3D&reserved=0>
>
> ------------------------------------------------------------------------
> 상기 메시지와 첨부화일 내에는 비밀정보가 포함되어 있을 수 있으며, 지
> 정된 수신자에 한하여 조회 및 사용될 수 있습니다. 만약 송신자의 실수
> 로 인하여 상기 메시지를 수신하였다면, 송신자에게 메시지를 반송해 주
> 시고, 원본 메시지와 모든 사본을 폐기해 주시기 바랍니다.
> 상기 메시지의 전체 또는 일부에 대해 무단 열람, 사용, 공개, 배포하는
> 것은 금지되어 있습니다.(주)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 -- freeipa-users@lists.fedorahosted.org
> <mailto:freeipa-users@lists.fedorahosted.org>
> To unsubscribe send an email to
> freeipa-users-leave@lists.fedorahosted.org
> <mailto:freeipa-users-leave@lists.fedorahosted.org>
> Fedora Code of Conduct:
> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373504038%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=IOJUFt4zqwKuTlpE8LbiX%2BkdB67CYaL2fRUhDxDay4U%3D&reserved=0
> List Guidelines: https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelines&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373523224%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=w%2FD4THwBp4NTfmF%2BMfEiKdmfu7lcCE4%2BQkGLW1MMTtI%3D&reserved=0
> List Archives:
> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedorahosted.org%2Farchives%2Flist%2Ffreeipa-users%40lists.fedorahosted.org&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373541933%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=hAa3x6%2F4K0DboQQjEOQlMztE%2Bc4NWC8dla9p4bO6bDo%3D&reserved=0
> Do not reply to spam, report it:
> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fforge.fedoraproject.org%2Finfra%2Ftickets%2Fissues%2Fnew&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373564065%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=FhzXocFM4KEG4Fp1GzDMBIZVBbyffN6Vt999UiFY2ns%3D&reserved=0
>
>
>
> 고객의소리열기
> <https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcppm.singlex.com%2Fpublic%2FpainpointDirects%2FC998%3FmediaSource%3DEMAIL&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373582605%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=vLy6f9yqW7yXvSO0IlzDQHvgf%2BOqfzBE4p0w81oB3K4%3D&reserved=0>
>
> ------------------------------------------------------------------------
> 상기 메시지와 첨부화일 내에는 비밀정보가 포함되어 있을 수 있으며, 지정된
> 수신자에 한하여 조회 및 사용될 수 있습니다. 만약 송신자의 실수로 인하여
> 상기 메시지를 수신하였다면, 송신자에게 메시지를 반송해 주시고, 원본 메시
> 지와 모든 사본을 폐기해 주시기 바랍니다.
> 상기 메시지의 전체 또는 일부에 대해 무단 열람, 사용, 공개, 배포하는 것은
> 금지되어 있습니다.(주)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.
>
상기 메시지와 첨부화일 내에는 비밀정보가 포함되어 있을 수 있으며, 지정된 수신자에 한하여 조회 및 사용될 수 있습니다. 만약 송신자의 실수로 인하여 상기 메시지를 수신하였다면, 송신자에게 메시지를 반송해 주시고, 원본 메시지와 모든 사본을 폐기해 주시기 바랍니다.
상기 메시지의 전체 또는 일부에 대해 무단 열람, 사용, 공개, 배포하는 것은 금지되어 있습니다.(주)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.
상기 메시지와 첨부화일 내에는 비밀정보가 포함되어 있을 수 있으며, 지정된 수신자에 한하여 조회 및 사용될 수 있습니다. 만약 송신자의 실수로 인하여 상기 메시지를 수신하였다면, 송신자에게 메시지를 반송해 주시고, 원본 메시지와 모든 사본을 폐기해 주시기 바랍니다.
상기 메시지의 전체 또는 일부에 대해 무단 열람, 사용, 공개, 배포하는 것은 금지되어 있습니다.(주)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.
-- _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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://forge.fedoraproject.org/infra/tickets/issues/new
[389-users] Fwd: retrieving 75K objects each with 77 attributes vs. all attributes
On Thu, May 28, 2026 at 1:16 PM Mark Reynolds <mareynol@redhat.com> wrote: > > Hi Bob, > > What is in the access log for these searches? I suspect you're doing an > unindexed search (check access log for notes=A or notes=U). There are no notes=A or notes=U access events, just notes=P (paged search) and a smattering of notes=N. > This is not really an ideal way to test the server's performance. One > thing to help with this type of search is to adjust the idscanlimit to > at least 100000 (it might already be set really high) > > # dsconf slapd-YOUR_INSTANCE backend config get | grep > nsslapd-idlistscanlimit > > If it's 4000 (or less than 100k) you can bump it up: > > # dsconf slapd-YOUR_INSTANCE backend config set > --idlistscanlimit=100000 (this does not require a server restart to > take effect) nsslapd-idlistscanlimit is 2147483646. > Otherwise, in this case the only other option is to make sure your entry > cache is large enough to hold all the entries. Note - running > concurrent searches like this is not going to be performant because it > has to process so many results. So I am not surprised the more > concurrent searches you run the slower they all get. Am I correct that nsslapd-cachesize: -1 under dn: cn=userroot,cn=ldbm database,cn=plugins,cn=config will "automatically size" the entry cache? I ask because dsconf INSTANCE backend monitor --suffix dc=example,dc=com reports: currententrycachesize: 2818570021 maxentrycachesize: 2818572288 which is just about at the maximum, though perhaps this will grow in size as needed? Or should I replace -1 with a larger value? I also increased nsslapd-ndn-cache-max-size, dcsonf INSTANCE config replace nsslapd-ndn-cache-max-size after seeing this with dsconf INSTANCE monitor backend: currentnormalizeddncachesize: 20971440 maxnormalizeddncachesize: 20971440 Thank you for the suggestions. Bob -- _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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://forge.fedoraproject.org/infra/tickets/issues/new