The referential integrity plugin does not work correctly in 389-ds-base-1.3.2.8-1.fc20:
389-ds-base-1.3.2.8-1.fc20
$ kinit admin $ ldapsearch -H ldap://ipa.example.com -Y GSSAPI -b 'cn=referential integrity postoperation,cn=plugins,cn=config' -s base '(objectClass=*)' nsslapd-pluginEnabled nsslapd-pluginarg7 # referential integrity postoperation, plugins, config dn: cn=referential integrity postoperation,cn=plugins,cn=config nsslapd-pluginEnabled: on nsslapd-pluginarg7: manager $ ipa user-add manager $ ipa user-add user --manager=manager $ ldapsearch -H ldap://ipa.example.com -Y GSSAPI -b 'uid=user,cn=users,cn=accounts,dc=example,dc=com' -s base '(objectClass=*)' manager # user, users, accounts, example.com dn: uid=user,cn=users,cn=accounts,dc=example,dc=com manager: uid=manager,cn=users,cn=accounts,dc=example,dc=com $ ipa user-del manager $ ldapsearch -H ldap://ipa.example.com -Y GSSAPI -b 'uid=manager,cn=users,cn=accounts,dc=example,dc=com' -s base '(objectClass=*)' dn # search result search: 4 result: 32 No such object matchedDN: cn=users,cn=accounts,dc=example,dc=com $ ldapsearch -H ldap://ipa.example.com -Y GSSAPI -b 'uid=user,cn=users,cn=accounts,dc=example,dc=com' -s base '(objectClass=*)' manager # user, users, accounts, example.com dn: uid=user,cn=users,cn=accounts,dc=example,dc=com manager: uid=manager,cn=users,cn=accounts,dc=example,dc=com
(The manager attribute should be deleted by refint and gone in the last ldapsearch output, but it is not.)
Could you check if it works if you add the two attrs to the referint config:
nsslapd-pluginEntryScope: dc=example,dc=com nsslapd-pluginContainerScope: dc=example,dc=com
That fixed the issue. Is this a misconfiguration on IPA's side?
nothing wrong with ipa. it is probably a side effect of fix 47527, where tese params were introduced, but without them behaviour should be as before. I failed to reproduce with my current version for #47621, but will test again.
just confirmed that with the original fix for 47527 referint fails if the delay (pluginarg0) is set to 0. There are two workarounds, either specify enetryscope and containerscope as suggested in comment #2 or configure a delay for the referential integrity plugin eg nsslapd-pluginarg0: 1
It will be fixed with 47621.
The bug was that update_integrity was only called if entryScope was defined:
if (plugin_EntryScope && slapi_sdn_issuffix(sdn, plugin_EntryScope)) { rc = update_integrity(argv, sdn, NULL, NULL, logChanges); } which violated default behaviour. The fix for #47621 handles this: - if (plugin_EntryScope && slapi_sdn_issuffix(sdn, plugin_EntryScope)) { + if (referint_sdn_in_entry_scope(sdn)) { rc = update_integrity(sdn, NULL, NULL, logChanges);
and referint_sdn_in_entry_scope() handles it correctly
Closing as a duplicate of ticket #47621.
Metadata Update from @lkrispen: - Issue assigned to lkrispen - Issue set to the milestone: N/A
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/961
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Duplicate)
Login to comment on this ticket.