openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

(ITS#9122) slapadd with dry run fails with back-mdb
by quanah＠openldap.org 25 Nov '19

25 Nov '19

Full_Name: Quanah Gibson-Mount Version: 2.4.48 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.143.26) When testing an slapadd import with back-mdb as the database backend, it errors out incorrectly with a unknown attribute error: slapadd -F /tmp/slapd.d -l slapd-config-config.ldif -n 0 -u 5ddc186e PROXIED attributeDescription "DC" inserted. 5ddc186e <= str2entry: str2ad(olcDbNoSync): attribute type undefined slapadd: could not parse entry (line=1620) _################### 99.10% eta none elapsed none spd 18.7 M/s However the actual LDIF file is just fine: slapadd -F /tmp/slapd.d -l slapd-config.ldif -n 0 _#################### 100.00% eta none elapsed none fast! Closing DB... I'm guessing that on a dry-run, it doesn't actually fully load the modules defined in moduleload to get their schema definitions, which results in a false failure instead of a success.

1 0

(ITS#9121) dynlist enhancements
by quanah＠openldap.org 20 Nov '19

20 Nov '19

Full_Name: Quanah Gibson-Mount Version: 2.4 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.143.26) There are some enhancements to dynlist that would make it more useful/versatile: a) Be able to do (unique)member= searches to find all groups a given group member belongs to b) be able to generate dynamic (is)memberOf values on user entries for the groups they belong to

1 0

(ITS#9120) Searches including generalizedTime attributes with index
by markus.widmer＠daasi.de 19 Nov '19

19 Nov '19

Full_Name: Markus Widmer Version: 2.4.48 OS: CentOS 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (37.24.13.226) Hi! we have recognized a strange behaviour for searches which include an attribute with syntax 1.3.6.1.4.1.1466.115.121.1.24 and the matching rules generalizedTimeMatch and generalizedTimeOrderingMatch set. If the timestamps in the objects have values before 1970, then a search for "<=" or ">=" only seams to works if: - The attribute is not part of the index - The attribute is part of the index but "objectClass" is not Reproduction: We used two entries with the attribute "schacExpiryDate" from the objectClass "schacEntryMetadata" but this can be reproduced with other attributes as well: attributetype ( 1.3.6.1.4.1.25178:1:2:17 NAME 'schacExpiryDate' DESC 'Date from which the set of data is to be considered invalid (format YYYYMMDDhhmmssZ)' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SINGLE-VALUE SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) We used two entries: user.1: schacExpiryDate: 19711007093230.514Z user.2: schacExpiryDate: 19561007093230.514Z First try: we used this index configuration: index sn eq index schacExpiryDate eq index objectClass eq Search filter 1 was: (schacExpiryDate<=19800101120000Z) Result 1 was: user.1 Search filter 2 was: (schacExpiryDate>=19010101120000Z) Result 2 was: user.2 Second try: we used this index configuration: index sn eq #index schacExpiryDate eq index objectClass eq Search filter 1 was: (schacExpiryDate<=19800101120000Z) Result 1 was: user.1 and user.2 Search filter 2 was: (schacExpiryDate>=19010101120000Z) Result 2 was: user.2 and user.2 Third try: we used this index configuration: index sn eq index schacExpiryDate eq #index objectClass eq Search filter 1 was: (schacExpiryDate<=19800101120000Z) Result 1 was: user.1 and user.2 Search filter 2 was: (schacExpiryDate>=19010101120000Z) Result 2 was: user.1 and user.2 We could reproduce this with 2.4.42, 2.4.44 and 2.4.48. We hope you can reproduce this as well to see what is happening here. Thank you very much for doing a great job!

1 0

Re: (ITS#9119) back-monitor can miscount monitorOpCompleted
by hyc＠symas.com 15 Nov '19

15 Nov '19

quanah(a)openldap.org wrote: > 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. Fixed in git master. > > These are the results of a series of queries: > > monitorOpCompleted: 326801 > monitorOpCompleted: 326733 > monitorOpCompleted: 326830 > monitorOpCompleted: 326830 > monitorOpCompleted: 326752 > monitorOpCompleted: 326855 > monitorOpCompleted: 326777 Unable to reproduce. Please test the patch and report back if the problem still shows up. -- -- 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#9118) Add support for MAP_NOSYNC
by hyc＠symas.com 15 Nov '19

15 Nov '19

quanah(a)openldap.org wrote: > 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 > > Added in mdb.master -- -- 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#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

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