October 2020 - openldap-bugs

[Issue 9365] New: Mem leaks with Æ-DIR providers

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9365 Issue ID: 9365 Summary: Mem leaks with Æ-DIR providers Product: OpenLDAP Version: 2.4.53 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: michael(a)stroeder.com Target Milestone: --- Created attachment 772 --> https://bugs.openldap.org/attachment.cgi?id=772&action=edit valgrind output on openSUSE Tumbleweed x86_64 An Æ-DIR installation with self-compiled OpenLDAP 2.4.53 on Debian (now buster) has memory leak issues on the Æ-DIR providers. The read-only consumers do not have this issue. The provider config is more complex with more overlays and more ACLs. In this production deployment slapd is automatically restarted (by monit) when memory consumption reaches 80%. Thus monitoring clearly shows a frequent saw tooth pattern. I've also tested on openSUSE Tumbleweed x86_64 with a RE24 build [1] by running slapd under control of valgrind for a couple of minutes continously sending simple bind operations (additional to the monitoring and other back-ground jobs running). Find valgrind output of my first attempt attached. Does that make sense at all? -- You are receiving this mail because: You are on the CC list for the issue.

2 days, 17 hours

1
12
0 / 0

[Issue 9339] New: Add syncrepl status in cn=monitor

by openldap-its＠openldap.org

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.

3 weeks, 2 days

1
9
0 / 0

[Issue 9358] New: back-mdb may return accesslog entries out of order

by openldap-its＠openldap.org

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 month

1
6
0 / 0

[Issue 9343] New: Expand ppolicy policy configuration to allow URL filter

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9343 Issue ID: 9343 Summary: Expand ppolicy policy configuration to allow URL filter 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: --- Currently, ppolicy only supports a single global default policy, and past that any policies must be manually added to a given user entry if they are supposed to have something other than the default policy. Also, some sites want no default policy, and only a specific subset to have a policy applied to them. For both of these cases, it would be helpful if it were possible to configure a policy to apply to a set of users via a URL similar to the way we handle creating groups of users in dynlist -- You are receiving this mail because: You are on the CC list for the issue.

7 months

1
9
0 / 0

[Bug 9256] New: The ACLs required for SASL binding are not fully documented

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9256 Bug ID: 9256 Summary: The ACLs required for SASL binding are not fully documented Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: kop(a)karlpinc.com Target Milestone: --- Created attachment 727 --> https://bugs.openldap.org/attachment.cgi?id=727&action=edit Patch massaging the SASL binding requirement docs While some ACL requirements for SASL binding are documented, some are not. E.g, that olcAuthzRegexp requires =x on objectClass when direct DN mapping is not documented. Other requirements can be reasoned out based on the existing documentation, but this can be very difficult when unfamiliar with all the moving parts and the places they are documented. E.g. knowing that (objectClass=*) is the default filter, and that there's _always_ _some_ filter, and connecting this with ACLs required to do search-based SASL mapping. The attached patch brings all the SASL binding requirements together in one place in the docs and makes everything explicit. The word "SASL" is included, for those searching for that keyword. I, Karl O. Pinc, 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. -- You are receiving this mail because: You are on the CC list for the bug.

7 months, 1 week

1
27
0 / 0

[Bug 9189] New: Add GSSAPI channel-bindings support

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9189 Bug ID: 9189 Summary: Add GSSAPI channel-bindings support Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: iboukris(a)gmail.com Target Milestone: --- Recently MS has announce they plan to enforce channel-bindings for LDAP over TLS (ADV190023). To support it on client side, we need to pass "tls-endpoint" bindings (RFC 5929) to the SASL plugin, and make use of that in GSSAPI. See also: https://github.com/cyrusimap/cyrus-sasl/pull/601 -- You are receiving this mail because: You are on the CC list for the bug.

7 months, 2 weeks

1
13
0 / 0

[Issue 9350] New: Expand test suite for null base

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9350 Issue ID: 9350 Summary: Expand test suite for null base Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Currently we have no tests that use the empty suffix (null base). This is an entirely valid configuration setup, and there are unique challenges and bugs that crop up with this usage. We need to ensure we're covering this use case, particularly with syncrepl and delta-syncrepl configurations. -- You are receiving this mail because: You are on the CC list for the issue.

8 months, 1 week

1
4
0 / 0

[Issue 9282] New: Syncrepl re-creates deleted entry

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9282 Issue ID: 9282 Summary: Syncrepl re-creates deleted entry Product: OpenLDAP Version: 2.4.50 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Scenario: 2 node Multi-provider replication Add database to provider A ensure database replicates to provider B Stop provider A delete entry on provider B Start provider A Wait for provider B to reconnect to provider A Deleted entry re-appears -- You are receiving this mail because: You are on the CC list for the issue.

9 months, 3 weeks

1
22
0 / 0

[Issue 9356] New: Add list of peerSIDs to consumer cookie to reduce cross traffic

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9356 Issue ID: 9356 Summary: Add list of peerSIDs to consumer cookie to reduce cross traffic Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- If we add a list of peersids to the cookie, each consumer can tell the providers who else the consumers talk to and then the provider can omit sending updates to that consumer, originating from those peers There's some special handling needed if a connection dies If a consumer loses one of its peer connections, and after N retries is still not connected, it should send a new cookie to its remaining peers saying "here's my new peer list" with the missing one removed. Likewise, if a retry eventually connects again, it can send a new cookie again Make that peer list reset configurable in the syncrepl config stanza. This can help account for end admin knowledge that some links may be more or less stable than other ones. The idea here is that if one of your other peers can still see the missing peer, they can start routing updates to you again It should abandon all existing persist sessions and send a new sync search with the new cookie to all remaining peers For consumer side, also means adding the sid for a given provider into the syncrepl stanza to save on having to try and discover the peer sid. -- You are receiving this mail because: You are on the CC list for the issue.

10 months, 3 weeks

1
9
0 / 0

[Bug 9200] New: 2.4 to 2.5 upgrade documentation

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9200 Bug ID: 9200 Summary: 2.4 to 2.5 upgrade documentation Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: blocker Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- For the 2.5 release, we need to document the upgrade procedures for moving from OpenLDAP 2.4 to OpenLDAP 2.5. -- You are receiving this mail because: You are on the CC list for the bug.

1 year, 1 month

1
20
0 / 0

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2020