https://bugs.openldap.org/show_bug.cgi?id=9863
Issue ID: 9863 Summary: lastbind configuration fails to honor chaining configuration Product: OpenLDAP Version: 2.6.2 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs@openldap.org Reporter: quanah@openldap.org Target Milestone: ---
In an environment where consumers are configured to chain writes up to the providers, lastbind configuration fails to honor this which is generally what one would expect. This causes mismatches between the providers and consumers in regards to the database state. Additionally it introduces random serverIDs into the database.
In my case, the providers have serverIDs 10, 20, 30 configured but the consumer is generating serverID 1 for the entryCSN.
Expectation: consumer does not generate *any* entryCSN value and instead forwards the write op to the provider.
Log from consumer:
slap_get_csn: conn=1069 op=0 generated new csn=20220610180137.644625Z#000000#001#000000 manage=1
https://bugs.openldap.org/show_bug.cgi?id=9863
--- Comment #1 from Quanah Gibson-Mount quanah@openldap.org --- Note that this means in a replicated environment, there's currently no way to configure the system to work correctly with ppolicy+lastbind. The slapo-lastbind overlay is not an option because it tracks a different attribute.
https://bugs.openldap.org/show_bug.cgi?id=9863
--- Comment #2 from Quanah Gibson-Mount quanah@openldap.org --- A couple of other things to check on:
a) In a delta-syncrepl environment, what happens if an account has first bound to a consumer (causing pwdLastSuccess to populate there) followed by a bind to the provider (causing pwdLastSuccess to populate and replicate). This could cause a collision and REFRESH. Subsequent BIND ops to the provider should result in a mod/replace. Real question is if the first time is a mod/add.
b) What happens in a race condition situation (similar to a, but assuming chaining was actually functional).
https://bugs.openldap.org/show_bug.cgi?id=9863
--- Comment #3 from Michael Ströder michael@stroeder.com --- This sounds somewhat related to my question on openldap-technical about slapo-syncprov on read-only consumers:
https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/m...
https://bugs.openldap.org/show_bug.cgi?id=9863
--- Comment #4 from Quanah Gibson-Mount quanah@openldap.org --- Enabling this feature in a replicated environment is extremely dangerous as it will cause the consumers to either (a) update a CSN that may not currently be in use causing them to be out of sync with the providers, (b) update a CSN that is in use causing it to be out of sync with the providers, or (c) create a brand new CSN in their local database, causing them to have a mismatch with the providers. None of these situations is good.
In my non-prod environment, this is the CSNs on the providers:
contextCSN: 20220613043332.710038Z#000000#00a#000000 contextCSN: 20220613063348.624161Z#000000#014#000000 contextCSN: 20220613063341.429488Z#000000#01e#000000
On the consumers where I enabled lastbind, we have:
contextCSN: 20220613062500.129913Z#000000#001#000000 contextCSN: 20220613043332.710038Z#000000#00a#000000 contextCSN: 20220613063348.624161Z#000000#014#000000 contextCSN: 20220613063341.429488Z#000000#01e#000000
The #001# CSN was generated by lastbind. So now the consumers have mismatched cookies in comparison to the provider nodes.
https://bugs.openldap.org/show_bug.cgi?id=9863
--- Comment #5 from Quanah Gibson-Mount quanah@openldap.org --- (In reply to Michael Ströder from comment #3)
This sounds somewhat related to my question on openldap-technical about slapo-syncprov on read-only consumers:
https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/ message/QDHF7YR3QM7OUG5SGWGZDA3NL2TL3X3D/
Yes, similar issue except that I have forwarding configured. Generally I would say that for ppolicy and lastbind, forwarding should always be enabled (and functional, which it currently is not for lastbind). Even if syncprov is not enabled on the consumers.
https://bugs.openldap.org/show_bug.cgi?id=9863
--- Comment #6 from Quanah Gibson-Mount quanah@openldap.org --- Ok, I tracked down why serverID 1 was being picked on the consumers (bad consumer config setting olcServerID 1). However even removing that, we still get a serverID of 0 used instead, which is also not desirable behavior and doesn't change the issues arising in this report.
https://bugs.openldap.org/show_bug.cgi?id=9863
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |IN_PROGRESS Ever confirmed|0 |1
--- Comment #7 from Quanah Gibson-Mount quanah@openldap.org --- https://git.openldap.org/openldap/openldap/-/merge_requests/542
https://bugs.openldap.org/show_bug.cgi?id=9863
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|needs_review | Target Milestone|--- |2.6.3
https://bugs.openldap.org/show_bug.cgi?id=9863
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|IN_PROGRESS |RESOLVED
--- Comment #8 from Quanah Gibson-Mount quanah@openldap.org --- head:
• fb115157 by Quanah Gibson-Mount at 2022-07-06T20:46:49+00:00 ITS#9863 - Forward lastbind updates if configured
• cfa6c07c by Quanah Gibson-Mount at 2022-07-06T20:46:49+00:00 ITS#9863 - Regression test case for pwdLastSuccess
RE26:
• f080ba08 by Quanah Gibson-Mount at 2022-07-07T15:48:59+00:00 ITS#9863 - Forward lastbind updates if configured
• 5fecce1b by Quanah Gibson-Mount at 2022-07-07T15:49:04+00:00 ITS#9863 - Regression test case for pwdLastSuccess
https://bugs.openldap.org/show_bug.cgi?id=9863
Howard Chu hyc@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=9882
https://bugs.openldap.org/show_bug.cgi?id=9863
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED
https://bugs.openldap.org/show_bug.cgi?id=9863
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |marco.pizzoli@gmail.com
--- Comment #9 from Quanah Gibson-Mount quanah@openldap.org --- *** Issue 6871 has been marked as a duplicate of this issue. ***
-
openldap-its＠openldap.org