openldap-bugs October 2024

openldap-bugs@openldap.org

1 participants
113 discussions

[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 8673] Need duration logging for sync ops
by openldap-its＠openldap.org 02 Oct '24

02 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=8673 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Ondřej Kuzník <ondra(a)mistotebe.net> --- *** This issue has been marked as a duplicate of issue 9886 *** -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[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

[Issue 9002] Add option to slapcat to honor rtxnsize setting
by openldap-its＠openldap.org 01 Oct '24

01 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9002 --- Comment #4 from Howard Chu <hyc(a)openldap.org> --- It's a tradeoff. If you can't accomodate the potential DB size increase, you must stop slapd. If you can't tolerate stopping slapd, you have to provide enough disk space. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9022] Force slapadd to rewrite all entryCSN values
by openldap-its＠openldap.org 01 Oct '24

01 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9022 --- Comment #2 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Add it as a new option under -o flag -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9002] Add option to slapcat to honor rtxnsize setting
by openldap-its＠openldap.org 01 Oct '24

01 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9002 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|slapd |documentation --- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Document best practices for consistent backups, namely: Stop slapd, slapcat, start slapd, perhaps a dedicated server for this purpose. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8757] RFE: let slapd MMR instances vote primary master
by openldap-its＠openldap.org 01 Oct '24

01 Oct '24

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

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2024