(ITS#8121) mention LDAP_SASL_SIMPLE in ldap_bind.3
by ryan＠openldap.org
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.
8 years, 7 months
Re: (ITS#8117) Bugs related to key-size in lmdb and backend
by hyc＠symas.com
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/
8 years, 7 months
Re: (ITS#8117) Bugs related to key-size in lmdb and backend
by leo＠yuriev.ru
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.
8 years, 7 months
Re: (ITS#8119) ldapsearch: put empty line after result not before next result
by michael＠stroeder.com
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.
8 years, 7 months
Re: (ITS#8117) Bugs related to key-size in lmdb and backend
by hyc＠symas.com
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/
8 years, 7 months
(ITS#8119) ldapsearch: put empty line after result not before next result
by linuxgeek＠gmail.com
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?
8 years, 7 months
Re: (ITS#8117) Bugs related to key-size in lmdb and backend
by leo＠yuriev.ru
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.
8 years, 7 months
Re: (ITS#8118) [PATCH] tool_write_ldif: flush stdout
by hyc＠symas.com
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/
8 years, 7 months
