openldap-bugs September 2024

openldap-bugs@openldap.org

1 participants
69 discussions

[Issue 10256] New: Custom attribute disappears after slapd restart
by openldap-its＠openldap.org 04 Oct '24

04 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=10256 Issue ID: 10256 Summary: Custom attribute disappears after slapd restart Product: OpenLDAP Version: 2.4.57 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: heinrich.blatt(a)googlemail.com Target Milestone: --- Hi, i want to use a custom attribute in my schema. I use that ldif: dn: cn=schema,cn=config changetype: modify add: olcAttributeTypes olcAttributeTypes: ( 1.2.840.113556.1.4.7000 NAME 'rfidtoken' DESC 'RFID Token' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) This i inject via ldapmodify. For the session it works, but after restarting slapd the attribute disappears. If i add it again via ldapmodify it is there for the session again. My /etc/ldap/slapd.d/cn=config/cn=schema.ldif contains the change. This seems related to #9066, however the documentation indicates that i can make the changes via ldapmodify persistent. What is the right approach there? What i can do to persist the change? Thanks in advance for support -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10253] New: Compile failure with GnuTLS and GCC 14 on 32-bit
by openldap-its＠openldap.org 04 Oct '24

04 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=10253 Issue ID: 10253 Summary: Compile failure with GnuTLS and GCC 14 on 32-bit Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- Debian bug report: https://bugs.debian.org/1078822 tls_g.c fails to compile on 32-bit platforms with GCC 14: $ gcc --version gcc (Debian 14.2.0-2) 14.2.0 Copyright (C) 2024 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ gcc -dumpmachine i686-linux-gnu $ ./configure --disable-slapd --with-tls=gnutls [...] $ make [...] libtool: compile: cc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c tls_g.c -fPIC -DPIC -o .libs/tls_g.o tls_g.c: In function ‘tlsg_session_pinning’: tls_g.c:971:57: error: passing argument 4 of ‘gnutls_fingerprint’ from incompatible pointer type [-Wincompatible-pointer-types] 971 | keyhash.bv_val, &keyhash.bv_len ) < 0 ) { | ^~~~~~~~~~~~~~~ | | | ber_len_t * {aka long unsigned int *} In file included from tls_g.c:44: /usr/include/gnutls/gnutls.h:2408:32: note: expected ‘size_t *’ {aka ‘unsigned int *’} but argument is of type ‘ber_len_t *’ {aka ‘long unsigned int *’} 2408 | size_t *result_size); | ~~~~~~~~^~~~~~~~~~~ make[2]: *** [Makefile:431: tls_g.lo] Error 1 It looks like the warning has always been emitted since the code was originally committed, but with GCC 14 it became an error. (See <https://gcc.gnu.org/gcc-14/porting_to.html>. The last successful Debian build used GCC 13.) Quoting from the Debian bug report: > ber_len_t is typedef'ed in openldap as unsigned LBER_LEN_T, which is > AC_DEFINED as long. I'm not sure what a static AC_DEFINE in configure.ac > achieves, but that's what we have. On the other side, we have size_t, > which happens to be 32bit. Bummer. I suggest passing the 4th argument as > a temporary variable of type size_t and copying it from/to the target > structure after validating that it fits. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10233] New: wrong idl intersection
by openldap-its＠openldap.org 04 Oct '24

04 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=10233 Issue ID: 10233 Summary: wrong idl intersection Product: OpenLDAP Version: 2.6.8 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: hamano(a)osstech.co.jp Target Milestone: --- The `mdb_idl_intersection()` and `wt_idl_intersection()` functions derived from back-bdb return wrong results. expect: [1, 3] ∩ [2] = [] actual: [1, 3] ∩ [2] = [2] -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10237] New: openldap-2.6.8 fails to build with GCC14 with [-Wint-conversion]
by openldap-its＠openldap.org 04 Oct '24

04 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=10237 Issue ID: 10237 Summary: openldap-2.6.8 fails to build with GCC14 with [-Wint-conversion] Product: OpenLDAP Version: 2.6.8 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: timo.gurr(a)gmail.com Target Milestone: --- Created attachment 1023 --> https://bugs.openldap.org/attachment.cgi?id=1023&action=edit openldap-2.6.8-build.log With GCC 14 I'm experiencing the following error trying to build openldap 2.6.8: [...] In file included from ../slap.h:55, from search.c:32: search.c: In function 'ldap_back_search': ../../../include/ldap_pvt.h:531:31: error: passing argument 3 of '__gmpz_add' makes pointer from integer without a cast [-Wint-conversion] 531 | mpz_add((mpr), (mpr), (mpv)) | ^~~~~ | | | int search.c:257:9: note: in expansion of macro 'ldap_pvt_mp_add' 257 | ldap_pvt_mp_add( li->li_ops_completed[ SLAP_OP_SEARCH ], 1 ); | ^~~~~~~~~~~~~~~ In file included from ../../../include/ldap_pvt.h:519: /usr/x86_64-pc-linux-gnu/include/gmp.h:633:51: note: expected 'mpz_srcptr' {aka 'const __mpz_struct *'} but argument is of type 'int' 633 | __GMP_DECLSPEC void mpz_add (mpz_ptr, mpz_srcptr, mpz_srcptr); | ^~~~~~~~~~ make[3]: *** [Makefile:331: search.lo] Error 1 make[2]: *** [Makefile:550: .backend] Error 1 make[1]: *** [Makefile:298: all-common] Error 1 make: *** [Makefile:319: all-common] Error 1 This is with GCC 14.1.0, switching to GCC 13.2.0 instead allows the build to succeed, I checked other distributions (already on GCC 14) and git for possible patches but couldn't find anything relevant. Complete build log is attached. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10247] New: libldap should reject unrecognized critical URL extensions
by openldap-its＠openldap.org 04 Oct '24

04 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=10247 Issue ID: 10247 Summary: libldap should reject unrecognized critical URL extensions Product: OpenLDAP Version: 2.6.8 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Currently the only URL extension libldap recognizes is StartTLS. It ignores anything else, but it is not supposed to ignore them if they're marked critical. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10242] New: Improve syncrepl client traceability
by openldap-its＠openldap.org 04 Oct '24

04 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=10242 Issue ID: 10242 Summary: Improve syncrepl client traceability 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: --- The o_log_prefix in do_syncrepl()'s internal operation could be tweaked to contain the rid=..., that would significantly improve syncrepl traceability in the server logs and gdb. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9303] New: Add support for WolfSSL as an alternative to OpenSSL
by openldap-its＠openldap.org 03 Oct '24

03 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9303 Issue ID: 9303 Summary: Add support for WolfSSL as an alternative to OpenSSL Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- For OpenLDAP 2.6, we should investigate adding support for WolfSSL as an alternative to OpenSSL. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 9886] New: At "sync" logging, nothing shows how long a write op took on consumers
by openldap-its＠openldap.org 02 Oct '24

02 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9886 Issue ID: 9886 Summary: At "sync" logging, nothing shows how long a write op took on consumers Product: OpenLDAP Version: unspecified 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: --- If sync logging is enabled on a consumer, there's no etime logged which means it is not possible to see how long a write op took on that consumer. This can be useful information to see how the node is performing, particularly if it is a read only node where there will be no general MOD timing logged. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10260] New: Document alignment of MDB_val.mv_data
by openldap-its＠openldap.org 02 Oct '24

02 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=10260 Issue ID: 10260 Summary: Document alignment of MDB_val.mv_data Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: sascha(a)brawer.ch Target Milestone: --- In lmdb.h, could the documentation for MDB_val talk about alignment of mv_data? For example, is the key guaranteed to be aligned to an 8-byte boundary if a table got created with MDB_INTEGERKEY? What about values in MDB_INTEGERDUP tables? Can database values be directly loaded into SIMD registers (of what width?) without first copying the data to an aligned location? On some processor architectures, unaliged reads lead to bus errors; therefore, it would help programmers to know whether LMDB makes any alignment guarantees. Even if clients cannot assume anything, it would be good if LMDB’s public API documentation could state so. Many thanks for documenting this! Just adding 1 or 2 sentences to the MDB_val section in lmdb.h would be enough. — Sascha Brawer, sascha(a)brawer.ch -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10262] New: Feature request: configurable memory alignment of LMDB keys and values
by openldap-its＠openldap.org 02 Oct '24

02 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=10262 Issue ID: 10262 Summary: Feature request: configurable memory alignment of LMDB keys and values Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: sascha(a)brawer.ch Target Milestone: --- When creating an LMDB table, it would be nice if an application could request how its keys and values will be aligned in memory. Currently, LMDB seems to gives 2-byte alignment; see LMDB issue 10260. On most non-Intel CPUs, unaligned reads will cause SIGBUS errors, so any data with 32-bit or 64-bit values has to be accessed in multiple 16-bit chunks (which is inefficient), or copied out of LMDB-mapped memory into a custom, properly aligned buffer (which is inefficient, too). To prevent such performance degradation, it would be nice if applications could request alignment of keys and/or values to 8-byte boundaries. Then, LMDB data would have the same alignment guarantees as malloc(). The Linux kernel has a nice description of alignment: https://www.kernel.org/doc/html/latest/core-api/unaligned-memory-access.html Even on Intel CPUs, being able to specify alignment would be useful. For example, AVX-512 benefits from data being aligned to 64-byte boundaries. If an application could request 64-byte alignment for a given table, its values could be loaded direclty into AVX-512 registers. This would be useful for applications whose tables contain bitvectors or other data suitable for SIMD proceesing. https://www.intel.com/content/www/us/en/developer/articles/technical/data-a… Of course, padding comes at a cost. It increases storage space and reduces cache effectiveness. It would be wasteful to align each key and value in every table to some boundary. Hence the suggestion to make this configurable per table, perhaps with additional flags for mdb_dbi_open(). One could argue that memory alignment is out of scope for LMDB, leaving it up to applications to deal with misalignments. However, because of the cost of workarounds, it would make LMDB (significantly) less efficient than it could be, even on Intel CPUs. Thus, many thanks for considering this feature request. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2024