openldap-bugs December 2021

openldap-bugs@openldap.org

1 participants
127 discussions

[Bug 9244] New: API calls blocking after async connect
by openldap-its＠openldap.org 16 Feb '26

16 Feb '26

https://bugs.openldap.org/show_bug.cgi?id=9244 Bug ID: 9244 Summary: API calls blocking after async connect Product: OpenLDAP Version: 2.4.49 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- Created attachment 721 --> https://bugs.openldap.org/attachment.cgi?id=721&action=edit async connect test without TLS My understanding of LDAP_OPT_CONNECT_ASYNC is that the attached program should not block. If the connection does not establish fast enough, the bind call is supposed to return LDAP_X_CONNECTING. (At least that's how I understand it, based on the original behaviour (circa 2.4.23 up to 2.4.40) as well as the bind loop in back-meta. On the other hand, the man page does "Subsequent calls to library routines will poll for completion of the connect before performing further operations" which might be interpreted as meaning they would block...) In current releases it does block, as demonstrated by strace on Linux (latency added using 'tc qdisc'): [...] connect(3, {sa_family=AF_INET, sin_port=htons(389), sin_addr=inet_addr("192.168.1.204")}, 16) = -1 EINPROGRESS (Operation now in progress) write(3, "0\f\2\1\1`\7\2\1\3\4\0\200\0", 14) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=3, events=POLLOUT|POLLERR|POLLHUP}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}]) write(3, "0\f\2\1\1`\7\2\1\3\4\0\200\0", 14) = 14 poll([{fd=3, events=POLLIN|POLLPRI}], 1, -1) = 1 ([{fd=3, revents=POLLIN}]) read(3, "0\f\2\1\1a\7\n", 8) = 8 read(3, "\1\0\4\0\4\0", 6) = 6 write(2, "OK: ldap_simple_bind_returned 0 "..., 42OK: ldap_simple_bind_returned 0 (Success) ) = 42 [...] As discussed in IRC, I believe I bisected this down to commit ae6347bac, from bug 8022. The reasoning is sound, but ldap_int_open_connection does not actually return -2, only -1 or 0. The patch is simple enough, but I'm also looking at some later commits that were probably done to work around this, and might not be needed now (bug 8957, bug 8968, bug 8980). Also need to test all setups thoroughly (ldap, ldaps, STARTTLS, not to mention back-meta/asyncmeta). I also notice that LDAP_OPT_CONNECT_ASYNC is not effective unless LDAP_OPT_NETWORK_TIMEOUT is also set. It might be intentional, but the man page doesn't mention this specifically, and I don't see why it would be necessary... -- You are receiving this mail because: You are on the CC list for the bug.

1 16

[Issue 9513] New: Enhanced debug output
by openldap-its＠openldap.org 12 Feb '26

12 Feb '26

https://bugs.openldap.org/show_bug.cgi?id=9513 Issue ID: 9513 Summary: Enhanced debug output Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: enhancement Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- While debugging ITS#9479 I needed more information on which threads were doing what actions. Also, when looking for delays/hangs/race conditions, the 1-second granularity of the debug msg timestamp was inadequate. And also, some of the debug output for the Search operation was being done in separate Debug calls for a single line of output. This gets jumbled up pretty badly if other threads are printing output as well. New patch set will extend the debug timestamp to have fractional seconds too; it will use clock_gettime for nanosecond resolution if available, otherwise use gettimeofday for microsecond resolution. Also tweak the Search debug output to only use one Debug invocation per line of output. This is MR!279. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Bug 9225] New: back-mdb: Add support for PREPARE/2-phase commit
by openldap-its＠openldap.org 12 Feb '26

12 Feb '26

https://bugs.openldap.org/show_bug.cgi?id=9225 Bug ID: 9225 Summary: back-mdb: Add support for PREPARE/2-phase commit Product: OpenLDAP Version: 2.4.50 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Add support for PREPARE/2-phase commit in back-mdb -- You are receiving this mail because: You are on the CC list for the bug.

1 10

[Bug 9224] New: Add support for PREPARE/2-phase commit
by openldap-its＠openldap.org 12 Feb '26

12 Feb '26

https://bugs.openldap.org/show_bug.cgi?id=9224 Bug ID: 9224 Summary: Add support for PREPARE/2-phase commit Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- In LMDB, add support for PREPARE/2-phase commits -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Issue 9577] New: slapd -V should be deprecated
by openldap-its＠openldap.org 15 Dec '25

15 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=9577 Issue ID: 9577 Summary: slapd -V should be deprecated Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: smckinney(a)symas.com Target Milestone: --- Sometimes a user's (present one included) ignorance gets them in trouble unnecessarily. The -V option is an example... Normally, when one wants to determine the version of a process, they use -V, or perhaps -v. With slapd, the daemon actually continues to run, which can have negative consequences. The doc clearly states that -VV is probably what the user wants, but is counter-intutive. Who RTFM's before checking the version? -V print version info (-VV exit afterwards, -VVV print info about static overlays and backends) I propose we eliminate the option to allow slapd to continue running after displaying the version. Perhaps we eliminate the -V option entirely, or just make it work the same as -VV. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 9640] New: ACL privilege for MOD_INCREMENT
by openldap-its＠openldap.org 15 Dec '25

15 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=9640 Issue ID: 9640 Summary: ACL privilege for MOD_INCREMENT Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: michael(a)stroeder.com Target Milestone: --- I'm using LDAP write operations with MOD_INCREMENT with pre-read-control for uidNumber/gidNumber generation. I'd like to limit write access to an Integer attribute "nextID" to MOD_INCREMENT, ideally even restricting the de-/increment value. (Uniqueness is achieved with slapo-unique anyway but still I'd like to avoid users messing with this attribute). IMHO the ideal solution would be a new privilege "i". Example for limiting write access to increment by one and grant read access for using read control: access to attrs=nextID val=1 by group=... =ri Example for decrementing by two without read: access to attrs=nextID val=-2 by group=... =i -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9305] New: ldap_connect_to_host: Return code from getaddrinfo() discarded, troubleshooting difficult
by openldap-its＠openldap.org 15 Dec '25

15 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=9305 Issue ID: 9305 Summary: ldap_connect_to_host: Return code from getaddrinfo() discarded, troubleshooting difficult Product: OpenLDAP Version: 2.4.46 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: minfrin(a)sharp.fm Target Milestone: --- When the ldap_connect_to_host() function sees a failure from getaddrinfo(), the meaningless return code -1 is returned. This makes troubleshooting difficult on a webserver, where the low level printf debugging is not practical. (gdb) step ldap_connect_to_host (ld=ld@entry=0x7fffc4002e10, sb=0x7fffc400b240, proto=1, srv=srv@entry=0x7fffc400b2f0, async=async@entry=0) at os-ip.c:543 543 { (gdb) next 546 ber_socket_t s = AC_SOCKET_INVALID; (gdb) 562 if ( srv->lud_host == NULL || *srv->lud_host == 0 ) { (gdb) 568 port = srv->lud_port; (gdb) 570 if( !port ) { (gdb) 578 switch(proto) { (gdb) 580 osip_debug( ld, (gdb) warning: Source file is more recent than executable. 71 return __builtin___memset_chk (__dest, __ch, __len, __bos0 (__dest)); (gdb) 598 hints.ai_flags = AI_ADDRCONFIG; (gdb) 601 hints.ai_socktype = socktype; (gdb) 602 snprintf(serv, sizeof serv, "%d", port ); (gdb) 605 LDAP_MUTEX_LOCK(&ldap_int_resolv_mutex); (gdb) 607 err = getaddrinfo( host, serv, &hints, &res ); (gdb) 609 LDAP_MUTEX_UNLOCK(&ldap_int_resolv_mutex); (gdb) 611 if ( err != 0 ) { (gdb) 612 osip_debug(ld, "ldap_connect_to_host: getaddrinfo failed: %s\n", (gdb) print host $3 = <optimized out> (gdb) print serv $4 = "636\000\000\000" (gdb) next 614 return -1; (gdb) The ldap_connect_to_host() function needs to return proper error codes. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9584] New: cn=config replication ops/refresh should pause server
by openldap-its＠openldap.org 08 Dec '25

08 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=9584 Issue ID: 9584 Summary: cn=config replication ops/refresh should pause server Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Looking into this crash: https://git.openldap.org/openldap/openldap/-/jobs/7286 The thread in question is running a plain syncrepl refresh while another thread seems to have done the same. This thread fetched the entryUUID attribute of the 'cn=config' entry as 'a' and in the meantime, that entry has been rewritten, with 'a' presumably cleaned up and returned to the pool, so addressing a->a_nvals[0] is a NULL-dereference now. This might or might not be related to the fix in ITS#8102. -- You are receiving this mail because: You are on the CC list for the issue.

1 19

[Issue 9739] New: Undefined reference to ber_sockbuf_io_udp in 2.6.0
by openldap-its＠openldap.org 04 Dec '25

04 Dec '25

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.

1 17

[Issue 9652] New: Add "tee" capability to load balancer
by openldap-its＠openldap.org 04 Dec '25

04 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=9652 Issue ID: 9652 Summary: Add "tee" capability to load balancer Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: mhardin(a)symas.com Target Milestone: --- This is a request for an enhancement that would add a "tee" or "fan-out" capability to load balancer, where received operations are sent to two or more destinations simultaneously. The primary goal or the enhancement is to make it possible to keep multiple independent and likely dissimilar directory systems in lock-step with each other over hours, days, or possibly even weeks. The enhancement would not necessarily need to include a mechanism for converging the target systems should they become out of sync. This is not intended to be a replication solution, rather it is viewed more as a "copy" solution intended to be used for specific short-term tasks that need multiple directory systems to be exactly synchronized but where replication is not desirable or even possible. At least two uses come to mind: 1. Test harnesses, evaluating side-by-side operation of separate directory systems over time 2. Directory system transition validation harnesses 3. (maybe) Part of a test harness to record or replay LDAP workloads * Other uses? -- You are receiving this mail because: You are on the CC list for the issue.

1 8

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs December 2021