https://bugs.openldap.org/show_bug.cgi?id=10503
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Group|OpenLDAP-devs |
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8461
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |FIXED
--- Comment #7 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
Fixed by switch to lmdb 1.0
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10274
Issue ID: 10274
Summary: Replication issue on MMR configuration
Product: OpenLDAP
Version: 2.5.14
Hardware: All
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: falgon.comp(a)gmail.com
Target Milestone: ---
Created attachment 1036
--> https://bugs.openldap.org/attachment.cgi?id=1036&action=edit
In this attachment you will find 2 openldap configurations for 2 instances +
slamd conf exemple + 5 screenshots to show the issue and one text file to
explain what you see
Hello we are openning this issue further to the initial post in technical :
https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/…
Issue :
We are working on a project and we've come across an issue with the replication
after performance testing :
*Configuration :*
RHEL 8.6
OpenLDAP 2.5.14
*MMR-delta *configuration on multiple servers attached
300,000 users configured and used for tests
*olcLastBind: TRUE*
Use of SLAMD (performance shooting)
*Problem description:*
We are currently running performance and resilience tests on our infrastructure
using the SLAMD tool configured to perform BINDs and MODs on a defined range of
accounts.
We use a load balancer (VIP) to poll all of our servers equally. (but it is
possible to do performance tests directly on each of the directories)
With our current infrastructure we're able to perform approximately 300
MOD/BIND/s. Beyond that, we start to generate delays and can randomly come
across one issue.
However, when we run performance tests that exceed our write capacity, our
replication between servers can randomly create an incident with directories
being unable to catch up with their replication delay.
The directories update their contextCSNs, but extremely slowly (like freezing).
From then on, it's impossible for the directories to catch again. (even with no
incoming traffic)
A restart of the instance is required to perform a full refresh and solve the
incident.
We have enabled synchronization logs and have no error or refresh logs to
indicate a problem ( we can provide you with logs if necessary).
We suspect a write collision or a replication conflict but this is never write
in our sync logs.
We've run a lot of tests.
For example, when we run a performance test on a single live server, we don't
reproduce the problem.
Anothers examples: if we define different accounts ranges for each server with
SALMD, we don't reproduce the problem either.
If we use only one account for the range, we don't reproduce the problem
either.
______________________________________________________________________
I have add some screenshots on attachement to show you the issue and all the
explanations.
______________________________________________________________________
*Symptoms :*
One or more directories can no longer be replicated normally after performance
testing ends.
No apparent error logs.
Need a restart of instances to solve the problem.
*How to reproduce the problem:*
Have at least two servers in MMR mode
Set LastBind to TRUE
Perform a SLAMD shot from a LoadBalancer in bandwidth mode OR start multiple
SLAMD test on same time for each server with the same account range.
Exceed the maximum write capacity of the servers.
*SLAMD configuration :*
authrate.sh --hostname ${HOSTNAME} --port ${PORTSSL} \
--useSSL --trustStorePath ${CACERTJKS} \
--trustStorePassword ${CACERTJKSPW} --bindDN "${BINDDN}" \
--bindPassword ${BINDPW} --baseDN "${BASEDN}" \
--filter "(uid=[${RANGE}])" --credentials ${USERPW} \
--warmUpIntervals ${WARMUP} \
--numThreads ${NTHREADS} ${ARGS}
--
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=9009
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|UNCONFIRMED |RESOLVED
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8461
Issue 8461 depends on issue 9009, which changed state.
Issue 9009 Summary: 2.7: Switch to LMDB v1.0
https://bugs.openldap.org/show_bug.cgi?id=9009
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |FIXED
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10500
Issue ID: 10500
Summary: back-ldif/ldif.c crc32() should be static — collides
with zlib's crc32 at link time
Product: OpenLDAP
Version: 2.6.13
Hardware: All
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: ionutn(a)gmail.com
Target Milestone: ---
In servers/slapd/back-ldif/ldif.c, the helper crc32() (defined at line 393 in
2.6.13) is declared with external linkage:
unsigned int
crc32(const void *vbuf, int len)
{
...
}
It is only used inside that file (lines 470 and 511). It has the same name as
zlib's public crc32() but a completely different signature and semantics — it's
an internal helper for hashing LDIF entry filenames, unrelated to zlib's
CRC-32-IEEE-802.3.
This is a latent symbol collision that has been present for many years. Until
recently, ld silently resolved zlib's crc32 references (from inflate.c.o /
deflate.c.o, transitively pulled in by libcrypto) against back-ldif's crc32 —
because back-ldif is linked first — and libz.a's crc32.c.o was never pulled in.
NEWLY EXPOSED BY zlib 1.3.2: zlib 1.3.2's deflate.c added an internal call to
crc32_z, a symbol defined only in libz.a(crc32.c.o). When slapd is linked
against libssl/libcrypto + libz.a, ld now has to pull in crc32.c.o to satisfy
crc32_z, which brings the public crc32 along — colliding with back-ldif's:
libz.a(crc32.c.o): In function `crc32':
zlib-1.3.2/crc32.c:950: multiple definition of `crc32'
libbackends.a(ldifldif.o):.../back-ldif/ldif.c:399: first defined here
collect2: error: ld returned 1 exit status
Reproduction: any build that links slapd (or anything pulling in libbackends.a)
together with libssl + libcrypto + zlib 1.3.2's libz.a. Hit on Linux/aarch64
and Linux/x86_64 with GCC 8.5 + ld from binutils.
Suggested fix (one keyword)
---------------------------
Mark the function static:
-unsigned int
+static unsigned int
crc32(const void *vbuf, int len)
Tested locally on 2.6.13: slapd builds cleanly against zlib 1.3.2 with this
change. No behaviour change since the function is only ever called from
within ldif.c.
Versions
--------
- Confirmed: 2.6.13 (latest) and 2.6.10. The code path appears identical going
back many releases.
- ld behaviour change is triggered specifically by zlib 1.3.2 (released
Feb 2026).
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10495
Issue ID: 10495
Summary: Environment variable for Systemd is ignored by
configure
Product: OpenLDAP
Version: 2.6.13
Hardware: All
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: openldap.aftermost863(a)passinbox.com
Target Milestone: ---
Hello,
When using the configure script to generate the Makefile, the documentation in
the --help option states that the environment variable 'systemdsystemunitdir'
can be used to override the default system path for Systemd units.
However, this does not work: if I export the variable with a valid existing
path (e.g. 'export systemdsystemunitdir=/tmp/test') and then run ./configure,
the variable is found but is ignored in the output variables and is therefore
not used in the Makefile.
config.log:
...
## ---------------- ##
## Cache variables. ##
## ---------------- ##
...
ac_cv_env_systemdsystemunitdir_set=set
ac_cv_env_systemdsystemunitdir_value=/tmp/test
...
## ----------------- ##
## Output variables. ##
## ----------------- ##
...
systemdsystemunitdir='/usr/lib/systemd/system'
...
The configure script seems to override that variable on line 23942:
systemdsystemunitdir=
I don’t quite understand why this line is there, and it seems suspicious to me.
However, if I remove it and run ./configure again in the exact same shell,
config.log now shows the correct path in the output variables, and the Makefile
uses it correctly afterward:
...
## ---------------- ##
## Cache variables. ##
## ---------------- ##
...
ac_cv_env_systemdsystemunitdir_set=set
ac_cv_env_systemdsystemunitdir_value=/tmp/test
...
pkg_cv_systemdsystemunitdir=/tmp/test
## ----------------- ##
## Output variables. ##
## ----------------- ##
...
systemdsystemunitdir='/tmp/test'
I had this issue on both Debian 13 (using bash) and Arch Linux (using zsh).
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10498
Issue ID: 10498
Summary: libldap OpenSSL 4 compatibility
Product: OpenLDAP
Version: 2.6.13
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: rainer.jung(a)kippdata.de
Target Milestone: ---
Created attachment 1145
--> https://bugs.openldap.org/attachment.cgi?id=1145&action=edit
Patch for libldap OpenSSL 4 compatibility
libldap uses direct access to struct members made opaque in OpenSSL 4.
Alternative getter methods needed to access the struct members seem to be
available since OpenSSL 1.1.0, so very long ago. I suggest the attached
(trivial) patch to replace direct access with getter methods.
The patch is based on OpenLDAP 2.6.13. From visual code inspection it seems the
problem also exists in the master branch.
I did not try to compile the rest of OpenLDAP with OpenSSL 4, just libldap.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10496
Issue ID: 10496
Summary: Remove references to Mozilla NSS in lload.conf(5) man
page
Product: OpenLDAP
Version: 2.6.10
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: ---
We removed Mozilla NSS support in OpenLDAP 2.5, remove references to it from
OpenLDAP 2.6 man pages.
--
You are receiving this mail because:
You are on the CC list for the issue.