openldap-bugs June 2019

openldap-bugs@openldap.org

27 participants
104 discussions

Re: (ITS#8977) Make IDL sizes configurable in back-mdb
by quanah＠symas.com 27 Jun '19

27 Jun '19

--On Tuesday, June 25, 2019 7:07 PM +0000 quanah(a)symas.com wrote: > c) That conversion from slapd.conf to cn=config be fixed so that it works. I'm not entirely sure that the fix that went in for this in ec411582d663667d6b638162db51dfa70f5263d3 is correct. Specifically, unlike everything else, there is no associated weight. If in the future other backends (such as SQL, LDAP, etc) support server-wide settings via an olcBackend configuration, the weight would need to exist. root@anvil4:/tmp/q/slapd.d/cn=config# ls -l total 64 -rw------- 1 root root 448 Jun 27 12:19 'cn=module{0}.ldif' drwxr-x--- 2 root root 4096 Jun 27 12:19 'cn=schema' -rw------- 1 root root 39646 Jun 27 12:19 'cn=schema.ldif' -rw------- 1 root root 435 Jun 27 12:19 'olcBackend=mdb.ldif' -rw------- 1 root root 596 Jun 27 12:19 'olcDatabase={-1}frontend.ldif' -rw------- 1 root root 584 Jun 27 12:19 'olcDatabase={0}config.ldif' -rw------- 1 root root 859 Jun 27 12:19 'olcDatabase={1}mdb.ldif' I.e., I was rather expecting: olcBackend={1}mdb.ldif or similar. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#9043) Improve loglevel sync logging
by ondra＠openldap.org 26 Jun '19

26 Jun '19

Full_Name: Ondrej Kuznik Version: master OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.10.24.68) The existing replication logs are quite hard to follow. In syncprov, messages about different sessions mingle with no indication where they belong and many important replication decisions are not logged at all. And what is logged is very hard to follow and understand why the provider/consumer does what it does. The following could be done to improve matters: - prepend the request information to syncprov messages - add information to existing messages, especially human-readable commentary that can be followed as a story, giving context in terms of "X happened so doing Y" - log when checkpoints happen, what cookies are generated and why, ... Most of the above is drafted here: https://github.com/mistotebe/openldap/tree/its9043

1 0

Re: (ITS#8977) Make IDL sizes configurable in back-mdb
by quanah＠symas.com 25 Jun '19

25 Jun '19

--On Monday, May 06, 2019 9:28 PM +0000 quanah(a)symas.com wrote: To further document the issues after further testing with OpenLDAP master as of 6/25/2019 a) If a value for idlexp is set in a slapd.conf file that is not allowed (< 16 or > 31), converting to cn=config using slaptest will incorrectly report that the target "slapd.d" directory doesn't exist, like: /usr/local/etc/openldap# /usr/local/sbin/slaptest -f slapd.conf -F /tmp/slapd.d slaptest: bad configuration directory! ls -ld /tmp/slapd.d drwxr-xr-x 2 root root 40 Jun 25 17:59 /tmp/slapd.d b) If the idlexp value is corrected to be within the allowed range, the converted cn=config database loses the backend configuration and the idlexp setting: /usr/local/sbin/slaptest -f slapd.conf -F /tmp/slapd.d config file testing succeeded cd /tmp/slapd.d/ find . -type f | xargs grep -i idlexp ./cn=config/cn=schema.ldif:olcAttributeTypes: ( OLcfgBkAt:12.1 NAME 'olcBkMdbIdlExp' DESC 'Power of 2 u ./cn=config/cn=schema.ldif: onfiguration' SUP olcBackendConfig STRUCTURAL MAY olcBkMdbIdlExp ) No olcBackend... file exists, etc. Suggested remedies: a) The man page documentation be updated to note the limitations on valid ranges for the idlexp setting (16<=x<=31), at least for 64-bit systems. b) slaptest provides a valid error if the idlexp setting is not within the valid range (as opposed to complaining the target directory does not exist, when in fact it does). c) That conversion from slapd.conf to cn=config be fixed so that it works. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#9042) loglevel setting that allows seeing attribute values for MOD operations
by quanah＠symas.com 25 Jun '19

25 Jun '19

--On Tuesday, June 25, 2019 5:04 PM +0000 quanah(a)openldap.org wrote: > Currently there is no way to see what values a client is providing for a > MOD operation outside of the "packets" debug level. It would be helpful > for debugging purposes where one does not have control of the client to > be able to set a loglevel that would expose this information. STATS2 would be the appropriate loglevel setting. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#9042) loglevel setting that allows seeing attribute values for MOD operations
by quanah＠openldap.org 25 Jun '19

25 Jun '19

Full_Name: Quanah Gibson-Mount Version: HEAD OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.128.44) Currently there is no way to see what values a client is providing for a MOD operation outside of the "packets" debug level. It would be helpful for debugging purposes where one does not have control of the client to be able to set a loglevel that would expose this information.

1 0

Re: (ITS#9041) cyrus.c includes limits.h twice
by quanah＠symas.com 25 Jun '19

25 Jun '19

--On Friday, June 21, 2019 10:58 PM +0000 quanah(a)openldap.org wrote: > This should be cleaned up. Fixed in b02807ea2f5eaf85e57e67e5851931a116947b94 --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#7996) Tighten race in ldap_int_initialize
by Armin.Tueting＠tueting-online.com 23 Jun '19

23 Jun '19

Am Freitag, den 21.06.2019, 13:31 +0200 schrieb Ond=C5=99ej Kuzn=C3=ADk: [...] > Hi Armin, Hi Ondrej, > thank you very much for your report, this should now be fixed in master > with commit b2f4cacd4783cfe49370accc712863f9537f9924. I'm not following 'master' - I'm afraid! But, the commit has been merged into 'OPENLDAP_REL_ENG_2_4' and slapd is now serving our requests! So far, so good! Thanks for your effort! >=20 > Regards, Regards, Armin.

1 0

(ITS#9041) cyrus.c includes limits.h twice
by quanah＠openldap.org 21 Jun '19

21 Jun '19

Full_Name: Quanah Gibson-Mount Version: RE24 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.128.44) There appear to have been dueling commits on April 10, 2005 and April 9, 2005, so that we get: 3e800f20bd (Kurt Zeilenga 2005-04-10 19:32:14 +0000 28)#ifdef HAVE_LIMITS_H 3e800f20bd (Kurt Zeilenga 2005-04-10 19:32:14 +0000 29)#include <limits.h> 3e800f20bd (Kurt Zeilenga 2005-04-10 19:32:14 +0000 30)#endif 3e800f20bd (Kurt Zeilenga 2005-04-10 19:32:14 +0000 31) bc0cc3272c (Kurt Zeilenga 2003-02-21 17:48:03 +0000 32)#include "ldap-int.h" bc0cc3272c (Kurt Zeilenga 2003-02-21 17:48:03 +0000 33) bc0cc3272c (Kurt Zeilenga 2003-02-21 17:48:03 +0000 34)#ifdef HAVE_CYRUS_SASL bc0cc3272c (Kurt Zeilenga 2003-02-21 17:48:03 +0000 35) eca819d866 (Howard Chu 2005-04-09 06:41:39 +0000 36)#ifdef HAVE_LIMITS_H eca819d866 (Howard Chu 2005-04-09 06:41:39 +0000 37)#include <limits.h> eca819d866 (Howard Chu 2005-04-09 06:41:39 +0000 38)#endif This should be cleaned up.

1 0

Re: (ITS#9037) observing crash in mdb_cursor_put()
by myk＠mykzilla.org 21 Jun '19

21 Jun '19

After stepping through the test program in a debugger, I see that mdb_page_search returns MDB_NOTFOUND if mc->mc_db->md_root is P_INVALID because the tree is empty. And mdb_cursor_put sets rc to MDB_NO_ROOT if mc->mc_db->md_root is P_INVALID. So that can't be related to the crash, at least not in the instances I'm investigating, because insert_key and insert_data (and hence rc) is always MDB_NOTFOUND in their minidumps when the crash occurs, which can't happen when rc is set to MDB_NO_ROOT. -myk

1 0

Re: (ITS#7996) Tighten race in ldap_int_initialize
by ondra＠mistotebe.net 21 Jun '19

21 Jun '19

On Tue, Jun 18, 2019 at 07:33:48AM +0000, Armin.Tueting(a)tueting-online.com wrote: > Am Montag, den 17.06.2019, 15:40 -0700 schrieb Quanah Gibson-Mount: >> --On Monday, June 17, 2019 7:16 PM +0200 Armin T=C3=BCting=20 >> <Armin.Tueting(a)tueting-online.com> wrote: >>>> I.e., it started and then got as far as reading your ldap.conf file. >>>> What is the contents of ldap.conf? >>> Attached 'ldap.conf'. Nothing unusual... >>> >>>> Have you run the test suite (make test)? Does it pass? fail? >>> Attached 'make_test.txt'. As far as I can see - it has been passed. >> >> Ok, so make test passes without issue, so it would appear there's something >> specific with your configuration that is triggering the problem. Would you >> be able to provide your slapd configuration (minus any passwords and the >> like)? > I'll privately send it to you in a seperate email. > >> >> Additionally, if you could get a full gdb backtrace of the hung slapd=20 >> process that would be useful as well. I.e.: >> >> start up slapd >> gdb /path/to/slapd <pid #> > (gdb) thr apply all bt full > #3 0x00007ffa4a92a135 in ldap_pvt_thread_mutex_lock > #4 0x00007ffa4a944e6e in ldap_set_option > #5 0x00007ffa4a943ed3 in openldap_ldap_init_w_conf > #6 0x00007ffa4a944318 in openldap_ldap_init_w_sysconf > #8 0x00007ffa4a944e38 in ldap_set_option > #9 0x0000000000413cd6 in main () Hi Armin, thank you very much for your report, this should now be fixed in master with commit b2f4cacd4783cfe49370accc712863f9537f9924. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs June 2019