openldap-bugs

openldap-bugs@openldap.org

1 participants
20891 discussions

[Issue 10121] New: cldap is not work in 2.6.0
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=10121 Issue ID: 10121 Summary: cldap is not work in 2.6.0 Product: OpenLDAP Version: 2.6.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: 1010881517(a)qq.com Target Milestone: --- I can't use ldapsearch to query cldap:/// on 2.6.0, but it works fine on 2.4.0. Do you have any instructions on cldap configuration?ldap and ldapi are normal. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 7981] Feature request: Crypt scheme in pwdPolicy
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=7981 --- Comment #3 from Ondřej Kuzník <ondra(a)mistotebe.net> --- Rather than extending the pwdPolicy objectclass, maybe the new mechanism added in ITS#9343 could be used to override the default scheme if desided? -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10111] New: dynlist crashes when using member+memberOf@groupOfNames
by openldap-its＠openldap.org 31 Oct '23

31 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=10111 Issue ID: 10111 Summary: dynlist crashes when using member+memberOf@groupOfNames Product: OpenLDAP Version: 2.6.6 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: uberthoth(a)gmail.com Target Milestone: --- slapd crashes if queried for the memberof field if dynlist has this config (which is directly from the manpage for slapo-dynlist): olcDynListAttrSet: groupOfURLs memberURL member+memberOf@groupOfNames There is an example repo with a docker-compose.yml to replicate this issue here: https://github.com/joshuacox/openldap-overlay-dynlist This may be a duplicate of this https://bugs.openldap.org/show_bug.cgi?id=10091 though I did not see a seg fault. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10072] New: Querying for transaction memory use
by openldap-its＠openldap.org 28 Oct '23

28 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=10072 Issue ID: 10072 Summary: Querying for transaction memory use Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: tagwerk19.openldap(a)innerjoin.org Target Milestone: --- It would be useful to have a way to ask liblmdb how much "dirty memory" a transaction is using, up to that point. The goal is to be able to bundle writes into fewer transactions, making best use of available memory and reducing total disc writes. It is possible for an application to count the number of writes but this has only a loose relation to the *actual* number of dirty pages flagged. The target would be to write data up until the dirty memory gets to a threshold and then commit. I see that there's a: txn->mt_dirty_room and wonder if MDB_IDL_UM_MAX - txn->mt_dirty_room would give a count of that an "aware" application could make use of (an exact count? or maybe a usable and sufficient indication?) The need for this has been sharpened with the use of systemd service files that cap the memory allowed for a process, for example: MemoryHigh=512M If the process reaches this limit and continues to write data, the system uses swap. See: https://invent.kde.org/frameworks/baloo/-/merge_requests/148 Thank you for providing and supporting LMDB -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10122] New: Deletes are not replicated
by openldap-its＠openldap.org 26 Oct '23

26 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=10122 Issue ID: 10122 Summary: Deletes are not replicated Product: OpenLDAP Version: 2.4.46 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: kinouchi-kazuhito(a)jsdnet.co.jp Target Milestone: --- Thank you for your help. I am doing replication using syncrepl rehreshOnly mode. All of a sudden, entry deletions are no longer reflected to the consumer. Looking at the logs, nonpresent_callback is no longer printed in the consumer's logs. Further parsing the logs shows that after the last nonpresent_callback, the provider and consumer are updating the same attribute on the same entry. How should I recover? -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9959] New: Expose the lloadd connection endpoints in cn=monitor for identification
by openldap-its＠openldap.org 25 Oct '23

25 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=9959 Issue ID: 9959 Summary: Expose the lloadd connection endpoints in cn=monitor for identification 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: --- ITS#9600 introduces a way to operate on lloadd connections, however it is impossible to identify which socket this actually corresponds to. While we're at it, might also expose the current bound identity there. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10085] New: test029 can't pass with SLAPD_USE_SASL is set
by openldap-its＠openldap.org 25 Oct '23

25 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=10085 Issue ID: 10085 Summary: test029 can't pass with SLAPD_USE_SASL is set Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: test suite Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Running make test with SLAPD_USE_SASL set will fail test029. There is even a comment there that we can't support that functionality as-is when SASL binds are configured. We should probably remove that part of the test or skip it unconditionally for now. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10045] New: back-config operations abandoned while waiting in slap_pause_server() aren't committed to ldif
by openldap-its＠openldap.org 24 Oct '23

24 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=10045 Issue ID: 10045 Summary: back-config operations abandoned while waiting in slap_pause_server() aren't committed to ldif 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: --- slap_pause_server() can take an unbounded time to process and it is possible the operation is abandoned in the meantime (e.g. the connection is lost and the loss is still noticed at this point). However the processing still goes ahead and passed onto back-ldif - where it is discarded as abandoned already so we can end up with an inconsistent view of our persistent configuration. Checking op->o_abandon again after slap_pause_server() finishes might be enough. -- You are receiving this mail because: You are on the CC list for the issue.

2 13

[Issue 10095] New: Race condition causing corruption of mutexes when closing the database
by openldap-its＠openldap.org 23 Oct '23

23 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=10095 Issue ID: 10095 Summary: Race condition causing corruption of mutexes when closing the database Product: LMDB Version: 0.9.30 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: peter(a)peterzhu.ca Target Milestone: --- We're running into a race condition across multiple processes causing the corruption of mutexes when a process closes the database caused by the fix for https://bugs.openldap.org/show_bug.cgi?id=9278 (commit https://git.openldap.org/openldap/openldap/-/commit/f683ffdc81d0edb20437cb7…). Here's the interleaving of two processes (p0 and p1) that can cause this situation. p0: Opens connection to database using mdb_env_create and mdb_env_open. ...some things happen in between... p0: Begins closing the database using mdb_env_close: p0: Calls mdb_env_close0: p0: Acquires write lock on the file lock using mdb_env_excl_lock. p0: Calls pthread_mutex_destroy on the mutexes. SWITCH TO p1 p1: Begins opening the database using mdb_env_create. Then calls mdb_env_open, in mdb_env_open: p1: Calls mdb_env_setup_locks: p1: Calls mdb_env_excl_lock, but it's unable to acquire a write file lock due to p0 holding the write file lock. It waits on acquiring a read file lock. SWITCH TO p0 p0: Calls close on the file descriptor which releases the write lock. SWITCH TO p1 p1: Acquires the read file lock. p1: Does NOT call pthread_mutex_init since it did not acquire a write file lock. ...some things happen in between... p1: Try to lock the mutex using pthread_mutex_lock. This call fails with a EINVAL due to locking a destroyed mutex. I'm not sure how to actually solve this problem. We're currently mitigating this problem by reverting the commit linked above (so no mutexes get destroyed). -- You are receiving this mail because: You are on the CC list for the issue.

1 13

[Issue 7226] olcAuditlogFile should be single valued, but accepts multiple values (additional values ignored)
by openldap-its＠openldap.org 23 Oct '23

23 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=7226 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |RESOLVED Resolution|--- |TEST --- Comment #18 from Quanah Gibson-Mount <quanah(a)openldap.org> --- • 242d1e6d by Ondřej Kuzník at 2023-08-21T12:19:16+01:00 ITS#7226 Make olcAuditlogFile SINGLE-VALUE -- You are receiving this mail because: You are on the CC list for the issue.

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs