openldap-bugs February 2022

openldap-bugs@openldap.org

1 participants
109 discussions

[Issue 9782] New: regression test its8752 failure
by openldap-its＠openldap.org 08 Jul '22

08 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9782 Issue ID: 9782 Summary: regression test its8752 failure 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: --- If a contextCSN update (new cookie) goes from server A through server B to server C, server C will use that CSN to update entryCSN as well (which neither A nor B did). This fails the initial replication check. The issue has likely existed since deltasync was made possible, a version of this is confirmed at least in 2.4.60 onwards to current master. In principle, it is related to concerns raised in ITS#9580. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9534] New: Persistent test043 failures
by openldap-its＠openldap.org 07 Jul '22

07 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9534 Issue ID: 9534 Summary: Persistent test043 failures 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: --- In testing current RE25 as of 4/23/2021 (73b2769d05529a7d474661023f2c4f3a931417b2) test043 is sporadically failing. Examining the testrun log, it appears replication never even initiated. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 9642] New: Adding a task to runqueue doesn't wake the main thread
by openldap-its＠openldap.org 05 Jul '22

05 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9642 Issue ID: 9642 Summary: Adding a task to runqueue doesn't wake the main thread Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- If a connection adds a new syncrepl stanza, that is not started until the main thread comes around to doing it. However if that thread is currently stuck in SLAP_EVENT_WAIT() and nothing else happens (like an unbind over the connection that modified the config), the task is never started. This can take a long time. No idea yet how to wake it up with/from ldap_pvt_runqueue_insert() given that sits within libldap and not really something that should be calling slap_wake_listener(). -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9468] New: slapd-ldap does anonymous bind even if rebind-as-user is set
by openldap-its＠openldap.org 30 Jun '22

30 Jun '22

https://bugs.openldap.org/show_bug.cgi?id=9468 Issue ID: 9468 Summary: slapd-ldap does anonymous bind even if rebind-as-user is set Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: tero.saarni(a)est.tech Target Milestone: --- When back-ldap retries bind operation after connection retry, it will do it as anonymous even if rebind-as-user is set to yes. Expected behavior is that (re)bind is done with user's credentials from the initial bind operation. I observed following (Warning: I might have understood details of the code incorrectly): When rebind-as-user is set and bind operation from client is processed, proxy will copy the credentials to ldapconn_t representing the remote LDAP connection. When remote LDAP connection is closed (e.g. by the proxy itself due to timeout), the bind credentials information is lost when freeing the old ldapconn_t. At this point, client still holds the connection to proxy and is unaware of the remote connection being lost. Proxy then re-establishes the connection and "synthetically" generates new bind itself, but since it does not have the credentials stored in memory anymore, it sends anonymous bind on behalf of the client. As a side effect, slapd currently crashes if remote server does not allow anonymous bind and responds with InvalidCredentials instead. The crash is due to assert(), which is handled in separate issue https://bugs.openldap.org/show_bug.cgi?id=9288 -- You are receiving this mail because: You are on the CC list for the issue.

1 12

[Issue 9799] New: Clearing pending ops on Bind
by openldap-its＠openldap.org 07 Jun '22

07 Jun '22

https://bugs.openldap.org/show_bug.cgi?id=9799 Issue ID: 9799 Summary: Clearing pending ops on Bind 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: --- When slapd receives some operations before it has started processing a queued bind, those get added into conn->c_ops_pending and c_n_pending_ops is updated accordingly. Bind then eventually invokes connection_abandon() which forgets to zero out c_n_pending_ops and the connection remains unusable forever. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9385] New: Opening an env with MDB_NOSUBDIR with no existing file returns error
by openldap-its＠openldap.org 13 May '22

13 May '22

https://bugs.openldap.org/show_bug.cgi?id=9385 Issue ID: 9385 Summary: Opening an env with MDB_NOSUBDIR with no existing file returns error Product: LMDB Version: unspecified Hardware: All OS: Mac OS Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: kriszyp(a)gmail.com Target Milestone: --- Created attachment 776 --> https://bugs.openldap.org/attachment.cgi?id=776&action=edit A fix to tolerate stat call on non-existing file Calling mdb_env_open with a file path to a file that doesn't exist yet, with MDB_NOSUBDIR on a non-Windows OS will return an error indicating that the file doesn't exist. This is supposed to create a new file, and works properly on the mdb.master branch, and still functions properly on Windows. The error is due to the stat() call in mdb_env_open prior to the file existing. I attached a patch that tolerates the absence of the file before checking if the file is on a block device. I am not sure if this is the appropriate fix, or if would be better to move this check later in mdb_env_open after the file is created, or alternately, determining the parent directory and calling stat on that. -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 9702] New: slapadd is missing -r chroot option
by openldap-its＠openldap.org 12 May '22

12 May '22

https://bugs.openldap.org/show_bug.cgi?id=9702 Issue ID: 9702 Summary: slapadd is missing -r chroot option Product: OpenLDAP Version: 2.5.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- I want to run slapd under chroot with the -r option. In order to initialize the setup, I want to use `slapadd -n0 configuration.ldif`. The configuration file contains mdb databases and these databases have `olcDbDirectory: ` paths. Since slapd will load the databases from the chroot environment, the directory names must be submitted to slapadd to be correct in the chroot environment. This means, that outside the chroot environment the directory paths are not correct. When I call `slapadd -n0 ` I get the error olcDbDirectory: value #0: invalid path: No such file or directory slapadd: could not add entry dn="olcDatabase={1}mdb,cn=config" (line=909): Closing DB... which means, that slapadd cannot open (outside the chrooted environment) the olcDbDirectory path. Thus slapadd shall first enter the chrooted environment, but it lacks option for this. Probably slapcat will also need this option to dump the databases. The chrooted environment is created specially for openldap, so it contains no tools. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9745] New: Local Logging - Timestamp Formatting
by openldap-its＠openldap.org 12 May '22

12 May '22

https://bugs.openldap.org/show_bug.cgi?id=9745 Issue ID: 9745 Summary: Local Logging - Timestamp Formatting Product: OpenLDAP Version: 2.6.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: gnoe(a)symas.com Target Milestone: --- Timestamps for log lines in the 2.6+ local logging feature are saved unformatted (ex: "618ae741.0f6eb63a"). This has the potential to break any log aggregation/analysis program like splunk that expect timestamps in syslog format. These timestamps should configurable in various syslog formats. -- You are receiving this mail because: You are on the CC list for the issue.

1 13

[Issue 9403] New: add option to completely disable syslog logging
by openldap-its＠openldap.org 12 May '22

12 May '22

https://bugs.openldap.org/show_bug.cgi?id=9403 Issue ID: 9403 Summary: add option to completely disable syslog logging Product: OpenLDAP Version: 2.4.45 Hardware: All OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: cvuillemez(a)yahoo.fr Target Milestone: --- For auditing purpose, I need to enable "stats" loglevel. So on heavy load, slapd send lots of events to local syslog socket /dev/log, when compiled with LDAP_SYSLOG (on Debian / Ubuntu). It worked fine on old systems with a simple syslog service. But when upgrading on system with journald+syslog, CPU "overhead" becomes totally crazy. It would be great to have an option at run time to completely disable syslog logging, or/and use a cutom socket, e.g. /run/systemd/journal/syslog to bypass journald service. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9675] New: Allow overwriting the default SLAPD_DEFAULT_CONFIGDIR during ./configure
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9675 Issue ID: 9675 Summary: Allow overwriting the default SLAPD_DEFAULT_CONFIGDIR during ./configure Product: OpenLDAP Version: 2.5.7 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- Created attachment 839 --> https://bugs.openldap.org/attachment.cgi?id=839&action=edit fix I want to have different default for SLAPD_DEFAULT_CONFIGDIR in my slapd. By calling CPPFLAGS="-DSLAPD_DEFAULT_CONFIGDIR='\"/new/config/dir/\"'" ./configure one can change the default configdir in slapd. Provided that the macro SLAPD_DEFAULT_CONFIGDIR is not changed in the code, which is ensured by the provided patch. Macro SLAPD_DEFAULT_UCDATA is not used anywhere. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

← Newer
1
...
4
5
6
7
8
9
10
11
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2022