https://bugs.openldap.org/show_bug.cgi?id=6949
--- Comment #20 from OndÅ™ej KuznÃk <ondra(a)mistotebe.net> ---
I would also note that there's a fair amount of fprintf( stderr, ... ) peppered
around the code, that might also need cleaning up at some point.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9692
Issue ID: 9692
Summary: Insertion rate in large groups slows unexpectedly
Product: OpenLDAP
Version: 2.5.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: smckinney(a)symas.com
Target Milestone: ---
Created attachment 843
--> https://bugs.openldap.org/attachment.cgi?id=843&action=edit
slapd.conf
Observed during jmeter tests[1] that perform ldapmod operations, adding members
into a group. The insertion speed decreases unexpectedly, as the size of the
group increases.
A test run starts 10 jmeter threads, each doing 1000 mods = 100,000 members
added altogether to a group.
At the beginning of the test, throughput is approximately 200/s. At the end,
the mod rate slows down to < 10/s.
Multival and sortval are enabled (slapd.conf attached):
sortvals member
multival member 500,3
*** Server info
Ubuntu20
2 CPU Cores
4GB RAM
symas-openldap-server 2.5.7-1focal1
*** To verify multival is enabled:
```
data/dc=example,dc=com# mdb_stat -s id2v .
Status of id2v
Tree depth: 1
Branch pages: 0
Leaf pages: 1
Overflow pages: 0
Entries: 746316
```
[1][ldap-load-gen](https://gitlab.symas.net/symas-public/ldap-load-gen)
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9639
Issue ID: 9639
Summary: slapd -r : what must be present in the chroot
environment
Product: OpenLDAP
Version: 2.4.59
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: dpa-openldap(a)aegee.org
Target Milestone: ---
`man slapd` -
https://www.openldap.org/software/man.cgi?query=slapd&apropos=0&sektion=0&m…
- says that the -r option calls chroot.
Please clarify, what must be present in the chroot environment: /proc, /tmp,
/dev/shm , libc
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=6949
--- Comment #19 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
head:
• 66c62841
by Howard Chu at 2021-09-30T04:23:29+01:00
ITS#6949 fixup loglevel delete, consolidate redundant code
RE26:
• e2739d9f
by Howard Chu at 2021-09-30T15:32:11+00:00
ITS#6949 fixup loglevel delete, consolidate redundant code
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9156
--- Comment #15 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
head:
commit 4cd096defffc278f13edf9a194f4bc62095a947e
Author: OndÅ™ej KuznÃk <ondra(a)mistotebe.net>
Date: Mon Jun 7 15:52:25 2021 +0100
ITS#9156 Do not spam the logs on account of lastbind
Re25:
• 667ea288
by OndÅ™ej KuznÃk at 2021-09-30T16:02:34+00:00
ITS#9156 Do not spam the logs on account of lastbind
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9710
Issue ID: 9710
Summary: integrated lastbind debug statement at ANY level
Product: OpenLDAP
Version: 2.5.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
For some reason, a debug statement for the newly integrated lastbind code is
logging at ANY level, which seems incorrect:
Debug( LDAP_DEBUG_ANY, "fe_op_lastbind: "
"old pwdLastSuccess value=%s %lds ago\n",
a->a_nvals[0].bv_val, bindtime == (time_t)-1 ? -1 : op->o_time
- bindtime );
This results in log lines with every bind like:
Sep 30 01:41:42 ub18 slapd[5980]: fe_op_lastbind: old pwdLastSuccess
value=20210930014121Z 21s ago
I think a different loglevel should be in use here.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9156
--- Comment #14 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
*** Issue 9710 has been marked as a duplicate of this issue. ***
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=6949
--- Comment #18 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
head:
Commits:
• 10fb8c0a
by Howard Chu at 2021-09-29T14:39:28+01:00
ITS#6949 fix logfile_only regression in prev commit
RE26:
Commits:
• 74d1475a
by Howard Chu at 2021-09-29T21:29:15+00:00
ITS#6949 fix logfile_only regression in prev commit
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9708
Issue ID: 9708
Summary: null (empty) attribute values of type Directory String
pass the dry-run validation
Product: OpenLDAP
Version: 2.5.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: mheyman(a)symas.com
Target Milestone: ---
On behalf of Aaron Bliss at Paychex
----
I'm pretty confident that I've identified a bug when running slapadd with the
dry-run switch. As a step of migrating a given replica set from oDSEE to
OpenLDAP, we of course make use of the dry-run switch after sanitizing a given
oDSEE export. However on a few migrations I've noticed that null (empty)
attribute values of type Directory String (which are illegal per the RFC) pass
the dry-run validation. This becomes really problematic because a subsequent
slapadd in which the quick switch is passed will load the invalid data into the
database. I understand that loading a given ldif using the quick switch
performs fewer consistency checks on the input data however with our largest
dataset's, it's not viable for us to migrate a given replica set from oDSEE to
OpenLDAP without using the quick switch (it would require an outage that's far
longer than we can allow for on the customer side of things).
It makes total sense for sure that OpenLDAP will not allow for null values for
this attribute type in keeping with the standard but unfortunately oDSEE allows
for it as such we have to account for it. Would it be possible to catch the
null attribute value scenario when performing a dry run and if so is there any
way this could be prioritized (doing so would be of tremendous help to us)? If
not then I'll have to write my own validation (not at all ideal) to check for
this scenario but for sure would be better if slapadd can catch this condition.
Thanks much as always.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=6949
--- Comment #17 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
RE26:
• c23c6563
by Howard Chu at 2021-09-27T19:20:18+00:00
ITS#6949 honor specified loglevel, not just debuglevel
--
You are receiving this mail because:
You are on the CC list for the issue.