https://bugs.openldap.org/show_bug.cgi?id=9207
Bug ID: 9207
Summary: Remove Moznss compatibility layer
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
For the 2.5 release, remove the MozNSS compatibility layer.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9278
Issue ID: 9278
Summary: liblmdb: robust mutexes should not be unmapped
Product: LMDB
Version: unspecified
Hardware: All
OS: FreeBSD
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: delphij(a)freebsd.org
Target Milestone: ---
Created attachment 736
--> https://bugs.openldap.org/attachment.cgi?id=736&action=edit
A possible workaround
We recently noticed that lmdb would have the memory region containing the
robust mutex unmapped on mdb_env_close0():
munmap((void *)env->me_txns,
(env->me_maxreaders-1)*sizeof(MDB_reader)+sizeof(MDB_txninfo));
Note that if this is the last unmap for a robust mutex, the FreeBSD
implementation would garbage-collect the mutex, making it no longer visible to
other processes. As the result, a second instance of the attached test.c (from
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244493 with minor changes)
would trigger the assertion at mdb_txn_begin() because the acquisition of the
mutex would return 22 (EINVAL), because the mutex appeared to be a robust
mutex, but was invalid.
The attached lmdb.diff is a possible workaround for this (it would skip
unmapping when setting up the robust mutex for the first time).
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9220
Bug ID: 9220
Summary: Rewrite Bind and Exop result handling
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: ---
Bind and Exop result handling needs a rewrite so it is no longer a special case
for overlays.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9245
Bug ID: 9245
Summary: devel/programming needs rewrite
Product: website
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: website
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
The information on the devel/programming web page is at least a decade out of
date and needs a complete overhaul.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9219
Bug ID: 9219
Summary: Streamline tool API for 2.5
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: ---
The current tool API is a mess and needs fixing for 2.5. This affects things
like slapacl (The fix for bug#7920 was a kludge to deal with this, needs
revisiting).
--
You are receiving this mail because:
You are on the CC list for the bug.
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.
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.
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.
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.
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.