openldap-bugs April 2015

openldap-bugs@openldap.org

29 participants
104 discussions

(ITS#8121) mention LDAP_SASL_SIMPLE in ldap_bind.3
by ryan＠openldap.org 29 Apr '15

29 Apr '15

Full_Name: Ryan Tandy Version: OS: URL: Submission from: (NULL) (24.68.37.4) Submitted by: ryan In IRC, txtd noted that both ldap_simple_bind and ldap_bind are marked as deprecated in ldap.h, and asked about the recommended way to perform a simple bind. OpenLDAP code uses ldap_sasl_bind(LDAP_SASL_SIMPLE), but that flag is not mentioned in any man page.

1 0

(ITS#8120) CHECK_CSN unreliable as final check is after mutex is unlocked
by quanah＠openldap.org 29 Apr '15

29 Apr '15

Full_Name: Quanah Gibson-Mount Version: 2.4.40 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) The CHECK_CSN ifdef code is unreliable as the final check on the CSN's is done after the mutex is unlocked, while all of the other checks are done after the mutex is locked. This can cause the assert to trigger on valid CSNs.

1 0

Re: (ITS#8117) Bugs related to key-size in lmdb and backend
by hyc＠symas.com 29 Apr '15

29 Apr '15

Leonid Yuriev wrote: > 29.04.2015 21:55, Howard Chu пишет: >> Leonid Yuriev wrote: >> >>> But what about 5-bytes keys from indexer? >>> - How ones should be compared, as a 4-byte int without MSB, or as a >>> padded 8-byte long? >> >> The indexer doesn't use MDB_INTEGER so your question is irrelevant. >> > OK, but then - what is the purpose of MDB_INTEGERDUP in > mdb_attr_dbs_open()? > > flags = MDB_DUPSORT|MDB_DUPFIXED|MDB_INTEGERDUP; > if ( !(slapMode & SLAP_TOOL_READONLY) ) > flags |= MDB_CREATE; > > Think it is not necessary, is it? You really think so? Have you thought about what the actual *values* are in an index, instead of just the keys? Anyway, this ITS is resolved. Thank you for reporting the bug. If you want to ask further questions about how the indexer works take it to openldap-devel. -- -- 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#8117) Bugs related to key-size in lmdb and backend
by leo＠yuriev.ru 29 Apr '15

29 Apr '15

29.04.2015 21:55, Howard Chu пишет: > Leonid Yuriev wrote: > >> But what about 5-bytes keys from indexer? >> - How ones should be compared, as a 4-byte int without MSB, or as a >> padded 8-byte long? > > The indexer doesn't use MDB_INTEGER so your question is irrelevant. > OK, but then - what is the purpose of MDB_INTEGERDUP in mdb_attr_dbs_open()? flags = MDB_DUPSORT|MDB_DUPFIXED|MDB_INTEGERDUP; if ( !(slapMode & SLAP_TOOL_READONLY) ) flags |= MDB_CREATE; Think it is not necessary, is it? Leonid.

1 0

Re: (ITS#8119) ldapsearch: put empty line after result not before next result
by michael＠stroeder.com 29 Apr '15

29 Apr '15

linuxgeek(a)gmail.com wrote: > ldapsearch outputs LDAP results in a loop. The LDIF separator isn't printed > after the result is printed. It's printed before the next result is printed. > This subtlety causes a problem for a program consuming the output of a > persistent ldapsearch (-Esync=rp). Sorry, but anyone who wants to implement a robust syncrepl client should not rely on ldapsearch command-line tool for that job. IMO it will never really fit the requirements. Use a decent LDAP module for your programming language. Ciao, Michael.

1 0

Re: (ITS#8117) Bugs related to key-size in lmdb and backend
by hyc＠symas.com 29 Apr '15

29 Apr '15

Leonid Yuriev wrote: > 29.04.2015 19:35, Howard Chu пишет: >> Ah yes, the padding is currently only done on platforms that don't >> allow unaligned access to ints (e.g. Sparc) >> >> git rev e2a7617d17368b5787fc24fbd017623d00fe162b > But what about 5-bytes keys from indexer? > - How ones should be compared, as a 4-byte int without MSB, or as a > padded 8-byte long? The indexer doesn't use MDB_INTEGER so your question is irrelevant. > - Where is the padding code? The code is in the git commit ID I already posted in my previous reply. -- -- 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

(ITS#8119) ldapsearch: put empty line after result not before next result
by linuxgeek＠gmail.com 29 Apr '15

29 Apr '15

Full_Name: Thomas Cort Version: HEAD OS: 10.10.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (96.46.34.154) ldapsearch outputs LDAP results in a loop. The LDIF separator isn't printed after the result is printed. It's printed before the next result is printed. This subtlety causes a problem for a program consuming the output of a persistent ldapsearch (-Esync=rp). It has no way of knowing the current result has been fully output until the separator is printed (when the next result comes in), which could take a long time if there are no changes going on. I think the newline should be printed at the end of the for-loop (after the result is printed), not at the beginning (when the next result is received). I tried moving the putchar('\n') to the end of the for-loop. The output is the same for some simple searches I tried and the test suite passes. I'm hesitant to submit that as a patch because I think there might be some subtle edge cases I haven't hit where an extra newline would be inserted or omitted. Any ideas from someone who understands the code?

1 0

Re: (ITS#8118) [PATCH] tool_write_ldif: flush stdout
by linuxgeek＠gmail.com 29 Apr '15

29 Apr '15

--089e0160bf101f3e240514e06e96 Content-Type: text/plain; charset=UTF-8 > A more suitable patch might be one that flushes once when all currently > available messages have been processed in ldapsearch.c. > I.e., after the for-loop in dosearch() completes. Here's an updated patch: ftp://ftp.openldap.org/incoming/thomas-cort-150429b.patch --089e0160bf101f3e240514e06e96 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>> A more suitable patch might be one that flushes = once when all currently</div><div>> available messages have been process= ed in ldapsearch.c.</div><div>> I.e., after the for-loop in dosearch() c= ompletes.<br><br></div><div>Here's an updated patch:</div><div><br></di= v><div><a href=3D"ftp://ftp.openldap.org/incoming/thomas-cort-150429b.patch= ">ftp://ftp.openldap.org/incoming/thomas-cort-150429b.patch</a></div><div c= lass=3D"gmail_extra"><br></div></div> --089e0160bf101f3e240514e06e96--

1 0

Re: (ITS#8117) Bugs related to key-size in lmdb and backend
by leo＠yuriev.ru 29 Apr '15

29 Apr '15

29.04.2015 19:35, Howard Chu пишет: > Leonid Yuriev wrote: >> this is enough: >> - add assert(a->mv_key_size == sizeof(size_t)) into mdb_cmp_long() >> - make all test >> - see a coredump > > OK, fixed in git. For the record, this affected MDB_INTEGERDUP, not > MDB_INTEGERKEY. > >>>> 3) lmdb-backend: >>>> AttributeDescription->ad_type->sat_equality->smr_indexer() >>>> could generate a 5-byte sized ks.s. I can just imagine what this can >>>> create a >>>> many problems. For instance, when I adds the control for key size, it >>>> breaks >>>> test017-syncreplication-refresh. But I am not tested more. >>> >>> Not a bug, indexer keys are padded to 8 bytes. >> >> There is just NOT padded, I am sure. >> Also this is reason for unaligned-access in mdb_cmp_int() and >> mdb_cmp_long(). >> It is similar to reproduce, just assert + make test. > > Ah yes, the padding is currently only done on platforms that don't > allow unaligned access to ints (e.g. Sparc) > > git rev e2a7617d17368b5787fc24fbd017623d00fe162b > >> Seems that bugs together could break ordering of entries, this is >> detected by loop over all entries with mdb_cursor_get(..., MDB_NEXT) and >> comparing keys from previous step. >> All of this I was found today, during developing a mdb_chk tool. Yes, I was made same local changes few hours ago. This fixs miss-call for mdb_cmp_long(). But what about 5-bytes keys from indexer? - How ones should be compared, as a 4-byte int without MSB, or as a padded 8-byte long? - Where is the padding code? Leonid.

1 0

Re: (ITS#8118) [PATCH] tool_write_ldif: flush stdout
by hyc＠symas.com 29 Apr '15

29 Apr '15

linuxgeek(a)gmail.com wrote: > Full_Name: Thomas Cort > Version: HEAD > OS: Mac OS X 10.10.3 > URL: ftp://ftp.openldap.org/incoming/thomas-cort-150429.patch > Submission from: (NULL) (96.46.34.154) > > > The LDIF output wasn't being explicitly flushed. In certain scenarios, > such as piping the output of a persistent ldapsearch to node.js v0.12 > on Mac OS X 10.10.3, the output is unavailable to the process > consuming the search results until some operating system limit is > reached (8192 bytes for example) and it is automatically flushed. > This can leave the tail end of persistent search results in an operating > system buffer for a long time (until enough output has accumulated > for the OS to flush it). > > Explicitly call flush so that the output is immediately available. That totally defeats the purpose of using stdio - which is, to generate buffered output and avoid excessive numbers of system calls. Rejecting this patch. A more suitable patch might be one that flushes once when all currently available messages have been processed in ldapsearch.c. I.e., after the for-loop in dosearch() completes. > > I uploaded the patch to ftp.openldap.org as thomas-cort-150429.patch > > The attached patch file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following patch(es) were > developed by Thomas Cort <linuxgeek(a)gmail.com>. I have not assigned rights > and/or interest in this work to any party. > > I, Thomas Cort, hereby place the following modifications to OpenLDAP Software > (and only these modifications) into the public domain. Hence, these > modifications may be freely used and/or redistributed for any purpose with or > without attribution and/or other notice. > > -- -- 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 2015