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