openldap-bugs April 2013

openldap-bugs@openldap.org

27 participants
76 discussions

Re: ITS#7518
by hyc＠symas.com 23 Apr '13

23 Apr '13

Matthew.Monaco(a)colorado.edu wrote: > commit c3411fb breaks building, reverting on OPENLDAP_REL_ENG_2_4 allows me to build > > were updated files omitted from the nss-pam-ldapd directory? Yes, it looks like it. Updated files now pushed to git master, thanks for the report. -- -- 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#7518
by Matthew.Monaco＠colorado.edu 23 Apr '13

23 Apr '13

commit c3411fb breaks building, reverting on OPENLDAP_REL_ENG_2_4 allows me to build were updated files omitted from the nss-pam-ldapd directory?

1 0

Re: (ITS#7576) olcLogFile does not work on Ubuntu 12.04
by quanah＠zimbra.com 18 Apr '13

18 Apr '13

--On Tuesday, April 16, 2013 5:06 PM +0000 hvnsweeting(a)gmail.com wrote: > Full_Name: Nguyen Viet Hung > Version: 2.4.28 > OS: Ubuntu 12.04 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (123.16.114.114) > > > I tried this directive on Ubuntu but it does not work. > Someone on openldap IRC said that > "olclogfile is only used on windows, because it lacks syslog" > > If he is right, please do change OpenLDAP document to make this less > confusing. Thanks Incorrect. Please read the slapd-config(5) man page. There is no issue using the logfile on linux. If you have questions on how to create one, please follow up with the openldap-technical list. This ITS will be closed. I would generally note that on linux setting the olcLogfile is not necessary, but if you must catch the stderr messages, you may which to do so. I would also note the version of OpenLDAP you are using is quite ancient. You'd be better served to upgrade to a current release. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7576) olcLogFile does not work on Ubuntu 12.04
by hvnsweeting＠gmail.com 16 Apr '13

16 Apr '13

Full_Name: Nguyen Viet Hung Version: 2.4.28 OS: Ubuntu 12.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.16.114.114) I tried this directive on Ubuntu but it does not work. Someone on openldap IRC said that "olclogfile is only used on windows, because it lacks syslog" If he is right, please do change OpenLDAP document to make this less confusing. Thanks

1 0

Re: (ITS#7570) fix MDB_GET_MULTIPLE and MDB_NEXT_MULTIPLE behaviour
by claude.brisson＠gmail.com 16 Apr '13

16 Apr '13

Ok, I understand, now. I totally overlooked the definition of MDB_NEXT_MULTIPLE, which I believed was here to return all the duplicate of the next key. Really sorry about all that noise. You may be interested in keeping the following little change from my patch, though: @@ -4377,6 +4377,8 @@ mdb_cursor_next(MDB_cursor *mc, MDB_val *key, MDB_val *data, MDB_cursor_op op) rc = mdb_cursor_first(&mc->mc_xcursor->mx_cursor, data, NULL); if (rc != MDB_SUCCESS) return rc; + } else if (mc->mc_db->md_flags & MDB_DUPSORT) { + mc->mc_xcursor->mx_cursor.mc_flags &= ~C_INITIALIZED; } } mdb_cursor_next should invalidate mx_cursor when there is no duplicate data for the current key. It's maybe useless if we are sure that we won't ever rely on this flag thereafter, but it's certainly safer. Regards, Claude On Mon, 15 Apr 2013 13:42:40 -0700 Howard Chu <hyc(a)symas.com> wrote: > claude.brisson(a)gmail.com wrote: > > On Mon, 15 Apr 2013 20:01:01 GMT > > hyc(a)symas.com wrote: > > > >> Your patch changes the meaning of these operations. > >> GET_MULTIPLE/NEXT_MULTIPLE is *only* for duplicate data and already > >> documented as such. > > > > The documentation in the header never states that MULTIPLE > > operations should *fail* on singletons. One could expect that the > > sentence "Return all the duplicate data items at the current cursor > > position" means that singletons will *also* be returned, without > > having to resort to a second call in case of failure. > > > >> Your patch makes them return non-duplicate data. This is a > >> fundamental change in an established behavior. A complete break, > >> actually; it will return data that doesn't match the key that the > >> client requested. It is completely wrong. > > > > I'm sorry if it broke something and made you loose your time, I was > > trying to help here. But the only change is to return singletons > > instead of MDB_NOTFOUND - the data will always match the key. > > No. This is in your patch: > > @@ -4803,7 +4806,7 @@ mdb_cursor_get(MDB_cursor *mc, MDB_val *key, > MDB_val *data, if (!(mc->mc_flags & C_INITIALIZED)) > rc = mdb_cursor_first(mc, key, data); > else > - rc = mdb_cursor_next(mc, key, data, > MDB_NEXT_DUP); > + rc = mdb_cursor_next(mc, key, data, > MDB_NEXT_NODUP); if (rc == MDB_SUCCESS) { > if (mc->mc_xcursor->mx_cursor.mc_flags & > C_INITIALIZED) { MDB_cursor *mx; > > So you've made it return non-matching data. > > > Maybe I missed something, here. But I wonder why the client code > > should at any point *expect* truly duplicate data. > > That is the sole purpose of these options. > > Re-read the description: > > MDB_GET_MULTIPLE, /**< Return all the duplicate data items > at the current > cursor position. Only for > #MDB_DUPFIXED */ > > If the current cursor position is a singleton, then you already have > its data if you positioned the cursor using (&key, &data) so there is > no need to make any further calls anyway. >

1 0

Re: (ITS#7570) fix MDB_GET_MULTIPLE and MDB_NEXT_MULTIPLE behaviour
by hyc＠symas.com 15 Apr '13

15 Apr '13

claude.brisson(a)gmail.com wrote: > On Mon, 15 Apr 2013 20:01:01 GMT > hyc(a)symas.com wrote: > >> Your patch changes the meaning of these operations. >> GET_MULTIPLE/NEXT_MULTIPLE is *only* for duplicate data and already >> documented as such. > > The documentation in the header never states that MULTIPLE operations > should *fail* on singletons. One could expect that the sentence "Return > all the duplicate data items at the current cursor position" means > that singletons will *also* be returned, without having to resort to a > second call in case of failure. > >> Your patch makes them return non-duplicate data. This is a >> fundamental change in an established behavior. A complete break, >> actually; it will return data that doesn't match the key that the >> client requested. It is completely wrong. > > I'm sorry if it broke something and made you loose your time, I was > trying to help here. But the only change is to return singletons > instead of MDB_NOTFOUND - the data will always match the key. No. This is in your patch: @@ -4803,7 +4806,7 @@ mdb_cursor_get(MDB_cursor *mc, MDB_val *key, MDB_val *data, if (!(mc->mc_flags & C_INITIALIZED)) rc = mdb_cursor_first(mc, key, data); else - rc = mdb_cursor_next(mc, key, data, MDB_NEXT_DUP); + rc = mdb_cursor_next(mc, key, data, MDB_NEXT_NODUP); if (rc == MDB_SUCCESS) { if (mc->mc_xcursor->mx_cursor.mc_flags & C_INITIALIZED) { MDB_cursor *mx; So you've made it return non-matching data. > Maybe I missed something, here. But I wonder why the client code should > at any point *expect* truly duplicate data. That is the sole purpose of these options. Re-read the description: MDB_GET_MULTIPLE, /**< Return all the duplicate data items at the current cursor position. Only for #MDB_DUPFIXED */ If the current cursor position is a singleton, then you already have its data if you positioned the cursor using (&key, &data) so there is no need to make any further calls anyway. -- -- 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#7570) fix MDB_GET_MULTIPLE and MDB_NEXT_MULTIPLE behaviour
by claude.brisson＠gmail.com 15 Apr '13

15 Apr '13

On Mon, 15 Apr 2013 20:01:01 GMT hyc(a)symas.com wrote: > Your patch changes the meaning of these operations. > GET_MULTIPLE/NEXT_MULTIPLE is *only* for duplicate data and already > documented as such. The documentation in the header never states that MULTIPLE operations should *fail* on singletons. One could expect that the sentence "Return all the duplicate data items at the current cursor position" means that singletons will *also* be returned, without having to resort to a second call in case of failure. > Your patch makes them return non-duplicate data. This is a > fundamental change in an established behavior. A complete break, > actually; it will return data that doesn't match the key that the > client requested. It is completely wrong. I'm sorry if it broke something and made you loose your time, I was trying to help here. But the only change is to return singletons instead of MDB_NOTFOUND - the data will always match the key. Maybe I missed something, here. But I wonder why the client code should at any point *expect* truly duplicate data. Regards, Claude

1 0

Re: (ITS#7570) fix MDB_GET_MULTIPLE and MDB_NEXT_MULTIPLE behaviour
by hyc＠symas.com 15 Apr '13

15 Apr '13

Claude Brisson wrote: > So it means the following: with the current code, when the client code > wants to optimize transfers with GET_MULTIPLE/NEXT_MULTIPLE, it has to > fall back to standard GET/NEXT whenever it encounters MDB_NOTFOUND. > Whereas the patch assumes that GET_MULTIPLE/NEXT_MULTIPLE will not > depend on the number of records. > > IMHO, the current behavior is a bit cumbersome. Would it be that > complex to update the client code? Your patch changes the meaning of these operations. GET_MULTIPLE/NEXT_MULTIPLE is *only* for duplicate data and already documented as such. Your patch makes them return non-duplicate data. This is a fundamental change in an established behavior. A complete break, actually; it will return data that doesn't match the key that the client requested. It is completely wrong. > > Claude > > On Sun, 14 Apr 2013 23:56:41 GMT > hyc(a)symas.com wrote: > >> hyc(a)symas.com wrote: >>> claude.brisson(a)gmail.com wrote: >>>> Full_Name: Claude Brisson >>>> Version: HEAD >>>> OS: linux 64 >>>> URL: >>>> ftp://ftp.openldap.org/incoming/0001-fix-MDB_GET_MULTIPLE-and-MDB_NEXT_MULT… >>>> Submission from: (NULL) (84.103.74.130) >>>> >>>> >>>> In a db with MDB_DUPSORT flag, when there is only one DUP data for >>>> a key, F_DUPDATA is not set for this key, and there is no >>>> sub-cursor. >>>> >>>> In this case, the current behaviour of MDB_GET_MULTIPLE and >>>> MDB_NEXT_MULTIPLE is broken because they make the assumption that >>>> there is always a sub-cursor for DUP data, which is only true for >>>> keys with more than one DUP data. >>>> >>>> This patch address this specific issue. >>> >>> Something's wrong with this patch, it breaks >>> MDB_GET_MULTIPLE/NEXT_MULTIPLE usage in slapd. Need to investigate >>> further. >>> >> The original code is correct. GET_MULTIPLE/NEXT_MULTIPLE are only >> valid when there actually are duplicate records. MDB_NEXT_MULTIPLE is >> essentially just a shortcut for calling MDB_NEXT_DUP in a loop. If >> there are no dups, then MDB_NEXT_DUP (and MDB_NEXT_MULTIPLE) return >> MDB_NOTFOUND. >> >> This patch was in mdb.master but has now been reverted. Closing this >> ITS. >> > > -- -- 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#7570) fix MDB_GET_MULTIPLE and MDB_NEXT_MULTIPLE behaviour
by claude.brisson＠gmail.com 15 Apr '13

15 Apr '13

So it means the following: with the current code, when the client code wants to optimize transfers with GET_MULTIPLE/NEXT_MULTIPLE, it has to fall back to standard GET/NEXT whenever it encounters MDB_NOTFOUND. Whereas the patch assumes that GET_MULTIPLE/NEXT_MULTIPLE will not depend on the number of records. IMHO, the current behavior is a bit cumbersome. Would it be that complex to update the client code? Claude On Sun, 14 Apr 2013 23:56:41 GMT hyc(a)symas.com wrote: > hyc(a)symas.com wrote: > > claude.brisson(a)gmail.com wrote: > >> Full_Name: Claude Brisson > >> Version: HEAD > >> OS: linux 64 > >> URL: > >> ftp://ftp.openldap.org/incoming/0001-fix-MDB_GET_MULTIPLE-and-MDB_NEXT_MULT… > >> Submission from: (NULL) (84.103.74.130) > >> > >> > >> In a db with MDB_DUPSORT flag, when there is only one DUP data for > >> a key, F_DUPDATA is not set for this key, and there is no > >> sub-cursor. > >> > >> In this case, the current behaviour of MDB_GET_MULTIPLE and > >> MDB_NEXT_MULTIPLE is broken because they make the assumption that > >> there is always a sub-cursor for DUP data, which is only true for > >> keys with more than one DUP data. > >> > >> This patch address this specific issue. > > > > Something's wrong with this patch, it breaks > > MDB_GET_MULTIPLE/NEXT_MULTIPLE usage in slapd. Need to investigate > > further. > > > The original code is correct. GET_MULTIPLE/NEXT_MULTIPLE are only > valid when there actually are duplicate records. MDB_NEXT_MULTIPLE is > essentially just a shortcut for calling MDB_NEXT_DUP in a loop. If > there are no dups, then MDB_NEXT_DUP (and MDB_NEXT_MULTIPLE) return > MDB_NOTFOUND. > > This patch was in mdb.master but has now been reverted. Closing this > ITS. >

1 0

Re: (ITS#7570) fix MDB_GET_MULTIPLE and MDB_NEXT_MULTIPLE behaviour
by hyc＠symas.com 14 Apr '13

14 Apr '13

hyc(a)symas.com wrote: > claude.brisson(a)gmail.com wrote: >> Full_Name: Claude Brisson >> Version: HEAD >> OS: linux 64 >> URL: ftp://ftp.openldap.org/incoming/0001-fix-MDB_GET_MULTIPLE-and-MDB_NEXT_MULT… >> Submission from: (NULL) (84.103.74.130) >> >> >> In a db with MDB_DUPSORT flag, when there is only one DUP data for a key, >> F_DUPDATA is not set for this key, and there is no sub-cursor. >> >> In this case, the current behaviour of MDB_GET_MULTIPLE and MDB_NEXT_MULTIPLE is >> broken because they make the assumption that there is always a sub-cursor for >> DUP data, which is only true for keys with more than one DUP data. >> >> This patch address this specific issue. > > Something's wrong with this patch, it breaks MDB_GET_MULTIPLE/NEXT_MULTIPLE > usage in slapd. Need to investigate further. > The original code is correct. GET_MULTIPLE/NEXT_MULTIPLE are only valid when there actually are duplicate records. MDB_NEXT_MULTIPLE is essentially just a shortcut for calling MDB_NEXT_DUP in a loop. If there are no dups, then MDB_NEXT_DUP (and MDB_NEXT_MULTIPLE) return MDB_NOTFOUND. This patch was in mdb.master but has now been reverted. Closing this ITS. -- -- 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2013