openldap-technical July 2026

openldap-technical@openldap.org

11 participants
5 discussions

Windows native support in modern LMDB?
by Dave Trombley 17 Jul '26

17 Jul '26

Hi all! Could someone authoritative let me know what the current state of native windows support (I'm trying to compile with MSVC, not an emulation layer) is for the LMDB project? I notice that I can get 0.9.31 libraries/liblmdb to compile without error with MSVC tools (up to the C4333 warning which I understand from the issues tracker is routinely ignored/suppressed). However, the 1.0 release does not compile at all, with multiple errors and warnings that look very much like platform issues - stuff about the sizes of basic types and attempts to use unsupported features (like void* arithmetic). Was MSVC support present in 0.9.31 and then dropped? Am I missing some compiler flags? I can't really find any good information on the website or elsewhere about the possibility of building a stable, reliable LMDB with MSVC 1.0. Thanks in advance, Dave Trombley

4 7

Issues with syncrepl replication potentially since update from 2.6.10 to 2.6.13
by Ben Poliakoff 16 Jul '26

16 Jul '26

We've started experiencing syncrepl replication issues recently that look like this in the logs: syncrepl_entry: rid=011 be_search (0) syncrepl_entry: rid=011 uid=example,ou=People,dc=foo,dc=bar syncrepl_null_callback : error code 0x7a syncrepl_entry: rid=011 be_modify uid=example,ou=People,dc=foo,dc=bar (122) We have a 3 node multi-master/provider cluster that we recently upgraded from 2.6.10 to 2.6.13. We've been using the Symas packages, on Debian 12, FWIW. Our config uses simple syncrepl (not delta-syncrepl). We replicate both cn=config as well as our main base dn. Upon upgrading to 2.6.13, we faced an initial hiccup because the symas packages transitioned to use the OS provided cyrus sasl libraries, which meant the sasl config file changed locations. Once we sorted that out things seemed to be functioning properly. I should have checked the changelog on the package. As a practice we make all ldap entry updates/additions/modifications via one designated "primary" cluster member. My initial attempt to resolve the issue involved reloading the db on the two "non-primary" nodes from a slapcat from the "primary" node. This seemed to fix the replication issue (I could make changes via our primary node and they'd replicate properly to the other nodes), however a day later I'm noticing that replication has stalled out again. Does this sort of issue ring any bells for anyone? At first glance I don't see anything in the CHANGES file between v2.6.10 and v2.6.13 that would trigger this issue, but I'm certainly not an expert. Our cluster has been performing flawlessly with the 2.6 branch for several years now, so this is a bit disconcerting. Ben -- Ben Poliakoff <benp(a)reed.edu> - Technology Infrastructure Services - Reed College

7 20

Re: Issues with syncrepl replication potentially since update from 2.6.10 to 2.6.13
by Ben Poliakoff 13 Jul '26

13 Jul '26

On Sat, Jul 11, 2026 at 4:27 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Thursday, July 9, 2026 4:38 PM -0700 Ben Poliakoff <benp(a)reed.edu> > wrote: > > The syncrepl process seems to get hung up "every so often" (might run > > for several days without issue). Today I found that it had gotten "stuck" > > again (newer change to an entry on slapd-a that wasn't being propagated > > to slap-b and slapd-c). Sometimes in these cases, simply restarting slapd > > on the non-primary instances gets things moving again. Today, though, > > that didn't work, and I was only able to get replication moving again, by > > deleting the entry (on the primary slapd instance) that was being > > referenced in the logs, and then recreating it (also on the primary slapd > > instance). > > Hi Ben, > > I'm curious if rather than deleting/adding the entry, if you modify an > attribute on the entry back to its same value if that fixes it. That's > worked for me in the past. > > like: > > dn: uid=blah,dc... > changetype: modify > replace: description > description: account for blah > > Thanks Quanah... Just to make certain I'm understanding you correctly, given a scenario where an entry on the "primary" server has been updated, but the changes have not been replicated to the two "non-primaries", you're suggesting I try updating the entry on the "primary" server again to see if that gets the replication flow working again? I can certainly try that, the next time this issue comes up (seems to happen every few days). By the way, when I follow the method (described previously) where I delete and recreate a "stuck" entry on the primary server, I also end up having to restart the slapd process on the two non-primary servers (ie simply deleting and recreating the entry on the primary server doesn't clear up the issue, but deleting and recreating the entry on the primary server, followed by restarting slapd on the non-primary servers tends to work, which makes it feel like a thread is "stuck" on the non-primary servers). Ben

1 0

Possible to watch for changes?
by Stef Bon 13 Jul '26

13 Jul '26

Hi, is there a way for clients to listen for changes in (a part of) openldap directory. I've read: https://stackoverflow.com/questions/20080819/ldap-server-updates-and-event-… but curious what your comment is. Stef Bon the Netherlands

2 1

auth mechanisms
by Gustavo Rios 07 Jul '26

07 Jul '26

Hi folks, how are you ? I am needing to auth a connection for a given ldap user entry (posixaccouint). ldap_sasl_bind_s allows to specify the auth mechanism, How to specify anonymous bind ? How to specify cleartext password ? How to specify a sasl mech for authentication for the user entry whose userpassword field is : {SSHA}dvTRokuLQQcKBpeM50HOUkNpJHSIE77Y For these 3 scenarios, what should ldap_sasl_bind_s specify with the mechanism parameter ? Thanks a lot. -- In software systems the price of reliability is the pursuit of the utmost simplicity. It is a price which the very rich find most hard to pay.

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical July 2026