openldap-bugs September 2025

openldap-bugs@openldap.org

1 participants
65 discussions

[Issue 10383] New: slapd-meta ignores olcDbIDAssertBind if olcDbURI defined after it
by openldap-its＠openldap.org 28 Nov '25

28 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=10383 Issue ID: 10383 Summary: slapd-meta ignores olcDbIDAssertBind if olcDbURI defined after it Product: OpenLDAP Version: 2.6.9 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: david.frickert(a)protonmail.com Target Milestone: --- Hi, We are using slapd-meta to connect an OpenLDAP server to another external LDAP server and it works well on first configuration. However, if we want to update any info, e.g. the external LDAP URI, we must replace the olcDbURI attribute. This means that the ordering of the attributes change and this attribute is now defined after olcDbIDAssertBind. Didn't think this would be important, but after this change the "meta" connection stops working and upon enabling debugging i can see that the external LDAP server is responding with: "ldap_bind: Inappropriate authentication (48) additional info: Anonymous Simple Bind Disabled" This seems to imply that the olcDbIDAssertBind attribute is being ignored, likely due to being defined before olcDbURI (my assumption). Is this intended? If so, what can we do to mitigate this problem? Do we need to perform a replace on all attributes of the object to ensure correct ordering, or is there any way to perform an in-place attribute modification without making it shift its position in the object? Example: First configuration (OK): # {0}uri, {2}meta, config dn: olcMetaSub={0}uri,olcDatabase={2}meta,cn=config objectClass: olcMetaTargetConfig olcMetaSub: {0}uri --> olcDbURI: ldap://REDACTED/ou=users,REDACTED olcDbIDAssertBind: bindmethod=simple starttls=yes tls_reqcert=demand binddn="REDACTED" credentials="REDACTED" olcDbRewrite: {0}suffixmassage REDACTED REDACTED olcDbKeepalive: 0:0:0 olcDbBindTimeout: 100000 olcDbCancel: abandon After URI update (NOK): # {0}uri, {2}meta, config dn: olcMetaSub={0}uri,olcDatabase={2}meta,cn=config objectClass: olcMetaTargetConfig olcMetaSub: {0}uri olcDbIDAssertBind: bindmethod=simple starttls=yes tls_reqcert=demand binddn="REDACTED" credentials="REDACTED" olcDbRewrite: {0}suffixmassage REDACTED REDACTED olcDbKeepalive: 0:0:0 olcDbBindTimeout: 100000 olcDbCancel: abandon --> olcDbURI: ldap://REDACTED/ou=users,REDACTED The olcDbURI attribute is shifted to the bottom after a modify operation, and seems to cause these issues. Best Regards, David -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10286] New: ldap_pvt_gettime may result in "not new enough csn" problems in multi-thread case.
by openldap-its＠openldap.org 27 Nov '25

27 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=10286 Issue ID: 10286 Summary: ldap_pvt_gettime may result in "not new enough csn" problems in multi-thread case. Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: 971748261(a)qq.com Target Milestone: --- Created attachment 1041 --> https://bugs.openldap.org/attachment.cgi?id=1041&action=edit the log of adding two entry which shows the time sequence. I used openldap as krb5's database, and openldap was deploymented in mirrormode. I tried to add kerberos principals via kadmin.local -q "addprinc -randkey principal. slapd log showed that the entry of kadmin/admin was added earlier than the entry of ossuser. But the csn of kadmin/admin was greater than ossuser. In this case, when the two entry began to sync to the other slapd server, ossuser was ignored because of "csn not new enough" -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10293] New: Log operations generated by syncrepl at STATS level
by openldap-its＠openldap.org 26 Nov '25

26 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=10293 Issue ID: 10293 Summary: Log operations generated by syncrepl at STATS level Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- Similarly to how incoming operations are logged, operations created by syncrepl should be logged as well. -- You are receiving this mail because: You are on the CC list for the issue.

1 14

[Issue 10329] New: Additional issues with pcache, and a test
by openldap-its＠openldap.org 25 Nov '25

25 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=10329 Issue ID: 10329 Summary: Additional issues with pcache, and a test Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: aweits(a)rit.edu Target Milestone: --- Created attachment 1062 --> https://bugs.openldap.org/attachment.cgi?id=1062&action=edit test & patches Hello again! Further testing revealed some more issues in pcache [re: ITS#10270]. I've attached an update to test020-proxycache as well. These are based off the current git HEAD. -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Issue 10026] New: Refresh handling can skip entries (si_dirty not managed properly)
by openldap-its＠openldap.org 25 Nov '25

25 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=10026 Issue ID: 10026 Summary: Refresh handling can skip entries (si_dirty not managed properly) Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Take MPR plain syncrepl with 3+ providers. When a provider's own syncrepl session transitions to persist and a it starts a new parallel session towards another host, that session always has to start as a refresh. If that refresh serves entries to us, our handling of si_dirty is not consistent: - if the existing persist session serves some of these entries to us, we can "forget" to pass the others to a newly connected consumer - same if the refresh is abandoned and we start refreshing from a different provider that might be behind what we were being served (again our consumers could suffer) - if we restart, si_dirty is forgotten and our consumers suffer even worse We might need to be told (at the beginning of the refresh?) what the end state we're going for is, so we can keep si_dirty on until then. And somehow persist that knowledge in the DB... -- You are receiving this mail because: You are on the CC list for the issue.

1 18

[Issue 9717] New: The RADIUSOV overlay can be incorporated into OpenLDAP
by openldap-its＠openldap.org 25 Nov '25

25 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=9717 Issue ID: 9717 Summary: The RADIUSOV overlay can be incorporated into OpenLDAP Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: rdubner(a)symas.com Target Milestone: --- -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10363] New: Implement a target connection time-to-live in asyncmeta
by openldap-its＠openldap.org 25 Nov '25

25 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=10363 Issue ID: 10363 Summary: Implement a target connection time-to-live in asyncmeta Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- Implement a feature that limits the maximum time before a target connection is reset, even if it is not idle - conn-ttl. To avoid too many target connections timing out at once, a minimum reset interval per target should also be configurable. So, a configuration of: conn-ttl 5s 5s would mean connections have a 5 seconds time-to-live, but a connection should be reset no more frequently that once every 5 seconds per target. This feature was requested by a customer. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9731] New: startup messages still go to syslog when logfile-only is on
by openldap-its＠openldap.org 25 Nov '25

25 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=9731 Issue ID: 9731 Summary: startup messages still go to syslog when logfile-only is on Product: OpenLDAP Version: 2.6.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- When setting logfile-only on, slapd still logs its startup message to syslog: Oct 29 21:07:47 u18test slapd[18534]: @(#) $OpenLDAP: slapd 2.6.0 (Oct 29 2021 05:12:17) $#012#011openldap This is useful information to have consolidated into the specified logfile. Note that: 617c62a3.16f03fdb 0x7f9325ed67c0 slapd starting does make it to the logfile. However, it would be useful to have the build date and version in the specified logfile. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10380] New: file logger doesn't emit slapd startup/version info
by openldap-its＠openldap.org 25 Nov '25

25 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=10380 Issue ID: 10380 Summary: file logger doesn't emit slapd startup/version info Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- When using syslog, a startup message is emitted which is useful in many different contexts: - signals a slapd restart to the admin - shows the actual version used - if a crash happened just before, there is no "stopped" message, this is a hint to anyone looking that something was not right and the slapd is not the same process - people writing log processing scripts (incident response) know when it's necessary to reset their state, again as it's a new process Because of the above, it feels like a regression to me. I guess we can just emit this info on logfile config handlers? This means startups and logfile switches are still handled as they used to in syslog and log rotation doesn't emit anything (making it easy and safe to just concatenate files). Yes, slapd logs its PID in most formats so restarts can be detected that way, but that's considerably harder to search for. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10395] New: Support multiple readers on uncommitted changes
by openldap-its＠openldap.org 20 Nov '25

20 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=10395 Issue ID: 10395 Summary: Support multiple readers on uncommitted changes Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: renault.cle(a)gmail.com Target Milestone: --- Created attachment 1086 --> https://bugs.openldap.org/attachment.cgi?id=1086&action=edit A patch to support multiple readers on uncommitted changes Hello, The attached patch is not meant to be merged immediately into LMDB. Still, it demonstrates how I added a helpful feature to the key-value store: reading uncommitted changes from multiple transactions. I am conscious that the patch still requires some work and uses non-C99 features, i.e., atomics are C11, which could be a blocker for it to be merged upstream. I would also be delighted to merge these changes under a flag/define to ensure we don't impact other users with non-C99 stuff. The main feature we need at Meilisearch is to read uncommitted changes from multiple threads, compute parallel post-processing of different data structures [1], and speed up the search requests. We could have done the post-processing in a following transaction by opening multiple read transactions, but this would mean that the post-processed data structure would not include newly inserted or modified document IDs. Both data structures would be desync. Regarding the design choice, I decided to follow the same design as the nested write transactions: use the parent argument of the mdb_txn_begin [2], and allow the MDB_RDONLY flag, which was disallowed when the parent argument was non-NULL [3]. I find it clear enough that, by calling the mdb_txn_begin function with these arguments, you can call it multiple times (I need to update the doc) to obtain nested read-only transactions from the parent write transaction. ret = mdb_txn_begin(env, parent_txn, MDB_RDONLY, new_nested_rtxn); Note that this early proposal lacks security and error handling. The generated transactions are fake-read-only and actually write transactions that share the underlying parent allocations and data structures. This is unsafe and must be changed or reviewed carefully, but most importantly, we need to add read-only capabilities to these transactions to disallow writes. Using a Rust wrapper on top of LMDB, I wrapped the fake read-only transactions into ReadTxn, which disallows any writes at compile time. However, I haven't checked the conflict database creations or openings. The main issues I encountered were concurrent free of the main shared data structures when the different threads owning the transactions were dropping the transactions simultaneously. So, I decided to implement the equivalent of an ARC to free resources only when the last nested transaction was freed. I can share numbers about how this feature improves the post-processing by 4x-9x or from 1200s to 120s [1]. You can look at this PR, which I would be happy to merge once an improved version of this patch lands on LMDB upstream. I would be very happy if you could guide me a bit on how I could improve this patch to make it mergeable into LMDB. We want to contribute useful features like this to LMDB and not keep a deviant fork. LMDB works great; we are happy about it, and its performance is predictable. Have a lovely week, kero [1]: https://github.com/meilisearch/meilisearch/pull/5307 [2]: https://github.com/LMDB/lmdb/blob/14d6629bc8a9fe40d8a6bee1bf71c45afe7576b6/… [3]: https://github.com/LMDB/lmdb/blob/14d6629bc8a9fe40d8a6bee1bf71c45afe7576b6/… -- You are receiving this mail because: You are on the CC list for the issue.

1 8

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2025