https://bugs.openldap.org/show_bug.cgi?id=10092
Issue ID: 10092
Summary: Local logging doesn't build on Windows
Product: OpenLDAP
Version: 2.6.6
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
slapd/logging.c uses writev() to write a prefix and the log message together in
one call. This feature doesn't exist on Windows. The closest equivalent,
WriteFileGather, only works on page sized and aligned writes. On Windows the
only way to write as desired is to copy the message into a new buffer first.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10140
Issue ID: 10140
Summary: Add microsecond timestamp format for local file
logging
Product: OpenLDAP
Version: 2.6.6
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: gnoe(a)symas.com
Target Milestone: ---
Add microsecond-level timestamps to local file logging.
Format is:
"YYYY-mm-ddTHH:MM:SS.ffffffZ"
The attached patch file is derived from OpenLDAP Software. All of the
modifications to OpenLDAP Software represented in the following patch(es) were
developed by Gregory Noe gnoe(a)symas.com. I have not assigned rights and/or
interest in this work to any party.
The attached modifications to OpenLDAP Software are subject to the following
notice:
Copyright 2023 Gregory Noe
Redistribution and use in source and binary forms, with or without
modification, are permitted only as authorized by the OpenLDAP Public License.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10372
Issue ID: 10372
Summary: support lastbind_forward_updates outside of the
lastbind overlay
Product: OpenLDAP
Version: 2.6.10
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: lklement(a)symas.com
Target Milestone: ---
according to the documentation for the LastBind overlay (slapo-lastbind) this
overlay is no longer recommended unless lastbind_forward_updates is used.
Can this functionality be added to the current lastbind configuration
recommendation?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10378
Issue ID: 10378
Summary: A default build should NOT trigger asserts
Product: OpenLDAP
Version: 2.6.10
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: daniel(a)haxx.se
Target Milestone: ---
Hello OpenLDAP peeps!
The other day I filed a bug [1] against Debian's OpenLDAP packaging because the
library they ship can assert and abort due to run-time conditions.
A library should never abort (in a release build) but should return a proper
error code to allow the application to decide the appropriate next step.
I was then informed that this build setup is what upstream (you) recommend and
encourage by default.
So, I'm here with a weak bug that I think you should shoot down and close
immediately if I am wrong.
I want to make sure that Debian is wrong, and that we can use OpenLDAP libs in
production without causing asserts going forward.
Surely Debian can just switch off the debug option, run without asserts and not
lose any important functionality?
[1] = https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1109791
Thanks!
/ Daniel
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10365
Issue ID: 10365
Summary: OOM during replication with a lot of updates
Product: OpenLDAP
Version: 2.6.10
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: elecharny(a)apache.org
Target Milestone: ---
When applying millions of updates on a huge database (30M entries), the server
can crash with an out of memory.
What happens is that the replication client does not process the incoming
updates fast enough, syncprov accumulate the changes in memory up to the point
it crashes.
The clear workaround: use more memory on the server.
Context: the replication mode used is delta-syncrepl, 2 servers, MMR , with MDB
and accesslog.
My assumption is that it would be valuable to benefit from the fact that we
know when the socket is ready for write to actually push data to the replica,
which means we can use the changes stored in accesslog and not in memory, while
keeping a state of replication. I assume it's a huge change in the way it
currently works.
There is no urgency, considering it's quite a specific use case, and it would
be way faster to slapmodify the changes on a stopped base, then copy the
content to the replica, then restart everything.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10368
Issue ID: 10368
Summary: Must revert ITS#9849 license changes
Product: website
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: major
Priority: ---
Component: website
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
The changes related to license.wml made for ITS#9849 must be reverted. There is
only one OpenLDAP Public License and it applies to all OpenLDAP software. There
are not two different licenses for release/LTS. No single person has the right
to alter the existing license.
Currently the website is broken, as
https://openldap.org/software/release/license.html is an empty file.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9849
Issue ID: 9849
Summary: Update website to support LTS and Feature releases
Product: website
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: website
Assignee: bugs(a)openldap.org
Reporter: mnormann(a)symas.com
Target Milestone: ---
Modify .wlmrc variable names and website content to handle both Feature Release
and Long Term Support release.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10203
Issue ID: 10203
Summary: no pkgconfig file included for liblmdb
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: otto(a)drijf.net
Target Milestone: ---
liblmdb does not ship with a pkgconfig file. More and more build systems rely
on presense of a pkgconfig file, so it would be nice if liblmdb installed
oneone. An example:
prefix=/usr/local
exec_prefix=${prefix}
libdir=${prefix}/lib
includedir=${prefix}/include
Name: lmdb
Description: Lightning memory-mapped database: key-value data store
URL: https://www.symas.com/symas-embedded-database-lmdb
Version: 0.9.32
Libs: -L${libdir} -llmdb
Cflags: -I${includedir}
Thanks.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10362
Issue ID: 10362
Summary: Normalised value confusions in replication
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: ---
A lot of code expects a_nvals state to be consistent across modifies and
multiple instances of the same attribute (with asserts to that effect), but
replication doesn't seem to obey this:
Add this assert into syncrepl_diff_entry()[0] :
assert( ( old->a_nvals == NULL ) == ( new->a_nvals == NULL ) );
if ( old->a_nvals )
assert( ( old->a_nvals == old->a_vals ) == ( new->a_nvals == new->a_vals )
);
You'll see many tests fail this, the first of which is test043.
[0].
https://git.openldap.org/openldap/openldap/-/blob/14d47146b0442df85bd949b21…
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10364
Issue ID: 10364
Summary: back-asyncmeta should process a notice-of-disconnect
and close the target connection
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: nivanova(a)symas.com
Target Milestone: ---
At present, back-asyncmeta discards all unsolicited messages, received on the
target connections. It should instead process Notice-of-Disconnection messages
and close the connections on which they were received.
--
You are receiving this mail because:
You are on the CC list for the issue.