openldap-bugs August 2022

openldap-bugs@openldap.org

2 participants
96 discussions

[Issue 9878] New: test043 failures in 2.5/2.6
by openldap-its＠openldap.org 26 Sep '22

26 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9878 Issue ID: 9878 Summary: test043 failures in 2.5/2.6 Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- With test043 update for ITS#9823, we manage to introduce a scenario where the server is completely idle except for a runqueue change. This is partly identical with ITS#9642 and a similar approach would work. Except that changes our module facing ABI so might not be something we can backport. For the streams we can't, we might have to change the test to make the server not idle. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9524] New: Removing last entry in database triggers MDB_PROBLEM
by openldap-its＠openldap.org 21 Sep '22

21 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9524 Issue ID: 9524 Summary: Removing last entry in database triggers MDB_PROBLEM Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: kriszyp(a)gmail.com Target Milestone: --- With a fresh database, if you have have an open read transaction, and you create a new entry in a write transaction and commit it, and then create a new transaction and delete that entry, when you commit, it will return an MDB_PROBLEM from approximately line 4408 from the mt_loose_count/dirty_list check. This seems to occur on mdb.master3, but not mdb.master. Here is a minimal example/test-case of how to reproduce: MDB_env* env; mdb_env_create(&env); int rc, flags = 0; mdb_env_open(env, "test", flags, 0664); MDB_txn* readonly_txn; mdb_txn_begin(env, nullptr, MDB_RDONLY, &readonly_txn); MDB_txn* txn; MDB_dbi dbi; mdb_txn_begin(env, nullptr, 0, &txn); mdb_dbi_open(txn, nullptr, MDB_CREATE, &dbi); MDB_val val; val.mv_data = (void*) "test"; val.mv_size = 4; mdb_put(txn, dbi, &val, &val, 0); mdb_txn_commit(txn); mdb_txn_begin(env, nullptr, 0, &txn); mdb_del(txn, dbi, &val, nullptr); rc = mdb_txn_commit(txn); // this returns MDB_PROBLEM (let me know if this should be submitted differently) -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Issue 9339] New: Add syncrepl status in cn=monitor
by openldap-its＠openldap.org 12 Sep '22

12 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9339 Issue ID: 9339 Summary: Add syncrepl status in cn=monitor Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Patch coming to expose some consumer state in cn=monitor Sample entry: # Consumer 001, database 2, databases, monitor dn: cn=Consumer 001,cn=database 2,cn=databases,cn=monitor objectClass: olmSyncReplInstance structuralObjectClass: olmSyncReplInstance cn: Consumer 001 creatorsName: modifiersName: createTimestamp: 20200906160447Z modifyTimestamp: 20200906160447Z olmSRProviderURIList: ldap://localhost:9011/ olmSRIsConnected: TRUE olmSRSyncPhase: Persist olmSRLastConnect: 20200906160448Z olmSRLastContact: 20200906160453Z olmSRLastCookieRcvd: rid=001,sid=001,csn=20200906160453.039573Z#000000#001#000 000 olmSRLastCookieSent: rid=001,sid=002,csn=20200906160447.723677Z#000000#001#000 000 entryDN: cn=Consumer 001,cn=database 2,cn=databases,cn=monitor subschemaSubentry: cn=Subschema hasSubordinates: FALSE -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 9853] New: lastbind-precision conversion fails from slapd.conf to cn=config
by openldap-its＠openldap.org 12 Sep '22

12 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9853 Issue ID: 9853 Summary: lastbind-precision conversion fails from slapd.conf to cn=config Product: OpenLDAP Version: 2.6.2 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- When converting a slapd.conf file to cn=config, the "lastbind-precision" value is not preserved. slapd.conf: lastbind-precision 300 cn=config value: olcLastBindPrecision: 0 -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9437] New: Add OTP module to core
by openldap-its＠openldap.org 12 Sep '22

12 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9437 Issue ID: 9437 Summary: Add OTP module to core Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Symas will contribute its OTP module for OpenLDAP 2.5 as a core overlay -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 9817] New: rwm overlay : Issue with DN containing special characters
by openldap-its＠openldap.org 12 Sep '22

12 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9817 Issue ID: 9817 Summary: rwm overlay : Issue with DN containing special characters Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: thierry.pubellier(a)paris.fr Target Milestone: --- Hi, I'm using rwn to select the database useg for bind operations based on the result of a rewriteMap requets. Sample configuration in global section : #Rewrite Map to request a remote server rwm-rewriteMap ldap checkEntry "ldap://10.1.2.3/ou=users,dc=paris,dc=local?dn?sub" binddn="cn=myuser,ou=users,dc=paris,dc=local" credentials="XXX" # Backing up original DN rwm-rewriteRule ".+" "${&binddn($0)}$0" ":" # Contructing LDAP Filter for remote search. Combined with a rewrite Map, the requested DN is returned if there is a match. rwm-rewriteRule ".+" "(&(!(description=TEST))(distinguishedName=$0))" ":" # If filter matches, end of rewriting. Going to 'dc=paris,dc=local' database rwm-rewriteRule ".+" "${checkIfPasswordExpiredDN($0)}" ":@I" # Otherwise, restoring the original DN. rwm-rewriteRule ".+" "${*binddn}" ":" # And final DN massaging from "dc=paris,dc=local" to "dc=paris,dc=local2" database rwm-rewriteRule "(.+,)?ou=users,dc=paris,dc=local$" "$1ou=users,dc=paris,dc=local2" ":@" Everything goes fine until I use DN with special characters, like ',' or '['. For example : 'cn=Pubellier\, Thierry (TEST),ou=users,dc=paris,dc=local' In this case, the rwm-rewriteRule contructs a LDAP filter with incorrect syntax, as special caracters are not being escaped. I have to use some ugly tricks to escape these caracters, as shown below : #Rewrite Map to request a remote server rwm-rewriteMap ldap checkEntry "ldap://10.1.2.3/ou=users,dc=paris,dc=local?dn?sub" binddn="cn=myuser,ou=users,dc=paris,dc=local" credentials="XXX" # Backing up original DN rwm-rewriteRule ".+" "${&binddn($0)}$0" ":" # Rewriting for ',' rwm-rewriteRule "(.+).\2C(.+)" "$1\\,$2" # Adding a special '#' (asserting it in none of my DNs) suffix for special characters, in order to escape them without looping forever rwm-rewriteRule "(.*)([)*(\\])([^#].*|$)" "$1$2#$3" # Escaping of special characters with dedicated '#' suffix, avoiding infinite loops rwm-rewriteRule "(.*)([)*(\\])#(.*)" "$1\\$2$3" # Contructing LDAP Filter for remote search. Combined with a rewrite Map, the requested DN is returned if there is a match. rwm-rewriteRule ".+" "(&(!(description=TEST))(distinguishedName=$0))" ":" # If filter matches, end of rewriting. Going to 'dc=paris,dc=local' database rwm-rewriteRule ".+" "${checkIfPasswordExpiredDN($0)}" ":@I" # Otherwise, restoring the original DN. rwm-rewriteRule ".+" "${*binddn}" ":" # And final DN massaging from "dc=paris,dc=local" to "dc=paris,dc=local2" database rwm-rewriteRule "(.+,)?ou=users,dc=paris,dc=local$" "$1ou=users,dc=paris,dc=local2" ":@" Could there be a way to integrate the ldap escape mechanism when making an variable assignment (like using a '#' character in place of the usual '&') ? Thanks by advance, Best regards, Thierry -- You are receiving this mail because: You are on the CC list for the issue.

1 21

[Issue 9438] New: Add remoteauth overlay to core
by openldap-its＠openldap.org 12 Sep '22

12 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9438 Issue ID: 9438 Summary: Add remoteauth overlay to core Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Symas will contribute its remoteauth overlay for OpenLDAP 2.5 as a core overlay -- You are receiving this mail because: You are on the CC list for the issue.

1 12

[Issue 9905] New: The test case 043 execution failed
by openldap-its＠openldap.org 05 Sep '22

05 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9905 Issue ID: 9905 Summary: The test case 043 execution failed Product: OpenLDAP Version: 2.6.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: 1010881517(a)qq.com Target Milestone: --- Test case 043 failed after I added #9823 pr to my openldap-2.6.0. Some logs may be useful to you. >>>>> Starting test043-delta-syncrepl for mdb... running defines.sh Starting provider slapd on TCP/IP port 9011... Using ldapsearch to check that provider slapd is running... Using ldapadd to create the context prefix entries in the provider... Starting consumer slapd on TCP/IP port 9012... Using ldapsearch to check that consumer slapd is running... Using ldapadd to populate the provider directory... Waiting 7 seconds for syncrepl to receive changes... Stopping the provider, sleeping 10 seconds and restarting it... Using ldapsearch to check that provider slapd is running... Using ldapmodify to modify provider directory... Waiting 7 seconds for syncrepl to receive changes... Using ldapsearch to read all the entries from the provider... Using ldapsearch to read all the entries from the consumer... Filtering provider results... Filtering consumer results... Comparing retrieved entries from provider and consumer... Stopping consumer to test recovery... Modifying more entries on the provider... Restarting consumer... Waiting 7 seconds for syncrepl to receive changes... Try updating the consumer slapd... Waiting 7 seconds for syncrepl to receive changes... Using ldapsearch to read all the entries from the provider... Using ldapsearch to read all the entries from the consumer... Filtering provider results... Filtering consumer results... Comparing retrieved entries from provider and consumer... Stopping consumer to test recovery after logpurge expired... Modifying even more entries on the provider... Configuring logpurge of 1 second... Waiting 4 seconds for accesslog to be purged... Using ldapsearch to check if accesslog is empty... Restarting consumer... Waiting 7 seconds for syncrepl to receive changes... Using ldapsearch to read all the entries from the provider... Using ldapsearch to read all the entries from the consumer... Filtering provider results... Filtering consumer results... Comparing retrieved entries from provider and consumer... test failed - provider and consumer databases differ >>>>> Failed test043-delta-syncrepl for mdb after 0 seconds (exit 1) -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9358] New: back-mdb may return accesslog entries out of order
by openldap-its＠openldap.org 01 Sep '22

01 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9358 Issue ID: 9358 Summary: back-mdb may return accesslog entries out of order Product: OpenLDAP Version: 2.4.53 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- back-mdb will usually return search entries in entryID order, but may do a dn traversal instead if the count of children is smaller than the count of search filter candidates. The RDNs are sorted in length order, not lexical order. For accesslog, all RDNs are of equal length but if they have trailing zeroes, the generalizedTime normalizer truncates them. Changing their lengths causes accesslog's timestamp-based RDNs to sort in the wrong order. The least intrusive fix is to override the syntax/normalizer for reqStart and reqEnd attributes to not truncate trailing zeroes. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9903] New: Broken link and images in Powered By page
by openldap-its＠openldap.org 31 Aug '22

31 Aug '22

https://bugs.openldap.org/show_bug.cgi?id=9903 Issue ID: 9903 Summary: Broken link and images in Powered By page Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: jkirkwood(a)kclinfo.com Target Milestone: --- In the page https://www.openldap.org/powered.html (linked from the phrase 'This site is powered by open source software.' at the bottom of the home page) 1) the link to 'Website Meta Language' is broken - it may have moved to https://thewml.github.io ? 2) the links to the logo images are broken - https://www.openldap.org/icons/logo/wml.gif - https://www.openldap.org/icons/logo/freebsd.gif - https://www.openldap.org/icons/logo/apache.gif I randomly noticed this - not breaking anything I'm aware of, so possibly only a cosmetic issue. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs August 2022