Re: (ITS#8116) [PATCH] ldapsearch: print 'SyncInfo Received' as a comment.
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-150428.patch
> Submission from: (NULL) (96.46.34.154)
>
>
> When the -Esync command line option is used and a Sync Info
> Message (RFC4533) is received, ldapsearch simply prints
> 'SyncInfo Received' to STDOUT. This causes LDIF parsers and
> other tools which consume ldapsearch output to break on invalid
> input.
>
> Change this informational message to be conveyed as a comment.
> Additionally, hide the message when comments are disabled (-LL or
> -LLL).
If we're going to the trouble of patching this bit of code, I wonder if
it would be worthwhile to actually print the contents of the syncinfo as
well. Maybe a hex dump.
>
> I uploaded the patch to ftp.openldap.org as thomas-cort-150428.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, Thas C 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/
6 years, 7 months
(ITS#8118) [PATCH] tool_write_ldif: flush stdout
by linuxgeek＠gmail.com
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.
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.
6 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 16:06, Howard Chu пишет:
>> leo(a)yuriev.ru wrote:
>>> Full_Name: Leo Yuriev
>>> Version: 2.4-HEAD
>>> OS: RHEL7
>>> URL: ftp://ftp.openldap.org/incoming/
>>> Submission from: (NULL) (31.130.36.33)
>>>
>>>
>>> 1) LMDB: On 64-bit systems, in some cases mdb_cmp_int() could be
>>> called instead
>>> of mdb_cmp_long(), when key.mv_size == 8.
>>> To reproduce this is enough add an assertion-check for key.size ==
>>> sizeof(int)
>>> into mdb_cmp_int().A%A
>>
>> You need to provide more details than this. mdb_cmp_int() isn't even
>> used on regular databases, only on DUPSORT databases. Provide actual
>> code reproducing the issue.
>>
> 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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
6 years, 7 months
Re: (ITS#8117) Bugs related to key-size in lmdb and backend
by leo＠yuriev.ru
29.04.2015 17:07, Howard Chu пишет:
> leo(a)yuriev.ru wrote:
>> Code style and code quality of OpenLDAP - is just a trash (IMHO).
>
> And your opinion is worth what, exactly?
>
> This code has come a long way since I started working on it in 1998.
> Frankly I had the same opinion then, as you do now. But rather than
> complain, I fixed the problems I found. There are probably still many
> more of course, in corners of the code I have never looked at.
>
> If you think you can do better, prove it - take a copy of UMich LDAP
> 3.3, where OpenLDAP started from, and bring it up to date with LDAPv3
> and make it match OpenLDAP's performance and features. I look forward
> to reviewing your result.
>
> Until you do that, you have no basis for your pointless insults.
>
I have no intention to offend or humiliate you.
It's hard to say what I would do in your position, but I have my opinion
(as I believe informed) about the quality of the code.
Whether are necessary to correct the situation, and how to do it - you
decide.
I think the first important step - to acknowledge the problem and put
into a goals.
For my part I can say that I must to achieve stability, at least in our
scenarios.
Regards,
Leonid.
6 years, 7 months
Re: (ITS#8117) Bugs related to key-size in lmdb and backend
by hyc＠symas.com
leo(a)yuriev.ru wrote:
> Code style and code quality of OpenLDAP - is just a trash (IMHO).
And your opinion is worth what, exactly?
This code has come a long way since I started working on it in 1998.
Frankly I had the same opinion then, as you do now. But rather than
complain, I fixed the problems I found. There are probably still many
more of course, in corners of the code I have never looked at.
If you think you can do better, prove it - take a copy of UMich LDAP
3.3, where OpenLDAP started from, and bring it up to date with LDAPv3
and make it match OpenLDAP's performance and features. I look forward to
reviewing your result.
Until you do that, you have no basis for your pointless insults.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
6 years, 7 months
Re: (ITS#8117) Bugs related to key-size in lmdb and backend
by leo＠yuriev.ru
29.04.2015 16:06, Howard Chu пишет:
> leo(a)yuriev.ru wrote:
>> Full_Name: Leo Yuriev
>> Version: 2.4-HEAD
>> OS: RHEL7
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (31.130.36.33)
>>
>>
>> 1) LMDB: On 64-bit systems, in some cases mdb_cmp_int() could be
>> called instead
>> of mdb_cmp_long(), when key.mv_size == 8.
>> To reproduce this is enough add an assertion-check for key.size ==
>> sizeof(int)
>> into mdb_cmp_int().A%A
>
> You need to provide more details than this. mdb_cmp_int() isn't even
> used on regular databases, only on DUPSORT databases. Provide actual
> code reproducing the issue.
>
this is enough:
- add assert(a->mv_key_size == sizeof(size_t)) into mdb_cmp_long()
- make all test
- see a coredump
>
>> 2) LMDB: There is no any checking for invalid key-size for
>> MDB_INTEGERKEY and
>> MDB_INTEGERDUP. Therefore, for example, mdb_cursor_put() accepts a
>> key.size == 1
>> and so forth.
>
> Not a bug, MDB_INTEGERKEY is documented to only be used with
> word-sized keys.
Ok, let it be "a feature" ;)
>> 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.
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.
>> P.S.
>> It is a one more nice rebus from Howard ;)
>
> Thanks for the irrelevant editorials. It might even be amusing if they
> were true, but mostly they just demonstrate your inexperience.
>
Code style and code quality of OpenLDAP - is just a trash (IMHO).
By functional is a 100 times simple than (for instance)
Linux/FreeBSD/Windows kernel, or PostgreSQL.
But simultaneously it is 100 times harder to find and fix bugs or make a
some progress.
You can't hide the obvious.
6 years, 7 months
Re: (ITS#8117) Bugs related to key-size in lmdb and backend
by hyc＠symas.com
leo(a)yuriev.ru wrote:
> Full_Name: Leo Yuriev
> Version: 2.4-HEAD
> OS: RHEL7
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (31.130.36.33)
>
>
> 1) LMDB: On 64-bit systems, in some cases mdb_cmp_int() could be called instead
> of mdb_cmp_long(), when key.mv_size == 8.
> To reproduce this is enough add an assertion-check for key.size == sizeof(int)
> into mdb_cmp_int().A%A
You need to provide more details than this. mdb_cmp_int() isn't even
used on regular databases, only on DUPSORT databases. Provide actual
code reproducing the issue.
> 2) LMDB: There is no any checking for invalid key-size for MDB_INTEGERKEY and
> MDB_INTEGERDUP. Therefore, for example, mdb_cursor_put() accepts a key.size == 1
> and so forth.
Not a bug, MDB_INTEGERKEY is documented to only be used with word-sized
keys.
> 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.
> P.S.
> It is a one more nice rebus from Howard ;)
Thanks for the irrelevant editorials. It might even be amusing if they
were true, but mostly they just demonstrate your inexperience.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
6 years, 7 months
(ITS#8117) Bugs related to key-size in lmdb and backend
by leo＠yuriev.ru
Full_Name: Leo Yuriev
Version: 2.4-HEAD
OS: RHEL7
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (31.130.36.33)
1) LMDB: On 64-bit systems, in some cases mdb_cmp_int() could be called instead
of mdb_cmp_long(), when key.mv_size == 8.
To reproduce this is enough add an assertion-check for key.size == sizeof(int)
into mdb_cmp_int().A%A
2) LMDB: There is no any checking for invalid key-size for MDB_INTEGERKEY and
MDB_INTEGERDUP. Therefore, for example, mdb_cursor_put() accepts a key.size == 1
and so forth.
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.
P.S.
It is a one more nice rebus from Howard ;)
6 years, 7 months
(ITS#8116) [PATCH] ldapsearch: print 'SyncInfo Received' as a comment.
by linuxgeek＠gmail.com
Full_Name: Thomas Cort
Version: HEAD
OS: Mac OS X 10.10.3
URL: ftp://ftp.openldap.org/incoming/thomas-cort-150428.patch
Submission from: (NULL) (96.46.34.154)
When the -Esync command line option is used and a Sync Info
Message (RFC4533) is received, ldapsearch simply prints
'SyncInfo Received' to STDOUT. This causes LDIF parsers and
other tools which consume ldapsearch output to break on invalid
input.
Change this informational message to be conveyed as a comment.
Additionally, hide the message when comments are disabled (-LL or
-LLL).
I uploaded the patch to ftp.openldap.org as thomas-cort-150428.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, Thas C 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.
6 years, 7 months
Re: (ITS#8115) Adding passwd hash schemes
by quanah＠zimbra.com
--On Tuesday, April 28, 2015 3:33 PM +0000 bruno_haleblian(a)carrefour.com
wrote:
> Supposing I can translate it to C, what is the best and cleanest way to
> integrate this specific scheme?
> Is there an "overlay way" to do this?
> Do I Have to hack into passwd.c in lutils?
> Has this kind of work already been done?
The ITS system is for reporting bugs, not asking usage questions about the
software. Please re-direct your questions to
openldap-technical(a)openldap.org. This ITS will be closed.
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
6 years, 7 months
