389-users

389-users@lists.fedoraproject.org

6658 discussions

Question about 389-ds versions for RHEL
by Bryan K. Walton 27 Jul '26

27 Jul '26

Hi, I have a few questions about the 389-ds versions available for RHEL. On https://www.port389.org/docs/389ds/download.html it states that to install the cockpit-389-ds package, we must use the copr repo. When we enable that repo on RHEL 8, the newest version of 389-ds-base and cockpit-389-ds available to us is 2.2.9. This seems to correspond with this page: https://copr.fedorainfracloud.org/coprs/g/389ds/389-directory-server/builds/ That pages shows that the most recent successful build was version 2.2.9-2. However, digging around the copr servers, I see an epel 8 version 2.5.2 available here: https://download.copr.fedorainfracloud.org/results/%40389ds/389-directory-s… Questions: 1. Is that 2.5.2 version bad? 2. Is the 2.2.9 version really the lastest supported version for RHEL 8? 3. If we upgrade our server to RHEL 10, I see that epel 10 has version 3.2.0 of 389-ds-base in it. How do we get a newer version of cockpit-389-ds for use with the newer versions of 389-ds-base? Thanks, Bryan Walton

3 6

high memory usage in 2.7.0
by Morgan Jones 09 Jul '26

09 Jul '26

Hello, I am struggling to determine why 389-Directory/2.7.0 B2026.064.0000 is using a crippling amount of memory. I'm not married to 2.7.0, just looking for something stable and actively supported but not too new. We're running it in Docker on almalinux:9. If I set nsslapd-cache-autosize to much over 5 ns-slapd consumes memory and is killed by the OOM. I have increased docker's memory limit to that of the host but if it's smaller the same happens, sometimes just sooner as the OOM sees the process exceed Docker's limits. The server has 16gb of ram, I have turned off the NDN cache. ns-slapd is using 14gb of ram not leaving much for the OS. nsslapd-cache-autosize is set to 5, where is all of the memory going?? Here's the current state of the cache: # docker exec -it sdp389ds dsconf localhost monitor dbmon DB Monitor Report: 2026-07-02 17:24:32 -------------------------------------------------------- Database Cache: - Cache Hit Ratio: 89% - Free Space: 101.89 MB - Free Percentage: 51.3% - RO Page Drops: 14972351 - Pages In: 15086991 - Pages Out: 405261 Backends: - dc=philasd,dc=org (userRoot): - Entry Cache Hit Ratio: 13% - Entry Cache Count: 38259 - Entry Cache Free Space: 6.8 KB - Entry Cache Free Percentage: 0.0% - Entry Cache Average Size: 15.42 KB - DN Cache Hit Ratio: 97% - DN Cache Count: 336275 - DN Cache Free Space: 37.42 MB - DN Cache Free Percentage: 58.5% - DN Cache Average Size: 82.0 B # Any advice would be appreciated, I have to be missing something simple here! Thank you, -morgan

3 6

2.4.7 with CVE-2026-9064 ?
by Dave Botsch 01 Jul '26

01 Jul '26

Was just browsing through... last 2.4.x release is 2.4.6 from what I see tagged. And there's Issue 7503, CVE-2026-9064 ... does it make sense to tag a 2.4.7 that is 2.4.6 with that CVE cherry picked? thanks -- ******************************** David William Botsch Programmer/Analyst @CornellCNF botsch(a)cnf.cornell.edu ********************************

2 1

replica RUV communicanting by 389 port
by Ciber Center 03 Jun '26

03 Jun '26

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.

2 2

Fwd: retrieving 75K objects each with 77 attributes vs. all attributes
by Bob Green 01 Jun '26

01 Jun '26

On Thu, May 28, 2026 at 1:16 PM Mark Reynolds <mareynol(a)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

3 4

parentid index mismatch after replica initialization causes one-level search to return no entries
by 박성호 28 May '26

28 May '26

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-23 2. 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 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(a)redhat.com> 보낸 날짜: 2026년 5월 28일 목요일 오전 3:55 받는 사람: FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>; Florence Blanc-Renaud <flo(a)redhat.com> 참조: 이철구 <cgulee(a)lgcns.com>; 박성호 <seongho.park(a)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(a)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(a)lgcns.com> > *보낸 날짜:* 2026년 5월 26일 화요일 오후 11:33 > *받는 사람:* Florence Blanc-Renaud <flo(a)redhat.com>; FreeIPA users list > <freeipa-users(a)lists.fedorahosted.org> > *참조:* 이철구 <cgulee(a)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.re…<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://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.re…<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 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(a)redhat.com> > *보낸 날짜:* 2026년 5월 26일 화요일 오후 10:04 > *받는 사람:* FreeIPA users list <freeipa-users(a)lists.fedorahosted.org> > *참조:* 이철구 <cgulee(a)lgcns.com>; 박성호 <seongho.park(a)lgcns.com> > *제목:* Re: [Freeipa-users] FreeIPA replica install fails after initial > replication: one-level search under cn=masters returns 0 until userRoot > reindex > > > flo(a)redhat.xn--com-y27lq63fmig 전자 메일을 받지 못하는 경우가 많습니다. 이 문제가 > 중요한 이유 <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.re…<https://access.redhat.com/solutions/7135993> > > The fixes are available: > - on 8.10: > https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.re…<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://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.re…<https://access.redhat.com/errata/RHSA-2026:3189> with > 389-ds-base-2.7.0-10.el9_7 > - on 9.8: https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.re…<https://access.redhat.com/errata/RHBA-2026:18956> with > 389-ds-base-2.8.0-6.el9_8 > - on 10.1: > https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.re…<https://access.redhat.com/errata/RHSA-2026:3208> with 389-ds-base-3.1.3-7.el10_1. > - on 10.2: https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.re…<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 > <freeipa-users(a)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.exampl…<http://idm.example.com/>> > - Realm: IDM.EXAMPLE.COM <https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fidm.exampl…<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://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcppm.sing…<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 -- freeipa-users(a)lists.fedorahosted.org > <mailto:freeipa-users@lists.fedorahosted.org> > To unsubscribe send an email to > freeipa-users-leave(a)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.fedo…<https://docs.fedoraproject.org/en-US/project/code-of-conduct/> > List Guidelines: https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedorapro…<https://fedoraproject.org/wiki/Mailing_list_guidelines> > List Archives: > https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fed…<https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahost…> > Do not reply to spam, report it: > https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fforge.fed…<https://forge.fedoraproject.org/infra/tickets/issues/new> > > > > 고객의소리열기 > <https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcppm.sing…<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. > [고객의소리열기]<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.

2 2

retrieving 75K objects each with 77 attributes vs. all attributes
by Bob Green 28 May '26

28 May '26

I've been fiddling with various 389ds tuning parameters to see if I can improve performance running 389-ds-2.7.0~git144.f597a91d8-150700.3.13.1.x86_64 on SLES15sp7 on a modestly specced KVM guest with 16GB of RAM and 2 "Intel Core Processor (Haswell, no TSX)". I believe performance is bottlenecked by my CPUs. I'm wondering if someone can confirm that an ldapsearch filter (objectclass=computer) that retrieves 75682 objects with 870191 attributes counting dn: in just under a minute is considered reasonable? If instead I request the 77 attributes I want to retrieve for each object, rather than "attrs=ALL", the same query filter will take ~85 seconds. I'm guessing the increased time is due to the overhead incurred by 389ds to selectively pick out those attributes, and that this is expected? I was wondering if there exists any computer sizing recommendations that might help me determine what hardware I should install 389ds on? As mentioned, I believe my 389ds instance is CPU bound, when I run the same query above in parallel, every additional query seems to add roughly 30 seconds to the amount of time the queries will take to finish. e.g. single query finishes in 60 seconds, 2 in parallel 90 seconds, 4 in parallel ~150 seconds, 10 concurrent queries will take ~330 seconds for all to complete. sar/mpstat on the 389ds instance shows that as I increase the number of concurrent queries cpu %usr utilization on the 389ds increases while %sys drops. expected I'm guessing... I'm trying to rule out whether I have inadequate indexing or whether some other tunable might improve concurrent queries of what is an admittedly large query, and hoping the community might be able to validate that yes, your query is large, if you insist on running this on 389ds you should plan on having 389ds run on significant hardware resources. Thank you for your time, Bob

2 1

Docker, dscontainer, and production version(s)
by Morgan Jones 18 May '26

18 May '26

Hello, I could use a little advice before I go down too many more rabbit holes: We are looking to run 389 in Docker and we prefer a stable version that will be supported for a while. We have a large user base and and value stability over new features. Is there a maintained docker image for, ideally, 389 versions 2.6 or 2.7? I'm open to 2.8 or 3.0 but worry they are a bit too bleeding edge for use in a large-ish environment. 2.4 worked well for us when we last tested but looks to now but deprecated. I'm happy to diy but from my testing and reading 2.6 and 2.7 dscontainer, at least in Alma Linux 9 as the base Docker image, seem to be buggy: the config directory is not correctly populated in the data directory. I am game for diy'ing a 2.8 or 3.0 Docker image if the consensus is that they are production ready but does dscontainer work in them and do you have a suggestion for what Docker operating system base image to use? I see 3.0, and maybe 2.8, can be enabled through copr in Alma 9 but don't want to get *too* exotic for production use. thank you! -morgan

1 0

Cannot change nsslapd-db-max-locks
by Orion Poplawski 13 May '26

13 May '26

On one of our EL9 IPA servers I'm unable to change nsslapd-db-max-locks ldapsearch returns: # database, monitor, ldbm database, plugins, config dn: cn=database,cn=monitor,cn=ldbm database,cn=plugins,cn=config nsslapd-db-current-locks: 96 nsslapd-db-max-locks: 179 dsconf config get returns: nsslapd-db-locks: 50018 I've restarted many times. Changed the value a couple of times. What's up? 389-ds-base-2.7.0-12.el9_7.x86_64 -- Orion Poplawski he/him/his - surely the least important thing about me Manager of IT Systems 720-772-5637 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 https://www.nwra.com/

3 5

version 3.1 : ERR - attrcrypt_ciphe
by Ghiurea, Isabella 11 May '26

11 May '26

After installing new Certs on version 389-ds-base-libs-3.1.3-7.el10_1.x86_64 , I am seeing the following ERR in errolog when restarting the ldap. [08/May/2026:12:47:19.286692556 -0700] - INFO - dbmdb_make_env - MDB environment created with max database instances=512. [08/May/2026:12:47:19.287568735 -0700] - ERR - attrcrypt_cipher_init - Failed to retrieve key for cipher AES (2) [08/May/2026:12:47:19.287866902 -0700] - ERR - attrcrypt_cipher_init - Failed to retrieve key for cipher 3DES (2) [08/May/2026:12:47:19.288083818 -0700] - ERR - attrcrypt_init - All prepared ciphers are not available. Please disable attribute encryption. And here are my entries for encryption in dse.ldif : dn: cn=encrypted attribute keys,cn=userroot,cn=ldbm database,cn=plugins,cn=con fig objectClass: top objectClass: extensibleObject cn: encrypted attribute keys creatorsName: cn=ldbm database,cn=plugins,cn=config modifiersName: cn=ldbm database,cn=plugins,cn=config createTimestamp: 20260128,........ modifyTimestamp: 20260128........ numSubordinates: 2 dn: cn=encrypted attributes,cn=userroot,cn=ldbm database,cn=plugins,cn=config objectClass: top objectClass: extensibleObject cn: encrypted attributes creatorsName: cn=ldbm database,cn=plugins,cn=config modifiersName: cn=ldbm database,cn=plugins,cn=config createTimestamp: 202601282.... modifyTimestamp: 20260128.... What else must be change to eliminate the errors. thank you !

3 4

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users