openldap-bugs February 2017

openldap-bugs@openldap.org

22 participants
59 discussions

Re: (ITS#8581) slapd-meta backend SSL negociation timeout
by louis.chanouha＠test.univ-toulouse.fr 10 Feb '17

10 Feb '17

I tried with ltb's latest Jessie builds but same problem occurs. I fast-checked tls_o.c, i can't find any code relative to handshake timeout (https://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=libraries…), but as i never handle any ssl lib code, i can be completely mistaken. On Jessie, default timeout on gnuTLS seems to be 3600 secs, I will try to wait. /usr/local/openldap/libexec/slapd -V @(#) $OpenLDAP: slapd 2.4.44 (Feb 8 2016 17:34:53) $ root@debian8:/opt/paquet-openldap-debian/openldap-ltb-2.4.44/servers/slapd

1 0

Re: (ITS#8582) LMDB lockfile/mutex arch dependency
by hyc＠symas.com 09 Feb '17

09 Feb '17

hyc(a)openldap.org wrote: > Full_Name: Howard Chu > Version: HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.235.15.200) > Submitted by: hyc > > > I ran into some corruption problems when running a 64bit LMDB process concurrent > with a 32bit one using MDB_VL32. While LMDB's own structures are all 64bit clean > in a VL32 build, unfortunately pthread_mutex_t structures are not. In > particular, in glibc a pthread_mutex_t can be one of 3 different sizes - 24 > bytes for 32bit runtime on 32bit processor, 32 bytes for 32bit runtime on > x86-64, and 40 bytes for 64bit runtime on x86-64. As such, we cannot safely > share an LMDB environment between 32 and 64bit Linux processes, even when using > MDB_VL32. > > This problem doesn't affect Windows, platforms using SysV semaphores, or > platforms using POSIX named semaphores. I don't currently know whether this is a > problem on other platforms that support POSIX process-shared mutexes. For glibc, I've submitted an enhancement request regarding mutex sizes: https://sourceware.org/bugzilla/show_bug.cgi?id=21119 -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8584) reloadhint for syncprov overlay should default to TRUE
by quanah＠symas.com 07 Feb '17

07 Feb '17

> On Feb 7, 2017, at 10:25 AM, hyc(a)symas.com wrote: >=20 > Quanah Gibson-Mount wrote: >> --On Tuesday, February 07, 2017 8:53 AM +0000 Howard Chu <hyc(a)symas.com> w= rote: >>=20 >>=20 >>> The relevant part of the doc is "It must be set TRUE when using the >>> accesslog overlay for delta-based syncrepl support." Otherwise it has no= >>> effect, so there is no reason to change it in the default case. >>=20 >> Actually, what the manpage says is: >>=20 >> This option should be set TRUE when working with >> newer releases that properly support this flag. It must be set >> TRUE when using the accesslog overlay for delta-based syncrepl >> replication support. >>=20 >> So, that clearly states it should *always* be TRUE unless you have a 2.3.= 11 or >> earlier consumer, which is technically not allowable. There is zero reas= on >> for this tunable to exist. It should be deprecated and the internal code= >> changed to simply set the flag to TRUE. One less item for anyone to have= to >> ever deal with is a win. >=20 > "when working with newer releases that properly support this flag." >=20 > The syncrepl consumer only pays attention to this flag in delta-sync. Ther= e is=20 > no reason to use reloadhint in regular syncrepl. Turning it on by default o= nly=20 > slows down the refresh negotiation in regular syncrepl. >=20 > --=20 > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ >=20 Then the man page needs updating since the information on it is blatantly wr= ong. The "newer releases" is clearly indicated to be anything later than 2.= 3.11. --Quanah=

1 0

Re: (ITS#8584) reloadhint for syncprov overlay should default to TRUE
by hyc＠symas.com 07 Feb '17

07 Feb '17

Quanah Gibson-Mount wrote: > --On Tuesday, February 07, 2017 8:53 AM +0000 Howard Chu <hyc(a)symas.com> wrote: > > >> The relevant part of the doc is "It must be set TRUE when using the >> accesslog overlay for delta-based syncrepl support." Otherwise it has no >> effect, so there is no reason to change it in the default case. > > Actually, what the manpage says is: > > This option should be set TRUE when working with > newer releases that properly support this flag. It must be set > TRUE when using the accesslog overlay for delta-based syncrepl > replication support. > > So, that clearly states it should *always* be TRUE unless you have a 2.3.11 or > earlier consumer, which is technically not allowable. There is zero reason > for this tunable to exist. It should be deprecated and the internal code > changed to simply set the flag to TRUE. One less item for anyone to have to > ever deal with is a win. "when working with newer releases that properly support this flag." The syncrepl consumer only pays attention to this flag in delta-sync. There is no reason to use reloadhint in regular syncrepl. Turning it on by default only slows down the refresh negotiation in regular syncrepl. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8584) reloadhint for syncprov overlay should default to TRUE
by quanah＠symas.com 07 Feb '17

07 Feb '17

--On Tuesday, February 07, 2017 8:53 AM +0000 Howard Chu <hyc(a)symas.com> wrote: > The relevant part of the doc is "It must be set TRUE when using the > accesslog overlay for delta-based syncrepl support." Otherwise it has no > effect, so there is no reason to change it in the default case. Actually, what the manpage says is: This option should be set TRUE when working with newer releases that properly support this flag. It must be set TRUE when using the accesslog overlay for delta-based syncrepl replication support. So, that clearly states it should *always* be TRUE unless you have a 2.3.11 or earlier consumer, which is technically not allowable. There is zero reason for this tunable to exist. It should be deprecated and the internal code changed to simply set the flag to TRUE. One less item for anyone to have to ever deal with is a win. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8585) assert in ber_get_next after connection error
by hyc＠openldap.org 07 Feb '17

07 Feb '17

Full_Name: Howard Chu Version: any OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.235.15.200) Submitted by: hyc 1) ldap_result() returns -1 with ld_errno = LDAP_LOCAL_ERROR because it read an unrecognizable message from the network. 2) ldap_result() is called again on the same LDAP*. During (1) the lc->lconn_ber was not zeroed out so it is used again in (2). But ber_get_next() already fully parsed its input during (1) so this assert fails on the 2nd call: 513 if (ber->ber_rwptr == NULL) { 514 assert( ber->ber_buf == NULL ); 515 ber->ber_rwptr = (char *) &ber->ber_len-1; 516 ber->ber_ptr = ber->ber_ptr%r; 517 ber->ber_tag = 0; 518 } ldap_result() should clear lconn_ber before returning with an error. The LDAP* session probably should not be used again after (1) anyway but this is still messy.

1 0

Re: (ITS#8584) reloadhint for syncprov overlay should default to TRUE
by hyc＠symas.com 07 Feb '17

07 Feb '17

quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.44 > OS: N/A > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (47.208.148.26) > > > The "reloadhint" option for the syncprov overlay currently defaults to FALSE. > However, the documentation clearly notes that you want to set it to true for any > release > 2.3.11. Given that 2.3 has been obsolete for years and it has been > over 11 years since the release of 2.3.11, we should really fix the default > value, and note that it should be changed if and only if there is a consumer > running 2.3.11 or prior. The relevant part of the doc is "It must be set TRUE when using the accesslog overlay for delta-based syncrepl support." Otherwise it has no effect, so there is no reason to change it in the default case. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8584) reloadhint for syncprov overlay should default to TRUE
by quanah＠symas.com 06 Feb '17

06 Feb '17

--On Monday, February 06, 2017 11:54 PM +0000 quanah(a)openldap.org wrote: > The "reloadhint" option for the syncprov overlay currently defaults to > FALSE. However, the documentation clearly notes that you want to set it > to true for any release > 2.3.11. Given that 2.3 has been obsolete for > years and it has been over 11 years since the release of 2.3.11, we > should really fix the default value, and note that it should be changed > if and only if there is a consumer running 2.3.11 or prior. Actually, since it is not a valid configuration scenario to have a 2.4 provider and a 2.3 consumer, it seems that the configuration option should be deprecated entirely, and the internal code simply default to TRUE. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8584) reloadhint for syncprov overlay should default to TRUE
by quanah＠openldap.org 06 Feb '17

06 Feb '17

Full_Name: Quanah Gibson-Mount Version: 2.4.44 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.26) The "reloadhint" option for the syncprov overlay currently defaults to FALSE. However, the documentation clearly notes that you want to set it to true for any release > 2.3.11. Given that 2.3 has been obsolete for years and it has been over 11 years since the release of 2.3.11, we should really fix the default value, and note that it should be changed if and only if there is a consumer running 2.3.11 or prior.

1 0

(ITS#8583) LDAPCtrl::LDAPCtrl(const LDAPControl* ctrl) issue
by jim.rooks＠neustar.biz 06 Feb '17

06 Feb '17

Full_Name: Jim Rooks Version: 2.4.44 OS: RedHat 6.8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (104.129.194.54) The following code in contrib/ldapc++/src/LDAPControl.cpp needs to be corrected: LDAPCtrl::LDAPCtrl(const LDAPControl* ctrl){ DEBUG(LDAP_DEBUG_CONSTRUCT,"LDAPCtrl::LDAPCtrl()" << endl); m_oid = string(ctrl->ldctl_oid); m_oid = ctrl->ldctl_iscritical ? true : false; m_oid = string(ctrl->ldctl_value.bv_val, ctrl->ldctl_value.bv_len ); } to something like: LDAPCtrl::LDAPCtrl(const LDAPControl* ctrl){ DEBUG(LDAP_DEBUG_CONSTRUCT,"LDAPCtrl::LDAPCtrl()" << endl); m_oid = string(ctrl->ldctl_oid); m_isCritical = ctrl->ldctl_iscritical ? true : false; m_data = string(ctrl->ldctl_value.bv_val, ctrl->ldctl_value.bv_len ); m_noData = ctrl->ldctl_value.bv_len ? false : true; }

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2017