openldap-bugs November 2024

openldap-bugs@openldap.org

1 participants
87 discussions

[Issue 10279] New: add debug notice also to client tools
by openldap-its＠openldap.org 22 May '25

22 May '25

https://bugs.openldap.org/show_bug.cgi?id=10279 Issue ID: 10279 Summary: add debug notice also to client tools Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: rossi.f(a)inwind.it Target Milestone: --- Created attachment 1040 --> https://bugs.openldap.org/attachment.cgi?id=1040&action=edit openldap-2.6.4-debug-notice.patch The command line -d option, when used for debugging, does nothing if openldap was not compiled byth --enable-debug option. For the server part there is a notice to the user regarding this, I propose to add the same also to client tools. Here is attached the simple patch. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10226] New: [PATCH] ldap.conf: some remarks and editorial fixes for this man page
by openldap-its＠openldap.org 22 May '25

22 May '25

https://bugs.openldap.org/show_bug.cgi?id=10226 Issue ID: 10226 Summary: [PATCH] ldap.conf: some remarks and editorial fixes for this man page Product: OpenLDAP Version: unspecified Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: bjarniig(a)vortex.is Target Milestone: --- Created attachment 1020 --> https://bugs.openldap.org/attachment.cgi?id=1020&action=edit Remarks and editotiral fixes for the manual ldap.conf.5 Version 2.6.8 is not named on the webpage when entering an issue. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10270] New: Issues with pcache when refresh/persistPcache used
by openldap-its＠openldap.org 22 May '25

22 May '25

https://bugs.openldap.org/show_bug.cgi?id=10270 Issue ID: 10270 Summary: Issues with pcache when refresh/persistPcache used Product: OpenLDAP Version: 2.5.18 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: --- Greetings, OpenLDAP-folk. We've been running with the pcache overlay in 2.5.18 with both query refresh and pcachePersist for a bit and have observed some oddities: 1.) Negative queries don't get refreshed 2.) Queries don't seem to be persisted These behaviors are all exhibited from the current git version as well - code/patches below for clarity of communication: Thanks! Andy commit c0b4fe92c8df746c0e6a777f93f1687135114eb9 Author: Andrew Elble <aweits(a)rit.edu> Date: Fri Oct 11 08:43:47 2024 -0400 negative cache entries are not loaded when pcachePersist is on diff --git a/servers/slapd/overlays/pcache.c b/servers/slapd/overlays/pcache.c index 9ef78fd6bf43..9fd72e6d7261 100644 --- a/servers/slapd/overlays/pcache.c +++ b/servers/slapd/overlays/pcache.c @@ -802,7 +802,11 @@ url2query( goto error; } - cq = add_query( op, qm, &query, qt, PC_POSITIVE, 0 ); + if (BER_BVISNULL( &uuid )) { + cq = add_query( op, qm, &query, qt, PC_NEGATIVE, 0 ); + } else { + cq = add_query( op, qm, &query, qt, PC_POSITIVE, 0 ); + } if ( cq != NULL ) { cq->expiry_time = expiry_time; cq->refresh_time = refresh_time; commit 8f7b50dfcec69fa01f8cf0a4b77f3dee8ef9f0f6 Author: Andrew Elble <aweits(a)rit.edu> Date: Fri Oct 11 08:38:36 2024 -0400 queries with ttr/x-refresh are not loaded when pcachePersist is on diff --git a/servers/slapd/overlays/pcache.c b/servers/slapd/overlays/pcache.c index 40c1f9673776..9ef78fd6bf43 100644 --- a/servers/slapd/overlays/pcache.c +++ b/servers/slapd/overlays/pcache.c @@ -749,7 +749,7 @@ url2query( } } - if ( got != GOT_ALL ) { + if ( (got & GOT_ALL) != GOT_ALL) { rc = 1; goto error; } commit c7e52c90192a43876d40b9776a58db951d27937c Author: Andrew Elble <aweits(a)rit.edu> Date: Fri Oct 11 08:37:13 2024 -0400 ttr was not being applied to negatively cached entries diff --git a/servers/slapd/overlays/pcache.c b/servers/slapd/overlays/pcache.c index 1d6e4ba4edcf..40c1f9673776 100644 --- a/servers/slapd/overlays/pcache.c +++ b/servers/slapd/overlays/pcache.c @@ -1580,6 +1580,8 @@ add_query( case PC_NEGATIVE: ttl = templ->negttl; + if ( templ->ttr ) + ttr = now + templ->ttr; break; case PC_SIZELIMIT: -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9934] New: slapd-config(5) should document how to store certificates for slapd usage
by openldap-its＠openldap.org 22 May '25

22 May '25

https://bugs.openldap.org/show_bug.cgi?id=9934 Issue ID: 9934 Summary: slapd-config(5) should document how to store certificates for slapd usage Product: OpenLDAP Version: 2.5.13 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Commit 7b41feed83b expanded the ability of cn=config to save the certificates used for TLS by slapd directly in the config database. However the documentation for the new parameters was never added to the slapd-config(5) man page. olcTLSCACertificate $ olcTLSCertificate $ olcTLSCertificateKey -- You are receiving this mail because: You are on the CC list for the issue.

1 13

[Issue 10163] New: Cleanup configure/test integration
by openldap-its＠openldap.org 06 May '25

06 May '25

https://bugs.openldap.org/show_bug.cgi?id=10163 Issue ID: 10163 Summary: Cleanup configure/test integration Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- The sed commandline configure uses to perform substitutions is getting unwieldy and may be exceeding platform limits on various systems. All of the BUILD_xxx substitutions for overlays are only used in tests/run.in. They could be completely removed, and instead each of the enabled overlays could be emitted into a separate file that just gets included by the test scripts. There's no need for them to be part of the sed invocation at all. There's also leftover BUILD_xxx cruft from backends that we've removed (e.g. back-shell BUILD_SHELL) that nothing else in the tree references any more. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9367] New: back-mdb: encryption support
by openldap-its＠openldap.org 06 May '25

06 May '25

https://bugs.openldap.org/show_bug.cgi?id=9367 Issue ID: 9367 Summary: back-mdb: encryption support Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Need to add encryption support to the back-mdb backend, depends on issue#9364 -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10258] New: test050 failure: connection_close race?
by openldap-its＠openldap.org 25 Mar '25

25 Mar '25

https://bugs.openldap.org/show_bug.cgi?id=10258 Issue ID: 10258 Summary: test050 failure: connection_close race? 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: --- Created attachment 1032 --> https://bugs.openldap.org/attachment.cgi?id=1032&action=edit tail of slapd log Running test050 repeatedly, the slapd managed to get itself into an apparent inconsistency in the connections structure. The logs suggest that there might be a race closing the connection. Unfortunately the sanitiser didn't initiate a core dump in this case. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

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

25 Mar '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 9

[Issue 10266] New: Adopt broader RFC4511 NoD interpretation on lloadd's client side
by openldap-its＠openldap.org 04 Mar '25

04 Mar '25

https://bugs.openldap.org/show_bug.cgi?id=10266 Issue ID: 10266 Summary: Adopt broader RFC4511 NoD interpretation on lloadd's client side Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Server side, lloadd has long implemented a broad interpretation of NoD unsolicited response handling: when the message is issued, no new requests are accepted on the session however the client and server are both free to keep the session open if there are any operations that have not resolved yet. The server is still expected to close the connection as soon as no operations are still pending. This seems to interoperate with known clients. Those that want to will close the session immediately, unaware of this possibility, those that also want to interpret RFC 4511 this way can choose to wait for existing operations to resolve. This ticket is to track the lloadd's implementation of the client side of this - when receiving a NoD message, we don't close the connection immediately+unconditionally either but are willing to wait. Related functionality: - if connection was a bind connection processing a multi-stage SASL bind, the bind should fail if/when the client attempts to progress it - clients assigned to this connection through coherence at least 'connection' are also marked closing -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10024] New: MDB_PREVSNAPSHOT broken
by openldap-its＠openldap.org 21 Feb '25

21 Feb '25

https://bugs.openldap.org/show_bug.cgi?id=10024 Issue ID: 10024 Summary: MDB_PREVSNAPSHOT broken Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: markus(a)objectbox.io Target Milestone: --- It seems that the patch #9496 had a negative side effect on MDB_PREVSNAPSHOT. In certain cases, when opening the DB using MDB_PREVSNAPSHOT, the previous (2nd latest) commit is not selected. Instead, reads show that the latest commit was selected voiding the effect of MDB_PREVSNAPSHOT. I observed this in our test cases a while back. Today, I was finally able to reproduce it and debug into it. When creating the transaction to read the data, I debugged into mdb_txn_renew0. Here, ti (MDB_txninfo; env->me_txns) was non-NULL. However, ti->mti_txnid was 0 (!) and thus txn->mt_txnid was set to 0. That's the reason for always selecting the first (index 0) meta page inside mdb_txn_renew0: meta = env->me_metas[txn->mt_txnid & 1]; This line occurs twice (once for read txn and once for write txn; it affects both txn types). Thus, the chances of MDB_PREVSNAPSHOT selecting the correct meta page is 50-50. It's only correct if the first meta page (index 0) is the older one. I believe that this is related to #9496 because the patch, that was provided there, removed the initialization of "env->me_txns->mti_txnid" in mdb_env_open2. This would explain why txn->mt_txnid inside mdb_txn_renew0 was set to 0. I can confirm that adding back the following two lines back in fixes MDB_PREVSNAPSHOT: if (env->me_txns) env->me_txns->mti_txnid = meta.mm_txnid; The said patch including the removal of these two lines was applied in the commit(s) "ITS#9496 fix mdb_env_open bug from #8704" (Howard Chu on 09.04.21). I hope this information is useful to find a suitable fix. Please let me know if you have questions. Also, I'd be happy to help confirming a potential fix with our test suite. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

← Newer
1
2
3
4
5
6
7
8
9
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2024