https://bugs.openldap.org/show_bug.cgi?id=10362
Issue ID: 10362
Summary: Normalised value confusions in replication
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: ---
A lot of code expects a_nvals state to be consistent across modifies and
multiple instances of the same attribute (with asserts to that effect), but
replication doesn't seem to obey this:
Add this assert into syncrepl_diff_entry()[0] :
assert( ( old->a_nvals == NULL ) == ( new->a_nvals == NULL ) );
if ( old->a_nvals )
assert( ( old->a_nvals == old->a_vals ) == ( new->a_nvals == new->a_vals )
);
You'll see many tests fail this, the first of which is test043.
[0].
https://git.openldap.org/openldap/openldap/-/blob/14d47146b0442df85bd949b21…
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10360
Issue ID: 10360
Summary: delta-sync can apply old mods
Product: OpenLDAP
Version: 2.6.9
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
This might be related to #10358, but not sure.
In delta MPR, if an older mod is received on an entry after a newer mod has
already been applied by a local user, the older mod is applied and the newer
mod is lost.
The incoming replication ops are checked for freshness by check_csn_age() but
that only checks the incoming cookieCSN against contextCSNs of the same SID.
I.e., that check only prevents duplicate mods being replicated multiple times
from the same remote provider. If check_csn_age() passes, then
syncrepl_message_to_op() is invoked which just applies the mod. It doesn't
check the mod or cookieCSN against the entry's current entryCSN.
The code in syncrepl_op_mod() performs the checks we need. The code just needs
to be pulled into a new function so it can be used in both places.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10359
Issue ID: 10359
Summary: delta-MPR uses logbase for more than it documents
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: ---
syncrepl logbase=<dn> is used not just for a syncrepl session (documented) but
also for internal searches when it comes to delta-MPR conflict resolution. This
is not documented so an admin doesn't know that the local accesslog DB needs to
exist and have the same suffix.
Either the documentation needs updating or a new configuration item needs to be
added to allow an accesslog DB with a different suffix locally.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10358
Issue ID: 10358
Summary: syncrepl can revert an entry's CSN
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: ---
Created attachment 1080
--> https://bugs.openldap.org/attachment.cgi?id=1080&action=edit
Debug log of an instance of this happening
There is a sequence of operations which can force a MPR node to apply changes
out of order (essentially reverting an operation). Currently investigating
which part of the code that should have prevented this has let it slip.
A sample log showing how this happened is attached.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10365
Issue ID: 10365
Summary: OOM during replication with a lot of updates
Product: OpenLDAP
Version: 2.6.10
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: elecharny(a)apache.org
Target Milestone: ---
When applying millions of updates on a huge database (30M entries), the server
can crash with an out of memory.
What happens is that the replication client does not process the incoming
updates fast enough, syncprov accumulate the changes in memory up to the point
it crashes.
The clear workaround: use more memory on the server.
Context: the replication mode used is delta-syncrepl, 2 servers, MMR , with MDB
and accesslog.
My assumption is that it would be valuable to benefit from the fact that we
know when the socket is ready for write to actually push data to the replica,
which means we can use the changes stored in accesslog and not in memory, while
keeping a state of replication. I assume it's a huge change in the way it
currently works.
There is no urgency, considering it's quite a specific use case, and it would
be way faster to slapmodify the changes on a stopped base, then copy the
content to the replica, then restart everything.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10361
Issue ID: 10361
Summary: lapo-auditlog: Add olcAuditLogNonBlocking to avoid
blocking when logging to named pipes
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: a.cudbardb(a)freeradius.org
Target Milestone: ---
Created attachment 1081
--> https://bugs.openldap.org/attachment.cgi?id=1081&action=edit
Patch adding olcAuditlogNonBlocking and a tests for slapo-auditlog
The default behaviour of fopen() when called on a named pipe which does not
have any reader, is to block, until a reader opens the pipe. This in turn
blocks slapo-auditlog when it attempts to write output, and prevents slapd
processing requests. Depending on how critical the audit log is, it may be
preferable to discard audit log output and continue processing requests if
there's no reader available which olcAuditLogNonBlocking: TRUE allows.
For clarity the call to fopen() is removed and replaced with open()/fdopen(),
allowing us to specify O_* flags as opposed to using fopen() OR open()/fdopen()
depending on whether we should block. 0666 are the base permissions used by
fopen() when files are created.
There were no tests for slapo-auditlog, so a small test suite that tests both
the basic behaviour, and blocking/non-blocking writes.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10356
Issue ID: 10356
Summary: Openldap -> Chasing the referral is not proceeding
further after 3 referrals
Product: OpenLDAP
Version: 2.4.56
Hardware: All
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: hharshitha2797(a)gmail.com
Target Milestone: ---
Hi Team
I have an issue with OpenLDAP 2.4.56. Chasing the referral only yields 3
referrals; the user login does not proceed further to other referrals.
This issue is seen in CentOS with OPENSSL 3.0
In OpenLDAP 2.1.22, the same is working; here, OpenSSL is not used. Here
OPENSSL 3.0 is not used. We can see around 8 referrals here.
--
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=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=10355
Issue ID: 10355
Summary: mplay doesn't compile on musl
Product: LMDB
Version: 0.9.33
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: tools
Assignee: bugs(a)openldap.org
Reporter: bgilbert(a)backtick.net
Target Milestone: ---
With the musl C library (e.g. Alpine Linux) mplay doesn't compile:
gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast
-Wuninitialized -c mplay.c
mplay.c: In function 'addpid':
mplay.c:490:23: error: assignment of read-only variable 'stdin'
490 | stdin = fdopen(0, "r");
| ^
mplay.c:491:24: error: assignment of read-only variable 'stdout'
491 | stdout = fdopen(1, "w");
| ^
make: *** [Makefile:99: mplay.o] Error 1
--
You are receiving this mail because:
You are on the CC list for the issue.