https://bugs.openldap.org/show_bug.cgi?id=10389
Issue ID: 10389
Summary: mdb_opinfo_get: Assertion `!rc' failed. And data got
lost.
Product: OpenLDAP
Version: 2.6.9
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: 3049720393(a)qq.com
Target Milestone: ---
Hi All,
Don't know whether this problem is related to this bug or not, but want to
share it here as we still do not know the reason ;)
We're using version 2.6.9 now and started up by docker container. It works very
well when installing and starting it on a server instance.
But recently, we try to create it on Azure Container Apps service (which is a
service supporting to start docker containers), but found out that when two
openldap containers(openldap processes) run at the same time with same data
volume mounted, well, one is normally started, and another one is looping to
try to start but always failed.
The failed one shows errors:
```
mdb_db_open: database "dc=xxx,dc=exmple,dc=com" cannot be opened: Resource
temporarily unavailable (11). Restore from backup!
backend_startup_one (type=mdb, suffix="dc=xxx,dc=exmple,dc=com"): bi_db_open
failed! (11)
```
I think this is OK, because the started one is occupying the resources. And the
started up one is working well for some time, BUT suddenly at some point, it
went down to exit with the following error messages:
```
slapd: id2entry.c:828: mdb_opinfo_get: Assertion `!rc' failed.
/usr/local/bin/entrypoint.sh: line 160: 50 Aborted (core
dumped) slapd -d 32768 -u openldap -g openldap -F /etc/ldap/slapd.d
```
And as the previous normal one is exit, the other one can start up normally. So
we bash into it and ran `ldapsearch` command and found out that some of the
people entries were gone!!! But until now we still do not know the reason...
try to get some help here ;) thanks.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10395
Issue ID: 10395
Summary: Support multiple readers on uncommitted changes
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: renault.cle(a)gmail.com
Target Milestone: ---
Created attachment 1086
--> https://bugs.openldap.org/attachment.cgi?id=1086&action=edit
A patch to support multiple readers on uncommitted changes
Hello,
The attached patch is not meant to be merged immediately into LMDB. Still, it
demonstrates how I added a helpful feature to the key-value store: reading
uncommitted changes from multiple transactions. I am conscious that the patch
still requires some work and uses non-C99 features, i.e., atomics are C11,
which could be a blocker for it to be merged upstream. I would also be
delighted to merge these changes under a flag/define to ensure we don't impact
other users with non-C99 stuff.
The main feature we need at Meilisearch is to read uncommitted changes from
multiple threads, compute parallel post-processing of different data structures
[1], and speed up the search requests. We could have done the post-processing
in a following transaction by opening multiple read transactions, but this
would mean that the post-processed data structure would not include newly
inserted or modified document IDs. Both data structures would be desync.
Regarding the design choice, I decided to follow the same design as the nested
write transactions: use the parent argument of the mdb_txn_begin [2], and allow
the MDB_RDONLY flag, which was disallowed when the parent argument was non-NULL
[3]. I find it clear enough that, by calling the mdb_txn_begin function with
these arguments, you can call it multiple times (I need to update the doc) to
obtain nested read-only transactions from the parent write transaction.
ret = mdb_txn_begin(env, parent_txn, MDB_RDONLY, new_nested_rtxn);
Note that this early proposal lacks security and error handling. The generated
transactions are fake-read-only and actually write transactions that share the
underlying parent allocations and data structures. This is unsafe and must be
changed or reviewed carefully, but most importantly, we need to add read-only
capabilities to these transactions to disallow writes. Using a Rust wrapper on
top of LMDB, I wrapped the fake read-only transactions into ReadTxn, which
disallows any writes at compile time. However, I haven't checked the conflict
database creations or openings.
The main issues I encountered were concurrent free of the main shared data
structures when the different threads owning the transactions were dropping the
transactions simultaneously. So, I decided to implement the equivalent of an
ARC to free resources only when the last nested transaction was freed.
I can share numbers about how this feature improves the post-processing by
4x-9x or from 1200s to 120s [1]. You can look at this PR, which I would be
happy to merge once an improved version of this patch lands on LMDB upstream.
I would be very happy if you could guide me a bit on how I could improve this
patch to make it mergeable into LMDB. We want to contribute useful features
like this to LMDB and not keep a deviant fork. LMDB works great; we are happy
about it, and its performance is predictable.
Have a lovely week,
kero
[1]: https://github.com/meilisearch/meilisearch/pull/5307
[2]:
https://github.com/LMDB/lmdb/blob/14d6629bc8a9fe40d8a6bee1bf71c45afe7576b6/…
[3]:
https://github.com/LMDB/lmdb/blob/14d6629bc8a9fe40d8a6bee1bf71c45afe7576b6/…
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10392
Issue ID: 10392
Summary: back-ldap does not return a response if incorrect
secprops is configured
Product: OpenLDAP
Version: 2.6.10
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: ---
If a non-existent secprops mechanism is configured as part of a back-ldap
idassert-bind directive, back-ldap does not return a response to the following
requests, leaving the client waiting. In the same case meta and asyncmeta would
return an LDAP error. My guess is failure to establish the target connection is
handled incorrectly in that code path.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10391
Issue ID: 10391
Summary: Add proper compiler/linker flag for threading support
on HP-UX
Product: OpenLDAP
Version: 2.6.10
Hardware: Other
OS: Other
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: michael.osipov(a)innomotics.com
Target Milestone: ---
Created attachment 1085
--> https://bugs.openldap.org/attachment.cgi?id=1085&action=edit
Patch against master
If an application uses a thread-enabled library or the application itself is
thread enabled it is imperative on HP-UX to use the -mt flag through out build.
The compiler will transform into proper -D and -l flags.
From the manpage:
-mt Sets various -D flags to enable multi-threading. Also
sets -lpthread. +Oopenmp automatically implies -mt.
For details see HP C/aC++ Online Programmer's Guide.
Find a Git-formatted patch attached.
Sample output:
libtool: link: /opt/aCC/bin/aCC -AC99 +We901 -o ldapsearch ldapsearch.o
common.o ldsversion.o -L/opt/ports/lib/hpux32
../../libraries/liblutil/liblutil.a ../../libraries/libldap/.libs/libldap.a
-L/opt/ports/lib
/var/tmp/ports/work/openldap-threading-hpux/libraries/liblber/.libs/liblber.a
../../libraries/liblber/.libs/liblber.a /opt/ports/lib/hpux32/libsasl2.so -ldl
-lssl -lcrypto -mt -Wl,+b -Wl,/opt/ports/lib/hpux32
--
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.
https://bugs.openldap.org/show_bug.cgi?id=10393
Issue ID: 10393
Summary: Duplicate test names test090-asyncmeta-conttl and
test090-auditlog
Product: OpenLDAP
Version: 2.6.10
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: test suite
Assignee: bugs(a)openldap.org
Reporter: nivanova(a)symas.com
Target Milestone: ---
Probably patch approval timing problem, I suggest to rename
test090-asyncmeta-conttl to test091-asyncmeta-conttl.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10386
Issue ID: 10386
Summary: Feature request for Bcrypt Module
Product: OpenLDAP
Version: unspecified
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: contrib
Assignee: bugs(a)openldap.org
Reporter: young2k15(a)tutanota.com
Target Milestone: ---
I would like to have a bcrypt module added to the project.
--
You are receiving this mail because:
You are on the CC list for the issue.