https://bugs.openldap.org/show_bug.cgi?id=5277
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |SUSPENDED
Status|UNCONFIRMED |RESOLVED
Target Milestone|2.7.0 |---
--- Comment #2 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
patches welcome
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=5271
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |VERIFIED
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=5271
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|2.7.0 |---
Resolution|--- |SUSPENDED
Status|UNCONFIRMED |RESOLVED
--- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
patch welcome
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10108
Issue ID: 10108
Summary: "mdb_dump -a" does not dump the main database
Product: LMDB
Version: 0.9.29
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: tuukka.pensala(a)gmail.com
Target Milestone: ---
In mdb_dump.c we have these instructions:
/* -a: dump main DB and all subDBs
* -s: dump only the named subDB
* -n: use NOSUBDIR flag on env_open
* -p: use printable characters
* -f: write to file instead of stdout
* -V: print version and exit
* (default) dump only the main DB
*/
However, contrary to the description, the option -a does not dump the main DB.
With argument -a "dumpit(..)" is called for the named databases, but not for
the unnamed one.
With the current behavior, if the data store contains subDBs and has user-added
data in the main DB, there seems to be no way to dump all of it at once using
mdb_dump.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10107
Issue ID: 10107
Summary: Update support page with updated procedures to request
a listing.
Product: website
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: website
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Update the support page text at the bottom of the page on how to request a
listing using the ITS system instead of email as currently is described.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9735
Issue ID: 9735
Summary: [PATCH] try hard to find free space if database cannot
grow
Product: LMDB
Version: 0.9.24
Hardware: All
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: libor.peltan(a)nic.cz
Target Milestone: ---
Created attachment 851
--> https://bugs.openldap.org/attachment.cgi?id=851&action=edit
Patch fixing the issue "try hard to find free space if database cannot grow"
Note:
- the issue is the same in version 0.9.70 (git)
Situation:
- the database had already grown to its limit (mapsize) in the past
- overflow pages are used heavily as stored values are usually several pages
long
- free space got fragmented
Problem:
- attempt to insert new value results in MDB_MAP_FULL despite there is free
space available
Cause: there is a heursitic in mdb_page_alloc() that gives up searching for
free space chunk if this would take too much time. This is useful when the
database can still grow, as it balances performance with space usage. However,
if the database can no longer grow, it prevents inserting new values.
Solution: detect early on in mdb_page_alloc() if the database can grow, and if
not, let it try hard to search for free space.
Patch: attached
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10102
Issue ID: 10102
Summary: DB_LOCK_DEADLOCK
Product: OpenLDAP
Version: 2.4.23
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: daniel.hy.chan(a)pccw.com
Target Milestone: ---
We are getting "bdb_idl_insert_key: c_del failed: DB_LOCK_DEADLOCK: Locker
killed to resolve a deadlock (-30995)" error in Openldap debug log. We are
using Openldap.2.4.23 and have configured master-slave.
It seems insert error. Please kindly help.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10064
Issue ID: 10064
Summary: Add modrdn support for Cft_Misc entries
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: ---
Currently in cn=config, there is some special handling to maintain overlays/dbs
entries to allow list-like management. All module defined entries are marked
Cft_Misc and this behaviour is not available there.
It boils down to allowing the module to screen rename/renumber requests and
having bconfig defer to that callback if it's defined.
Use-case: policy selection rules in ITS#9343 would benefit from being managed
this way rather than having to reparse a long line every time a rule is
adjusted.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9471
Issue ID: 9471
Summary: Add RBAC 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 RBAC overlay to core
The slapo-rbac overlay is an implementation of the ANSI INCITS 359 Role-Based
Access Control (RBAC) Core.
When instantiated, it intercepts, decodes and enforces specific RBAC policies
per the Apache Fortress RBAC data formats.
The overlay provides a set of extended operations.
They include session create/delete, checkAccess, addActiveRole, dropActiveRole
and sessionRoles.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9472
Issue ID: 9472
Summary: Add datamorph 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 datamorph overlay to core
The datamorph overlay to slapd allows attributes with a few predefined values
to be saved more space-efficiently as well as signed or unsigned integer
attributes.
--
You are receiving this mail because:
You are on the CC list for the issue.