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.
https://bugs.openldap.org/show_bug.cgi?id=10265
Issue ID: 10265
Summary: Make it possible to change olcBkLloadListen at runtime
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: ---
Currently, olcBkLloadListen changes only take effect on lloadd startup:
- an added olcBkLloadListen should come online at the end of the modify
operation
- at the end of the modify operation a removed olcBkLloadListen will stop
listening on the sockets associated with it, clients that connected over these
are marked CLOSING
- to facilitate replacing a value where URIs resolved sockets overlap,
olcBkLloadListen should become a MAY in olcBkLloadConfig objectclass
Lloadd's startup was modelled upon slapd's, but the requirements have changed
considerably when it was turned into a module. Sockets are acquired at module
configuration time, which is much later than standalone/slapd's own startup and
so the way the URLs are handled also needs to be reworked. This will resolve
other related issues.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9186
Bug ID: 9186
Summary: RFE: More metrics in cn=monitor
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: michael(a)stroeder.com
Target Milestone: ---
Currently I'm grepping metrics from syslog with mtail:
https://gitlab.com/ae-dir/ansible-ae-dir-server/-/blob/master/templates/mta…
With a new binary logging this is not possible anymore.
Thus it would be nice if cn=monitor provides more metrics.
1. Overall connection count per listener starting at 0 when started. This would
be a simple counter added to:
entries cn=Listener 0,cn=Listeners,cn=Monitor
2. Counter for the various "deferring" messages separated by the reason for
deferring.
3. Counters for all possible result codes. In my mtail program I also label it
with the result type.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=7249
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|TEST |FIXED
--- Comment #23 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
RE26:
• d66062dc
by OndÅ™ej KuznÃk at 2025-02-19T18:37:48+00:00
ITS#7249 Let backend_attribute know who's calling it
• 5c734d2b
by OndÅ™ej KuznÃk at 2025-02-19T18:37:53+00:00
ITS#7249 Disallow memberof-addcheck when memberof is global
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=7080
--- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
RE26 (2.6.10):
• 8d19c205
by OndÅ™ej KuznÃk at 2025-02-19T18:06:29+00:00
ITS#7080 Do not munge path twice
• f328965d
by OndÅ™ej KuznÃk at 2025-02-19T18:06:33+00:00
ITS#7080 Implement pre/postread for modrdn
• c667f2ea
by OndÅ™ej KuznÃk at 2025-02-19T18:15:58+00:00
ITS#7080 Do not reuse back-ldif's stack for controls
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=7249
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|IN_PROGRESS |RESOLVED
Resolution|--- |TEST
--- Comment #22 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
head:
• 993f488e
by OndÅ™ej KuznÃk at 2025-02-19T17:29:04+00:00
ITS#7249 Let backend_attribute know who's calling it
• f2cba910
by OndÅ™ej KuznÃk at 2025-02-19T17:29:04+00:00
ITS#7249 Disallow memberof-addcheck when memberof is global
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10296
Issue ID: 10296
Summary: Force a Mac OS full flush
Product: LMDB
Version: unspecified
Hardware: All
OS: Mac OS
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 1045
--> https://bugs.openldap.org/attachment.cgi?id=1045&action=edit
Use a F_FULLFSYNC fcntl when committing on Mac OS
Hello Howard and Happy New Year,
As discussed in this issue [1], the LMDB durability is incorrect when
committing. I propose the following patch that uses fcntl with the F_FULLFSYNC
flag. The fcntl documentation is on this page [2].
Note that I kept the calls to msync/fsync for simplicity and because they don't
cost much but feel free to skip them on Mac OS.
Have a nice day,
kero
[1]: https://github.com/cberner/redb/pull/928#issuecomment-2567032808
[2]:
https://developer.apple.com/library/archive/documentation/System/Conceptual…
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10160
Issue ID: 10160
Summary: Add negset and negurl for slapo-constraint
Product: OpenLDAP
Version: 2.6.6
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: manu(a)netbsd.org
Target Milestone: ---
Created attachment 1003
--> https://bugs.openldap.org/attachment.cgi?id=1003&action=edit
Add negset and negurl for slapo-constraint
Add negset and negurl constraints for slapo-constraint. THe two new types are
logical not of set and url. They will fire a constraint violation if the set or
LDAP URL query is non empty.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=7080
--- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
• 86d23423
by OndÅ™ej KuznÃk at 2024-12-16T17:01:26+00:00
ITS#7080 Do not munge path twice
• e5826622
by OndÅ™ej KuznÃk at 2024-12-16T17:01:26+00:00
ITS#7080 Implement pre/postread for modrdn
• 70d8e22d
by OndÅ™ej KuznÃk at 2024-12-16T17:01:26+00:00
ITS#7080 Do not reuse back-ldif's stack for controls
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10294
Issue ID: 10294
Summary: Overlay seems to load before schema in folder
configuration mode
Product: OpenLDAP
Version: 2.6.8
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: pduvax(a)gmail.com
Target Milestone: ---
In the folder configuration (vs slapd.conf file), the modules seem to be loaded
before schema folders files.
This makes troubles with memberOf attributeType which is created by the dynlist
overlay if missing (cf. the base function "dynlist_initialize" which starts by
doing this). As the schema files are not yet loaded, it creates systematically
the attributes which then prohibits the load of msuser.ldif schema without
raising the error "Duplicate attributeType".
I found a workaround by naming the entry of the dynlist overlay olcModuleList
cn=z-module{X} while z is alphanumerically after cn=schema. But as it is
hazardous, I think that the best way is to load modules after the schema by the
code.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10306
Issue ID: 10306
Summary: epoll, kqueue etc. are not used when cross compiling
Product: OpenLDAP
Version: 2.6.9
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: hi(a)alyssa.is
Target Milestone: ---
OpenLDAP's build system relies on running test programs to see whether epoll or
kqueue are available, after checking the headers are available. When cross
compiling, test programs can't be run, and even if they could, they wouldn't
produce useful results because they'd be testing the build machine. Running
test programs like this isn't even a great idea for native builds, because the
package is still quite likely to end up running on a different machine than it
was built for — think about distro packages.
This means that cross-compiled OpenLDAP ends up using select, even though it
could almost certainly use epoll or kqueue.
The best thing to do for this sort of thing is to check at runtime whether the
epoll/kqueue/whatever is available, and fall back if not, but this would
probably be hard to implement in OpenLDAP. Other, easier, things that could be
done to improve the situation would be:
• Assume that epoll/kqueue are available if the headers are. It's very
unlikely nowadays that a system with the headers won't actually have the API
available.
• If the AC_RUN_IFELSE checks are staying, make sure that they're all
overridabel with configure flags or at least AC_CACHE_CHECK.
There are also uses of AC_RUN_IFELSE for pthreads, which presumably have the
same problem.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10308
Issue ID: 10308
Summary: Implement cn=monitor for back-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: ---
Currently back-asyncmeta has no cn=monitor capabilities. It will be useful to
implement some, specifically to monitor targets and target connection states.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10139
OndÅ™ej KuznÃk <ondra(a)mistotebe.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.openldap.org/s
| |how_bug.cgi?id=10307
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10056
Issue ID: 10056
Summary: test069-delta-multiprovider-starttls failures on
static builds
Product: OpenLDAP
Version: 2.6.4
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: kaction(a)disroot.org
Target Milestone: ---
Hello.
I am getting following test error when trying to build `openldap` statically:
```
[nix-shell:/tmp/openldap-static/openldap-2.6.4/tests]$ ./run
test069-delta-multiprovider-starttls
Cleaning up test run directory leftover from previous run.
Running ./scripts/test069-delta-multiprovider-starttls for mdb...
running defines.sh
Initializing server configurations...
Starting server 1 on TCP/IP port 9011...
Using ldapsearch to check that server 1 is running...
Waiting 5 seconds for slapd to start...
Using ldapadd for context on server 1...
Starting server 2 on TCP/IP port 9012...
Using ldapsearch to check that server 2 is running...
Waiting 5 seconds for slapd to start...
Using ldapadd to populate server 1...
Waiting 7 seconds for syncrepl to receive changes...
Using ldapsearch to read all the entries from server 1...
Using ldapsearch to read all the entries from server 2...
Comparing retrieved entries from server 1 and server 2...
Using ldapadd to populate server 2...
Using ldapsearch to read all the entries from server 1...
Using ldapsearch to read all the entries from server 2...
Comparing retrieved entries from server 1 and server 2...
Breaking replication between server 1 and 2...
Using ldapmodify to force conflicts between server 1 and 2...
Restoring replication between server 1 and 2...
Waiting 7 seconds for syncrepl to receive changes...
Using ldapsearch to read all the entries from server 1...
Using ldapsearch to read all the entries from server 2...
Comparing retrieved entries from server 1 and server 2...
test failed - server 1 and server 2 databases differ (561)
```
I added line number (561) into error message to pinpoint it more precisely.
And here is difference between databases:
```
--- /tmp/openldap-static/openldap-2.6.4/tests/testrun/server1.flt
2023-05-23 22:53:51.000965129 -0400
+++ /tmp/openldap-static/openldap-2.6.4/tests/testrun/server2.flt
2023-05-23 22:53:51.005965136 -0400
@@ -289,13 +289,10 @@
userPassword:: amFq
dn: cn=James A Jones 2,ou=Alumni Association,ou=People,dc=example,dc=com
-carLicense: 123-XYZ
cn: James A Jones 2
cn: James Jones
cn: Jim Jones
-description: Amazing
description: Bizarre
-description: Mindboggling
description: Stupendous
employeeNumber: 64
employeeType: deadwood
@@ -307,7 +304,7 @@
pager: +1 313 555 3923
postalAddress: Alumni Association $ 111 Maple St $ Anytown, MI 48109
seeAlso: cn=All Staff,ou=Groups,dc=example,dc=com
-sn: Surname
+sn: Jones
telephoneNumber: +1 313 555 0895
title: Mad Cow Researcher, UM Alumni Association
uid: jaj
```
Suggestions on what more information I can provide are welcome. You can also
try to build `pkgsStatic.openldap` in this nixpkgs
[commit](f9e32f61282275eb5fa9064e08bbd0a92d1187de)
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10149
Issue ID: 10149
Summary: [PATCH] Allow certificates and keys to be read from
URIs.
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: minfrin(a)sharp.fm
Target Milestone: ---
Add the LDAP_OPT_X_TLS_URIS and LDAP_OPT_X_TLS_CACERTURIS
options to allow certificates and keys to be set using OpenSSL
provider URIs.
The attached patch file is derived from OpenLDAP Software. All of the
modifications to OpenLDAP Software represented in the following patch(es) were
developed by Graham Leggett minfrin(a)sharp.fm. I have not assigned rights and/or
interest in this work to any party.
The attached modifications to OpenLDAP Software are subject to the following
notice:
Copyright 2023 Graham Leggett
Redistribution and use in source and binary forms, with or without
modification, are permitted only as authorized by the OpenLDAP Public License.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10300
Issue ID: 10300
Summary: Add detailed instructions for MRs to "Guidelines for
Contributing" page
Product: website
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: website
Assignee: bugs(a)openldap.org
Reporter: smckinney(a)symas.com
Target Milestone: ---
The current page covers submitting patches but doesn't adequately cover
creating merge requests. This provides a barrier for new developers.
In addition to clarifying when a change should be submitted with a patch or
merge request, it could provide a set of steps including creating a fork,
branch, squash, fixup, naming conventions and other info that would be lost on
a new contributor.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9245
Bug ID: 9245
Summary: devel/programming needs rewrite
Product: website
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: website
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
The information on the devel/programming web page is at least a decade out of
date and needs a complete overhaul.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=10298
Issue ID: 10298
Summary: cannot find DN in memberOf attribute when dynlist
overlay contains multiple memberOf definitions
Product: OpenLDAP
Version: 2.5.13
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: jan.pekar(a)imatic.cz
Target Milestone: ---
I'm using dynlist to define multiple static objectClasses (static-oc) to be
searched for member attributes and added to memberOf attribute.
My configuration is in cn=config, so I defined it using multiple olcDlAttrSet
attributes
groupOfURLs memberURL member+memberOf@groupOfMembers*
groupOfURLs memberURL member+memberOf@groupOfNames*
I noticed, that memberOf attribute contains users from both groups
(groupOfMembers and groupOfNames) but I can use search operation to only first
defined configuration (in above example groupOfMembers) and user membership
from groupOfNames groups is not found.
Maybe it must be defined in one line but I was not able to find proper syntax.
Maybe attribute must be mapped somehow but when it works for first definition,
should be working for next one so it is bug?
Thank you
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8988
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|INVALID |---
Status|VERIFIED |CONFIRMED
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8988
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|slapd |liblmdb
Version|2.4.47 |0.9.33
Assignee|bugs(a)openldap.org |hyc(a)openldap.org
Target Milestone|--- |0.9.34
Product|OpenLDAP |LMDB
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=7249
OndÅ™ej KuznÃk <ondra(a)mistotebe.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Status|UNCONFIRMED |IN_PROGRESS
Assignee|bugs(a)openldap.org |ondra(a)mistotebe.net
--- Comment #21 from OndÅ™ej KuznÃk <ondra(a)mistotebe.net> ---
https://git.openldap.org/openldap/openldap/-/merge_requests/742
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10084
Issue ID: 10084
Summary: Move away from DIGEST-MD5 as a default in the test
suite
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: test suite
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
cyrus-sasl seem on the verge or removing the DIGEST-MD5 mechanism from 2.2
onwards. As such we should update our defaults in a couple of our test scripts
for master/2.7 at least. Are SCRAM mechanisms the go-to these days?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9739
Issue ID: 9739
Summary: Undefined reference to ber_sockbuf_io_udp in 2.6.0
Product: OpenLDAP
Version: 2.6.0
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: simon.pichugin(a)gmail.com
Target Milestone: ---
While I was trying to build OpenLDAP 2.6 on Fedora Rawhide I've got the error
message:
/usr/bin/ld: ./.libs/libldap.so: undefined reference to
`ber_sockbuf_io_udp'
I've checked commits from https://bugs.openldap.org/show_bug.cgi?id=9673 and
found that 'ber_sockbuf_io_udp' was not added to
https://git.openldap.org/openldap/openldap/-/blob/master/libraries/liblber/…
I've asked on the project's mailing list and got a reply:
"That symbol only exists if OpenLDAP is built with LDAP_CONNECTIONLESS
defined, which is not a supported feature. Feel free to file a bug report
at https://bugs.openldap.org/"
https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/…
Hence, creating the bug.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10295
Issue ID: 10295
Summary: To compare strings in Java
Product: JLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: JLDAP
Assignee: bugs(a)openldap.org
Reporter: chetansinha35(a)gmail.com
Target Milestone: ---
Created attachment 1044
--> https://bugs.openldap.org/attachment.cgi?id=1044&action=edithttps://docs.vultr.com/java/java/examples/java/examples/reverse-a-number
Java Program to Reversing a number in Java is a common task achieved using
loops and arithmetic operations. By repeatedly extracting the last digit of the
number with the modulus operator (%) and constructing the reversed number using
multiplication and addition, the process is efficient. For example, a while
loop can be used to iterate until the number becomes zero, applying reversed =
reversed * 10 + number % 10. This logic makes reversing numbers simple and
highlights Java's flexibility in handling number manipulation tasks.
--
You are receiving this mail because:
You are on the CC list for the issue.