openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

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

27 Jun '19

--On Thursday, June 27, 2019 8:35 PM +0000 hyc(a)symas.com wrote: > No, because order is irrelevant for these. Cool, thanks! I'll continue on with deeper testing then. :) --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#8977) Make IDL sizes configurable in back-mdb
by hyc＠symas.com 27 Jun '19

27 Jun '19

Quanah Gibson-Mount wrote: > --On Tuesday, June 25, 2019 7:07 PM +0000 quanah(a)symas.com wrote: >=20 >> c) That conversion from slapd.conf to cn=3Dconfig be fixed so that it = works. >=20 >=20 > I'm not entirely sure that the fix that went in for this in ec411582d66= 3667d6b638162db51dfa70f5263d3 is correct.=C2=A0 Specifically, unlike ever= ything else, there is > no associated weight.=C2=A0 If in the future other backends (such as SQ= L, LDAP, etc) support server-wide settings via an olcBackend configuratio= n, the weight would > need to exist. >=20 > root@anvil4:/tmp/q/slapd.d/cn=3Dconfig# ls -l > total 64 > -rw------- 1 root root=C2=A0=C2=A0 448 Jun 27 12:19 'cn=3Dmodule{0}.ldi= f' > drwxr-x--- 2 root root=C2=A0 4096 Jun 27 12:19 'cn=3Dschema' > -rw------- 1 root root 39646 Jun 27 12:19 'cn=3Dschema.ldif' > -rw------- 1 root root=C2=A0=C2=A0 435 Jun 27 12:19 'olcBackend=3Dmdb.l= dif' > -rw------- 1 root root=C2=A0=C2=A0 596 Jun 27 12:19 'olcDatabase=3D{-1}= frontend.ldif' > -rw------- 1 root root=C2=A0=C2=A0 584 Jun 27 12:19 'olcDatabase=3D{0}c= onfig.ldif' > -rw------- 1 root root=C2=A0=C2=A0 859 Jun 27 12:19 'olcDatabase=3D{1}m= db.ldif' >=20 >=20 > I.e., I was rather expecting: >=20 > olcBackend=3D{1}mdb.ldif >=20 > or similar. No, because order is irrelevant for these. --=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/

1 0

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

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