openldap-bugs

openldap-bugs@openldap.org

20977 discussions

[Bug 8614] Test suite fails when using --with-threads=no
by openldap-its＠openldap.org 22 Apr '20

22 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=8614 --- Comment #7 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Need to check the various man pages etc about threads. For example, slapd-ldap(5) has: Note: When looping back to the same instance of slapd(8), each connection requires a new thread; as a consequence, slapd(8) must be compiled with thread support, and the threads parameter may need some tuning; in those cases, one may consider using slapd-relay(5) instead, which performs the relayed operation internally and thus reuses the same connection. slapd always will have thread support in 2.5+, so the wording needs adjustment. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 6740] syncrepl/--disable-rewrite dependency
by openldap-its＠openldap.org 22 Apr '20

22 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=6740 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |TEST Keywords|OL_2_5_REQ | --- Comment #11 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Commits: • bc9a9286 by Quanah Gibson-Mount at 2020-04-22T14:49:10+00:00 ITS#6740 - Always enable rewrite -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 8575] Argon2 Password hashing contrib module
by openldap-its＠openldap.org 22 Apr '20

22 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=8575 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|TEST |FIXED Target Milestone|--- |2.4.50 -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 9098] assert fails in meta_back_search in some cases after reconnect
by openldap-its＠openldap.org 21 Apr '20

21 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=9098 --- Comment #16 from maxime.besson(a)worteks.com <maxime.besson(a)worteks.com> --- The issues started appearing because one of the ldap-meta backends tended to become unreachable (through a site to site VPN) during the night. In the log I just attached, you will see that a bunch of backends become unreachable at the same time, which, from what I could gather, comes from temporary routing issues on the OpenLDAP side. One of my log traces however shows a crash (same stack trace again): Jan 10 13:51:29 slapd.service: Main process exited, code=killed, status=6/ABRT happening 10 seconds after a retry, instead of immediately after it Jan 10 13:51:19 slapd[1409]: conn=62130 op=1 meta_back_retry[7]: meta_back_single_dobind=52 And no other backends had connectivity issues at the time. In all of these cases, the local NIC was still online but the network issues were occuring somewhere else (router, VPN gateway...) One important, related information from my original report is that we had no crashing issues before we set up backend timeouts (but of course, when a backend went down and no timeouts were in place, searches became completely unresponsive and ended up saturating all available openldap threads) -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 9098] assert fails in meta_back_search in some cases after reconnect
by openldap-its＠openldap.org 21 Apr '20

21 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=9098 --- Comment #15 from nivanova(a)symas.com <nivanova(a)symas.com> --- (In reply to maxime.besson(a)worteks.com from comment #13) > Created attachment 713 [details] > syslog traces a minute before an assert crash in 2.4.47 > Thank you! At this point I think the anonymised version will be enough, but we'll get in touch if for some reason we need the real logs. What we are interested in is what is happening to the particular connection in the seconds leading up to the accident, for example was meta trying to re-bind it, were there any errors logged that involved it, etc, and database information is not relevant to that anyway. It would be helpful to know, if you can clarify without revealing sensitive information, what does network interruption mean exactly in this case - e. g the remote targets become unreachable, but the network interface on the machine running the front meta is operational? Best Regards, Nadya Nadezhda Ivanova Software Developer @ Symas Corp. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 9098] assert fails in meta_back_search in some cases after reconnect
by openldap-its＠openldap.org 21 Apr '20

21 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=9098 --- Comment #14 from maxime.besson(a)worteks.com <maxime.besson(a)worteks.com> --- Created attachment 714 --> https://bugs.openldap.org/attachment.cgi?id=714&action=edit backtrace for 2.4.47 corresponding to the provided syslog -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 9098] assert fails in meta_back_search in some cases after reconnect
by openldap-its＠openldap.org 21 Apr '20

21 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=9098 --- Comment #13 from maxime.besson(a)worteks.com <maxime.besson(a)worteks.com> --- Created attachment 713 --> https://bugs.openldap.org/attachment.cgi?id=713&action=edit syslog traces a minute before an assert crash in 2.4.47 I do not have the syslog traces for that backtrace I sent earlier, however I do have a backtrace and syslogs for a 2.4.47 crash. You'll find it looks very similar to 2.4.48. I'm attaching these, but since they come from a security sensitive environment I will have to anonymize them, hopefully there will be enough information. If you need the full logs and core dumps, let me know how we can proceed administratively speaking. Because I'm pretty sure this will have to involve an NDA in some form. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 9098] assert fails in meta_back_search in some cases after reconnect
by openldap-its＠openldap.org 21 Apr '20

21 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=9098 --- Comment #12 from nivanova(a)symas.com <nivanova(a)symas.com> --- We are looking into this issue and are trying to reproduce it. In the mean time - are there any logs from immediately before the crash (preferably from the same crash that generated the back traces you provided), that you can share with us? Best Regards, Nadya Nadezhda Ivanova Software Developer @ Symas Corp. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 9231] New: LDAP_USE_NON_BLOCKING_TLS not defined in tls_o.c
by openldap-its＠openldap.org 20 Apr '20

20 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=9231 Bug ID: 9231 Summary: LDAP_USE_NON_BLOCKING_TLS not defined in tls_o.c Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- 81588880852e83e094fea5c0b3dc7c75cf39112c (ITS#8980) added code in tls_o.c that's conditional on LDAP_USE_NON_BLOCKING_TLS. However, it's only defined in tls2.c, not in any common header. I suspect that patch might have been developed with -DLDAP_USE_NON_BLOCKING_TLS added on the command line. I further suspect that this addition might not even be needed at all, after fixing ITS#8650. To do: - test async connect behaviour before/after ITS#8980 (confirm the bug and fix) - determine whether the added code is still needed, either delete it or move the #define to a header so it's actually effective -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 8614] Test suite fails when using --with-threads=no
by openldap-its＠openldap.org 20 Apr '20

20 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=8614 --- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> --- (In reply to Ryan Tandy from comment #5) > We should keep the ability to specify the threads library by > --with-threads=<impl>, and only remove the --without-threads option. > > We're still going to ship some libldap.so -> libldap_r.so symlinks in order > to avoid breaking everyone's Makefiles, correct? Yep to both. We'll delete back-shell/back-perl from the 2.5 release tree specifically, no point in shipping them, but leave them in master for reference. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

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