389-users June 2026

389-users@lists.fedoraproject.org

3 participants
3 discussions

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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users June 2026