Description of problem: Undefined behaviour of referint plugin, when PluginConfigArea DN renamed during runtime. How reproducible: always Steps to Reproduce: [0] Create MMR setup [1] Enable referential integrity plugin on M1, configure membership-attrs (exclude uniqueMember): referint-membership-attr: member referint-membership-attr: owner referint-membership-attr: seeAlso Restart the server [2] Add config area: dn: cn=referintConfig,dc=example,dc=com objectClass: extensibleObject objectClass: nsContainer objectClass: top cn: referintConfig referint-update-delay: 0 referint-logfile: /var/log/dirsrv/slapd-M1/referint referint-logchanges: 0 referint-membership-attr: member referint-membership-attr: uniquemember referint-membership-attr: owner referint-membership-attr: seeAlso Configure plugin to use it: dn: cn=referential integrity postoperation,cn=plugins,cn=config changetype: modify replace: nsslapd-pluginConfigArea nsslapd-pluginConfigArea: cn=referintConfig,dc=example,dc=com [3] Test MODRDN on PluginConfigArea for referint PluginConfigArea contains referint-membership-attr: member referint-membership-attr: uniquemember referint-membership-attr: owner referint-membership-attr: seeAlso cn=referential integrity postoperation,cn=plugins,cn=config contains referint-membership-attr: member referint-membership-attr: owner referint-membership-attr: seeAlso MODRDN on entries updates uniqueMember in groupOfUniqueNames as expected (it means that settings in PluginConfigArea override settings for plugin in cn=config) [3.1] Rename cn=referintConfig,dc=example,dc=com to cn=referintConfig_disabled,dc=example,dc=com Do MODRDN on entry that is a member of groupOfUniqueNames - server updates groupOfUniqueNames -> FAIL In my opinion, this is undefined behaviour, since server doesn't have valid runtime configuration for referint (pluginConfigArea points to inexisting dn, but options from it were used) Possible solutions: a) Server should not allow renaming of dn that is a value of pluginConfigArea. b) Server should fall back to cn=config options, if pluginConfigArea contains invalid dn during runtime. c) Server should maintain integrity of pluginConfigArea. [3.2] Remove from cn=referintConfig_disabled referint-membership-attr: uniquemember. Rename it back to cn=referintConfig. Do MODRDN on entry that is a member of groupOfUniqueNames - server updates groupOfUniqueNames, but there is no uniquemember in referint-membership-attr -> FAIL [3.3] Add back referint-membership-attr: uniquemember. Do MODRDN on entry that is a member of groupOfUniqueNames - server updates groupOfUniqueNames -> PASS [3.4] Remove referint-membership-attr: uniquemember. Do MODRDN on entry that is a member of groupOfUniqueNames - server doesn't update it, as expected -> PASS
Metadata Update from @nhosoi: - Issue set to the milestone: 1.3.6.0
Metadata Update from @mreynolds: - Custom field component reset (from Server - Plugins) - Issue close_status updated to: None - Issue set to the milestone: 1.3.7 backlog (was: 1.3.6.0)
Metadata Update from @mreynolds: - Custom field reviewstatus adjusted to None - Issue set to the milestone: 1.4.2 (was: 1.3.7 backlog)
Metadata Update from @vashirov: - Issue close_status updated to: wontfix - Issue status updated to: Closed (was: Open)
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/1342
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.
Login to comment on this ticket.