https://bugs.openldap.org/show_bug.cgi?id=9742
Issue ID: 9742 Summary: syncprov-nopresent is harmful Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs@openldap.org Reporter: ondra@mistotebe.net Target Milestone: ---
If setting up a new delta-MPR environment such that: - server A has been slapadd-ed the seed data - accesslog is set to "logops all"
There is a sequence of events where servers are started and replicate from each other before they get a chance to talk to A, they will each generate a CSN and replicate it. Once they start talking to A, it will see that it has a CSN (its own) that none of them have sent and "syncprov-nopresent" makes it just go ahead where the only sane outcome is to send SYNC_REFRESH_REQUIRED.
Am I missing a usecase for this or should it just have been this way all along?
https://bugs.openldap.org/show_bug.cgi?id=9742
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs@openldap.org |ondra@mistotebe.net Keywords|needs_review | Target Milestone|--- |2.6.1
https://bugs.openldap.org/show_bug.cgi?id=9742
Ondřej Kuzník ondra@mistotebe.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|syncprov-nopresent is |deltasync replication after |harmful |initial slapcat
--- Comment #1 from Ondřej Kuzník ondra@mistotebe.net --- I guess running without that option wouldn't have helped and the same would have happened anyway since the log is just missing things.
Seems like adding a new serverID into a deltasync cluster is an administrative task that should be documented and managed. We have two options there: - we have syncprov return a SYNC_REFRESH_REQUIRED, triggering a fallback sync and tainting everyone's accesslog - we mandate that the initial environment set up is done very carefully (the seed is contacted first by everyone or distributed ahead of time) and keep the current behaviour
https://bugs.openldap.org/show_bug.cgi?id=9742
--- Comment #2 from Quanah Gibson-Mount quanah@openldap.org --- (In reply to Ondřej Kuzník from comment #1)
I guess running without that option wouldn't have helped and the same would have happened anyway since the log is just missing things.
Seems like adding a new serverID into a deltasync cluster is an administrative task that should be documented and managed. We have two options there:
- we have syncprov return a SYNC_REFRESH_REQUIRED, triggering a fallback
sync and tainting everyone's accesslog
- we mandate that the initial environment set up is done very carefully (the
seed is contacted first by everyone or distributed ahead of time) and keep the current behaviour
I consider it essential that it be trivial to add new nodes to an MPR cluster at any time w/o it requiring any special handling. Replication is already insanely complex in OpenLDAP.
https://bugs.openldap.org/show_bug.cgi?id=9742
--- Comment #3 from Ondřej Kuzník ondra@mistotebe.net --- I'm inclined to making it reject that op, the problem with deltasync is these transitions wreak havoc on the accesslog. When we finally understand it, the exact scope of the damage and how to deal with it, we might need to be able to interfere with other client sessions - and how not to keep triggering this forever if we want to keep delta-MPR viable.
https://bugs.openldap.org/show_bug.cgi?id=9742
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.6.1 |2.6.2
https://bugs.openldap.org/show_bug.cgi?id=9742
--- Comment #4 from Howard Chu hyc@openldap.org --- (In reply to Ondřej Kuzník from comment #0)
If setting up a new delta-MPR environment such that:
- server A has been slapadd-ed the seed data
- accesslog is set to "logops all"
There is a sequence of events where servers are started and replicate from each other before they get a chance to talk to A, they will each generate a CSN and replicate it. Once they start talking to A, it will see that it has a CSN (its own) that none of them have sent and "syncprov-nopresent" makes it just go ahead where the only sane outcome is to send SYNC_REFRESH_REQUIRED.
Am I missing a usecase for this or should it just have been this way all along?
Sounds like the seed data should include the accesslog context entry.
https://bugs.openldap.org/show_bug.cgi?id=9742
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.6.2 |2.6.1 Status|UNCONFIRMED |RESOLVED Resolution|--- |TEST
--- Comment #5 from Quanah Gibson-Mount quanah@openldap.org --- • c51320a6 by Ondřej Kuzník at 2021-12-13T19:20:58+00:00 ITS#9742 Reject a refresh if we can't do a precise resync
https://bugs.openldap.org/show_bug.cgi?id=9742
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.6.1 |2.5.10
https://bugs.openldap.org/show_bug.cgi?id=9742
--- Comment #6 from Quanah Gibson-Mount quanah@openldap.org --- RE26:
• 60c92687 by Ondřej Kuzník at 2021-12-14T16:46:40+00:00 ITS#9742 Reject a refresh if we can't do a precise resync
https://bugs.openldap.org/show_bug.cgi?id=9742
--- Comment #7 from Quanah Gibson-Mount quanah@openldap.org --- • 52b89f52 by Ondřej Kuzník at 2021-12-14T16:50:11+00:00 ITS#9742 Reject a refresh if we can't do a precise resync
https://bugs.openldap.org/show_bug.cgi?id=9742
--- Comment #8 from Quanah Gibson-Mount quanah@openldap.org --- RE25:
(In reply to Quanah Gibson-Mount from comment #7)
• 52b89f52 by Ondřej Kuzník at 2021-12-14T16:50:11+00:00 ITS#9742 Reject a refresh if we can't do a precise resync
https://bugs.openldap.org/show_bug.cgi?id=9742
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED Resolution|TEST |FIXED
https://bugs.openldap.org/show_bug.cgi?id=9742
Ondřej Kuzník ondra@mistotebe.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |PARTIAL See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=9580, | |https://bugs.openldap.org/s | |how_bug.cgi?id=9782 Summary|deltasync replication after |deltasync replication after |initial slapcat |initial slapadd
-
openldap-its＠openldap.org