openldap-bugs

openldap-bugs@openldap.org

1 participants
20997 discussions

[Issue 8665] limits documentation update for glued databases
by openldap-its＠openldap.org 27 Feb '21

27 Feb '21

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

1 0

[Issue 7790] config.h filename clash. include path broken.
by openldap-its＠openldap.org 27 Feb '21

27 Feb '21

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

1 0

[Issue 9422] New: add #define LDAP_OPT_X_TLS_PROTOCOL_TLS1_3 to ldap.h
by openldap-its＠openldap.org 27 Feb '21

27 Feb '21

https://bugs.openldap.org/show_bug.cgi?id=9422 Issue ID: 9422 Summary: add #define LDAP_OPT_X_TLS_PROTOCOL_TLS1_3 to ldap.h Product: OpenLDAP Version: 2.4.56 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: michael(a)stroeder.com Target Milestone: --- I'm not sure whether naively adding this line to ldap.h would be correct: #define LDAP_OPT_X_TLS_PROTOCOL_TLS1_3 ((3 << 8) + 4) -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 8464] Documentation for enabling monitoring via cn=config
by openldap-its＠openldap.org 27 Feb '21

27 Feb '21

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

1 0

[Issue 9102] Update sasl-secprops ssf wording
by openldap-its＠openldap.org 27 Feb '21

27 Feb '21

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

1 0

[Issue 9465] New: When compiled in debug mode ldap_get_option asserts breaking API compatibility
by openldap-its＠openldap.org 27 Feb '21

27 Feb '21

https://bugs.openldap.org/show_bug.cgi?id=9465 Issue ID: 9465 Summary: When compiled in debug mode ldap_get_option asserts breaking API compatibility Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: doug.leavitt(a)oracle.com Target Milestone: --- In a multi-threaded application, sometimes it is useful to use ldap_get_option to get the LDAP_OPT_RESULT_CODE of an operation (possibly from a different thread). A useful side effect of calling ldap_get_option is that if the connection is no longer valid, the API returns LDAP_OPT_ERR when compiled without debug per the man page: ERRORS On success, the functions return LDAP_OPT_SUCCESS, while they may return LDAP_OPT_ERROR to indicate a generic option handling error. ... However, if libldap is compiled with debugging enabled the same if test throws an assert instead of returning the documented error code, changing the behavior of the API. Specifically this assert: https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/… Compiling in debugging is useful for tracing output even in complex production environments but since there is no specific libldap API to test for valid LD* the seemingly best choice of ldap_get_option breaks in this situation. It is not clear what the original rational for the assert at this specific location was. This ITS requests removing the assert so that ldap_get_option behaves the same both with and without debugging enabled. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Bug 9197] New: slapd-ldap/slapo-chain hits error 80 after idletimeout
by openldap-its＠openldap.org 27 Feb '21

27 Feb '21

https://bugs.openldap.org/show_bug.cgi?id=9197 Bug ID: 9197 Summary: slapd-ldap/slapo-chain hits error 80 after idletimeout Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- From a customer: In order to communicate via the LB managed writable ldap, we have to ensure that an idle connection is periodically refreshed. If we do not, the LB will silently drop the connection after 5 minutes. Therefore to combat that I set an olcIdleTimeout on the writable server so that the chain cached connections will be removed before the LB timeout hits. However the slapo-ldap client goes into CLOSE_WAIT state, which causes subsequent ldapmodify updates being brokered by the read only instance to fail with err=80. There appear to be a few bugs filed on this in the past against slapd-ldap, but it's not clear if we may be hitting the same issue, or if this is a new one. I've also connected the read only instances directly to the writable ldap instances and the CLOSE_WAIT issue persists, so I don't believe the CLOSE_WAIT issue is caused by the LB These were the other threads I found as I started looking for this problem, these are using the ldap-proxy though I think: https://www.openldap.org/lists/openldap-technical/201301/msg00323.html http://www.openldap.org/lists/openldap-software/201004/msg00060.html https://www.openldap.org/lists/openldap-bugs/200412/msg00029.html The LB we have seems to be set to forget connections that last over 5 min per the setting, so the 240:10:30 seemed like it should have worked and I just thought it wasn't working because in the man page the text "Only some systems support the customization of these values" is present. however after setting keepalive to 60:10:30 did I maintain a stable connection, so there may be other network settings at play I'm not aware of. -- You are receiving this mail because: You are on the CC list for the bug.

1 14

[Issue 9450] New: INSTALL file needs updating
by openldap-its＠openldap.org 27 Feb '21

27 Feb '21

https://bugs.openldap.org/show_bug.cgi?id=9450 Issue ID: 9450 Summary: INSTALL file needs updating Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- The file "INSTALL" in the root of the source repository needs to be updated to account for the new load balancer. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 8248] misleading information in manpage about the use of the logfile option
by openldap-its＠openldap.org 27 Feb '21

27 Feb '21

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

1 0

[Issue 8904] Cannot enable SSL3 when disabled by default in OpenSSL
by openldap-its＠openldap.org 27 Feb '21

27 Feb '21

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

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