openldap-technical July 2025

openldap-technical@openldap.org

16 participants
14 discussions

openldap-technical return-exact-case is set to "on"
by JM Lacombe 17 Jul '25

17 Jul '25

openldap to the "openldap-technical" mailing list openldap-technical(a)openldap.org hello like on SUN (odsee) : set config nsslapd-return-exact-case is set to "on" or off with openldap v2.6.6.3, how to get same feature ? and force return entryDN to lower case. best regards JM Lacombe email: jmlacombe(a)hotmail.com

3 6

Queries on openLDAP deployment on multi region on Kubernetes cluster
by vithal.akunuri＠tdsynnex.com 17 Jul '25

17 Jul '25

Hi, openldap-stack-ha was deployed as stateful set of 4 on multi region Kubernetes ( micro K8s ) cluster with 2 nodes in each region with multi master configuration. Application connections to LDAP are managed through kubernetes service. Multiple issues are noticed with this setup and would like to seek some guidance and feedback. 1. Frequent replication issues : For monitoring, script is being executed every 1 hour to check the replication status using check_syncrepl_extended command between all the providers and consumers. Is there any better to monitor the replication lag ? To recover from this issue, the pods are being recycled on the provider host which is out of sync. Is there any guidance of deploying LDAP in multi region ? Is multi master recommended in production environment for resiliency and performance? 2. Bulk upload : Is there any guidance on doing bulk upload into LDAP in this current setup? Thanks, Vithal

1 0

Two questions understanding delta-syncrepl
by Windl, Ulrich 17 Jul '25

17 Jul '25

Hi! I'm getting more experience with delta-syncrepl, but I still have two questions I'm unsure about: 1. In contrast to plan syncrepl, is it true that plain syncrepl will sync contents "from the past" (i.e. content changed before syncrepl had been activated), whereas delta-syncrepl will nor sync changes that were made before delta-syncrepl had been activated (i.e. sync only "new changes"" mad after the delta-syncrepl configuration? (see below, also) 2. Is it expected that the entryCSNs are identical for a synced entry on each server? I use a check that compare the UUID and the CSN for each entry to verify synchronization, but I see small differences (example below) For question #1: Specifically I have these messages (from today when establishing a new RID) in mind: slapd[22664]: conn=35370 op=2 syncprov_findbase: searching slapd[22664]: conn=35370 op=2 syncprov_op_search: registered persistent search slapd[22664]: conn=35370 op=2 syncprov_play_accesslog: accesslog information inadequate for log replay on csn=20250707100648.450369Z#000000#001#000000 slapd[22664]: conn=35370 op=2 syncprov_findcsn: mode=FIND_CSN csn=20250707100648.450369Z#000000#001#000000 slapd[22664]: conn=35370 op=2 syncprov_findcsn: csn==20250707100648.450369Z#000000#001#000000 not found slapd[22664]: conn=35370 op=2 syncprov_findcsn: csn<=20250707100648.450369Z#000000#001#000000 found slapd[22664]: conn=35370 op=2 syncprov_findcsn: mode=FIND_PRESENT csn= slapd[22664]: conn=35370 op=2 syncprov_sendinfo: present syncIdSet cookie= (and actually some changes made on that server recently were not synced to the other servers that should "pull" from this one) For question #2: On example I found (comparing server #2 with server #3) was: -uid=... (c3e62200-55af-1038-9b76-9916ef1a4822): 20250716105944.785857Z#000000#002#000000 +uid=... (c3e62200-55af-1038-9b76-9916ef1a4822): 20250716105944.780532Z#000000#002#000000 So there's a difference in the 5ms area, and (AFAIK) both changes originate from server #2. The corresponding changelog looks like this: dn: reqStart=20250716105944.000001Z,cn=changelog-1 objectClass: auditModify structuralObjectClass: auditModify reqStart: 20250716105944.000001Z reqEnd: 20250716105944.000003Z ... entryCSN: 20250716105944.780532Z#000000#002#000000 ... And that change is the only change made that second. Server #2 logged for sending the change to server #3: slapd[1811445]: conn=1020 op=2 syncprov_sendresp: to=003, cookie=rid=112,sid=002,csn=20250716105944.780532Z#000000#002#000000 Server #3 logged for receiving the change: slapd[2528537]: conn=-1 op=0 syncprov_add_slog: adding csn=20250716105944.780532Z#000000#002#000000 to sessionlog, uuid=c3e62200-55af-1038-9b76-9916ef1a4822 slapd[2528537]: slap_queue_csn: queueing 0x7f2d4816df90 20250716105944.780532Z#000000#002#000000 slapd[2528537]: slap_graduate_commit_csn: removing 0x7f2d4816df90 20250716105944.780532Z#000000#002#000000 slapd[2528537]: slap_queue_csn: queueing 0x7f2d4818bf70 20250716105944.780532Z#000000#002#000000 slapd[2528537]: conn=-1 op=0 syncprov_matchops: recording uuid for dn=reqStart=20250716105944.000001Z,cn=changelog-1 on opc=0x7f2d48002be0 slapd[2528537]: conn=1008 op=2 syncprov_qresp: set up a new syncres mode=1 csn=20250716105944.780532Z#000000#002#000000 ... slapd[2528537]: do_syncrep2: rid=113 cookie=rid=113,sid=003,csn=20250716105944.780532Z#000000#002#000000 slapd[2528537]: do_syncrep2: rid=113 CSN too old, ignoring 20250716105944.780532Z#000000#002#000000 (reqStart=20250716105944.000001Z,cn=changelog-1) slapd[2528537]: slap_graduate_commit_csn: removing 0x7f2d4814fd10 20250716105944.780532Z#000000#002#000000 (next change was several minutes later; rid113 would mean server #3 (sid 3) would try sync to itself (MMR on cn=config artefact)) Kind regards, Ulrich Windl

1 0

Advice / Rex on performance test
by BECOT Jérôme 16 Jul '25

16 Jul '25

Hi there, We want to run performance and load testing on our servers. Which tool fits the best for OpenLDAP (we are running servers behing haproxies as well).? Is there a specific tool for Openldap? Do you have any recommendation with other tools? We want to run tests through CI pipelines. Thank you

3 2

Q: Uniqueness ofSyncRepl RIDs, replicating cn=config
by Windl, Ulrich 11 Jul '25

11 Jul '25

Hi! I always wondered about the scope within SyncRepl RIDs have to be unique: * Per database * Per server * Within all servers For a support case covering MMR replication including cn=config I got this response: "One cannot copy the config between machines. Syncrepl configuration includes the RID parameter. That RID must be UNIQUE on all servers. By copying the config, one now has two machines with the same RID." I think it's OK to do so, however. Slapd handles the situation where a server is asked to sync from itself correctly ARAIK. We have three servers, says s1 (sid=1), s2 (sid=2), and s3 (sid=3). And there are three syncrepl statements making each server to syn from each of the three servers. So effectively s1 will sync from s2 and s3, s2 will sync from s1 and s3, and s3 will sync from s1 and s2 (each server ignoring the sync from itself). The log message may be like this for s2: slapd[1811445]: conn=1001 op=2 syncprov_matchops: skipping original sid 002 Am I correct, or is the support's answer correct? Kind regards, Ulrich Windl

2 1

Openldap unable to start after upgrading from 2.4 to 2.5
by Kaya Saman 11 Jul '25

11 Jul '25

Hi all, I've just performed an upgrade on my FreeBSD servers to get them all to version 13.5 and am now in the process of updating various @ports. OpenLDAP was upgraded from the 24 version port to the 25 (or version 2.5 in real terms) but for some reason the service does not want to start. I have checked the "upgrading" information here: https://openldap.org/doc/admin25/appendix-upgrading.html and tried to read around the issue, but I can't really understand what is going on. This is the output from the ldap.log file: Jul 8 23:48:03 ldap slapd[1302]: @(#) $OpenLDAP: slapd 2.5.20 (Jul 8 2025 21:55:10) $ @ldap.FQDN:/usr/ports/net/openldap25-server/work/openldap-2.5.20/servers/slapd Jul 8 23:48:03 ldap slapd[1302]: daemon_init: <null> Jul 8 23:48:03 ldap slapd[1302]: daemon: SLAP_SOCK_INIT: dtblsize=231210 Jul 8 23:48:03 ldap slapd[1302]: daemon_init: listen on ldap:/// Jul 8 23:48:03 ldap slapd[1302]: daemon_init: 1 listeners to open... Jul 8 23:48:03 ldap slapd[1302]: daemon: listener initialized ldap:/// Jul 8 23:48:03 ldap slapd[1302]: daemon_init: 1 listeners opened Jul 8 23:48:03 ldap slapd[1302]: slapd init: initiated server. Jul 8 23:48:03 ldap slapd[1302]: slap_sasl_init: initialized! Jul 8 23:48:03 ldap slapd[1302]: mdb_back_initialize: initialize MDB backend Jul 8 23:48:03 ldap slapd[1302]: mdb_back_initialize: LMDB 0.9.33: (May 21, 2024) Jul 8 23:48:03 ldap slapd[1302]: backend_startup_one: starting "cn=config" Jul 8 23:48:03 ldap slapd[1302]: ldif_read_file: no entry file "/usr/local/etc/openldap//cn=config.ldif" Jul 8 23:48:03 ldap slapd[1302]: send_ldap_result: conn=-1 op=0 p=0 Jul 8 23:48:03 ldap slapd[1302]: send_ldap_result: err=32 matched="" text="" Jul 8 23:48:03 ldap slapd[1302]: slapd destroy: freeing system resources. Jul 8 23:48:03 ldap slapd[1302]: slapd stopped. Jul 8 23:48:03 ldap slapd[1302]: connections_destroy: nothing to destroy. Has something with the configuration file changed in the meantime, or based off this line: "ldif_read_file: no entry file "/usr/local/etc/openldap//cn=config.ldif"" is it something to do with the slapd.ldif file in the openldap directory? If need be I can post my slapd.conf file too.... any pointers would be great or at least if there was somewhere to increase the logging to say exactly what and where is wrong would be great. Many thanks. Kaya

4 6

The infamous "main: TLS init def ctx failed: -1" and a solution
by Windl, Ulrich 10 Jul '25

10 Jul '25

Hi! When trying to start slapd, I got "main: TLS init def ctx failed: -1" before slapd quit. So I got the clue that something with TLS, probably certificates is wrong. I spend half of a day to examine the certificates used, found something, fixed that, but it did not help. Eventually I found some article (https://apple.stackexchange.com/questions/107130/slapd-daemon-cant-start-tl…) explaining that starting slapd with option -d1" would provide some more reasonable error details. So I tried that, and I found "TLS: could not load client CA list (file:`',dir:`/etc/ssl/certs')." That's much more helpful than the original message, so I examined the directory. Interestingly the issue was that there wre four stale links to centificate files that did not longer exist (those were not used any more, however, because they expired several years ago). Deleting those links by calling c_rehash fixed the problem. So at the very least I'm suggesting to provide the more useful error message also in non-debug mode. I'm not saying that the better error message couldn't be improved also. Kind regards, Ulrich Windl

1 0

LMDB and Disk fragmentation
by hubouvie＠microsoft.com 07 Jul '25

07 Jul '25

Hi everyone, We’ve been stress‑testing an LMDB database by continually inserting and deleting records ranging from 4 KB to 5 MB. To track utilization, we rely on two independent metrics: Application index – we track the sum of the payload bytes of keys currently present. mdb_stat output – pages in use /overlay etc.... The two figures agree closely. Despite this, we repeatedly hit MDB_MAP_FULL when both metrics say the map is only ≈ 50 % occupied (on both metrics). Our tentative conclusion is heavy page fragmentation: LMDB can’t find a sufficiently large contiguous run of free pages even though half of the map is nominally free. Questions - Is it normal to lose that much effective capacity with an insert/delete workload like ours? - How far can we realistically fill the map before hitting fragmentation limits? - Are there recommended ways to mitigate or “defragment”? Any advice would be greatly appreciated! Thanks! Hugues

3 4

Proxy Protocol support for ldap client
by BECOT Jérôme 07 Jul '25

07 Jul '25

Hello, We use the proxy protocol with our openldap 2.5 servers (pldaps). I noticed that client binaries allow pldaps as protocol in the host address option starting with 2.5, but how can I add proxy headers to the request to communicate with my servers ? I think that there might be something with '-o' that I'm not aware of. Thanks for your help. Jerome

3 3

Q: sync provider: "additional info: <olcUpdateRef> must appear after syncrepl or updatedn"
by Windl, Ulrich 04 Jul '25

04 Jul '25

Hi! I tried to set up a sync provider to have a UpdateRef pointing to itself, while not pulling any changes from anywhere. The idea was that the sync consumers will copy that UpdateRef and direct updates to the provider that way. This is a MMR scenario during migration where config is synced, too. So the current scenario is like this: P1 (provider, OpenLDAP 2.4) | | V v C1 <--> C2 (consumer, OpenLDAP 2.5) I could ldapmodify the change, but when doing a" slapcat -n0" now, I get the error: 68679fc8 olcUpdateRef: value #0: <olcUpdateRef> must appear after syncrepl or updatedn 68679fc8 config error processing olcDatabase={0}config,cn=config: <olcUpdateRef> must appear after syncrepl or updatedn slapcat: bad configuration file! Adding up to three "-c" options did not help (in old OpenLDAP 2.4) Should there be an exception if UpdateRef is pointing to the local server? Kind regards, Ulrich Windl

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical July 2025