[Issue 9295] New: ppolicy and replication: pwdLockedTime replication fails to replicate
by openldap-its@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9295
Issue ID: 9295
Summary: ppolicy and replication: pwdLockedTime replication
fails to replicate
Product: OpenLDAP
Version: 2.4.50
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
If you have the following setup, a replica will hit an error during
replication.
a) ppolicy is configured on provider(s) and replicas. Replica has
schemachecking=on in its syncrepl configuration
b) account gets locked on the replica, so pwdAccountLockedTime is set on the
replica but not on the provider(s)
c) admin does a MOD/ADD op against a provider for the user entry to add a value
to pwdAccountLockedTime
dn: ...
changetype: modify
add: pwdAccountLockedTime
pwdAccountLockedTime: ...
d) provider accepts this modification.
e) replica rejects this modification because the resulting change means that
there would be two pwdAccountLockedTime values on the account in question
Generally I believe that in this scenario, the MOD/ADD on the provider should
be treated as a replace OP instead of an ADD op
--
You are receiving this mail because:
You are on the CC list for the issue.
3 months, 1 week
[Issue 9359] New: syncrepl_op_modify can create invalid mods
by openldap-its@openldap.org
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.
3 months, 1 week
[Issue 9355] New: Delta-sync MPR can fail to recreate entries
by openldap-its@openldap.org
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.
3 months, 1 week
[Issue 9345] New: Restarted consumer with syncprov may have empty cookie
by openldap-its@openldap.org
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.
3 months, 1 week
[Issue 9352] New: delta-sync SEGV modifying zero-length context entry
by openldap-its@openldap.org
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.
3 months, 1 week
[Issue 9330] New: Need to fully serialize delta-syncrepl
by openldap-its@openldap.org
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.
3 months, 1 week
[Issue 9342] New: delta-sync: relax requirements on delete ops
by openldap-its@openldap.org
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.
3 months, 1 week
[Issue 5422] strerror(errno) problems
by openldap-its@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=5422
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |TEST
Keywords|OL_2_6_REQ |
Target Milestone|2.6.0 |2.5.0
--- Comment #2 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
• 3f5293e1
by Ondřej Kuzník at 2020-09-24T23:34:36+00:00
ITS#5422 Save errno before passing it to Debug()
--
You are receiving this mail because:
You are on the CC list for the issue.
3 months, 3 weeks