https://bugs.openldap.org/show_bug.cgi?id=9015
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |2.4.54
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9353
Issue ID: 9353
Summary: back-monitor confuses frontendDB with suffix ""
databases
Product: OpenLDAP
Version: 2.4.53
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
If a database is configured with zero length suffix, supplemental monitoring
entries/attributes that are to be registered against that database show up on
the cn=FrontendDB,cn=Databases,cn=Monitor entry instead.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9359
Issue ID: 9359
Summary: syncrepl_op_modify can create invalid mods
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: replication
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
In Delta MPR, if a modify gets delayed in reaching another server and another
(later) modify has already changed that entry, its parts are checked by
syncrepl_op_modify.
Replaces will then be split into a delete+add pairs so they can be resolved
separately, but a bug in mods_dup happily creates an (illegal) empty add if the
replace didn't contain any values.
Fix coming.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9355
Issue ID: 9355
Summary: Delta-sync MPR can fail to recreate entries
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
If an entry is missing on one host and a mod for that DN comes in from another,
it should attempt a fallback to retrieve the latest version.
That does not seem to happen in all cases. At least syncrepl_op_modify does not
seem to propagate the error from overlay_entry_get_ov correctly, instead it
ignores the mod and absorbs the CSN.
https://git.openldap.org/openldap/openldap/-/merge_requests/176
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9345
Issue ID: 9345
Summary: Restarted consumer with syncprov may have empty cookie
Product: OpenLDAP
Version: 2.4.52
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
On a relatively fresh node with both syncrepl and syncprov, after some writes
have occurred, if the consumer config is deleted and re-added, it's possible
the consumer won't see the current cookie. On startup it checks the local
database for contextCSN, but if syncprov has been caching cookie updates it may
not have been written to the DB yet. (And on an older server, the contextCSN
may be present in the DB, but stale relative to the state syncprov has cached.)
The consumer calls check_syncprov on subsequent iterations, but it ought to
also call it on startup, just in case.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8102
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |VERIFIED
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9352
Issue ID: 9352
Summary: delta-sync SEGV modifying zero-length context entry
Product: OpenLDAP
Version: 2.4.53
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
With a zero-length suffix, the context entry is usually a glue entry. It gets
created without an entryCSN. If an incoming mod updates it, syncrepl will crash
trying to find its entryCSN.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9330
Issue ID: 9330
Summary: Need to fully serialize delta-syncrepl
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
While using delta-syncrepl was supposed to fully serialize updates due to the
use of the accesslog DB, in extremely high write driven environments it became
clear this wasn't entirely the case. This would cause systems to constantly go
into mini REFRESH states as changes came in out of order.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9342
Issue ID: 9342
Summary: delta-sync: relax requirements on delete ops
Product: OpenLDAP
Version: 2.4.52
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
Currently if the delta-sync consumer encounters any unexpected changes it
always falls back to a regular refresh. We should allow it to proceed when a
Delete op fails with NoSuchObject. While unexpected changes are still an
indication of inconsistent logs, we can still safely advance to the next op in
the sequence before giving up (if necessary) since the outcome is the same.
The plain syncrepl consumer already has the same behavior for delete ops.
--
You are receiving this mail because:
You are on the CC list for the issue.