openldap-bugs January 2024

openldap-bugs@openldap.org

1 participants
191 discussions

[Issue 9729] New: Allow setting multiprovider before adding syncrepl stanzas
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=9729 Issue ID: 9729 Summary: Allow setting multiprovider before adding syncrepl stanzas 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: --- It should be possible to set multiprovider first, avoiding the window of the DB being read-only while performing an online upgrade of a single provider to an MPR set up and generally simplifying configuration. Instead, the only requirement should be that serverID has been explicitly set (hopefully != 0). -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9642] New: Adding a task to runqueue doesn't wake the main thread
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=9642 Issue ID: 9642 Summary: Adding a task to runqueue doesn't wake the main thread 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: --- If a connection adds a new syncrepl stanza, that is not started until the main thread comes around to doing it. However if that thread is currently stuck in SLAP_EVENT_WAIT() and nothing else happens (like an unbind over the connection that modified the config), the task is never started. This can take a long time. No idea yet how to wake it up with/from ldap_pvt_runqueue_insert() given that sits within libldap and not really something that should be calling slap_wake_listener(). -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10113] New: make connection debug output more uniform
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10113 Issue ID: 10113 Summary: make connection debug output more uniform Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: enhancement Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Here's what some of the debug output looks like currently: 6529a16e.07884bd6 0x7f7a68dff640 daemon: epoll: listen=8 active_threads=0 tvp=NULL 6529a16e.0788551d 0x7f7a68dff640 daemon: activity on 1 descriptor 6529a16e.07885e63 0x7f7a68dff640 daemon: activity on:6529a16e.07886607 0x7f7a68dff640 6529a16e.07886f93 0x7f7a68dff640 daemon: epoll: listen=7 active_threads=0 tvp=NULL 6529a16e.07887737 0x7f7a68dff640 daemon: epoll: listen=8 active_threads=0 tvp=NULL 6529a16e.0788987f 0x7f7a63fff640 tls_write: want=239 error=Broken pipe 6529a16e.0788a369 0x7f7a63fff640 TLS trace: SSL_accept:SSLv3/TLS write session ticket 6529a16e.0788d027 0x7f7a63fff640 connection_read(12): unable to get TLS client DN, error=49 id=1000 6529a16e.0788e6cc 0x7f7a63fff640 conn=1000 fd=12 TLS established tls_ssf=128 ssf=128 tls_proto=TLSv1.3 tls_cipher=TLS_AES_128_GCM_SHA256 6529a16e.078974a9 0x7f7a68dff640 daemon: activity on 2 descriptors 6529a16e.07898cf1 0x7f7a68dff640 daemon: activity on:6529a16e.07899409 0x7f7a68dff640 12r6529a16e.07899ef3 0x7f7a68dff640 6529a16e.0789a839 0x7f7a68dff640 daemon: read active on 12 6529a16e.0789c1de 0x7f7a68dff640 daemon: epoll: listen=7 active_threads=0 tvp=NULL 6529a16e.0789cd0e 0x7f7a68dff640 daemon: epoll: listen=8 active_threads=0 tvp=NULL 6529a16e.0789d9e0 0x7f7a68dff640 daemon: activity on 1 descriptor 6529a16e.0789e36d 0x7f7a68dff640 daemon: activity on:6529a16e.0789eaca 0x7f7a68dff640 6529a16e.0789f26e 0x7f7a68dff640 daemon: epoll: listen=7 active_threads=0 tvp=NULL 6529a16e.0789fd9d 0x7f7a68dff640 daemon: epoll: listen=8 active_threads=0 tvp=NULL 6529a16e.078a0a70 0x7f7a63fff640 connection_get(12) 6529a16e.078a1ea0 0x7f7a63fff640 connection_get(12): got connid=1000 6529a16e.078a25b8 0x7f7a63fff640 connection_read(12): checking for input on id=1000 6529a16e.078a32d0 0x7f7a63fff640 ber_get_next 6529a16e.078a6a78 0x7f7a63fff640 tls_read: want=5, got=5 6529a16e.078a7d91 0x7f7a63fff640 0000: 30 05 02 01 02 0.... 6529a16e.078aa0c2 0x7f7a63fff640 tls_write: want=24 error=Broken pipe 6529a16e.078aa820 0x7f7a63fff640 ldap_read: want=8 error=Broken pipe 6529a16e.078ab121 0x7f7a63fff640 ber_get_next on fd 12 failed errno=32 (Broken pipe) 6529a16e.078aba67 0x7f7a63fff640 connection_read(12): input error=-2 id=1000, closing. 6529a16e.078ac3ae 0x7f7a63fff640 connection_closing: readying conn=1000 sd=12 for close 6529a16e.078ad0c6 0x7f7a63fff640 connection_close: conn=1000 sd=12 6529a16e.078aed26 0x7f7a63fff640 daemon: removing 12 6529a16e.078b2ffd 0x7f7a68dff640 daemon: activity on 1 descriptor 6529a16e.078b4616 0x7f7a63fff640 conn=1000 fd=12 closed (connection lost) Most operations will be logged with "conn=xxxx fd=yy blah blah" but things like connection_close etc log "blah blah conn=xxxx sd=yy" instead. It would be nice if they all uniformly started with "conn=xxxx fd=yy blah blah" This is a trivial change. Could be a good first-time commit for a new dev. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9577] New: slapd -V should be deprecated
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

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 9

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

07 Aug '26

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 8

[Issue 9367] New: back-mdb: encryption support
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

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 12

[Issue 9796] New: Deprecate GnuTLS support
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=9796 Issue ID: 9796 Summary: Deprecate GnuTLS support Product: OpenLDAP Version: 2.6.1 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Support for GnuTLS was added specifically for the Debian (and thus Ubuntu) due to the license objections at the time that the Debian project had for the OpenSSL license. Since that time, Debian has reclassified OpenSSL as a core library and the OpenSSL project has resolved the original complaint by licensing OpenSSL 3 and later under the Apache License v2. Thus there is no longer a reason to maintain support for GnuTLS and given the long standing concerns over the security and quality of the GnuTLS bridge in addition to the extra cost of maintaining that code, it should be marked as deprecated and removed in a future release. -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 9493] New: slapo-accesslog handling of deletion of multi-valued configuration attributes removes wrong value from list
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=9493 Issue ID: 9493 Summary: slapo-accesslog handling of deletion of multi-valued configuration attributes removes wrong value from list Product: OpenLDAP Version: 2.4.57 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: svella(a)technologist.com Target Milestone: --- I observed this in the debugger while working on a small feature addition to slapo-accesslog. log_cf_gen(), when handling the initial configuration of oldAccessLogOldAttr (accesslog.c:989), linked list li_oldattrs is being built by inserting each value in order at the head of the list, resulting in the list being in reverse order. But when handling LDAP_MOD_DELETE of same attribute (accesslog.c:989), it is using the index of the removed value (valx) to find and removed the entry in the linked list, but it's counting from the head of li_oldattrs and not the tail, resulting in the wrong item being removed from the list unless counting from the head or the tail happens find the same item. (Line numbers refer to commit 6c469f07935e351e349bf38fc223dab704c51a76) Handling of oldAccessLogBase appears to have the same problem, and a cursory glance through the source of other overlays reveals a similar pattern, and I'm guessing the same problem. -- You are receiving this mail because: You are on the CC list for the issue.

1 22

[Issue 9556] New: slapd-config should return invalidAttributeSyntax if parsing schema description fails
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=9556 Issue ID: 9556 Summary: slapd-config should return invalidAttributeSyntax if parsing schema description fails Product: OpenLDAP Version: 2.5.4 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 currently testing error handling and interacting with LDAP clients (e.g. my web2ldap). Sending an invalid attribute type description results in an error (as expected) returned by slapd-config: RESULT tag=103 err=80 qtime=0.000032 etime=0.001271 text=olcAttributeTypes: Unexpected token before SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) But result code other(80) seems not very useful. It's too unspecific to decide on specific error handling. It would be much more useful if slapd-config returns invalidAttributeSyntax(21) in this case. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9959] New: Expose the lloadd connection endpoints in cn=monitor for identification
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=9959 Issue ID: 9959 Summary: Expose the lloadd connection endpoints in cn=monitor for identification 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: --- ITS#9600 introduces a way to operate on lloadd connections, however it is impossible to identify which socket this actually corresponds to. While we're at it, might also expose the current bound identity there. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs January 2024