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.
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.
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.
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.
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.
https://bugs.openldap.org/show_bug.cgi?id=9516
Issue ID: 9516
Summary: Argon2 configuration parameters with slappasswd
Product: OpenLDAP
Version: 2.4.58
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: gilbert.kowarzyk(a)servicenow.com
Target Milestone: ---
It is currently possible to generate an Argon2 hash using slappasswd as
follows:
slappasswd -h {ARGON2} -o module-load=pw-argon2
However, I believe that it is currently not possible to provide Argon2
configuration values for parameters "m", "t", and "p" when using slappasswd.
If it is currently possible to provide these config parameters when using
slappasswd, please add documentation for how to do so.
Thanks in advance!
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9726
Issue ID: 9726
Summary: Admin guide and man pages need better documentation on
disabling syslog
Product: OpenLDAP
Version: 2.6.0
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
2.6.0 added the new feature allowing using a logfile for all debug/loglevel
messages and bypassing syslog entirely. However, there is no documentation on
the new settings or examples of how to do this in the admin guide, and the man
page sections on the new parameters for the logfile side do not note at
when/how they enable bypassing syslog.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9782
Issue ID: 9782
Summary: regression test its8752 failure
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: ---
If a contextCSN update (new cookie) goes from server A through server B to
server C, server C will use that CSN to update entryCSN as well (which neither
A nor B did). This fails the initial replication check.
The issue has likely existed since deltasync was made possible, a version of
this is confirmed at least in 2.4.60 onwards to current master. In principle,
it is related to concerns raised in ITS#9580.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9534
Issue ID: 9534
Summary: Persistent test043 failures
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: ---
In testing current RE25 as of 4/23/2021
(73b2769d05529a7d474661023f2c4f3a931417b2)
test043 is sporadically failing. Examining the testrun log, it appears
replication never even initiated.
--
You are receiving this mail because:
You are on the CC list for the issue.