openldap-technical

openldap-technical@openldap.org

11 participants
9979 discussions

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

20 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 10

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

20 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 22

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

19 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

2 1

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

RE27 alpha stages testing call
by Quanah Gibson-Mount 19 Jun '26

19 Jun '26

This is an early testing call for the forthcoming OpenLDAP 2.76 series. The initial release state is largely finalized, so suitable for testing configurations, etc. It should not be used in a production environment. Note that the LMDB library has been updated to the 1.0 series, so if deploying this early RE27 into an environment it will be required to do a database dump via slapcat under 2.6, and then import the database with slapadd under 2.7. Generally, get the code for RE27: <https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_7/o…> Extract, configure, and build. Execute the test suite (via make test) after it is built. Optionally, cd tests && make its to run through the regression suite. Thanks! Regards, Quanah

6 13

When exactly do I have to apply the migration steps
by Hans Joachim Multhaupt 18 Jun '26

18 Jun '26

Hello the maintenance section of the documentation [1] describes: > the simplest steps needed to migrate between versions or upgrade When exactly do I have to apply these steps? I see these Options: 1. Only when upgrading from e.g. 2.5 to 2.6? 2. Also when upgrading from e.g. 2.6.12 to 2.6.13? 3. Or is this a case-by-case decision (like being necessary when upgrading from 2.6.j to 2.6.j+1 but not for 2.6.k to 2.6.k+1)? The LTS Release Changes [2] mostly contain Bugfixes and some additions and cleanups. So my impression is that the update strategy would only apply to Option 1. Is there any document or official statement, that can be used to confirm/underpin the applying Option? For some context: I have to run openldap with custom schema definitions in a Docker Image (deployed using a Helm Chart) and I have to make sure, that updating to a new Version of that Image will _usually_ not require manual intervention. In addition to the automation aspect there is the time aspect: Creating a Backup is one thing (better being safe than sorry). But importing it again does take quiet a lot of time (about 45 Minutes for an uncompressed 1 GB LDIF file). So I prefer not having to restore a backup _needlessly_. Though these timings might hint to other potential issues, that I did not look into, yet, e.g. attached network storage, indexing, etc. In case of Options 2 and 3 I would have to take an entirely different approach (e.g. creating the Backup with the old Docker Image, while restoring it with the new one), compared to Option 1 (which only happens every-so-often and which _could_ be covered with an explicit and manually executed backup-and-restore procedure). For the time being, replication/scalability is explicitly out-of-scope. References: [1] https://www.openldap.org/doc/admin26/maintenance.html#Migration [2] https://www.openldap.org/software/release/changes_lts.html Kind Regards, Hans Joachim Multhaupt.

6 5

Building the Admin Guide with sdf on modern perl?
by patrick+openldap.org＠laimbock.com 18 Jun '26

18 Jun '26

Hi, How does the project build the Admin Guide with sdf on modern perl? Fedora 44 has perl-5.42.2 and sdf is no longer compatible with perl-5.30+: sdf -2topics index.sdf $* is no longer supported as of Perl 5.30 at /usr/share/perl5/vendor_perl/sdf/subs.pl line 624. sdf source from https://metacpan.org/release/IANC/sdf-2.001beta1/source Thanks, Patrick

4 3

issue with new cert (now using CN = InCommon RSA OV SSL CA 3)
by steiner＠rutgers.edu 18 Jun '26

18 Jun '26

At the moment, I still update LDAP certificates by hand. All previous certs used "C = US, O = Internet2, CN = InCommon RSA Server CA 2" but on May 4th, moved to "C = US, O = "InCommon, LLC", CN = InCommon RSA OV SSL CA 3". I had to generate a new cert after that date... so I added in the new CA certs into my CACert file on both ends. But replication is failing with the new cert, works fine with the old cert: May 13 13:26:21 HOSTNAME slapd[4076661]: slap_client_connect: URI=ldap://master_vip_name/ ldap_sasl_interactive_bind_s failed (-1) May 13 13:26:21 HOSTNAME slapd[4076661]: do_syncrepl: rid=101 rc -1 retrying Tried changing tls_reqcert to never in ldap.conf and in the syncrepl and that didn't change anything. If I move back to the old cert (expires tomorrow) replication works again so probably not a password issue. Any suggestions for debugging this further? thanks, ds

3 13

Re: Cannot connect over TLS/SSL (ldaps) on v2.6.9
by Nick Milas 17 Jun '26

17 Jun '26

Hi Emmanuel, Are there any plans for an updated release of Apache Directory Studio? It has been about 6 years without a release and ADS can no more connect to modern LDAP Servers over TLS due to lack of supported ciphers. I would think that an updated release or patch should be considered mandatory. I hope Apache keeps on loving its users :) Best, Nick On 21/5/2025 4:44 μ.μ., Emmanuel Lécharny wrote: > Hi Nick, > > Apache Directory Studio has some issue with TLS 1.3, and we are > working on it. > > On 21/05/2025 11:33, Nick Milas wrote: >> On 21/5/2025 11:52 π.μ., Uwe Sauter wrote: >>> What is the output of your query with "-d -1" added to the command >>> line? What is the output of >>> "openssl s_client -connect $SERVER:636"? >>> >>> Can you query your server when you disable certificate checking in >>> ldap.conf ("TLS_REQCERT allow")? >> >> Hi Uwe, >> >> After further testing, I found that I can connect over ldaps from >> other servers (using ldapsearch) successfully, even from my (Windows) >> workstation with JXplorer, but not from Apache Directory Studio (also >> on my workstation). >> >> Quite strange. ADS can connect to the old server (which has exactly >> the same certificate!) without issues. >> >> I'll (try to) troubleshoot that further, but if you have any ideas, >> they are welcome! >> >> Thanks, >> Nick >> >

2 2

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical