openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

(ITS#8123) Incorrect loglevel man page content
by elecharny＠apache.org 01 May '15

01 May '15

Full_Name: Emmanuel L.charny Version: 2.4.40 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.12.43.27) The slapd-config man page contains a slightly incorrect explaination for the olcLogLevel config element. One can read : olcLogLevel: <integer> [...] ... The desired log level can be input as ... or as a list of the names that are shown between brackets... but the sample does not show any bracket being used : olcLogLevel: acl trace Actually, using brackets does not work (you can't inject the attribute using [acl trace] or {acl trace})

1 0

(ITS#8122) Incorrect Schema content
by elecharny＠apache.org 01 May '15

01 May '15

Full_Name: Emmanuel L.charny Version: 2.4.40 OS: Mac OSX URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.12.55.37) There are a few elements in some schema which are incorrect (even if it does not break anything) : Core schema ----------- * The organizationalRole OC has the preferredDeliveryMethod AT declared twice * The residentialPerson OC has the preferredDeliveryMethod AT declared twice Cosine schema ------------- * The domain OC has the streetAddress AT declared twice * The RFC822localPart OC has the telephoneNumber AT declared twice

1 0

(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

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