openldap-bugs December 2020

openldap-bugs@openldap.org

3 participants
95 discussions

[Bug 9193] New: HTML in mailing list description
by openldap-its＠openldap.org 19 Mar '24

19 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=9193 Bug ID: 9193 Summary: HTML in mailing list description Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- e.g. https://lists.openldap.org/postorius/lists/openldap-devel.openldap.org/ contains code for links and formatting, but all inside of a <pre> block. -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Issue 9341] New: Delta-sync MPR needs to be stable regardless of ordering
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9341 Issue ID: 9341 Summary: Delta-sync MPR needs to be stable regardless of ordering Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: replication Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- If two or more updates are spread across several providers before they have a chance to learn about the others, all replicas need to arrive at the same content regardless of the order in which they arrive. One example that is broken at the moment: - (csn a) server 1 accepts a modify - (csn b) server 2 accepts a delete on the same DN - (csn c) server 2 accepts an add on that DN again If a replica receives the actions in the order bca vs. abc, the content of the entry will be different even though the final CSN set is the same -> they will never converge. The ordering 'bac' also needs to result in eventual convergence, even if it means a refresh or replication from either provider stalling temporarily? Merge request with this test case (so far): https://git.openldap.org/openldap/openldap/-/merge_requests/145 -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Issue 9269] New: "hidden" "subordinate" database is shown in a directory tree
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9269 Issue ID: 9269 Summary: "hidden" "subordinate" database is shown in a directory tree Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: grapvar(a)gmail.com Target Milestone: --- "hidden" configuration option is ignored by slapd (not honored by "glue" overlay?) if the database it tries to hide is also a "subordinate" database. Checked for openldap 2.4.47 and current git master (f3952d9). -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Bug 9229] New: Make liblutil usable by libldap
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9229 Bug ID: 9229 Summary: Make liblutil usable by libldap Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- liblutil is a static library (non-PIC) and so cannot be linked into shared objects, however we have several use cases for reusing its code in libldap. Some options: - moving more code from liblutil to libldap - just merge the whole thing? - are there components that link liblutil but _not_ libldap? - build liblutil as PIC (take a minor performance hit when linked into programs?) - build liblutil twice (liblutil.a and liblutil_pic.a) - symlink liblutil sources into libldap build dir, like libldap_r does with libldap - both of these last options require checking whether executables can call the PIC symbols safely (if some symbols are used by both library and program code) Nice-to-have for 2.5, I'd say more likely for 2.6 at this point. -- You are receiving this mail because: You are on the CC list for the bug.

1 10

[Bug 9221] New: Move all replication consumer code into its own overlay
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9221 Bug ID: 9221 Summary: Move all replication consumer code into its own overlay 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: --- (In relation to a discussion about slapo-chain) <hyc> anyway, the nicer ting to fix would be in 2.5, push all of the repl consumer code into its own overlay <hyc> in that case, updateref would be processed wherever the overlay was configured <hyc> so no longer tied to the frontend <hyc> it would also make it more feasible to have multiple different consumer configs in a single DB, each with their own provider URL (and thus their own updateref) <hyc> I would think we can get rid of the update ref directive entirely, just point all writes to that consumer's provider. -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 9218] New: Revist entry_release handling in slapo-pache, slapo-translucent
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9218 Bug ID: 9218 Summary: Revist entry_release handling in slapo-pache, slapo-translucent 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: --- From a past discussion with hyc on 2.5 items: [13:57] <hyc> there's a nagging problem though, pcache's entry_release function needs to distinguish between its backend actually freeing the entry, or being a no-op [13:57] <hyc> so it can decide whether to return success or continue [13:58] <hyc> the patch to translucent sidesteps the question, by avoiding other overlays [13:58] <hyc> but we need to revisit this in 2.5 -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Bug 9217] New: Audit all schema definitions to have official non-experimental OIDs where possible
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9217 Bug ID: 9217 Summary: Audit all schema definitions to have official non-experimental OIDs where possible 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: --- From a past discussion with hyc on 2.5 requirements: [09:27] <hyc> we also need to audit all of these schema defs [09:27] <hyc> we're supposed to have official, non-experimental OIDs for released schema [09:28] <hyc> accesslog is still using 666, experimental arc [09:29] <hyc> I think this means we should polish up the logschema draft, Informational status, and publish it again as final -- You are receiving this mail because: You are on the CC list for the bug.

1 12

[Bug 9216] New: Port autoca to gnutls
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9216 Bug ID: 9216 Summary: Port autoca to gnutls Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- For 2.5, support building and running the autoca overlay with GnuTLS. -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Issue 9365] New: Mem leaks with Æ-DIR providers
by openldap-its＠openldap.org 03 Oct '22

03 Oct '22

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.

1 12

[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

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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs December 2020