openldap-bugs September 2021

openldap-bugs@openldap.org

1 participants
198 discussions

[Issue 8255] slapd-sock: response parsing in str2result() is broken
by openldap-its＠openldap.org 02 Sep '21

02 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=8255 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.7.0 |2.6.1 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9651] New: Add some kind of rate limiting option to ldapmodify
by openldap-its＠openldap.org 02 Sep '21

02 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9651 Issue ID: 9651 Summary: Add some kind of rate limiting option to ldapmodify Product: OpenLDAP Version: 2.5.6 Hardware: All OS: All Status: UNCONFIRMED Severity: enhancement Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- When using ldapmodify to replay a testing workload it would be useful to be able to specify a request rate, instead of just performing multiple operations in immediate succession. As a simpler alternative, just being able to specify a time interval between operations would be helpful. As an even greater future enhancement, it would be nice to have an option to replay an accesslog.ldif directly, using its embedded timestamps to control the time interval between operations. Currently this isn't feasible since reqstart timestamps only have 1-second granularity, the fraction part is a linear counter and not a microsecond value. The reqStart fraction would need to be extended to 9 decimal places with full nanosecond resolution in order to be usable as actual fractional time. We already know that microsecond resolution is insufficient to avoid frequent collisions. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9661] New: How to monitor an LDMB file for being pretty full
by openldap-its＠openldap.org 02 Sep '21

02 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9661 Issue ID: 9661 Summary: How to monitor an LDMB file for being pretty full Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- https://ltb-project.org/documentation/nagios-plugins/check_lmdb_usage provides a Nagios plugin, to check how full/free a LMDB database is. It calls mbd_stat -ef, and parses from the output the numbers in the “Max pages:”, “Number of pages used:”, and “Free pages:” lines. With these numbers it calculates “the percent of used pages” or “the percent of free pages” and signals the status with return values 0 -OK, 1 - warning, or 2 - critical . The disadvantage of check_lmdb_usage is, that it requires perl. Do you recommend to monitor the absolute number of free pages, the relative number of free pages, the absolute number of used pager, or the relative number of used pages? Please extend mdb_stat to be suitable for monitoring the fullness of a LMDB directory - accept parameters of for a warning and critical threshold, and a parameter on how to calculate the criterion (A - based on absolute number of free pages, B - relative number of free pages, C - absolute number of used pages, or D - relative number of used pages). -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 8375] paged results control results in full db search?
by openldap-its＠openldap.org 01 Sep '21

01 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=8375 --- Comment #7 from geert.hendrickx(a)telenetgroup.be <geert.hendrickx(a)telenetgroup.be> --- I can reproduce it on any sufficiently large db, both tree-structured or flat, given the right search scope. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8375] paged results control results in full db search?
by openldap-its＠openldap.org 01 Sep '21

01 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=8375 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |needs_review --- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> --- I'll put needs review on it though so we can discuss. ;) -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8375] paged results control results in full db search?
by openldap-its＠openldap.org 01 Sep '21

01 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=8375 --- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> --- (In reply to geert.hendrickx(a)telenetgroup.be from comment #4) > Hi > > I can reproduce exactly the same behaviour with OpenLDAP 2.5.7, on a freshly > slapadd'ed mdb. Target milestone for the fix is 2.7.0, so that's expected. ;) -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8375] paged results control results in full db search?
by openldap-its＠openldap.org 01 Sep '21

01 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=8375 --- Comment #4 from geert.hendrickx(a)telenetgroup.be <geert.hendrickx(a)telenetgroup.be> --- Hi I can reproduce exactly the same behaviour with OpenLDAP 2.5.7, on a freshly slapadd'ed mdb. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9658] New: libldap fails to compile on Hurd: MAXPATHLEN undeclared
by openldap-its＠openldap.org 31 Aug '21

31 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9658 Issue ID: 9658 Summary: libldap fails to compile on Hurd: MAXPATHLEN undeclared Product: OpenLDAP Version: 2.5.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- OpenLDAP 2.5 and later fails to compile on GNU/Hurd: libtool: compile: cc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c request.c -fPIC -DPIC -o .libs/request.o In file included from ldap-int.h:119, from request.c:53: request.c: In function 'ldap_dump_connection': ../../include/ldap_pvt.h:181:25: error: 'MAXPATHLEN' undeclared (first use in this function) 181 | #define LDAP_IPADDRLEN (MAXPATHLEN + sizeof("PATH=")) | ^~~~~~~~~~ request.c:859:17: note: in expansion of macro 'LDAP_IPADDRLEN' 859 | char from[LDAP_IPADDRLEN]; | ^~~~~~~~~~~~~~ ../../include/ldap_pvt.h:181:25: note: each undeclared identifier is reported only once for each function it appears in 181 | #define LDAP_IPADDRLEN (MAXPATHLEN + sizeof("PATH=")) | ^~~~~~~~~~ request.c:859:17: note: in expansion of macro 'LDAP_IPADDRLEN' 859 | char from[LDAP_IPADDRLEN]; | ^~~~~~~~~~~~~~ Makefile:435: recipe for target 'request.lo' failed make[2]: *** [request.lo] Error 1 This is not the same as ITS#9648. I have pulled latest master and the patch for that one does not solve it. GNU/Hurd actually does not have a MAXPATHLEN constant at all; paths are expected to be dynamically allocated. See: https://www.gnu.org/software/hurd/hurd/porting/guidelines.html#PATH_MAX_tt_… This is a low priority issue for me personally. I'm just filing it for tracking. I'm hoping someone from the GNU/Hurd community might be able to work on a patch. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2021