openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

[Issue 8245] slapo-unique constraints bypassed by manageDsaIt, change to relax?
by openldap-its＠openldap.org 23 Jun '22

23 Jun '22

https://bugs.openldap.org/show_bug.cgi?id=8245 --- Comment #15 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: • 81b5ca91 by Ondřej Kuzník at 2022-06-14T21:52:18+00:00 ITS#8245 Do not try to release a NULL entry RE26 (2.6.3): • 85649edf by Ondřej Kuzník at 2022-06-23T18:34:57+00:00 ITS#8245 Do not try to release a NULL entry RE25 (2.5.13): • c8059b5d by Ondřej Kuzník at 2022-06-23T18:46:44+00:00 ITS#8245 Do not try to release a NULL entry -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8227] syncprov should use more threads
by openldap-its＠openldap.org 23 Jun '22

23 Jun '22

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

1 0

[Issue 9870] New: Remove optional overlay syntax
by openldap-its＠openldap.org 23 Jun '22

23 Jun '22

https://bugs.openldap.org/show_bug.cgi?id=9870 Issue ID: 9870 Summary: Remove optional overlay syntax 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: --- While the module/overlay support was really young, an unreleased version of OpenLDAP supported 'optional overlays' that could fail start up without that being treated as a fatal error. This was later disabled, never documented and nowadays it can't work anyway, but the configuration option is still there in config_overlay() honouring overlay names starting with the '-' character as an alias. A patch to remove that leftover is coming. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9869] New: LDAP over TLS not doing hostname verification in version 2.4.59
by openldap-its＠openldap.org 21 Jun '22

21 Jun '22

https://bugs.openldap.org/show_bug.cgi?id=9869 Issue ID: 9869 Summary: LDAP over TLS not doing hostname verification in version 2.4.59 Product: OpenLDAP Version: 2.4.59 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: radiatejava(a)gmail.com Target Milestone: --- My software was using openldap client 2.4.44 to talk to the LDAP server. We have shifted to 2.4.59 now to address some issues. Ever since we shifted, the new version is allowing LDAP over TLS without hostname verification. In the older 2.4.44, I always got this error if hostname did not match the CN value: return code -1 - Can't contact LDAP server) diagnostic message TLS: hostname does not match CN in peer certificate But after the lib update, no such error even if I am using LDAP server IP to do LDAP bind while LDAP server certificate has CN set as some FQDN (say test.ldap.com). Our client side code has not changed while we updated the ldap lib. For our client, we are only doing these settings: ldap_set_option(ld, LDAP_OPT_X_TLS_CACERTDIR, lCertsDir) ldap_set_option(NULL, LDAP_OPT_X_TLS_CACERTFILE, lCert) Has there been any change in this regard? How do I enforce hostname verification now? Thanks -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 8227] syncprov should use more threads
by openldap-its＠openldap.org 21 Jun '22

21 Jun '22

https://bugs.openldap.org/show_bug.cgi?id=8227 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #6 from Ondřej Kuzník <ondra(a)mistotebe.net> --- Yeah, just gone all the way to backlogging one consumer till we block in slapd_wait_writer() and the other one keeps receiving all messages as they are prepared, just as one would hope. Resuming the blocked consumer seems to flush everything down that connection as well. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8227] syncprov should use more threads
by openldap-its＠openldap.org 21 Jun '22

21 Jun '22

https://bugs.openldap.org/show_bug.cgi?id=8227 --- Comment #5 from Howard Chu <hyc(a)openldap.org> --- Possibly this ticket is obsolete then. If you're satisfied that suspending/blocking one consumer doesn't interfere with other consumers' progress, we can just close this. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8227] syncprov should use more threads
by openldap-its＠openldap.org 21 Jun '22

21 Jun '22

https://bugs.openldap.org/show_bug.cgi?id=8227 --- Comment #4 from Ondřej Kuzník <ondra(a)mistotebe.net> --- Maybe you meant something else because I'm not seeing this, syncprov_matchops->syncprov_qresp already schedules a separate syncprov_qtask for each active persist session that has anything to send out. Those sessions each have a separate response queue, sharing a reference to the resinfo provided. And those tasks then run independent of each other sending messages (since ITS#5985 just one message at a time), reclaiming syncres and since ITS#8039 possibly resinfo as they make progress. Also verified all of this at runtime. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6942] updateref config is inadequate
by openldap-its＠openldap.org 13 Jun '22

13 Jun '22

https://bugs.openldap.org/show_bug.cgi?id=6942 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|--- |High --- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Fairly critical for 2.7.0 so that we can better handle replicated environments with chaining where MMR is in play. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9861] New: Read-only databases can't be opened - regression introduced with da0527ac
by openldap-its＠openldap.org 09 Jun '22

09 Jun '22

https://bugs.openldap.org/show_bug.cgi?id=9861 Issue ID: 9861 Summary: Read-only databases can't be opened - regression introduced with da0527ac Product: LMDB Version: unspecified Hardware: aarch64 OS: Mac OS Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: jocke(a)ordo.one Target Milestone: --- Created attachment 905 --> https://bugs.openldap.org/attachment.cgi?id=905&action=edit Reduced simple test to open the environment that fails The ability to open an environment in read-only mode when the file permissions is 'read only' for the user is no longer possible after the commit da0527ac75b811419b7007202799f96b2edb5aef. It is simply reproduced by creating a database with e.g. mtest.c, then changing the permissions to read-only, then running another trivial program trying to open the environment in read-only mode / no-lock mode fails. Specifically, after some investigation it seems that the check on line 5516 "if (!(flags & (MDB_RDONLY|MDB_WRITEMAP))) {" was removed in the above commit such that mdb_fopen() is called (presumably incorrectly?). Returning that guard check seems to restore functionality, but I'm not familiar enough with the code base to say that is a valid fix - but seems likely. I applied that single change here: https://github.com/hassila/swift-lmdb/tree/hassila-mdb-merge-patch with this commit: https://github.com/hassila/swift-lmdb/commit/c940b4c807c278cea43d2e3858dc22… To reproduce with a clean checkout: 1. make 2. mkdir tested 3. ./mtest 4. chmod -wx testdb/data.mdb 5. run the attached program (reduced from real code base) -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 9859] New: fix test
by openldap-its＠openldap.org 09 Jun '22

09 Jun '22

https://bugs.openldap.org/show_bug.cgi?id=9859 Issue ID: 9859 Summary: fix test Product: OpenLDAP Version: 2.5.12 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hamano(a)osstech.co.jp Target Milestone: --- Created attachment 904 --> https://bugs.openldap.org/attachment.cgi?id=904&action=edit openldap-2.5-fix_test.patch 1. specifiy modulepath and moduleload moduleload ../rel/mod.la works on build directry ex: make test but it doesn't work with installed slapd. It should be specified the modulepath and moduleload separately like other tests. ``` modulepath ../servers/slapd/overlays/ moduleload mod.la ``` 2. skip test020-proxycache for back-wt -- You are receiving this mail because: You are on the CC list for the issue.

1 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs