hyc(a)symas.com wrote:
> sergej.jurecko(a)gmail.com wrote:
>> Full_Name: Sergej Jurečko
>> Version: lmdb 0.9.16
>> OS: osx
>> URL: ftp://ftp.openldap.org/incoming/delerror.zip
>> Submission from: (NULL) (193.189.172.218)
>>
>>
>> Code and lmdb file is uploaded to ftp. Code is also here:
>> https://gist.github.com/SergejJurecko/68979ff6460806581ad5
>>
>> If you run the code on the uploaded lmdb file, it will result in MDB_PAGE_FULL
>> error out of mdb_cursor_del.
>>
>> I use dupsorts a lot in my app. Every value in the dupsort has 2 64bit integers
>> and 1 u8 in the beginning, which are used in the custom comparison function to
>> sort the values.
>>
>> During normal operation values are added to the end of the dupsort and
>> eventually a cleanup operation occurs that deletes unused values.
>>
>> The example app tries to delete the first value in the dupsort. But it will fail
>> the same if it tries to delete the next one instead.
>
> Thanks for the code and data, it shows the problem pretty clearly.
> Unfortunately the solution is less obvious at the moment, still working on it.
Fixed now in mdb.master, please test and followup with results. Thanks.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
sergej.jurecko(a)gmail.com wrote:
> Full_Name: Sergej Jurečko
> Version: lmdb 0.9.16
> OS: osx
> URL: ftp://ftp.openldap.org/incoming/delerror.zip
> Submission from: (NULL) (193.189.172.218)
>
>
> Code and lmdb file is uploaded to ftp. Code is also here:
> https://gist.github.com/SergejJurecko/68979ff6460806581ad5
>
> If you run the code on the uploaded lmdb file, it will result in MDB_PAGE_FULL
> error out of mdb_cursor_del.
>
> I use dupsorts a lot in my app. Every value in the dupsort has 2 64bit integers
> and 1 u8 in the beginning, which are used in the custom comparison function to
> sort the values.
>
> During normal operation values are added to the end of the dupsort and
> eventually a cleanup operation occurs that deletes unused values.
>
> The example app tries to delete the first value in the dupsort. But it will fail
> the same if it tries to delete the next one instead.
Thanks for the code and data, it shows the problem pretty clearly.
Unfortunately the solution is less obvious at the moment, still working on it.
The situation is this: deleting the record causes the leaf page to become too
empty, so it gets merged with a neighboring page - this is no problem. The
merge causes its parent branch page to also become too empty, so that is also
merged with a neighboring branch page. This is where the problem arises:
In a branch page, the key for slot 0 is always empty - it's never stored. So
we have two branch pages, each with two nodes, and node 0 of each is
essentially zero length. But when merging, we need to store a valid key.
We go from
page 1, slot 0; page 1, slot 1; and page 2, slot 0; page 2, slot 1
to
page 1, slot 0, slot 1, slot 2, slot 3
In this case, we have to retrieve the key corresponding to page 2 slot 0 and
store it in page 1 slot 2. In this DB this key is very large, and storing it
leaves no room for the last key in slot 3.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
peter(a)adpm.de wrote:
>>> - allow padding to be omitted (totally, not only parts)
>>
>> Why?
> To allow using the keys encoded by other implementations that do
> not generate the padding (e.g. Perl's Convert::Base32).
> (e.g. in a mass-rollout that sets userPassword using LDIF)
We must reject this on security grounds. See RFC3548 Security Considerations.
https://tools.ietf.org/html/rfc3548#page-10
Also, as already noted in the code comments, allowing partial bytes would open
a subliminal channel allowing information leaks.
If Perl's encoder is being so careless then that is a security vulnerability.
The other 3 points on this ticket have been committed in master. I consider
this ticket resolved.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
--001a11473c18e3466e0520962c9f
Content-Type: text/plain; charset=UTF-8
Sorry, the URL is:
https://github.com/lukeyeager/lmdb/commit/b0542bc783f2c349d1365a4e647241475…
On Fri, Sep 25, 2015 at 11:02 AM, <openldap-its(a)openldap.org> wrote:
>
> *** THIS IS AN AUTOMATICALLY GENERATED REPLY ***
>
> Thanks for your report to the OpenLDAP Issue Tracking System. Your
> report has been assigned the tracking number ITS#8256.
>
> One of our support engineers will look at your report in due course.
> Note that this may take some time because our support engineers
> are volunteers. They only work on OpenLDAP when they have spare
> time.
>
> If you need to provide additional information in regards to your
> issue report, you may do so by replying to this message. Note that
> any mail sent to openldap-its(a)openldap.org with (ITS#8256)
> in the subject will automatically be attached to the issue report.
>
> mailto:openldap-its@openldap.org?subject=(ITS#8256)
>
> You may follow the progress of this report by loading the following
> URL in a web browser:
> http://www.OpenLDAP.org/its/index.cgi?findid=8256
>
> Please remember to retain your issue tracking number (ITS#8256)
> on any further messages you send to us regarding this report. If
> you don't then you'll just waste our time and yours because we
> won't be able to properly track the report.
>
> Please note that the Issue Tracking System is not intended to
> be used to seek help in the proper use of OpenLDAP Software.
> Such requests will be closed.
>
> OpenLDAP Software is user supported.
> http://www.OpenLDAP.org/support/
>
> --------------
> Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.
>
>
--001a11473c18e3466e0520962c9f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Sorry, the URL is:<div><a href=3D"https://github.com/lukey=
eager/lmdb/commit/b0542bc783f2c349d1365a4e6472414759e4f04a.patch">https://g=ithub.com/lukeyeager/lmdb/commit/b0542bc783f2c349d1365a4e6472414759e4f04a.p=
atch</a><br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_=
quote">On Fri, Sep 25, 2015 at 11:02 AM, <span dir=3D"ltr"><<a href=3D"=
mailto:openldap-its@openldap.org" target=3D"_blank">openldap-its(a)openldap.o=
rg</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
*** THIS IS AN AUTOMATICALLY GENERATED REPLY ***<br>
<br>
Thanks for your report to the OpenLDAP Issue Tracking System.=C2=A0 Your<br=
>
report has been assigned the tracking number ITS#8256.<br>
<br>
One of our support engineers will look at your report in due course.<br>
Note that this may take some time because our support engineers<br>
are volunteers.=C2=A0 They only work on OpenLDAP when they have spare<br>
time.<br>
<br>
If you need to provide additional information in regards to your<br>
issue report, you may do so by replying to this message.=C2=A0 Note that<br=
>
any mail sent to <a href=3D"mailto:openldap-its@openldap.org">openldap-its@=
openldap.org</a> with (ITS#8256)<br>
in the subject will automatically be attached to the issue report.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mailto:<a href=3D"mailto:openldap-its@openldap.=
org">openldap-its(a)openldap.org</a>?subject=3D(ITS#8256)<br>
<br>
You may follow the progress of this report by loading the following<br>
URL in a web browser:<br>
=C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/its/index.cgi?findid=3D825=
6" rel=3D"noreferrer" target=3D"_blank">http://www.OpenLDAP.org/its/index.c=
gi?findid=3D8256</a><br>
<br>
Please remember to retain your issue tracking number (ITS#8256)<br>
on any further messages you send to us regarding this report.=C2=A0 If<br>
you don't then you'll just waste our time and yours because we<br>
won't be able to properly track the report.<br>
<br>
Please note that the Issue Tracking System is not intended to<br>
be used to seek help in the proper use of OpenLDAP Software.<br>
Such requests will be closed.<br>
<br>
OpenLDAP Software is user supported.<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/support/" re=
l=3D"noreferrer" target=3D"_blank">http://www.OpenLDAP.org/support/</a><br>
<br>
--------------<br>
Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.<br>
<br>
</blockquote></div><br></div>
--001a11473c18e3466e0520962c9f--
Full_Name: Luke Yeager
Version: OPENLDAP_REL_ENG_2_5, LMDB_0.9.16
OS: Ubuntu 14.04
URL:
Submission from: (NULL) (216.228.112.22)
This fixes two small issues. First, if the $(prefix) or $(prefix)/*
directories don't exist, they should be created. Second, the shared
library is not executable, and should not be marked as such.
Patch here:
https://github.com/keyeyeager/lmdb/commit/25db4c2ecdfc31653b702cf1e08a09537…
Full_Name: Michael Str.der
Version: HEAD
OS:
URL:
Submission from: (NULL) (79.223.42.126)
1. It would be nice if back-sock listeners could receive more details of an LDAP
request:
1.1 TLS client peer certificate would allow to distinguish between a normal
bind-DN and the system from which the LDAP request was sent.
- either subject-DN like used in authz-regexp configuration directive
- issuer-DN+serial like to be used with certificateExactMatch
1.2. Request controls
- either as base64-decoded BER (and the listener has to decode it) similar to
what RFC 2849 specifys
- in some suitable string representation (hard to define)
2. It would be nice if back-sock listeners could return extended response
controls to slapd which returns it to the LDAP client. Should be an extra line
"control:" with base64-encoded BER value similar to what RFC 2849 specifys
Full_Name: Quanah Gibson-Mount
Version: 2.4.x
OS: Linux 2.6
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (75.111.52.177)
The admin guide for 2.4 section on replication has the description for
syncprov-sessionlog from OpenLDAP 2.3, and needs to be updated to reflect
current reality of what is tracked (i.e., updated to match the 2.4 man page for
syncprov)
http://www.openldap.org/doc/admin24/replication.html#Syncrepl, section 18.3.1.2