https://bugs.openldap.org/show_bug.cgi?id=10363
Issue ID: 10363
Summary: Implement a target connection time-to-live in
asyncmeta
Product: OpenLDAP
Version: unspecified
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: ---
Implement a feature that limits the maximum time before a target connection is
reset, even if it is not idle - conn-ttl. To avoid too many target connections
timing out at once, a minimum reset interval per target should also be
configurable. So, a configuration of:
conn-ttl 5s 5s
would mean connections have a 5 seconds time-to-live, but a connection should
be reset no more frequently that once every 5 seconds per target.
This feature was requested by a customer.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10364
Issue ID: 10364
Summary: back-asyncmeta should process a notice-of-disconnect
and close the target connection
Product: OpenLDAP
Version: unspecified
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: ---
At present, back-asyncmeta discards all unsolicited messages, received on the
target connections. It should instead process Notice-of-Disconnection messages
and close the connections on which they were received.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10456
Issue ID: 10456
Summary: Record time it took to run purge task
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: ---
accesslog could report a summary at the end of the purge saying how long it
took and how many entries were (or would have been if shutting down) removed in
that run. Thinking SYNC level as that's where most accesslog's messages go
already.
--
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=10424
Issue ID: 10424
Summary: When using more than one syncrepl directive on a
single DB, the contextCSN should be stored accordingly
to the replication base
Product: OpenLDAP
Version: 2.6.10
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: elecharny(a)apache.org
Target Milestone: ---
Trying to replicate cn=config but parially, I tried to set many syncrepl
directives so that each oe of them just replicate the single element it is
configured for. Here is an exemple thet replicate the frontend database and
only it:
{0}rid=004
provider=ldaps://openldap1:10636
bindmethod=simple
binddn="cn=syncrepl,ou=accounts,dc=worteks,dc=com"
credentials=blah
tls_cacert=/opt/application/openldap/ssl/ca.crt
tls_cert=/opt/application/openldap/ssl/openldap-common.crt
tls_key=/opt/application/openldap/ssl/openldap-common.key
tls_reqcert=demand
tls_protocol_min=3.3
searchbase="olcDatabase={-1}frontend,cn=config"
scope="base"
type=refreshAndPersist
retry="30 +"
timeout=1
schemachecking=off
If I have this single syncrepl directive, all is ok, it replicates the frontend
data and only this entry.
Would I like to replicate, says, 'cn=config' with another syncrepl directive
like:
olcSyncrepl: {0}rid=001
provider=ldaps://openldap1:10636
bindmethod=simple
binddn="cn=syncrepl,ou=accounts,dc=worteks,dc=com"
credentials=blah
tls_cacert=/opt/application/openldap/ssl/ca.crt
tls_cert=/opt/application/openldap/ssl/openldap-common.crt
tls_key=/opt/application/openldap/ssl/openldap-common.key
tls_reqcert=demand
tls_protocol_min=3.3
searchbase="cn=config"
scope="base"
type=refreshAndPersist
retry="30 +"
timeout=1
schemachecking=off
where the search base is different, then suddenly I get some 'CSN too old'
errors, which make totally sense as we only have one single contextCSN stored
in the root entry (cn=config in my use case).
I know I'm really border line here (and the rational is that I want a partial
replication of cn=config because the two servers are a bit different), but I
would suggest that the contextCSN to be stored in the entry associated to the
searchBase, not at the root of the database.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10440
Issue ID: 10440
Summary: memberof stop working on replication slaves after
upgrade from 2.6.10
Product: OpenLDAP
Version: 2.6.12
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: statoon54(a)gmail.com
Target Milestone: ---
Hi,
We encountered a problem yesterday when upgrading to OpenLDAP version 2.6.12.1
from 2.6.10.1.
The memberOf overlay failed to delete or add memberOf on the replica servers.
Replication is functioning correctly, memberOf on master works too, but adding
or removing a group member from the master no longer triggers this change on
the slave servers. I think there's a regression in this version when
replication occurs.
Standard configuration
overlay memberof
memberof-refint true
memberof-dangling ignore
# sortVals
sortvals member
# multivalued attributes stockage improvement
multival member 1000,100
#
# Sync prov Replica
#
# syncrepl directive
syncrepl rid=001
provider=""xxxxxx"
bindmethod=simple
binddn="xxxxxx"
credentials="xxxxx"
searchbase="xxxxx"
scope="sub"
attrs="*,+"
schemachecking=off
type=refreshAndPersist
retry="5 12 60 10 300 24 3600 +"
timeout=60
network-timeout=0
keepalive=0:0:0
updateref xxxxxx
---
Some trace show a 122 failed on memberof_value_modify if i add or delete a
member. (works great since 2.6.10 on slaves)
févr. 04 11:38:04 ldap-v4-slave-1-dev slapd[573178]: syncrepl_entry: rid=001
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY)
csn=20260204103803.030751Z#000000#000#000000 tid 0x7f7a1d3fd6c0
févr. 04 11:38:04 ldap-v4-slave-1-dev slapd[573178]: syncrepl_entry: rid=001
be_search (0)
févr. 04 11:38:04 ldap-v4-slave-1-dev slapd[573178]: syncrepl_entry: rid=001
cn=APP:EBOUTIQUE,ou=groups,dc=exemple,dc=fr
févr. 04 11:38:04 ldap-v4-slave-1-dev slapd[573178]: slap_queue_csn: queueing
0x7f7a1443a5a0 20260204103803.030751Z#000000#000#000000
févr. 04 11:38:10 ldap-v4-slave-1-dev slapd[573178]: conn=-1 op=0:
memberof_value_modify DN="uid=269015,ou=accounts,dc=exemple,dc=fr" delete
memberOf="cn=APP:EBOUTIQUE,ou=groups,dc=exemple,dc=fr" failed err=122
févr. 04 11:38:10 ldap-v4-slave-1-dev slapd[573178]: slap_graduate_commit_csn:
removing 0x7f7a1443a5a0 20260204103803.030751Z#000000#000#000000
févr. 04 11:38:10 ldap-v4-slave-1-dev slapd[573178]: syncrepl_entry: rid=001
be_modify cn=APP:EBOUTIQUE,ou=groups,dc=exemple,dc=fr (0)
févr. 04 11:38:10 ldap-v4-slave-1-dev slapd[573178]: slap_queue_csn: queueing
0x7f7a14439de0 20260204103803.030751Z#000000#000#000000
févr. 04 11:38:10 ldap-v4-slave-1-dev slapd[573178]: slap_graduate_commit_csn:
removing 0x7f7a14439de0 20260204103803.030751Z#000000#000#000000
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10427
Issue ID: 10427
Summary: ldapsearch(1) incorrectly documents OID-based search
option
Product: OpenLDAP
Version: 2.6.10
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: michael.osipov(a)innomotics.com
Target Milestone: ---
Created attachment 1109
--> https://bugs.openldap.org/attachment.cgi?id=1109&action=edit
Git-formatted patch
Docs/manpage for -E say:
[!]<oid>[=:<value>|::<b64value>]
But it does not work:
> $ ldapsearch -Y GSSAPI -O maxssf=1 -E '!1.2.840.113556.1.4.1340::MAYSBAAAAAI=' -o ldif-wrap=no -H ldap://innomotics.net "(objectClass=dnsNode1)"
Invalid search extension name: 1.2.840.113556.1.4.1340::MAYSBAAAAAI
It is '=::':
> $ ldapsearch -Y GSSAPI -O maxssf=1 -E '!1.2.840.113556.1.4.1340=::MAYSBAAAAAI=' -o ldif-wrap=no -H ldap://innomotics.net "(objectClass=dnsNode1)"
> SASL/GSSAPI authentication started
Attached is a simple patch to fix it.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10451
Issue ID: 10451
Summary: Sporadic failures in test lloadd/test001
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: ---
It seems the connection is made but lloadd never gets the memo so it doesn't
proceed with setting up the rest.
--
You are receiving this mail because:
You are on the CC list for the issue.