Bug 1186352
| Summary: | Schema Compatibility plugin cache is not cleared during DS re-initialization | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Kaleem <ksiddiqu> | ||||
| Component: | slapi-nis | Assignee: | Alexander Bokovoy <abokovoy> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | Namita Soman <nsoman> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | --- | CC: | abokovoy, mkosek, pcech, pvoborni, rcritten, tbordaz | ||||
| Target Milestone: | rc | Flags: | pm-rhel:
mirror+
|
||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: |
When you restore an Identity Management (IdM) server from backup and re-initalize the restored data to other replicas, the Schema Compatibility plug-in can still maintain a cache of the old data from before performing the restore and re-initialization. Consequently, the replicas might behave unexpectedly. For example, if you attempt to add a user that was originally added after performing the backup, and thus removed during the restore and re-initialization steps, the operation might fail with an error, because the Schema Compatibility cache contains a conflicting user entry. To work around this problem, restart the IdM replicas after re-intializing them from the master server. This clears the Schema Compatibility cache and ensures that the replicas behave as expected in the described situation.
|
Story Points: | --- | ||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2020-10-22 11:35:00 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 1205796 | ||||||
| Attachments: |
|
||||||
|
Description
Kaleem
2015-01-27 13:49:50 UTC
the error 19 returned by the plugin is LDAP_CONSTRAINT_VIOLATION which could be returned by uid uniqueness plugin, could you upload the error log and the config file dse.ldif Created attachment 984715 [details]
contains error_log and dse.ldif
I reproduced the problem and wonder if it is not related to some schema-compat caching: test case on Master (ipa-backup, ipa-restore <backupd_dir>) on replica (ipa-replica-manage re-initialize --from <master_host>) After the re-init on Replica: # testuser4, users, compat, idm.lab.bos.redhat.com dn: uid=testuser4,cn=users,cn=compat,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com # testuser3, users, compat, idm.lab.bos.redhat.com dn: uid=testuser3,cn=users,cn=compat,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com # testuser2, users, compat, idm.lab.bos.redhat.com dn: uid=testuser2,cn=users,cn=compat,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com # testuser1, users, compat, idm.lab.bos.redhat.com dn: uid=testuser1,cn=users,cn=compat,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com # admin, users, compat, idm.lab.bos.redhat.com dn: uid=admin,cn=users,cn=compat,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com # admin, users, accounts, idm.lab.bos.redhat.com dn: uid=admin,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com # sudo, sysaccounts, etc, idm.lab.bos.redhat.com dn: uid=sudo,cn=sysaccounts,cn=etc,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com # testuser1, users, accounts, idm.lab.bos.redhat.com dn: uid=testuser1,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com # testuser2, users, accounts, idm.lab.bos.redhat.com dn: uid=testuser2,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com On master: # testuser2, users, compat, idm.lab.bos.redhat.com dn: uid=testuser2,cn=users,cn=compat,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com # testuser1, users, compat, idm.lab.bos.redhat.com dn: uid=testuser1,cn=users,cn=compat,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com # admin, users, compat, idm.lab.bos.redhat.com dn: uid=admin,cn=users,cn=compat,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com # admin, users, accounts, idm.lab.bos.redhat.com dn: uid=admin,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com # sudo, sysaccounts, etc, idm.lab.bos.redhat.com dn: uid=sudo,cn=sysaccounts,cn=etc,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com # testuser1, users, accounts, idm.lab.bos.redhat.com dn: uid=testuser1,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com # testuser2, users, accounts, idm.lab.bos.redhat.com dn: uid=testuser2,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com It is looking like the online init does not clear some schema-compat entries. The error 19 (constraint violation) is returned by schema-compat: [26/Jan/2015:23:38:41 -0500] schema-compat-plugin - searching from "dc=idm,dc=lab,dc=bos,dc=redhat,dc=com" for "(&(objectClass=posixAccount)(uid=testuser3))" with scope 2 (sub) [26/Jan/2015:23:38:41 -0500] schema-compat-plugin - search matched uid=testuser3,cn=users,cn=compat,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com [26/Jan/2015:23:38:41 -0500] NSUniqueAttr - SEARCH entry dn=uid=testuser3,cn=users,cn=compat,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com [26/Jan/2015:23:38:41 -0500] NSUniqueAttr - SEARCH complete result=19 [26/Jan/2015:23:38:41 -0500] NSUniqueAttr - SEARCH result = 19 [26/Jan/2015:23:38:41 -0500] NSUniqueAttr - ADD result 19 [26/Jan/2015:23:38:41 -0500] - SLAPI_PLUGIN_BE_TXN_PRE_ADD_FN plugin failed: 19 the error comes from the uid uniqueness plugin, but that the testuser4 is still present in the comapt tree should not happen Ludwig, Thierry - thanks for investigation. Can either of you please summarize what is the problem in the end, what is the impact and how can we fix it? (and where? 389-DS or IPA?). One idea we had is that perhaps slapi-nis needs to listen to the backend state -- whether it is online or offline. It would mean registering a handler with slapi_register_backend_state_change() and then check for SLAPI_BE_STATE_* states against subtrees we are listening to. For each subtree check if the backend that is changing its state to offline or deleted is handling the parent of the subtree and if so, invalidate cached entries from this subtree. For each subtree check if the backend that is changing its state to online is handling the parent of the subtree and if so, trigger populating the cache. There probably would be details and corner cases (AD users, for example, aren't related to any backend though their group membership is) but overall it looks like backend state handling is missing. sorry, I thought Alexanders update #7 would be enough. To me the problem is: on the replica there is user3 and it is also in the compat tree. the replica is reinitialized with data not containing user3, but it is not removed from the comapt tree cache when trying to add user3 again on the replica it fails because the uiduniqueness check fails since teh user is still there in the compat tree. A restart of DS fixes this, but a long term fix would have to be in slapi-nis plugin, see update #7 Thank you taking your time and submitting this request for Red Hat Enterprise Linux 7. Unfortunately, this bug cannot be kept even as a stretch goal and was postponed to RHEL8. This BZ has been evaluated multiple times over the last several years and we assessed that it is a valuable request to keep in the backlog and address it at some point in future. Time showed that we did not have such capacity, nor have it now nor will have in the foreseeable future. In such a situation keeping it in the backlog is misleading and setting the wrong expectation that we will be able to address it. Unfortunately we will not. To reflect this we are closing this BZ. If you disagree with the decision please reopen or open a new support case and create a new BZ. However this does not guarantee that the request will not be closed during the triage as we are currently applying much more rigor to what we actually can accomplish in the foreseeable future. Contributions and collaboration in the upstream community and CentOS Stream is always welcome! Thank you for understanding. Red Hat Enterprise Linux Identity Management Team |