openldap-bugs May 2022

openldap-bugs@openldap.org

1 participants
153 discussions

[Issue 9846] New: Provide ppm v2.2
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9846 Issue ID: 9846 Summary: Provide ppm v2.2 Product: OpenLDAP Version: 2.6.2 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: david.coutadeur(a)gmail.com Target Milestone: --- Provide the new release of ppm: v2.2: - implement a maximum number of characters for each class #18 - upgrade documentation for new olcPPolicyCheckModule in OpenLDAP 2.6 #30 - Make one unique code of development for 2.5 and 2.6 OpenLDAP versions #35 - fix segmentation fault in ppm_test #36 - various minor fixes and optimizations See: https://github.com/ltb-project/ppm/milestone/5 I am going to propose a MR soon. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 9856] New: Lloadd doesn't tag Notice of Disconnection responseName
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9856 Issue ID: 9856 Summary: Lloadd doesn't tag Notice of Disconnection responseName 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: --- The responseName field in Notice of Disconnection is being tagged as a generic octet string, where RFC4511 marks it with "responseValue [11] OCTET STRING OPTIONAL". Fix is coming. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9855] New: Implement a module to enable case-insensitive Boolean values
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9855 Issue ID: 9855 Summary: Implement a module to enable case-insensitive Boolean values Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- The module, when loaded from slapd.conf, will allow for values such as true, false and True, False, to be accepted by the server -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9850] New: slapd-watcher ignores sids when only 1 server is specified
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9850 Issue ID: 9850 Summary: slapd-watcher ignores sids when only 1 server is specified Product: OpenLDAP Version: 2.5.12 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- When only 1 URL is provided, it always uses only a contextCSN with sid=0. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9840] New: Fix parallel build failures
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9840 Issue ID: 9840 Summary: Fix parallel build failures Product: OpenLDAP Version: 2.5.9 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: yi.zhao(a)windriver.com Target Milestone: --- Created attachment 899 --> https://bugs.openldap.org/attachment.cgi?id=899&action=edit 0001-ldif-filter-fix-parallel-build-failure.patch I found there are two parallel build errors for ldif-filter and libraries: ldif-filter: ld: cannot find slapd-common.o: No such file or directory libraries: ../../build/shtool mkdir -p TOPDIR/tmp-glibc/work/cortexa15t2hf-neon-wrs-linux-gnueabi/openldap/2.5.9-r0/image/usr/lib mkdir: cannot create directory 'TOPDIR/tmp-glibc/work/cortexa15t2hf-neon-wrs-linux-gnueabi/openldap/2.5.9-r0/image/usr/lib': File exists make[1]: *** [Makefile:288: install-local] Error 1 I have attached 2 patches to fix these issues. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9824] New: getting/setting LDAP_OPT_X_SASL_ options require call to ldap_initialize
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9824 Issue ID: 9824 Summary: getting/setting LDAP_OPT_X_SASL_ options require call to ldap_initialize Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: jay.hendren(a)colorado.edu Target Milestone: --- Originally filed against python-ldap: https://github.com/python-ldap/python-ldap/issues/468 Per "man 3 ldap_get_option", some options can be set globally while others require an initialized LDAP struct: > These routines provide access to options stored either in a LDAP handle or as global options, where applicable. However, "where applicable" doesn't seem to have any further clarification. In particular, getting or setting any of the "LDAP_OPT_X_SASL_" options appears to require an initialized LDAP struct, as noted in the bug report against python-ldap, whereas most other options do not appear to share this requirement. I cannot find this fact documented anywhere. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9841] New: Build failure on musl due to conflicting declarations of ber_calloc
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9841 Issue ID: 9841 Summary: Build failure on musl due to conflicting declarations of ber_calloc Product: OpenLDAP Version: 2.5.11 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: helmut(a)subdivi.de Target Milestone: --- This is a forward of a Debian bug at https://bugs.debian.org/1008951 and a Gentoo bug at https://bugs.gentoo.org/546556. In essence, openldap #defines calloc ber_calloc and then #includes some system headers, which happen to #include <sched.h>. musl's <sched.h> happens to delcare calloc when _GNU_SOURCE is #defined. Since this is the case, musl's declaration is diverted to ber_calloc and since one parameter has a subtly different type, the declarations cause a conflict. I think this is actually two bugs. 1. musl should not declare calloc in <sched.h>. Doing so also breaks libgccjit (citation needed). 2. openldap should not #define calloc before #including system headers. Fixing either fixes the build failure. I think we should fix both. The openldap side can be fixed by reordering the #define and the relevant #include. You can find a working patch in the Debian bug above at https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1008951;filename=mu…. Does this look acceptable for inclusion into openldap? -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9847] New: kqueue problem with OpenBSD
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9847 Issue ID: 9847 Summary: kqueue problem with OpenBSD Product: OpenLDAP Version: 2.6.2 Hardware: All OS: Other Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: stu(a)spacehopper.org Target Milestone: --- The kqueue support added to slapd for 2.5 isn't working correctly on OpenBSD. If slapd runs as a daemon, errors like these are seen: slap_client_connect: URI=ldaps://XXX Warning, ldap_start_tls failed (1) mdb_opinfo_get: err Invalid argument(22) However if slapd is run in the foreground with -d, things are ok. They are also OK if kqueue is disabled (by neutering the autoconf check). I've tested 2.5.4, 2.5.9 and 2.6.2. Here are some log excerpts: 17:23:44.692: slapd starting 17:23:44.692: daemon: added 3r listener=0x0 17:23:44.692: daemon: added 6r listener=0x100263797200 17:23:44.692: daemon: added 7r listener=0x100263785400 17:23:44.692: daemon: kqueue: listen=6 active_threads=0 tvp=zero 17:23:44.692: daemon: kqueue: listen=7 active_threads=0 tvp=zero 17:23:44.692: daemon: activity on 1 descriptor 17:23:44.692: daemon: activity on: 17:23:44.692: 17:23:44.692: daemon: kqueue: listen=6 active_threads=0 tvp=zero 17:23:44.692: daemon: kqueue: listen=7 active_threads=0 tvp=zero 17:23:44.692: >>> dnNormalize: <cn=Consumer 101> 17:23:44.692: <<< dnNormalize: <cn=consumer 101> 17:23:44.692: =>do_syncrepl rid=101 17:23:44.763: slap_client_connect: URI=ldaps://XXXXXXXXXXXXXXX Warning, ldap_start_tls failed (1) 17:23:44.781: => mdb_entry_get: ndn: "dc=XXXXXXX,dc=XXX" 17:23:44.782: => mdb_entry_get: oc: "(null)", at: "contextCSN" 17:23:44.782: mdb_opinfo_get: err Invalid argument(22) 17:23:44.782: =>do_syncrep2 rid=101 17:23:44.782: daemon: added 9r listener=0x0 17:23:44.783: daemon: activity on 1 descriptor 17:23:44.783: daemon: activity on: 17:23:44.783: 17:23:44.783: daemon: kqueue: listen=6 active_threads=0 tvp=NULL 17:23:44.783: daemon: kqueue: listen=7 active_threads=0 tvp=NULL 17:23:44.800: daemon: activity on 1 descriptor 17:23:44.800: daemon: activity on: 17:23:44.800: 9r 17:23:44.800: 17:23:44.800: daemon: read active on 9 17:23:44.800: daemon: kqueue: listen=6 active_threads=0 tvp=NULL 17:23:44.800: daemon: kqueue: listen=7 active_threads=0 tvp=NULL 17:23:44.800: connection_get(9) 17:23:44.800: connection_get(9): got connid=0 17:23:44.801: =>do_syncrepl rid=101 17:23:44.801: =>do_syncrep2 rid=101 Not sure if it's any help but looking at kdump(1) output after a run under ktrace(1) I didn't spot the immediate problem resulting in "ldap_start_tls failed (1)" however the "mdb_opinfo_get: err Invalid argument(22)" occurs after attempting to call fcntl with F_SETLK on the fd 5 which is the kqueue fd: 65304 slapd RET write 97/0x61 65304 slapd CALL poll(0x89d39cb9004,1,INFTIM) 65304 slapd STRU struct kevent [2] { ident=9, filter=EVFILT_READ, flags=0x1005<EV_ADD|EV_ENABLE>, fflags=0<>, data=0, udata=0x231a1bea } { ident=9, filter=EVFILT_EXCEPT, flags=0x1005<EV_ADD|EV_ENABLE>, fflags=0x4<>, data=0, udata=0x231a1bea } 65304 slapd STRU struct kevent { ident=9, filter=EVFILT_READ, flags=0x1005<EV_ADD|EV_ENABLE>, fflags=0<>, data=36, udata=0x231a1bea } 65304 slapd STRU struct pollfd { fd=9, events=0x3<POLLIN|POLLPRI>, revents=0x1<POLLIN> } 65304 slapd RET poll 1 65304 slapd CALL read(9,0x89ccfb103e0,0x5) 65304 slapd GIO fd 9 read 5 bytes "\^W\^C\^C\0\^_" 65304 slapd RET read 5 65304 slapd CALL read(9,0x89ccfb349c5,0x1f) 65304 slapd GIO fd 9 read 31 bytes "\M^W\M-r\M-f\M^C\M-2\M^V\M-E\^O\M-hdgq\M-"\M-o\M-&\M^[*\M-9\M^E\M-Sd\M^A2\M-QE\M-cb |\M^VI" 65304 slapd RET read 31/0x1f 65304 slapd CALL mmap(0,0x2000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0) 65304 slapd RET mmap 9468564512768/0x89c926ca000 65304 slapd CALL fcntl(5,F_SETLK,0x8ef465d0) 65304 slapd RET fcntl -1 errno 22 Invalid argument 65304 slapd CALL getpid() 65304 slapd RET getpid 65304/0xff18 65304 slapd CALL sendsyslog(0x89c8ef44040,59,0<>) 65304 slapd GIO fd -1 wrote 59 bytes "<167>slapd[65304]: mdb_opinfo_get: err Invalid argument(22)" Any suggestions or requests for further information/tests would be welcome. Thanks! -- You are receiving this mail because: You are on the CC list for the issue.

1 16

[Issue 9534] New: Persistent test043 failures
by openldap-its＠openldap.org 07 Jul '22

07 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9534 Issue ID: 9534 Summary: Persistent test043 failures Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- In testing current RE25 as of 4/23/2021 (73b2769d05529a7d474661023f2c4f3a931417b2) test043 is sporadically failing. Examining the testrun log, it appears replication never even initiated. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

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

05 Jul '22

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 4

← Newer
1
...
6
7
8
9
10
11
12
...
16
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 May 2022