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.
https://bugs.openldap.org/show_bug.cgi?id=9361
Issue ID: 9361
Summary: accesslog logpurge generates new CSNs for its deletes
Product: OpenLDAP
Version: 2.4.53
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
The delete operations that are performed by logpurge are for internal
bookkeeping purposes and should not have new CSNs attached to them. In
the current code, since each delete has a new valid CSN, the logDB's
contextCSN becomes newer than its main DB's, and this can trigger the
syncprov on the logDB to send NEW_COOKIE messages to all delta consumers.
Meanwhile, the mainDB's contextCSN hasn't changed. As a result, the
consumers' contextCSN for that SID will be newer than the provider's.
Fix coming shortly.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9331
Issue ID: 9331
Summary: New Mirror in NL
Product: website
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: website
Assignee: bugs(a)openldap.org
Reporter: info(a)lyrahosting.com
Target Milestone: ---
Hi,
With much pleasure, Lyra Hosting has created a new Mirror for OpenLDAP.
Mirror is located in Netherland
access methods: http and https
Your mirror's available bandwidth: 200mbps
An administrative contact email: admin(a)lyrahosting.com
http://mirror.lyrahosting.com/OpenLDAP/https://mirror.lyrahosting.com/OpenLDAP/
Kindly regards
Dennis
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9017
--- Comment #23 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
Commits:
• d1814f7e
by Howard Chu at 2020-10-11T01:45:45+01:00
ITS#9017 fixes for encryption
--
You are receiving this mail because:
You are on the CC list for the issue.