openldap-bugs April 2020

openldap-bugs@openldap.org

2 participants
338 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 #8 from Howard Chu <hyc(a)openldap.org> --- (In reply to Quanah Gibson-Mount from comment #7) > 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. For this particular example, just delete "slapd(8) must be compiled with thread support, and " -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 5500] comments in cn=config entries
by openldap-its＠openldap.org 22 Apr '20

22 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=5500 --- Comment #4 from Karl O. Pinc <kop(a)karlpinc.com> --- The problem with adding an attribute is that this means that comments are per-entry, and cannot be associated with specific attribute values. Having to write comments on an entry that apply to a specific attribute value means having to describe the attribute's value within the comment. Most of my comments have to do with particular attribute values, so this would be awkward -- both for writer and reader. Below is an alternative design. It supports commenting both entries and attributes and working with commented ldif files in an "expected" way. The downside is that this design does not provide a "natural" user interface. Generic LDAP clients would not readily associate comment text with the entries or attributes commented. The OpenLDAP client tools would need to be used to produce and consume "commented ldif" files. No reason why this alternative design could not be implemented alongside the design previously proposed. Have a cn=comment,cn=config subtree. The dn is index=X,attribute=Y,EntryUUID=Z,cn=comment,cn=config. (Where index is the index of the commented attribute when an attribute is multi-valued.) Keep all the comments there. Index and attribute would be optional in the dn; when omitted the comment is on the entry. Pass a flag to ldapmodify and ldapadd so that comments are preserved on input, and a flag for ldapsearch to output such comments. The flag would only work on the cn=config DIT. Comments appearing in an ldif before a dn are attached to the entry. Comments appearing before an attribute are attached to the attribute. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[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 21 Apr '20

21 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

← Newer
1
...
10
11
12
13
14
15
16
...
34
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2020