https://bugs.openldap.org/show_bug.cgi?id=10291
Issue ID: 10291
Summary: OpenLDAP matches localhost against local hostname
incorrectly
Product: OpenLDAP
Version: 2.6.2
Hardware: All
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: cmousefi(a)gmail.com
Target Milestone: ---
When connecting to a localhost LDAP server using TLS, I get this in debug log:
# ldapsearch -ZZ -H ldap://localhost/ -d9
<skip...>
TLS trace: SSL_connect:before SSL initialization
TLS trace: SSL_connect:SSLv3/TLS write client hello
TLS trace: SSL_connect:SSLv3/TLS write client hello
TLS trace: SSL_connect:SSLv3/TLS read server hello
TLS trace: SSL_connect:TLSv1.3 read encrypted extensions
TLS certificate verification: depth: 1, err: 0, subject: /CN=Test LDAP CA Root,
issuer: /CN=Test LDAP CA Root
TLS certificate verification: depth: 0, err: 0, subject: /CN=localhost, issuer:
/CN=Test LDAP CA Root
TLS trace: SSL_connect:SSLv3/TLS read server certificate
TLS trace: SSL_connect:TLSv1.3 read server certificate verify
TLS trace: SSL_connect:SSLv3/TLS read finished
TLS trace: SSL_connect:SSLv3/TLS write change cipher spec
TLS trace: SSL_connect:SSLv3/TLS write finished
TLS: hostname (1384a4485398) does not match common name in certificate
(localhost).
TLS: can't connect: TLS: hostname does not match name in peer certificate.
ldap_err2string
ldap_start_tls: Connect error (-11)
additional info: TLS: hostname does not match name in peer certificate
Expected behaviour: When connecting to localhost, I would expect the
certificate issued to localhost to work.
Actual behaviour: Certificate is issued to localhost but ldapsearch matches
against local hostname.
Here is the server certificate textual presentation
subject=CN=localhost
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
41:68:1b:be:cb:46:95:45:e7:72:03:8b:6c:b4:75:55:ca:5c:cb:c9
Signature Algorithm: ecdsa-with-SHA256
Issuer: CN=Test LDAP CA Root
Validity
Not Before: Dec 3 19:04:58 2024 GMT
Not After : Sep 2 19:04:58 2034 GMT
Subject: CN=localhost
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:f5:f1:f4:7d:56:85:87:b2:98:c9:b2:a2:83:ef:
52:71:01:1e:81:64:9f:64:ec:99:5a:e4:38:63:13:
69:de:09:00:1e:a1:e1:83:4a:c6:58:0d:c0:bb:4f:
36:7f:5a:f7:8f:74:b4:e2:96:06:09:9b:2c:0d:fb:
8c:6d:57:44:2e
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Subject Key Identifier:
5A:54:AF:41:E8:A0:EC:3D:28:3D:D6:0D:91:20:97:73:FA:40:AE:9C
X509v3 Authority Key Identifier:
FB:AF:31:4B:A2:2B:E1:DA:55:6A:3F:EE:D1:A4:74:51:C7:B9:9F:A7
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Subject Alternative Name:
IP Address:127.0.0.1, IP Address:0:0:0:0:0:0:0:1,
DNS:localhost, DNS:localhost.localdomain
Signature Algorithm: ecdsa-with-SHA256
Signature Value:
30:46:02:21:00:d4:9a:16:ba:6e:1d:c7:df:bd:5b:3d:56:b7:
0d:ea:aa:a7:7a:7f:d0:c1:ed:77:11:48:e8:aa:b1:6a:a8:ac:
28:02:21:00:d8:41:3d:a0:52:c8:2b:cc:13:34:46:1b:34:dd:
96:87:e5:7c:71:62:50:f3:2d:b1:18:3d:ce:27:34:c9:c4:32
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10292
Issue ID: 10292
Summary: LMDB documentation is unavailable. lmdb.tech domain
has expired
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: vadim.kovalyov(a)gmail.com
Target Milestone: ---
LMDB documentation is unavailable. lmdb.tech domain has expired. I can't find
the documentation anywhere else. If domain is gone, at least we need to update
the openldap website to point to a (new) documentation site.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10288
Issue ID: 10288
Summary: autoca Attribute olcAutoCAserverClass
Product: OpenLDAP
Version: 2.6.9
Hardware: All
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: stefan(a)kania-online.de
Target Milestone: ---
I try to add the autoca overlay with the following ldif:
--------------
dn: olcOverlay=autoca,olcDatabase={2}mdb,cn=config
objectClass: olcAutoCAConfig
objectClass: olcOverlayConfig
olcOverlay: autoca
olcAutoCADays: 3652
olcAutoCAKeybits: 4096
olcAutoCAserverClass: ipHost
olcAutoCAserverDays: 1826
olcAutoCAserverKeybits: 4096
olcAutoCAuserClass: person
olcAutoCAuserDays: 365
olcAutoCAuserKeybits: 4096
--------------
ldapadd gives me:
adding new entry "olcOverlay=autoca,olcDatabase={2}mdb,cn=config"
ldap_add: Other (e.g., implementation specific) error (80)
additional info: <olcAutoCAserverClass> handler exited with 1
If I remove the attribute from my ldif, it works.
What is wrong with the olcAutoCAserverClass attribute in my ldif? I try to look
it up in the admin handbook but I could not find anything. I looked in the
source code and found:
------------
{ "serverClass", "objectclass", 2, 2, 0,
ARG_STRING|ARG_MAGIC|ACA_SRVCLASS, autoca_cf,
"( OLcfgOvAt:22.2 NAME 'olcAutoCAserverClass' "
"DESC 'ObjectClass of server entries' "
"EQUALITY caseIgnoreMatch "
"SYNTAX OMsDirectoryString SINGLE-VALUE )", NULL, NULL },
------------
For me it looks the same as the attribute olcAutoCAuserclass.
-------------
{ "userClass", "objectclass", 2, 2, 0,
ARG_STRING|ARG_MAGIC|ACA_USRCLASS, autoca_cf,
"( OLcfgOvAt:22.1 NAME 'olcAutoCAuserClass' "
"DESC 'ObjectClass of user entries' "
"EQUALITY caseIgnoreMatch "
"SYNTAX OMsDirectoryString SINGLE-VALUE )", NULL, NULL },
-------------
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10293
Issue ID: 10293
Summary: Log operations generated by syncrepl at STATS level
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: nivanova(a)symas.com
Target Milestone: ---
Similarly to how incoming operations are logged, operations created by syncrepl
should be logged as well.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9886
Issue ID: 9886
Summary: At "sync" logging, nothing shows how long a write op
took on consumers
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
If sync logging is enabled on a consumer, there's no etime logged which means
it is not possible to see how long a write op took on that consumer. This can
be useful information to see how the node is performing, particularly if it is
a read only node where there will be no general MOD timing logged.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10290
Issue ID: 10290
Summary: Combination of syncrepl+rwm+syncprov frees the wrong
modlist
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: ---
An MPR setup with rwm enabled (regardless of configuration it seems) will crash
with the provided modlist being freed twice. This is the sequence of events of
what is stored in op->orm_modlist, allocated and freed by whom, replacing the
actual pointers to make it easier to track:
syncrepl_message_to_op: preparing a modify with 0xoriginal
syncrepl_op_modify: old modlist 0xoriginal replacing with 0xsyncrepl_op_modify
rwm_op_modify: old modlist 0xsyncrepl_op_modify replacing with 0xrwm_op_modify
<modify happens>
syncrepl_modify_cb: freeing 0xsyncrepl_op_modify, replacing with 0xoriginal
(forgetting 0xrwm_op_modify)
rwm_op_rollback: freeing 0xoriginal replacing with 0xsyncrepl_op_modify
syncrepl_message_to_op: went in with 0xoriginal, got 0xsyncrepl_op_modify back
syncrepl_message_to_op: freeing 0xsyncrepl_op_modify
Not sure who is at fault: syncrepl_modify_cb is the one freeing the wrong
modlist, but then if backover were to work with an actual "stack", running
response callbacks in the opposite order from the request, things would have
been ok too.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10289
Issue ID: 10289
Summary: myldap
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: cmp(a)tutanota.de
Target Milestone: ---
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10275
Issue ID: 10275
Summary: mdb_load could use a parameter to pass batch size
Product: LMDB
Version: 0.9.21
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: tools
Assignee: bugs(a)openldap.org
Reporter: gkwicker(a)amazon.com
Target Milestone: ---
Created attachment 1037
--> https://bugs.openldap.org/attachment.cgi?id=1037&action=edit
Patch to mdb_load.c in version 0.9.21
mdb_load is very slow when ingesting a large db. The attached patch (0.9.21
but will apply to other versions with modification) allows the user to pass a
batch size to be used instead of the default value of 100. Changing the batch
size to a larger value improves ingestion speed.
I, Gary Wicker, hereby place the following modifications to OpenLDAP Software
(and only these modifications) into the public domain. Hence, these
modifications may be freely used and/or redistributed for any purpose with or
without attribution and/or other notice.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10024
Issue ID: 10024
Summary: MDB_PREVSNAPSHOT broken
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: markus(a)objectbox.io
Target Milestone: ---
It seems that the patch #9496 had a negative side effect on MDB_PREVSNAPSHOT.
In certain cases, when opening the DB using MDB_PREVSNAPSHOT, the previous (2nd
latest) commit is not selected. Instead, reads show that the latest commit was
selected voiding the effect of MDB_PREVSNAPSHOT.
I observed this in our test cases a while back. Today, I was finally able to
reproduce it and debug into it.
When creating the transaction to read the data, I debugged into mdb_txn_renew0.
Here, ti (MDB_txninfo; env->me_txns) was non-NULL. However, ti->mti_txnid was 0
(!) and thus txn->mt_txnid was set to 0. That's the reason for always selecting
the first (index 0) meta page inside mdb_txn_renew0:
meta = env->me_metas[txn->mt_txnid & 1];
This line occurs twice (once for read txn and once for write txn; it affects
both txn types).
Thus, the chances of MDB_PREVSNAPSHOT selecting the correct meta page is 50-50.
It's only correct if the first meta page (index 0) is the older one.
I believe that this is related to #9496 because the patch, that was provided
there, removed the initialization of "env->me_txns->mti_txnid" in
mdb_env_open2. This would explain why txn->mt_txnid inside mdb_txn_renew0 was
set to 0.
I can confirm that adding back the following two lines back in fixes
MDB_PREVSNAPSHOT:
if (env->me_txns)
env->me_txns->mti_txnid = meta.mm_txnid;
The said patch including the removal of these two lines was applied in the
commit(s) "ITS#9496 fix mdb_env_open bug from #8704" (Howard Chu on 09.04.21).
I hope this information is useful to find a suitable fix. Please let me know if
you have questions. Also, I'd be happy to help confirming a potential fix with
our test suite.
--
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.