https://bugs.openldap.org/show_bug.cgi?id=10353
Issue ID: 10353
Summary: No TLS connection on Windows because of missing
ENOTCONN in socket.h
Product: OpenLDAP
Version: 2.6.10
Hardware: All
OS: Windows
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: julien.wadel(a)belledonne-communications.com
Target Milestone: ---
On Windows, the TLS connection cannot be done and we get the connection error:
Can't contact LDAP server.
=> Connections are done with WSAGetLastError().
After getting WSAEWOULDBLOCK, the connection is not restart because of the
state WSAENOTCONN that is not known.
OpenLDAP use ENOTCONN that is set to 126 by "ucrt/errno.h" while WSAENOTCONN
is 10057L.
Adding #define ENOTCONN WSAENOTCONN
like for EWOULDBLOCK resolve the issue.
Reference commit on external project:
https://gitlab.linphone.org/BC/public/external/openldap/-/commit/62fbfb12e8…
--
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=9564
Issue ID: 9564
Summary: Race condition with freeing the spilled pages from
transaction
Product: LMDB
Version: 0.9.29
Hardware: Other
OS: Mac OS
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: kriszyp(a)gmail.com
Target Milestone: ---
Created attachment 825
--> https://bugs.openldap.org/attachment.cgi?id=825&action=edit
Free the spilled pages and dirty overflows before unlocking the write mutex
The spilled pages (a transaction's mt_spill_pgs) is freed *after* a write
transaction's mutex is unlocked (in mdb.master3). This can result in a race
condition where a second transaction can start and subsequently assign a new
mt_spill_pgs list to the transaction structure that it reuses. If this occurs
after the first transaction unlocks the mutex, but before it performs the free
operation on mt_spill_pgs, then the first transaction will end up calling a
free on the same spilled page list as the second transaction, resulting in a
double free (and crash).
It would seem to be an extremely unlikely scenario to actually happen, since
the free call is literally the next operation after the mutex is unlocked, and
the second transaction would need to make it all the way to the point of saving
the freelist before a page spill list is likely to be allocated. Consequently,
this probably has rarely happened. However, one of our users (see
https://github.com/DoctorEvidence/lmdb-store/issues/48 for the discussion) has
noticed this occurring, and it seems that it may be particularly likely to
happen on MacOS on the new M1 silicon. Perhaps there is some peculiarity to how
the threads are more likely to yield execution after a mutex unlock, I am not
sure. I was able to reproduce the issue by intentionally manipulating the
timing (sleeping before the free) to verify that the race condition is
technically feasible, and apparently this can happen "in the wild" on MacOS, at
least with an M1.
It is also worth noting that this is due to (or a regression from) the fix for
ITS#9155
(https://github.com/LMDB/lmdb/commit/cb256f409bb53efeda4ac69ee8165a0b4fc1a277)
where the free call was moved outside the conditional (for having a parent)
that had previously never been executed after the mutex is unlocked, but now is
called after the unlock.
Anyway, the solution is relatively simple, the free call simply has to be moved
above the unlock. In my patch, I also moved the free call for mt_dirty_ovs. I
am not sure what OVERFLOW_NOTYET/mt_dirty_ovs is for, but presumably it should
be handled the same. This could alternately be solved by saving the reference
to these lists before unlocking, and freeing after unlocking, which would
slightly decrease the amount of processing within the mutex guarded code. Let
me know if you prefer a patch that does that.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10191
Issue ID: 10191
Summary: backend searches should respond to pause requests
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
A long running search will cause mods to cn=config to wait a long time. Search
ops should periodically check for threadpool pause requests.
--
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=10313
Issue ID: 10313
Summary: 3-way multimaster oathHOTPCounter attribute update
code missing
Product: OpenLDAP
Version: 2.6.6
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: agrru01(a)gmail.com
Target Milestone: ---
I posted on openldap technical mail list and got a response saying I should
file a feature request.
I am using a 3-way multimaster syncrepl setup with the slapo-otp module. My
problem is that when authenticating with a user using HOTP, the attribute
oathHOTPCounter only updates the value on the target ldap instance. This means
the other two ldap instances do not get the updated HOTP-counter value and
therefore will allow authentication using the same HOTP code.
Interestingly enough, if I manually edit the oathHOTPCounter value it
synchronizes with the other masters.
Please see the technical mail list discussion:
https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/…
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9739
Issue ID: 9739
Summary: Undefined reference to ber_sockbuf_io_udp in 2.6.0
Product: OpenLDAP
Version: 2.6.0
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: simon.pichugin(a)gmail.com
Target Milestone: ---
While I was trying to build OpenLDAP 2.6 on Fedora Rawhide I've got the error
message:
/usr/bin/ld: ./.libs/libldap.so: undefined reference to
`ber_sockbuf_io_udp'
I've checked commits from https://bugs.openldap.org/show_bug.cgi?id=9673 and
found that 'ber_sockbuf_io_udp' was not added to
https://git.openldap.org/openldap/openldap/-/blob/master/libraries/liblber/…
I've asked on the project's mailing list and got a reply:
"That symbol only exists if OpenLDAP is built with LDAP_CONNECTIONLESS
defined, which is not a supported feature. Feel free to file a bug report
at https://bugs.openldap.org/"
https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/…
Hence, creating the bug.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10373
Issue ID: 10373
Summary: pcache SEGV with pcacheTemplate ttr
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: bertrand(a)jacquin.bzh
Target Milestone: ---
Hi,
I am currently setting up OpenLDAP with pcache to circumvent aggressive LDAP
queries from an application and thus reduce load to the SQL database used in
the backend through back-sql.so.
The setup is incomplete and likely not currently implemented properly, please
don't pay too much attention in configuration details from below, however I'm
noticing SEGV when pcacheTemplate are configured with ttr:
refresh_purge() attempts to dereference NULL pointer *a, leading to the SEGV:
```
$ gdb --args /usr/lib64/openldap/slapd -u ldap -h "ldapi:/// ldap:///
ldaps:///" -f /etc/openldap/slapd.conf -d stats -d pcache
688224ea.1e5f48d7 0x7fffedffb6c0 conn=1020 op=2 SEARCH RESULT tag=101 err=0
qtime=0.000166 etime=0.012879 nentries=0 text=
688224ea.1e633093 0x7fffedffb6c0 conn=1020 op=3 SRCH
base="ou=<redacted>,dc=<redacted>,dc=<redacted>" scope=2 deref=0
filter="(&(objectClass=inetOrgPerson)(&(jpegPhoto=*)(|(mail=<redacted>))))"
688224ea.1e64fd20 0x7fffedffb6c0 conn=1020 op=3 SRCH attr=dn
688224ea.1e65fb45 0x7fffedffb6c0 query template of incoming query =
(&(objectClass=)(&(jpegPhoto=*)(|(mail=))))
688224ea.1e660563 0x7fffedffb6c0 Entering QC, querystr =
(&(objectClass=inetOrgPerson)(&(jpegPhoto=*)(|(mail=<redacted>))))
688224ea.1e660de7 0x7fffedffb6c0 Lock QC index = 0x555555828190
688224ea.1e6616cf 0x7fffedffb6c0 Not answerable: Unlock QC index=0x555555828190
688224ea.1e66209d 0x7fffedffb6c0 QUERY NOT ANSWERABLE
688224ea.1e6627c3 0x7fffedffb6c0 QUERY CACHEABLE
688224ea.1ed69d89 0x7fffedffb6c0 conn=1020 op=3 SEARCH RESULT tag=101 err=32
qtime=0.000009 etime=0.007587 nentries=0 text=
688224ea.1ef64669 0x7ffff4dfe6c0 conn=1020 op=4 UNBIND
688224ea.1efab72d 0x7fffedffb6c0 conn=1020 fd=30 closed
Thread 7 "slapd" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffee7fc6c0 (LWP 136445)]
refresh_purge (op=0x7fffee7fb610, rs=0x7fffee7fb290) at pcache.c:3392
3392 dnl->delete = ( a->a_numvals == 1 );
(gdb) bt
#0 refresh_purge (op=0x7fffee7fb610, rs=0x7fffee7fb290) at pcache.c:3392
#1 refresh_purge (op=0x7fffee7fb610, rs=0x7fffee7fb290) at pcache.c:3367
#2 0x00005555555a6098 in slap_response_play (op=op@entry=0x7fffee7fb610,
rs=rs@entry=0x7fffee7fb290) at result.c:573
#3 0x00005555555a7ddd in slap_send_search_entry (op=0x7fffee7fb610,
rs=0x7fffee7fb290) at result.c:1078
#4 0x000055555562e007 in mdb_search (op=<optimized out>, rs=<optimized out>)
at search.c:1110
#5 0x00007ffff73a6509 in refresh_query (op=0x7fffee7fb610,
query=0x7fffd8131830, on=0x55555577c350) at pcache.c:3464
#6 consistency_check (ctx=<optimized out>, arg=0x5555559429a0) at
pcache.c:3644
#7 0x00007ffff7f9e09d in ldap_int_thread_pool_wrapper (xpool=0x5555557aed80)
at tpool.c:1059
#8 0x00007ffff7d3b86b in ?? () from /usr/lib64/libc.so.6
#9 0x00007ffff7dbc858 in ?? () from /usr/lib64/libc.so.6
(gdb) fr 0
#0 refresh_purge (op=0x7fffee7fb610, rs=0x7fffee7fb290) at pcache.c:3392
3392 dnl->delete = ( a->a_numvals == 1 );
(gdb) p *dnl
$17 = {
next = 0x0,
dn = {
bv_len = 40,
bv_val = 0x7fffe403cb70
"uid=john,ou=<redacted>,dc=<redacted>,dc=<redacted>"
},
delete = 80 'P'
}
(gdb) p a
$10 = (Attribute *) 0x0
(gdb) p ad_queryId
$14 = (AttributeDescription *) 0x555555819580
(gdb) p *rs
$11 = {
sr_type = REP_SEARCH,
sr_tag = 0,
sr_msgid = 0,
sr_err = 0,
sr_matched = 0x0,
sr_text = 0x0,
sr_ref = 0x0,
sr_ctrls = 0x0,
sr_un = {
sru_search = {
r_entry = 0x7fffe403c5a0,
r_attr_flags = 17,
r_operational_attrs = 0x0,
r_attrs = 0x7fffee7fb320,
r_nentries = 0,
r_v2ref = 0x0
},
sru_sasl = {
r_sasldata = 0x7fffe403c5a0
},
sru_extended = {
r_rspoid = 0x7fffe403c5a0 "!",
r_rspdata = 0x11
}
},
sr_flags = 0
}
(gdb) p *rs->sr_entry
$12 = {
e_id = 33,
e_name = {
bv_len = 40,
bv_val = 0x7fffe403cae0
"uid=john,ou=<redacted>,dc=<redacted>,dc=<redacted>"
},
e_nname = {
bv_len = 40,
bv_val = 0x7fffe403cb18
"uid=john,ou=<redacted>,dc=<redacted>,dc=<redacted>"
},
e_attrs = 0x7fffe403c5f0,
e_ocflags = 256,
e_bv = {
bv_len = 0,
bv_val = 0x0
},
e_private = 0x7fffe403c5a0
}
(gdb) p *rs->sr_entry->e_attrs
$13 = {
a_desc = 0x555555781be0,
a_vals = 0x7fffe403c7f8,
a_nvals = 0x7fffe403c7f8,
a_numvals = 1,
a_flags = 12,
a_next = 0x7fffe403c618
}
```
Looking further I can see that attr_find() can return NULL, however NULL are
not verified in refresh_purge() after call to attr_find().
Note that I am using 2.6.8 that includes all the changes from ITS#9966 and I
can't find any noticeable changes on that area between 2.6.8. and latest 2.6.9.
OpenLDAP is built on gentoo with hardened profile:
```
$ /usr/lib64/openldap/slapd -V
@(#) $OpenLDAP: slapd 2.6.8 (Jul 23 2025 23:10:57) $
@localhost:/var/tmp/portage/net-nds/openldap-2.6.8-r1/work/openldap-OPENLDAP_REL_ENG_2_6_8-abi_x86_64.amd64/servers/slapd
$ /usr/lib64/libc.so.6 -V
GNU C Library (Gentoo 2.41-r4 (patchset 6)) stable release version 2.41.
Copyright (C) 2025 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.
Compiled by GNU CC version 14.3.0.
libc ABIs: UNIQUE IFUNC ABSOLUTE
Minimum supported kernel: 3.2.0
For bug reporting instructions, please see:
<https://bugs.gentoo.org/>.
```
Configuration is as follow:
```
pidfile /run/openldap/slapd.pid
argsfile /run/openldap/slapd.args
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/rfc2307bis.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/rfc8284.schema
# From
https://raw.githubusercontent.com/jirutka/ssh-ldap-pubkey/refs/heads/master…
include /etc/openldap/schema/openssh-lpk.schema
#loglevel stats stats2
loglevel stats
# Load dynamic modules
moduleload argon2.so
moduleload pw-pbkdf2.so
moduleload pw-sha2.so
moduleload back_sql.so
moduleload pcache.so
# Transport Layer Security
TLSCertificateFile /etc/ssl/ldap/openldap.crt
TLSCertificateKeyFile /etc/ssl/ldap/openldap.key
TLSProtocolMin 3.4
TLSCipherSuite ECDHE+CHACHA20:ECDHE+AESGCM
TLSECName X448:P-384:X25519:P-256
# Default search base to use when client submits a non-base search request with
an empty base DN
defaultsearchbase dc=<redacted>,dc=<redacted>
# Hashes to be used in generation of user passwords
password-hash {ARGON2ID}
# Specify a set of conditions to require
require LDAPv3 strong
disallow bind_anon
# Set of security strength factors to require
security ssf=128
localSSF 256
# SASL security properties
sasl-secprops noanonymous,noplain
# SASL mapping
authz-regexp uid=([^@]+)@([^,]+),cn=login,cn=auth
uid=$1,ou=$2,dc=<redacted>,dc=<redacted>
authz-regexp uid=([^@]+)@([^,]+),cn=plain,cn=auth
uid=$1,ou=$2,dc=<redacted>,dc=<redacted>
# Allow access to root over SASL
access to *
by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage
by * break
# Allow service authentication from UNIX socket only
access to dn.subtree="dc=local" attrs=userPassword
by sockname="PATH=/var/run/ldapi" auth
by anonymous auth
by * none
# Allow access to top level objects
access to dn.base="dc=local"
by users read
by * break
# Allow access to service CN
access to dn.subtree="dc=local"
by set.exact="this/cn & user/cn" read
by * break
# Allow user authentication
access to dn.subtree="dc=<redacted>,dc=<redacted>" attrs=userPassword
by anonymous auth
by * none
# Allow access to top level objects
access to dn.base="dc=<redacted>,dc=<redacted>"
by users read
by * break
# Allow access to users OU
access to dn.subtree="dc=<redacted>,dc=<redacted>"
by set.exact="this/ou & user/ou" read
by * break
# Allow services to access directory
access to dn.subtree="dc=<redacted>,dc=<redacted>"
by dn.exact="cn=<redacted>,dc=local" read
by dn.exact="cn=<redacted>,dc=local" read
by * break
# Deny everything else
access to *
by * none
# The config backend manages all of the configuration information for the
slapd(8) daemon.
database config
# Access control policy
access to dn.subtree="cn=config"
by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage
by * none
# Database instance definition
database mdb
directory /var/lib/openldap-data/dc=local
# DN suffix of queries that will be passed to this backend database
suffix dc=local
# Database instance definition
database sql
dbname openldap
dbuser openldap
dbpasswd <redacted>
# DN suffix of queries that will be passed to this backend database
suffix dc=<redacted>,dc=<redacted>
rootdn "uid=root,dc=<redacted>,dc=<redacted>"
# Put the database into "read-only" mode
readonly yes
subtree_cond "ldap_entries.dn LIKE CONCAT('%',?)"
children_cond "ldap_entries.dn LIKE CONCAT('%,',?)"
dn_match_cond "ldap_entries.dn=?"
oc_query "SELECT id,name,keytbl,keycol,create_proc,delete_proc,expect_return
FROM ldap_oc_mappings"
at_query "SELECT
name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return,sel_expr_u
FROM ldap_attr_mappings WHERE oc_map_id=?"
id_query "SELECT id,keyval,oc_map_id,dn FROM ldap_entries WHERE dn=?"
insentry_stmt "INSERT INTO ldap_entries (dn,oc_map_id,parent,keyval) VALUES
(?,?,?,?)"
delentry_stmt "DELETE FROM ldap_entries WHERE id=?"
renentry_stmt "UPDATE ldap_entries SET dn=?,parent=?,keyval=? WHERE id=?"
delobjclasses_stmt "DELETE FROM ldap_entry_objclasses WHERE entry_id=?"
# Do not use DN in reverse uppercased form
has_ldapinfo_dn_ru no
# Caching of LDAP search requests in a local databas
overlay pcache
pcache mdb 65536 16 1024 60
directory /var/lib/openldap-data/pcache
pcacheMaxQueries 1024
# Cache DN
pcacheAttrset 0 1.1
pcacheTemplate (objectClass=) 0 3600 60 0 15
pcacheTemplate (objectClass=*) 0 3600 60 0 15
pcacheTemplate (&(objectClass=)(&(jpegPhoto=*)(|(mail=)))) 0 3600 60 0 15
pcacheAttrset 1 jid
pcacheTemplate (jid=) 1 3600 60 0 15
pcacheAttrset 2 ou cn givenname sn mail telephonenumber jid description
jpegphoto objectClass
pcacheTemplate (&(objectClass=)(&(jpegPhoto=*)(|(mail=)))) 2 3600 60 0 15
pcacheTemplate (objectClass=*) 2 3600 60 0 15
pcacheTemplate (objectClass=) 2 3600 60 0 15
pcacheAttrset 3 ou cn givenname sn mail telephonenumber description jpegphoto
objectClass
pcacheTemplate (&(objectClass=)(&(jpegPhoto=*)(|(mail=)))) 3 3600 60 0
pcacheTemplate (objectClass=*) 3 3600 60 0
pcacheTemplate (objectClass=) 3 3600 60 0
pcacheAttrset 4 mail
pcacheTemplate (objectClass=*) 4 3600 60 0
pcacheAttrset 5 * +
pcacheTemplate (objectClass=*) 5 3600 60 0 15
pcacheTemplate (mail=) 5 3600 60 0 15
```
Cheers,
Bertrand
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10205
Issue ID: 10205
Summary: SSL handshake blocks forever in async mode if server
unaccessible
Product: OpenLDAP
Version: 2.5.17
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: regtube(a)hotmail.com
Target Milestone: ---
When ldaps:// scheme is used to connect to currently unaccessible server with
LDAP_OPT_CONNECT_ASYNC and LDAP_OPT_NETWORK_TIMEOUT options set, it blocks
forever on SSL_connect.
Here is a trace:
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP winserv.test.net:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 192.168.56.2:636
ldap_pvt_connect: fd: 3 tm: 30 async: -1
ldap_ndelay_on: 3
attempting to connect:
connect errno: 115
ldap_int_poll: fd: 3 tm: 0
ldap_err2string
[2024-04-25 15:41:27.112] [error] [:1] bind(): Connecting (X)
[2024-04-25 15:41:27.112] [error] [:1] err: -18
ldap_sasl_bind
ldap_send_initial_request
ldap_int_poll: fd: 3 tm: 0
ldap_is_sock_ready: 3
ldap_ndelay_off: 3
TLS trace: SSL_connect:before SSL initialization
TLS trace: SSL_connect:SSLv3/TLS write client hello
Looks like it happens because non-blocking mode is cleared from the socket
(ldap_ndelay_off) after the first poll for write, and non-blocking mode is
never restored before attempt to do tls connect, because of the check that
assumes that non-blocking mode has already been set for async mode:
if ( !async ) {
/* if async, this has already been set */
ber_sockbuf_ctrl( sb, LBER_SB_OPT_SET_NONBLOCK, (void*)1 );
}
while in fact it was cleared.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10379
Issue ID: 10379
Summary: lastbind change prevents ppolicy response from
reaching accesslog
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 "lastbind on" and ppolicy are configured together, the pwdLastSuccess
update triggers an accesslog entry (using op->o_time, op->o_tincr), then
ppolicy_bind_response issues its own modification and since the time was copied
in lastbind, an entry of the same name already exists. This means the ppolicy
change is lost (and e.g. won't replicate).
Note that slapo-lastbind (=the contrib overlay) probably has the same impact.
--
You are receiving this mail because:
You are on the CC list for the issue.