openldap-bugs November 2019

openldap-bugs@openldap.org

11 participants
35 discussions

(ITS#9119) back-monitor can miscount monitorOpCompleted
by quanah＠openldap.org 15 Nov '19

15 Nov '19

Full_Name: Quanah Gibson-Mount Version: 2.4.43 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.143.26) When querying the monitor backend for monitorOpCompleted, the results are inconsistent. The code that calculates this value is also inefficient, as there is already a global counter of completed operations, but back-monitor doesn't use this and instead queries all the per-operation counters and then sums them together for the result, causing unnecessary work. These are the results of a series of queries: monitorOpCompleted: 326801 monitorOpCompleted: 326733 monitorOpCompleted: 326830 monitorOpCompleted: 326830 monitorOpCompleted: 326752 monitorOpCompleted: 326855 monitorOpCompleted: 326777

1 0

(ITS#9118) Add support for MAP_NOSYNC
by quanah＠openldap.org 15 Nov '19

15 Nov '19

Full_Name: Quanah Gibson-Mount Version: 2.4.48 OS: FreeBSD 11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.143.26) To improve back-mdb performance on LMDB when dbnosync is set, it would be useful to support MAP_NOSYNC as documented at http://nixdoc.net/man-pages/FreeBSD/mmap.2.html

1 0

Re: (ITS#9117) LMDB incorrect value for mapsize [Docs]
by hyc＠symas.com 13 Nov '19

13 Nov '19

progr-d(a)yandex.ru wrote: > No, I mean that in the code it is 1MB, and in the documentation - 10MB. Repeating myself just this once: Yes, this is known. The point is that yo= u're not supposed to trust the default value, you're supposed to always set th= e size explicitly. Closing this ITS. > 14 =D0=BD=D0=BE=D1=8F=D0=B1. 2019 =D0=B3., 5:05 +0300, Howard Chu <hyc@= symas.com>, =D0=BF=D0=B8=D1=81=D0=B0=D0=BB: >> progr-d(a)yandex.ru wrote: >>> Full_Name: Denis >>> Version: lmdb 0.9.24 >>> OS: macOS >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (80.211.15.98) >>> >>> >>> Incorrect value in documentation or code for DEFAULT_MAPSIZE: in code= is >>> 1048576, but in doc: 10485760. >>> >>> Code: http://www.lmdb.tech/doc/group__internal.html#ga506f893519db205= 966f7988c03c920f5 >>> Doc (see method description):=C2=A0http://www.lmdb.tech/doc/group__md= b.html#gaa2506ec8dab3d969b0e609cd82e619e5 >> >> Yes, this is known. The point is to force you to explicitly set a sane= value, therefore this >> will never be changed. >> >> -- >> -- Howard Chu >> CTO, Symas Corp. http://www.symas.com >> Director, Highland Sun http://highlandsun.com/hyc/ >> Chief Architect, OpenLDAP http://www.openldap.org/project/ --=20 -- 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#9117) LMDB incorrect value for mapsize [Docs]
by progr-d＠yandex.ru 13 Nov '19

13 Nov '19

--5dccf546_46e87ccd_19a8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline No, I mean that in the code it is 1MB, and in the documentation - 10MB. 14 =D0=BD=D0=BE=D1=8F=D0=B1. 2019 =D0=B3., 5:05 +0300, Howard Chu <hyc=40= symas.com>, =D0=BF=D0=B8=D1=81=D0=B0=D0=BB: > progr-d=40yandex.ru wrote: > > =46ull=5FName: Denis > > Version: lmdb 0.9.24 > > OS: macOS > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (80.211.15.98) > > > > > > Incorrect value in documentation or code for DE=46AULT=5FMAPSIZE: in = code is > > 1048576, but in doc: 10485760. > > > > Code: http://www.lmdb.tech/doc/group=5F=5Finternal.html=23ga506f89351= 9db205966f7988c03c920f5 > > Doc (see method description):=C2=A0http://www.lmdb.tech/doc/group=5F=5F= mdb.html=23gaa2506ec8dab3d969b0e609cd82e619e5 > > Yes, this is known. The point is to force you to explicitly set a sane = value, therefore this > will never be changed. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ --5dccf546_46e87ccd_19a8 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline <html xmlns=3D=22http://www.w3.org/1999/xhtml=22> <head> <title></title> </head> <body> <div name=3D=22messageBodySection=22> <div dir=3D=22auto=22>No, I mean that in the code it is 1MB, and in the d= ocumentation - 10MB.</div> </div> <div name=3D=22messageReplySection=22>14 =D0=BD=D0=BE=D1=8F=D0=B1. 2019 =D0= =B3., 5:05 +0300, Howard Chu <hyc=40symas.com>, =D0=BF=D0=B8=D1=81=D0= =B0=D0=BB:<br /> <blockquote type=3D=22cite=22 class=3D=22spark=5Fquote=22 style=3D=22marg= in: 5px 5px; padding-left: 10px; border-left: thin solid =231abc9c;=22>pr= ogr-d=40yandex.ru wrote:<br /> <blockquote type=3D=22cite=22 class=3D=22spark=5Fquote=22 style=3D=22marg= in: 5px 5px; padding-left: 10px; border-left: thin solid =23e67e22;=22>=46= ull=5FName: Denis<br /> Version: lmdb 0.9.24<br /> OS: macOS<br /> URL: ftp://ftp.openldap.org/incoming/<br /> Submission from: (NULL) (80.211.15.98)<br /> <br /> <br /> Incorrect value in documentation or code for DE=46AULT=5FMAPSIZE: in code= is<br /> 1048576, but in doc: 10485760.<br /> <br /> Code: http://www.lmdb.tech/doc/group=5F=5Finternal.html=23ga506f893519db2= 05966f7988c03c920f5<br /> Doc (see method description):&=23160;http://www.lmdb.tech/doc/group=5F=5F= mdb.html=23gaa2506ec8dab3d969b0e609cd82e619e5<br /></blockquote> <br /> Yes, this is known. The point is to force you to explicitly set a sane va= lue, therefore this<br /> will never be changed.<br /> <br /> --<br /> -- Howard Chu<br /> CTO, Symas Corp. http://www.symas.com<br /> Director, Highland Sun http://highlandsun.com/hyc/<br /> Chief Architect, OpenLDAP http://www.openldap.org/project/<br /></blockqu= ote> </div> </body> </html> --5dccf546_46e87ccd_19a8--

1 0

Re: (ITS#9117) LMDB incorrect value for mapsize [Docs]
by hyc＠symas.com 13 Nov '19

13 Nov '19

progr-d(a)yandex.ru wrote: > Full_Name: Denis > Version: lmdb 0.9.24 > OS: macOS > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.211.15.98) >=20 >=20 > Incorrect value in documentation or code for DEFAULT_MAPSIZE: in code i= s > 1048576, but in doc: 10485760. >=20 > Code: http://www.lmdb.tech/doc/group__internal.html#ga506f893519db20596= 6f7988c03c920f5 > Doc (see method description):=C2=A0http://www.lmdb.tech/doc/group__mdb.= html#gaa2506ec8dab3d969b0e609cd82e619e5 Yes, this is known. The point is to force you to explicitly set a sane va= lue, therefore this will never be changed. --=20 -- 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#9117) LMDB incorrect value for mapsize [Docs]
by progr-d＠yandex.ru 13 Nov '19

13 Nov '19

Full_Name: Denis Version: lmdb 0.9.24 OS: macOS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.211.15.98) Incorrect value in documentation or code for DEFAULT_MAPSIZE: in code is 1048576, but in doc: 10485760. Code: http://www.lmdb.tech/doc/group__internal.html#ga506f893519db205966f7988c03c… Doc (see method description): http://www.lmdb.tech/doc/group__mdb.html#gaa2506ec8dab3d969b0e609cd82e619e5

1 0

Re: (ITS#8575) Argon2 Password hashing contrib module
by ondra＠mistotebe.net 12 Nov '19

12 Nov '19

On Mon, Nov 11, 2019 at 05:48:05PM +0000, ondra(a)mistotebe.net wrote: > An implementation using libsodium is now available at > https://github.com/mistotebe/openldap/tree/its8575-argon > > Not configurable yet as to what parameters are chosen when a plaintext > password is being hashed, however. That branch now supports parameters being passed in at module load time. It won't help slappasswd as that one doesn't know how to pass parameters to modules but that is a different issue. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8575) Argon2 Password hashing contrib module
by ondra＠mistotebe.net 11 Nov '19

11 Nov '19

On Thu, Jan 31, 2019 at 03:20:22PM +0000, simon(a)slevermann.de wrote: > Hi, > > I have essentially given up on doing this, because I no longer work for > the employer that had me work on this, and at the time I did, I never > got the thing done. The code itself worked when I tried it, but it has > the caveat of not being configurable. I never quite found out how to > properly implement configuration of a module that isn't an overlay, so I > never got that done. Feel free to adjust the existing code, it should be > adaptable to libsodium relatively easily. An implementation using libsodium is now available at https://github.com/mistotebe/openldap/tree/its8575-argon Not configurable yet as to what parameters are chosen when a plaintext password is being hashed, however. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#9116) LMDB: Bogus BAD_DBI result on read-only txn
by hyc＠symas.com 09 Nov '19

09 Nov '19

hyc(a)openldap.org wrote: > Full_Name: Howard Chu > Version: 0.9.24 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.203.24.208) > Submitted by: hyc > > > There are some cases when renewing a cursor in a read-only txn that may return > MDB_BAD_DBI if the DBI has gone stale. This error is spurious, the check is only > supposed to be done in writable txns (see ITS#7825). A patch was pushed to mdb.master, but it is apparently not actually needed. The actual problem was caused by reusing a readtxn that had been left open after its original env had been closed and re-opened. This is a misuse of the API, all txns must be closed before closing the env. Ignore this issue. -- -- 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#9116) LMDB: Bogus BAD_DBI result on read-only txn
by hyc＠openldap.org 09 Nov '19

09 Nov '19

Full_Name: Howard Chu Version: 0.9.24 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.203.24.208) Submitted by: hyc There are some cases when renewing a cursor in a read-only txn that may return MDB_BAD_DBI if the DBI has gone stale. This error is spurious, the check is only supposed to be done in writable txns (see ITS#7825).

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2019