When trying to delete a group that contains members added through an automember rule, the delete operation fails with OPERATIONS ERROR.
Fedora 28 389-ds-base-1.4.0.21-1.fc28.x86_64
ipa group-del fails with OPERATIONS ERROR
ipa group-del should succeed.
Note that if the group is empty, delete succeeds.
logs: in /var/log/dirsrv/slapd-DOMAIN-COM/errors
/var/log/dirsrv/slapd-DOMAIN-COM/errors
[14/Mar/2019:10:46:25.258731651 +0100] - ERR - auto-membership-plugin - automember_update_member_value - Unable to add "uid=developer1,cn=users,cn=accounts,dc=domain,dc=com" as a "member" value to group "cn=developers,cn=groups,cn=accounts,dc=domain,dc=com" (No such object). [14/Mar/2019:10:46:25.261125413 +0100] - ERR - memberof-plugin - memberof_postop_del - Error deleting attr list - dn (cn=developers,cn=groups,cn=accounts,dc=domain,dc=com). Error (1)
In /var/log/dirsrv/slapd-DOMAIN-COM/access:
/var/log/dirsrv/slapd-DOMAIN-COM/access
[14/Mar/2019:10:46:25.249524963 +0100] conn=320 op=7 DEL dn="cn=developers,cn=groups,cn=accounts,dc=domain,dc=com" [14/Mar/2019:10:46:25.263777768 +0100] conn=320 op=7 RESULT err=1 tag=107 nentries=0 etime=0.0014377961
The reason of the failure:
- The DEL of the group 'devel' is caught by 'memberof' plugin that detect it has member 'devel1' - memberof plugin updates 'devel1' to remove 'member: devel_group' - On the update of 'devel1', automember catches the this user matches the automember definition and then updates the group 'devel' to add 'devel1' into that group. The problem is that the group 'devel' does not exist any more So the update of 'devel' group (by automember) fails, it trigger the failure of memberof that trigger the failure of the initial DEL of the group. - It exists a workaround: remove/change the autommember definition ('cn=devel,cn=Group,cn=automember,cn=etc' so that automember will not try to add 'devel1' user in 'devel' group
Next step - I think an improvement can be done in automember so that when it evaluates a definition it first check if 'autoMemberTargetGroup' exists
Metadata Update from @tbordaz: - Custom field origin adjusted to None - Custom field reviewstatus adjusted to None
Metadata Update from @tbordaz: - Issue assigned to tbordaz
PR is https://pagure.io/389-ds-base/pull-request/50285
Metadata Update from @tbordaz: - Custom field origin adjusted to IPA (was: None) - Issue set to the milestone: 1.4.0
208111a..da7d2de master b998fed..ada0f84 389-ds-base-1.4.0
Metadata Update from @tbordaz: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
Is this something that should go into RHEL 7.7 (1.3.9)?
@mreynolds, it applies in all versions but the bug was reported in 1.4.0 it is why I did not backport it in 1.3.9.
It is easy to backport it there as well, do you want so ?
@mreynolds, it applies in all versions but the bug was reported in 1.4.0 it is why I did not backport it in 1.3.9. It is easy to backport it there as well, do you want so ?
We should, is there a bugzilla for 1.4.0? If not please clone this ticket to 7.7
Metadata Update from @tbordaz: - Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1689313
Issue linked to Bugzilla: Bug 1689313
6eae9e0..bcacbf2 389-ds-base-1.3.9
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/3341
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: fixed)
Login to comment on this ticket.