https://bugs.openldap.org/show_bug.cgi?id=9953
Issue ID: 9953
Summary: Push replication issue for the pwdHistory attribute
Product: OpenLDAP
Version: 2.4.57
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: dh(a)dotlan.net
Target Milestone: ---
Hello,
I'm using a master ldap instance with a push replication instance to external
slaves using the ldap backend on Debian 11 (2.4.57) and I came across some
replication issues that forces me to drop the slave dbs and do a manually
fullsync everything this error occurs.
The problem
===========
I know that replication and maintaining a password policy is a complicated
task, especially since the ppolicy overlay must be loaded and active in every
instance (master, push instance, slave). This problem leads to interesting
challanges.
First, I encountered a problem where pwdChangedTime would be duplicate because
the ppolicy overlay of the push instance and the back_ldap/slave instance would
like to set it (which leads to a duplicate attribute error). To fix problem I
backported the patch [1] to my local version of the slapd packages. After this
problem was fixed, I've encountered the next problematic attribute:
"pwdHistory". I've play around with some syncrepl settings, but in the end, it
seems to be a similar issue. It looks likes the pwdHistory attribute is not yet
present on the slave and both instances (push and slave) try to add the
pwdHistory Attributes which leads to a problem where both entries collied
(pwdHistory: value #0 already exists). For whatever reason pwdHistory doesn't
show up as modified field on the slave in the MOD request. But anyways.
Something seems to be wrong, and it could a similar replication issue compared
with pwdChangedTime
I've lookup into the change history of the ppolicy.c file in the 2.5 and 2.6
branch but couldn't find a newer commit that would address this issue.
Does anyone has encountered a similar issue? I've not played around with the
2.5 or 2.6 version, but looking at the code, I've either not seen a fix or the
problem might still exist, hopefully I am wrong. Any suggestions?
--
best regards
Daniel Hoffend
[1]
https://github.com/openldap/openldap/commit/7a34f46d1cabe8e80937d5167b62152…
Setup
=====
Host Master
- Debian 11 slapd 2.4.57+dfsg-3
- slapd master instance with cn=config
- push replikation instance with simple config (syncrepl from localhost, write
to backend ldap)
Host Slave
- Debian 11 slapd 2.4.57+dfsg-3
- Readonly slave
On all 3 instances ppolicy is enabled otherwise the operational attributes
would be not known/available and sync of locked accounts or per account
selected password policy assignment wouldn't work.
PUSH Replication Instance
=========================
database ldap
[...]
overlay ppolicy
ppolicy_default "cn=default,ou=policies,dc=example,dc=org"
syncrepl rid=__RID__
provider=ldap://localhost:389/
binddn="cn=replication,ou=system,dc=example,dc=org"
bindmethod=simple
credentials="secret"
searchbase="dc=example,dc=org"
type=refreshAndPersist
schemachecking=off
retry="5 12 60 +"
attrs="*,memberOf,pwdPolicySubentry,pwdChangedTime,pwdAccountLockedTime,pwdHistory,creatorsName,createTimestamp,modifiersName,modifyTimestamp"
---
Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_message_to_entry: rid=016
DN: uid=user1,ou=accounts,dc=example,dc=org, UUID:
db720f56-df0d-103c-8635-9543ccd6e97d
Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_entry: rid=016
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid a0a89700
Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_entry: rid=016 be_search
(0)
Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_entry: rid=016
uid=user1,ou=accounts,dc=example,dc=org
Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_null_callback : error code
0x14
Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_entry: rid=016 be_modify
uid=user1,ou=accounts,dc=example,dc=org (20)
Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_entry: rid=016 be_modify
failed (20)
Nov 3 00:00:45 ldapmaster slapd[2308611]: do_syncrepl: rid=016 rc 20 retrying
SLAVE LDAP Server
=================
database mdb
[...]
overlay ppolicy
ppolicy_default "cn=default,ou=policies,dc=example,dc=org"
---
Nov 3 00:00:45 ldapslave slapd[2221506]: conn=176499 op=59513 SRCH
base="uid=user1,ou=accounts,dc=example,dc=org" scope=0 deref=0
filter="(objectClass=*)"
Nov 3 00:00:45 ldapslave slapd[2221506]: conn=176499 op=59513 SEARCH RESULT
tag=101 err=0 nentries=1 text=
Nov 3 00:00:45 ldapslave slapd[2221506]: conn=176500 op=59513 MOD
dn="uid=user1,ou=accounts,dc=example,dc=org"
Nov 3 00:00:45 ldapslave slapd[2221506]: conn=176500 op=59513 MOD
attr=structuralObjectClass creatorsName createTimestamp userPassword
pwdChangedTime memberOf entryCSN modifiersName modifyTimestamp
Nov 3 00:00:45 ldapslave slapd[2221506]: conn=176500 op=59513 RESULT tag=103
err=20 text=modify/add: pwdHistory: value #0 already exists
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9736
Issue ID: 9736
Summary: pwrite bug in OSX breaking LMDB promise about the
maximum value size
Product: LMDB
Version: unspecified
Hardware: All
OS: Mac OS
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: renault.cle(a)gmail.com
Target Milestone: ---
Hi,
I was working with LMDB and found an issue when trying to write a value of
approximately 3.3GiB in the database, I dive into the LMDB source code of the
mdb_put method using the lldb debugger and found out that it was not related to
an issue in LMDB itself but rather a bug in the pwrite function of the Mac OS
libc implementation.
The pwrite function is given four parameters, the file descriptor, the buffer,
the count of bytes to write from the buffer and, the offset of where to write
it in the file. On Mac OS the count of bytes is a size_t that must be a 64bits
unsigned integer but when you call pwrite with a number bigger or equal to 2^31
it returns an error 22 (invalid argument). LMDB was returning a 22 error from
the mdb_put call and not an EINVAL because the error was cause by an internal
issue and not something catchable by LMDB.
I am not sure about what we can do, can we implement this single pwrite [1] as
multiple pwrite with counts smaller than 2^31 in a loop, just for Mac OS? Like
for Windows where we do specific things for this operating system too?
I also found this issue on the RocksDB repository [2] about a similar problem
they have with pwrite and write on Mac OS it seems. I understand that this is
not a real promise that LMDB is specifying but rather an "in theory" rule [3].
Thank you for your time,
kero
[1]:
https://github.com/LMDB/lmdb/blob/01b1b7dc204abdf3849536979205dc9e3a0e3ece/…
[2]: https://github.com/facebook/rocksdb/issues/5169
[3]: http://www.lmdb.tech/doc/group__mdb.html#structMDB__val
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9436
Issue ID: 9436
Summary: OpenSSL 3.0: libldap uses depreciated functions
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
OpenLDAP master fails to build against OpenSSL 3.0 alpha when "no-deprecated"
is specified.
Currently hitting these errors:
./.libs/libldap.so: undefined reference to `SSL_get_peer_certificate'
./.libs/libldap.so: undefined reference to `PEM_read_bio_DHparams'
./.libs/libldap.so: undefined reference to `ERR_get_error_line'
./.libs/libldap.so: undefined reference to `DH_free'
./.libs/libldap.so: undefined reference to `SSL_CTX_set_tmp_dh'
Notes:
SSL_get_peer_certificate is SSL_get1_peer_certificate in 3.0.0
SSL_CTX_set_tmp_dh should be replaced as follows:
# define SSL_CTX_set_tmp_dh(ctx,dh) \
SSL_CTX_ctrl(ctx,SSL_CTRL_SET_TMP_DH,0,(char *)(dh))
Have to dig deeper for:
PEM_read_bio_DHparams
ERR_get_error_line
DH_free
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9832
Issue ID: 9832
Summary: back-monitor crash when sizelimit in operation
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
If a back-monitor search gets a failure in send_search_entry(), e.g. due to
sizelimit being reached, a pending server pause, etc., it will try to call
monitor_cache_release( mi, e ) where e == NULL instead of the correct entry to
release.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9460
Issue ID: 9460
Summary: Drop support for OpenSSL older than 1.1.1
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
OpenSSL no longer supports the 1.0.2 series and specifically notes it should
not be used:
"All older versions (including 1.1.0, 1.0.2, 1.0.0 and 0.9.8) are now out of
support and should not be used."
Currently configure checks for 1.0.2 or higher.
OpenSSL 1.1.1 is supported through 11 Sep 2023.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9496
Issue ID: 9496
Summary: Some writes missing from database
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: igfoo(a)github.com
Target Milestone: ---
With the attached test program, some of my database writes appear not to
actually be written to the database. For example, a run may look like this:
$ ./run.sh
All done.
All finished
1802 test.txt
foo_200 is missing
bar_200 is missing
foo_404 is missing
bar_404 is missing
foo_407 is missing
bar_407 is missing
The script that I am using to run the program is below. This is using
mdb.master 52bc29ee2efccf09c650598635cd42a50b6ecffe on Linux, with an ext4
filesystem.
Is this an LMDB bug, or is there a bug in my code?
Thanks
Ian
#!/bin/sh
set -e
if ! [ -d lmdb ]
then
rm -rf lmdb
git clone https://github.com/LMDB/lmdb.git
INSTALL_DIR="`pwd`/inst"
cd lmdb/libraries/liblmdb
make install prefix="$INSTALL_DIR"
cd ../../..
fi
gcc -Wall -Werror -Iinst/include loop.c inst/lib/liblmdb.a -o loop -pthread
rm -f test.db test.db-lock
./loop
echo "All finished"
mdb_dump -np test.db > test.txt
wc -l test.txt
for i in `seq 100 999`
do
if ! grep -q "foo_$i" test.txt
then
echo "foo_$i is missing"
fi
if ! grep -q "bar_$i" test.txt
then
echo "bar_$i is missing"
fi
done
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9887
Issue ID: 9887
Summary: Offer to mirror OpenLDAP
Product: website
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: website
Assignee: bugs(a)openldap.org
Reporter: mirrors(a)jevincanders.net
Target Milestone: ---
Greetings,
We're from Jevin Canders, a hosting company based in New York (servers are in
Buffalo).
We're wondering if you wanted/needed another US mirror. We're already mirroring
other open source projects, including Kali Linux and F-Droid. As of next week
(tentatively), our mirror server will have a 20 Gbps pipe to work with, so
we'll be able to handle new projects.
Let us know if you have any questions, concerns, or requests.
Sincerely,
Josh Anders and Kevin Croissant
JC Mirrors Team
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9956
Issue ID: 9956
Summary: Please register my company on the support page
Product: website
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: website
Assignee: bugs(a)openldap.org
Reporter: sjsong(a)aboutdap.kr
Target Milestone: ---
Hello. openldap page administrater.
Please register my company on the support page.
Please contact me if you need additional information.
Registration phrase
Seojindsa Co., Ltd. (Aboutdap Co., Ltd.)- Korea
Provides consultancy, development, training and user support for OpenLDAP
software in Korea.
URL : seojindsa : www.seojindsa.kr, aboutdap : www.aboutdap.kr
thank you.
Song.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9912
Issue ID: 9912
Summary: slapd attempting free on address which was not
malloced
Product: OpenLDAP
Version: 2.6.3
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: kimjuhi96(a)snu.ac.kr
Target Milestone: ---
Providing following command-line input results in invalid free.
./servers/slapd/slapd -h1 -h1
This issue exists in openldap-2.6.3 and the master branch of git.
Environment:
- Ubuntu 20.04
- clang-14.0.6 with CFLAGS="-fsanitize=address"
Backtrace:
=================================================================
==3323395==ERROR: AddressSanitizer: attempting free on address which was not
malloc()-ed: 0x7ffc8512c238 in thread T0
#0 0x4d0077
(/home/juhee/project/foxfuzz/programs/network/openldap/servers/slapd/slapd+0x4d0077)
#1 0xb77152
(/home/juhee/project/foxfuzz/programs/network/openldap/servers/slapd/slapd+0xb77152)
#2 0x65ff02
(/home/juhee/project/foxfuzz/programs/network/openldap/servers/slapd/slapd+0x65ff02)
#3 0x5168a9
(/home/juhee/project/foxfuzz/programs/network/openldap/servers/slapd/slapd+0x5168a9)
#4 0x7ff21bd3c082 (/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
#5 0x42130d
(/home/juhee/project/foxfuzz/programs/network/openldap/servers/slapd/slapd+0x42130d)
Address 0x7ffc8512c238 is located in stack of thread T0 at offset 10072 in
frame
#0 0x515fef
(/home/juhee/project/foxfuzz/programs/network/openldap/servers/slapd/slapd+0x515fef)
This frame has 10 object(s):
[32, 36) 'rc' (line 220)
[48, 52) 'syslogUser' (line 230)
[64, 72) 'waitfds' (line 234)
[96, 100) 'level' (line 402)
[112, 128) 'opt' (line 432)
[144, 148) 'opt393' (line 717)
[160, 168) 'errmsg' (line 726)
[192, 196) 'buf' (line 778)
[208, 336) 'ebuf' (line 798)
[368, 496) 'ebuf524' (line 821) <== Memory access at offset 10072 overflows
this variable
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism, swapcontext or vfork
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: bad-free
(/home/juhee/project/foxfuzz/programs/network/openldap/servers/slapd/slapd+0x4d0077)
==3323395==ABORTING
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9951
Issue ID: 9951
Summary: lloadd can lock up in cn=monitor modify
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: lloadd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
lload_monitor_conn_modify's callers have borrowed the cn=monitor entry from the
cache, however it also observes memory management, so if the connection is
released and it is the last thread around, it might be responsible for freeing
it via epoch_leave(). However freeing it also requires that the connection be
removed from cn=monitor and we can deadlock there.
A fix is coming.
--
You are receiving this mail because:
You are on the CC list for the issue.