https://bugs.openldap.org/show_bug.cgi?id=9398
Issue ID: 9398
Summary: Stale accesslog cookie due to unclean shutdown
Product: OpenLDAP
Version: 2.4.56
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
If slapd terminates uncleanly, a checkpoint will be lost on the accesslog db.
Depending on the syncprov overlay checkpoint settings (usually no checkpointing
is enabled on the accesslog db) this can cause the system to refuse engage in
replication at startup.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9225
Bug ID: 9225
Summary: back-mdb: Add support for PREPARE/2-phase commit
Product: OpenLDAP
Version: 2.4.50
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Add support for PREPARE/2-phase commit in back-mdb
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9186
Bug ID: 9186
Summary: RFE: More metrics in cn=monitor
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: michael(a)stroeder.com
Target Milestone: ---
Currently I'm grepping metrics from syslog with mtail:
https://gitlab.com/ae-dir/ansible-ae-dir-server/-/blob/master/templates/mta…
With a new binary logging this is not possible anymore.
Thus it would be nice if cn=monitor provides more metrics.
1. Overall connection count per listener starting at 0 when started. This would
be a simple counter added to:
entries cn=Listener 0,cn=Listeners,cn=Monitor
2. Counter for the various "deferring" messages separated by the reason for
deferring.
3. Counters for all possible result codes. In my mtail program I also label it
with the result type.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=8943
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |SUSPENDED
--- Comment #6 from Howard Chu <hyc(a)openldap.org> ---
One major problem here is that overlays assume they all execute in the same
thread for the duration of an operation. Putting the response in the worker
thread would break overlay response callbacks.
It would be quite a lot of refactoring to make overlays thread-independent, and
that's not going to happen soon.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10255
Issue ID: 10255
Summary: OpenLDAP should leak the SSL ctx and not try to free
it in an atexit() handler
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: simon.pichugin(a)gmail.com
Target Milestone: ---
As mentioned in the subject, OpenLDAP incorrectly handles OpenSSL in its
destructor.
Сomprehensive information can be found here (along with a possible solution):
https://github.com/openssl/openssl/issues/25294
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10232
Issue ID: 10232
Summary: assert() at shutdown if a syncrepl session is in
refresh
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: ---
When removing the last one, syncinfo_free() checks that there is no active
refresh on the backend. This works if operating on olcSyncrepl values because
refresh_finished is called where appropriate. However if we're shutting down,
this is skipped to make sure we don't schedule a new task and that could lead
to an assert failure if there indeed was a refresh in progress (the same
probably applies when removing the DB).
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10248
Issue ID: 10248
Summary: translucent + subordinate regression
Product: OpenLDAP
Version: 2.6.8
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: mike(a)nolta.net
Target Milestone: ---
Created attachment 1027
--> https://bugs.openldap.org/attachment.cgi?id=1027&action=edit
translucent + subordinate regression testcase, formatted for
tests/data/regressions/
Hi,
Attached please find a testcase for a regression we noticed in a translucent +
subordinate slapd configuration.
The test works in version 2.4.59, but fails in versions 2.5.5 and 2.6.8.
In a nutshell, search results from the subordinate database aren't being
returned, even though (judging by the logs) they appear to be found.
Thanks,
-Mike
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10249
Issue ID: 10249
Summary: slapo-nestgroup leak with non-nested groups
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
Searching for a member= of a group when no nesting is in place will leak
memory.
It seems to stem from a few `gi.gi_numDNs` tests that should most likely be
against `gi.gi_DNs` instead.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10253
Issue ID: 10253
Summary: Compile failure with GnuTLS and GCC 14 on 32-bit
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: ryan(a)openldap.org
Target Milestone: ---
Debian bug report: https://bugs.debian.org/1078822
tls_g.c fails to compile on 32-bit platforms with GCC 14:
$ gcc --version
gcc (Debian 14.2.0-2) 14.2.0
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc -dumpmachine
i686-linux-gnu
$ ./configure --disable-slapd --with-tls=gnutls
[...]
$ make
[...]
libtool: compile: cc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c
tls_g.c -fPIC -DPIC -o .libs/tls_g.o
tls_g.c: In function ‘tlsg_session_pinning’:
tls_g.c:971:57: error: passing argument 4 of ‘gnutls_fingerprint’ from
incompatible pointer type [-Wincompatible-pointer-types]
971 | keyhash.bv_val, &keyhash.bv_len
) < 0 ) {
| ^~~~~~~~~~~~~~~
| |
| ber_len_t *
{aka long unsigned int *}
In file included from tls_g.c:44:
/usr/include/gnutls/gnutls.h:2408:32: note: expected ‘size_t *’ {aka ‘unsigned
int *’} but argument is of type ‘ber_len_t *’ {aka ‘long unsigned int *’}
2408 | size_t *result_size);
| ~~~~~~~~^~~~~~~~~~~
make[2]: *** [Makefile:431: tls_g.lo] Error 1
It looks like the warning has always been emitted since the code was originally
committed, but with GCC 14 it became an error. (See
<https://gcc.gnu.org/gcc-14/porting_to.html>. The last successful Debian build
used GCC 13.)
Quoting from the Debian bug report:
> ber_len_t is typedef'ed in openldap as unsigned LBER_LEN_T, which is
> AC_DEFINED as long. I'm not sure what a static AC_DEFINE in configure.ac
> achieves, but that's what we have. On the other side, we have size_t,
> which happens to be 32bit. Bummer. I suggest passing the 4th argument as
> a temporary variable of type size_t and copying it from/to the target
> structure after validating that it fits.
--
You are receiving this mail because:
You are on the CC list for the issue.