- openldap-bugs - openldap.org

[Issue 9873] New: idle timeout by backends close connections
by openldap-its＠openldap.org 18 Jul '22

18 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9873 Issue ID: 9873 Summary: idle timeout by backends close connections Product: OpenLDAP Version: 2.6.2 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: ettorevi(a)gmail.com Target Milestone: --- Hi, making searches through lloadd to a bunch of backends returns weird results Sometimes I get: | ldap_bind: Other (e.g., implementation specific) error (80) | additional info: connection to the remote server has been severed Others ldap_result: Can't contact LDAP server (-1) due to an idle_timeout from the backend in the middle of the search, in a non deterministic way. If I search directly on the backends everything works ldapsearch -x -Hldaps://lloadd.server 'objectClass=*' -w pwd [...] # numResponses: 9620 # numEntries: 9620 ldap_result: Can't contact LDAP server (-1) lloadd compiled standalone from 2.6.2 with: --enable-balancer=yes --enable-syslog --enable-debug --enable-slapd=no Backends are older, 2.4.49+dfsg-2ubuntu1.9 from Ubuntu 20.04 Any hints? Thank you -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9849] New: Update website to support LTS and Feature releases
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9849 Issue ID: 9849 Summary: Update website to support LTS and Feature releases Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: mnormann(a)symas.com Target Milestone: --- Modify .wlmrc variable names and website content to handle both Feature Release and Long Term Support release. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[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 9858] New: cn=config replication refresh breaks mdb database
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9858 Issue ID: 9858 Summary: cn=config replication refresh breaks mdb database Product: OpenLDAP Version: 2.6.2 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- working in an environment with the following layout: Config node -> This node contains the cn=config databases for consumers in one tree and providers in another tree. provider nodes -> Pull their configuration from the config node via standard syncrepl consumer nodes -> Pull their configuration from the config node via standard syncrepl This worked fine with OpenLDAP 2.4. With 2.6, using the same cn=config configuration, slapd will segfault if the cn=config db is put through a REFRESH sequence. I've ruled out syncprov as an issue as I removed the syncprov configuration from the consumer nodes entirely and it still occurs (I was thinking perhaps it was the syncprov checkpoint at shutdown). At this point I can reproduce this trivially 100% of the time simply by having a node REFRESH cn=config. Once the REFRESH has occurred, slapd will continue running. However the next time it is stopped/started it will SEGV on startup. It is usually possible to use slapcat to extract the MDB database and rebuild it, at which point slapd will start again. A couple of times I was only able to extract a portion of the database using slapcat (70MB of 650MB). -- You are receiving this mail because: You are on the CC list for the issue.

1 19

[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 7165] Killing slap tools breaks the running mdb
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=7165 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9865] New: slapd-watcher: support for glue
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9865 Issue ID: 9865 Summary: slapd-watcher: support for glue Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: enhancement Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- When operating on glued backends, the DB where entry counts need to be monitored may be different from where the contextCSN updates occur. Add a "-c" option to allow specifying the contextCSN baseDN, separate from the main "-b" baseDN. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9872] New: slapd-ldap(5) man page missing bold tag on authz parameter
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9872 Issue ID: 9872 Summary: slapd-ldap(5) man page missing bold tag on authz parameter Product: OpenLDAP Version: 2.6.2 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: --- The slapd-ldap(5) man page is missing a bold tag on the authz configuration parameter. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9864] New: One-time leaks in accesslog
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9864 Issue ID: 9864 Summary: One-time leaks in accesslog Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: minor Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- In tool mode, the accesslog's configured logdb suffix isn't freed. It's normally freed by the db_open handler but in tool mode the overlay never actually gets opened. Also due to 414866b8889 ITS#9580, li_sids can leak when replacing mincsn. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 8882] Empty Directory String Overlay
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=8882 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9867] New: syncprov leak on early Abandons
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9867 Issue ID: 9867 Summary: syncprov leak on early Abandons Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- The baseDN found by syncprov_findbase() can be leaked if an Abandon or error occurs early during psearch processing. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9871] New: bind operations on relay entries cause slapd to segfault with rwm and ppolicy enabled
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9871 Issue ID: 9871 Summary: bind operations on relay entries cause slapd to segfault with rwm and ppolicy enabled Product: OpenLDAP Version: 2.5.12 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: subbarao(a)computer.org Target Milestone: --- On 2.5.12, slapd crashes during bind operations on relay entries with rwm and ppolicy both enabled. A simple way to reproduce this issue is to edit tests/scripts/relay and tests/data/slapd-relay.conf as follows, and then run test030-relay. I think this issue is the same as ITS#7966 reported in 2014. --- tests/scripts/relay.orig 2022-05-04 07:57:30.000000000 -0700 +++ tests/scripts/relay 2022-06-23 17:16:42.020652093 -0700 @@ -356,6 +356,16 @@ exit 1 fi +$LDAPADD -D "$MANAGERDN" -H $URI1 -w $PASSWD <<EOF > /dev/null 2>&1 +dn: cn=ppolicy,dc=example,dc=com +objectClass: top +objectClass: device +objectClass: pwdPolicy +cn: ppolicy +pwdMinLength: 5 +pwdAttribute: userPassword +EOF + BASEDN="o=Example,c=US" echo "Changing password to database \"$BASEDN\"..." $LDAPPASSWD -H $URI1 -D "cn=Manager,$BASEDN" -w $PASSWD \ --- tests/data/slapd-relay.conf.orig 2022-05-04 07:57:30.000000000 -0700 +++ tests/data/slapd-relay.conf 2022-06-23 16:57:15.184456120 -0700 @@ -31,6 +31,8 @@ #metamod#moduleload back_meta.la #rwmmod#modulepath ../servers/slapd/overlays/ #rwmmod#moduleload rwm.la +#ppolicymod#modulepath ../servers/slapd/overlays/ +#ppolicymod#moduleload ppolicy.la ####################################################################### # database definitions @@ -46,6 +48,9 @@ #ndb#dbname db_1 #ndb#include @DATADIR@/ndb.conf +overlay ppolicy +ppolicy_default cn=ppolicy,dc=example,dc=com + database @RELAY@ suffix "o=Example,c=US" ### back-relay can automatically instantiate the rwm overlay -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 9876] New: Coverity report on OpenLDAP libraries and client tools
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9876 Issue ID: 9876 Summary: Coverity report on OpenLDAP libraries and client tools Product: OpenLDAP Version: 2.6.2 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: simon.pichugin(a)gmail.com Target Milestone: --- Created attachment 906 --> https://bugs.openldap.org/attachment.cgi?id=906&action=edit Covscan report for OpenLDAP 2.6.2 I've got a report from our Coverity Scan system. It had a lot of false positives so I've filtered it a bit. Please, find below the report with only RESOURCE_LEAK, LOCK, and MISSING_LOCK issues. I think there are still some false positives left, but I hope it's worth checking by core OpenLDAP developers. The report: https://spichugi.fedorapeople.org/openldap-covscan-2.6.2.html Thank you! -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 9866] New: delta-sync memleak on Adds
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9866 Issue ID: 9866 Summary: delta-sync memleak on Adds Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Due to the entry->e_name massaging in back-mdb/add.c (ITS#5326) syncrepl wasn't freeing the non-normalized DN as expected after add finished. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[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 9882] New: slapd crashes when lastbind enabled w/ multi-provider
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9882 Issue ID: 9882 Summary: slapd crashes when lastbind enabled w/ multi-provider Product: OpenLDAP Version: 2.6.2 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: smckinney(a)symas.com Target Milestone: --- Created attachment 907 --> https://bugs.openldap.org/attachment.cgi?id=907&action=edit slapd.conf Description: Crash during bind operation when lastbind's enabled in a multi-provider env. Built from source: commit 23ef018c6f321413141f26ed6e1909f85047ba76 (HEAD -> OPENLDAP_REL_ENG_2_6, origin/OPENLDAP_REL_ENG_2_6) Configuration: attached System: AlmaLinux8 Backtrace: Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00000000004dfe66 in over_op_func (op=0x7d6b1fffe690, rs=0x7d6b1fffe620, which=op_modify) at backover.c:749 749 on = oi->oi_list; [Current thread is 1 (Thread 0x7d6b1ffff700 (LWP 96272))] Missing separate debuginfos, use: yum debuginfo-install cyrus-sasl-lib-2.1.27-6.el8_5.x86_64 glibc-2.28-189.5.el8_6.x86_64 keyutils-libs-1.5.10-9.el8.x86_64 krb5-libs-1.18.2-14.el8.x86_64 libblkid-2.32.1-35.el8.x86_64 libcap-2.48-2.el8.x86_64 libcom_err-1.45.6-4.el8.x86_64 libdb-5.3.28-42.el8_4.x86_64 libgcc-8.5.0-10.1.el8_6.alma.x86_64 libmount-2.32.1-35.el8.x86_64 libselinux-2.9-5.el8.x86_64 libtool-ltdl-2.4.6-25.el8.x86_64 libuuid-2.32.1-35.el8.x86_64 libxcrypt-4.1.1-6.el8.x86_64 openssl-libs-1.1.1k-6.el8_5.x86_64 pcre2-10.32-2.el8.x86_64 systemd-libs-239-58.el8.x86_64 zlib-1.2.11-18.el8_5.x86_64 (gdb) bt #0 0x00000000004dfe66 in over_op_func (op=0x7d6b1fffe690, rs=0x7d6b1fffe620, which=op_modify) at backover.c:749 #1 0x00000000004e0135 in over_op_modify (op=0x7d6b1fffe690, rs=0x7d6b1fffe620) at backover.c:808 #2 0x000000000046d785 in fe_op_lastbind (op=0x7d6b1010ed40) at bind.c:503 #3 0x000000000046da7f in fe_op_bind_success (op=0x7d6b1010ed40, rs=0x7d6b1fffe960) at bind.c:548 #4 0x000000000046d1e1 in fe_op_bind (op=0x7d6b1010ed40, rs=0x7d6b1fffe960) at bind.c:386 #5 0x000000000046c8cd in do_bind (op=0x7d6b1010ed40, rs=0x7d6b1fffe960) at bind.c:206 #6 0x000000000044427d in connection_operation (ctx=0x7d6b1fffea90, arg_v=0x7d6b1010ed40) at connection.c:1115 #7 0x000000000044488f in connection_read_thread (ctx=0x7d6b1fffea90, argv=0x16) at connection.c:1267 #8 0x00007f5f2d60a470 in ldap_int_thread_pool_wrapper (xpool=0xc79d80) at tpool.c:1053 #9 0x00007f5f2c1a51cf in start_thread () from /lib64/libpthread.so.0 #10 0x00007f5f2be11dd3 in clone () from /lib64/libc.so.6 -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[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 9868] New: backglue and syncprov must use same pending_csn_list
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9868 Issue ID: 9868 Summary: backglue and syncprov must use same pending_csn_list Product: OpenLDAP Version: 2.5.12 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- When replication is performed on a glued DB hierarchy the syncprov overlay must only be configured on the top DB. But when writes occur on a subDB their CSNs will be queued on the subDB's be_pending_csn_list. When syncprov sees these writes it will try to graduate these CSNs from the top DB's be_pending_csn_list, but never find them there. The CSN list will grow without bound. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9726] New: Admin guide and man pages need better documentation on disabling syslog
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9726 Issue ID: 9726 Summary: Admin guide and man pages need better documentation on disabling syslog Product: OpenLDAP Version: 2.6.0 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: --- 2.6.0 added the new feature allowing using a logfile for all debug/loglevel messages and bypassing syslog entirely. However, there is no documentation on the new settings or examples of how to do this in the admin guide, and the man page sections on the new parameters for the logfile side do not note at when/how they enable bypassing syslog. -- You are receiving this mail because: You are on the CC list for the issue.

1 30

[Issue 9883] New: OpenLDAP version 2.4.44 for CentoOS 7.9 contains several CVEs
by openldap-its＠openldap.org 12 Jul '22

12 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9883 Issue ID: 9883 Summary: OpenLDAP version 2.4.44 for CentoOS 7.9 contains several CVEs Product: OpenLDAP Version: 2.4.44 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: meirav.rath(a)imperva.com Target Milestone: --- Hello, My name is Meirav Rath, I'm a software developer and security champion at Imperva. As part of our effort to map security risks in our products I've been scanning our 3rd party rpms for vulnerabilities. It looks like OpenLDAP version 2.4.44 for CentOS 7.9 has the following security issues: 1. CVE-2020-36229 - https://nvd.nist.gov/vuln/detail/CVE-2020-36229 2. CVE-2019-13565 - https://nvd.nist.gov/vuln/detail/CVE-2019-13565 3. CVE-2020-36223 - https://nvd.nist.gov/vuln/detail/CVE-2020-36223 4. CVE-2020-36222 - https://nvd.nist.gov/vuln/detail/CVE-2020-36222 5. CVE-2019-13057 - https://nvd.nist.gov/vuln/detail/CVE-2019-13057 6. CVE-2021-27212 - https://nvd.nist.gov/vuln/detail/CVE-2021-27212 7. CVE-2020-36226 - https://nvd.nist.gov/vuln/detail/CVE-2020-36226 8. CVE-2020-36228 - https://nvd.nist.gov/vuln/detail/CVE-2020-36228 9. CVE-2022-29155 - https://nvd.nist.gov/vuln/detail/CVE-2022-29155 10. CVE-2020-36230 - https://nvd.nist.gov/vuln/detail/CVE-2020-36230 11. CVE-2020-36225 - https://nvd.nist.gov/vuln/detail/CVE-2020-36225 12. CVE-2020-36227 - https://nvd.nist.gov/vuln/detail/CVE-2020-36227 13. CVE-2020-36224 - https://nvd.nist.gov/vuln/detail/CVE-2020-36224 14. CVE-2020-36221 - https://nvd.nist.gov/vuln/detail/CVE-2020-36221 When can we expect an updated RPM with fixes for this issues, aimed for CentOS7.9? Thanks. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9782] New: regression test its8752 failure
by openldap-its＠openldap.org 08 Jul '22

08 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9782 Issue ID: 9782 Summary: regression test its8752 failure 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: --- If a contextCSN update (new cookie) goes from server A through server B to server C, server C will use that CSN to update entryCSN as well (which neither A nor B did). This fails the initial replication check. The issue has likely existed since deltasync was made possible, a version of this is confirmed at least in 2.4.60 onwards to current master. In principle, it is related to concerns raised in ITS#9580. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs