openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

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

Re: [Spam?] (ITS#8577) Accesslog overlay hangs slapd depending on module loading order
by quanah＠symas.com 06 Feb '17

06 Feb '17

--On Wednesday, February 01, 2017 6:38 PM +0000 mj(a)netauth.com wrote: > Full_Name: Mike Jackson > Version: 2.4.44 > OS: Oracle Linux Server release 7.2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.157.185.162) > > > Same issue as Stroeder mentioned here: > > http://www.openldap.org/lists/openldap-bugs/201111/msg00027.html > > If accesslog.la is loaded before syncprov.la, slapd will stop accepting > connections immediately after accesslog overlay is added. To note, this was a configuration error where accesslog overlay was being configured to write ops back onto itself. We should probably check for this and reject it (vs allowing it to lock up slapd). --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8582) LMDB lockfile/mutex arch dependency
by hyc＠openldap.org 06 Feb '17

06 Feb '17

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. Hallvard has suggested that we add some additional LOCK_FORMAT bits to protect against incompatible accesses. This would primarily be useful for the mdb_stat command, which can still safely retrieve some useful information from an environment without acquiring any mutexes. E.g., an MDB_VL32 build of mdb_stat could retrieve most envinfo, statinfo, and readerinfo from a running 64bit environment. It could not scan the freelist, scan all the names of named DBs, or clean the reader list, since these operations all require taking the reader mutex.

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