openldap-bugs September 2024

openldap-bugs@openldap.org

1 participants
96 discussions

[Issue 9356] New: Add list of peerSIDs to consumer cookie to reduce cross traffic
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9356 Issue ID: 9356 Summary: Add list of peerSIDs to consumer cookie to reduce cross traffic 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: --- If we add a list of peersids to the cookie, each consumer can tell the providers who else the consumers talk to and then the provider can omit sending updates to that consumer, originating from those peers There's some special handling needed if a connection dies If a consumer loses one of its peer connections, and after N retries is still not connected, it should send a new cookie to its remaining peers saying "here's my new peer list" with the missing one removed. Likewise, if a retry eventually connects again, it can send a new cookie again Make that peer list reset configurable in the syncrepl config stanza. This can help account for end admin knowledge that some links may be more or less stable than other ones. The idea here is that if one of your other peers can still see the missing peer, they can start routing updates to you again It should abandon all existing persist sessions and send a new sync search with the new cookie to all remaining peers For consumer side, also means adding the sid for a given provider into the syncrepl stanza to save on having to try and discover the peer sid. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 9272] New: Invalid search results for subordinate/glued database
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9272 Issue ID: 9272 Summary: Invalid search results for subordinate/glued database Product: OpenLDAP Version: 2.4.47 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: grapvar(a)gmail.com Target Milestone: --- Here is a trivial test case. Look at the following bunch of glued dit's/databases, declared in this order: | suffix ou=a,ou=1,ou=T # subordinate; contains only one (top-level) entry | suffix ou=2,ou=T # subordinate; contains only one (top-level) entry | suffix ou=b,ou=1,ou=T # subordinate; contains only one (top-level) entry | suffix ou=T # master database, has two entries, top-level | ` ou=1 # ... and this child entry let's query the united database: | $ ldapsearch -b ou=1,ou=T -s sub '' nx | dn: ou=1,ou=T | dn: ou=a,ou=1,ou=T | dn: ou=b,ou=1,ou=T Nice! But wait, what if ... | $ ldapsearch -b ou=1,ou=T -s sub -E\!pr=2/noprompt '' nx | dn: ou=1,ou=T | dn: ou=a,ou=1,ou=T | | # pagedresults: cookie=//////////8= ... BANG! ... | Server is unwilling to perform (53) The problem is the glue_op_search(), which has issues * different parts of code make different assumptions about data structures * different parts of code track state inconsistently * code that looks like a highly probably dead code I mean that likely possible to build another bug-triggering test cases, and glue_op_search() needs not just a fix of the bug above, but intense cleaning and structuring. -- You are receiving this mail because: You are on the CC list for the issue.

1 14

[Bug 9219] New: Streamline tool API for 2.5
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9219 Bug ID: 9219 Summary: Streamline tool API for 2.5 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: --- The current tool API is a mess and needs fixing for 2.5. This affects things like slapacl (The fix for bug#7920 was a kludge to deal with this, needs revisiting). -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Issue 10259] New: Wrong RID sends when using syncrepl provider
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=10259 Issue ID: 10259 Summary: Wrong RID sends when using syncrepl provider Product: OpenLDAP Version: 2.6.8 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: florent.david(a)gmail.com Target Milestone: --- When using a custom syncrepl consumer bind to an OpenLDAP v2.6.8 provider and it quickly appears than this provider sends to our consumer a cookie with a Replica ID different from the original one. In the logs below, we clearly see a refreshAndPersist synchronization initialized whith a RID with value 606. After a while, on the same connection, OpenLDAP syncrepl provider sends a new cookie with RID=612 66f2ea7d.3b1f8427 0x7fa80a5fd6c0 conn=92750 op=1 syncprov_op_search: got a persistent search with a cookie=rid=606,csn=20240924154708.334351Z#000000#000#000000 66f2ea7d.3b1fafc0 0x7fa80a5fd6c0 conn=92750 op=1 syncprov_findbase: searching 66f2ea7d.3b20ca28 0x7fa80a5fd6c0 conn=92750 op=1 syncprov_op_search: registered persistent search 66f2ea7d.3b20e5bf 0x7fa80a5fd6c0 conn=92750 op=1 syncprov_op_search: no change, skipping log replay 66f2ea7d.3b20ed6a 0x7fa80a5fd6c0 conn=92750 op=1 syncprov_op_search: nothing changed, finishing up initial search early 66f2ea7d.3b20f874 0x7fa80a5fd6c0 conn=92750 op=1 syncprov_sendinfo: refreshDelete cookie= 66f2ea7d.3b229483 0x7fa80a5fd6c0 conn=92750 op=1 syncprov_search_response: detaching op 66f2ed56.12f82965 0x7fa816dfe6c0 conn=92750 op=1 syncprov_qresp: set up a new syncres mode=4 csn=20240924164822.305028Z#000000#000#000000 66f2ed56.12fa5399 0x7fa7f58fc6c0 conn=92750 op=1 syncprov_sendinfo: sending a new cookie=rid=612,csn=20240924164822.305028Z#000000#000#000000 66f2ed8d.053d71e3 0x7fa8165fd6c0 conn=92750 op=1 syncprov_qresp: set up a new syncres mode=4 csn=20240924164917.069189Z#000000#000#000000 66f2ed8d.05405bb4 0x7fa7ed3fc6c0 conn=92750 op=1 syncprov_sendinfo: sending a new cookie=rid=612,csn=20240924164917.069189Z#000000#000#000000 Is it a normal behaviour ? Should consumer checks the Replica ID sends by OpenLDAP before storing it ? -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Bug 9204] New: slapo-constraint allows anyone to apply Relax control
by openldap-its＠openldap.org 08 Oct '24

08 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9204 Bug ID: 9204 Summary: slapo-constraint allows anyone to apply Relax control Product: OpenLDAP Version: 2.4.49 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- slapo-constraint doesn't limit who can use the Relax control, beyond the global limits applied by slapd. In practice, for many modifications this means any configured constraints are advisory only. In my opinion this should be considered a bug, in design if not implementation. I expect many admins would not read the man page closely enough to realize the behaviour does technically adhere to the letter of what's written there. Either slapd should require manage privileges for the Relax control globally, or slapo-constraint should perform a check for manage privilege itself, like slapo-unique does. Quoting ando in https://bugs.openldap.org/show_bug.cgi?id=5705#c4: > Well, a user with "manage" privileges on related data could bypass > constraints enforced by slapo-constraint(5) by using the "relax" > control. The rationale is that a user with manage privileges could be > able to repair an entry that needs to violate a constraint for good > reasons. Note that the user: > > - must have enough privileges to do it (manage) > > - must inform the DSA that intends to violate the constraint (by using > the control) but such privileges are currently not being required. -- You are receiving this mail because: You are on the CC list for the bug.

1 12

[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 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 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

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2024