Description of problem: MODDN fails when entry doesn't have memberOf attribute and new DN is in the scope of memberOfExcludeSubtree I see the following error message in the errors log: > [20/Nov/2014:00:16:35 +0100] memberof-plugin - memberof_postop_modrdn - delete dn callback failed for (uid=user1,ou=Deleted,ou=People,dc=example,dc=com), error (16) How reproducible: always Steps to Reproduce: 1. make a fresh install of DS 2. enable memberOf plugin: $ ldapmodify -v -h localhost:389 ... << EOF dn: cn=MemberOf Plugin,cn=plugins,cn=config changetype: modify add: memberofallbackends memberofallbackends: on - replace: memberofgroupattr memberofgroupattr: member memberofgroupattr: uniqueMember - replace: nsslapd-pluginEnabled nsslapd-pluginEnabled: on - EOF 3. create test entries: $ ldapmodify -v -h localhost:389 ... << EOF dn: ou=Deleted,ou=People,dc=example,dc=com changetype: add objectClass: top objectClass: organizationalunit ou: Deleted dn: cn=group0,ou=Groups,dc=example,dc=com changetype: add objectClass: top objectClass: groupOfUniqueNames cn: group0 dn: uid=user0,ou=People,dc=example,dc=com changetype: add uid: user0 objectClass: inetUser objectClass: inetOrgPerson objectClass: top objectClass: organizationalPerson objectClass: person cn: user0 sn: user0 dn: uid=user1,ou=People,dc=example,dc=com changetype: add uid: user1 objectClass: inetUser objectClass: inetOrgPerson objectClass: top objectClass: organizationalPerson objectClass: person cn: user1 sn: user1 EOF 4. configure scope of the memberOf plugin to include suffix and exclude ou=Deleted $ ldapmodify -v -h localhost:389 ... << EOF dn: cn=MemberOf Plugin,cn=plugins,cn=config changetype: modify add: memberofentryscope memberofentryscope: dc=example,dc=com - add: memberofentryscopeexcludesubtree memberofentryscopeexcludesubtree: ou=Deleted,ou=People,dc=example,dc=com EOF 5. restart the server $ sudo systemctl restart dirsrv.target 6. add user0 to group0 $ ldapmodify -v -h localhost:389 ... << EOF dn: cn=group0,ou=Groups,dc=example,dc=com changetype: modify add: uniqueMember uniqueMember: uid=user0,ou=people,dc=example,dc=com EOF 7. check that user0 has memberOf attribute and user1 doesn't: $ ldapsearch -h localhost:389 ... -b dc=example,dc=com -LLL "(uid=user*)" memberOf dn: uid=user0,ou=People,dc=example,dc=com memberOf: cn=group0,ou=Groups,dc=example,dc=com dn: uid=user1,ou=People,dc=example,dc=com 8. MODDN user0 and user1 to ou=Deleted: $ ldapmodify -v -h localhost:389 ... << EOF dn: uid=user0,ou=People,dc=example,dc=com changetype: moddn newrdn: uid=user0 deleteoldrdn: 1 newsuperior: ou=Deleted,ou=People,dc=example,dc=com EOF ldap_initialize( ldap://localhost:389 ) modifying rdn of entry "uid=user0,ou=People,dc=example,dc=com" new RDN: "uid=user0" (do not keep existing values) rename complete $ ldapmodify -v -h localhost:389 ... << EOF dn: uid=user1,ou=People,dc=example,dc=com changetype: moddn newrdn: uid=user1 deleteoldrdn: 1 newsuperior: ou=Deleted,ou=People,dc=example,dc=com EOF ldap_initialize( ldap://localhost:389 ) modifying rdn of entry "uid=user1,ou=People,dc=example,dc=com" new RDN: "uid=user1" (do not keep existing values) ldap_rename: No such attribute (16) 9. check for memberOf attribute: $ ldapsearch -h localhost:389 ... -b dc=example,dc=com -LLL "(uid=user*)" memberOf dn: uid=user0,ou=Deleted,ou=People,dc=example,dc=com dn: uid=user1,ou=Deleted,ou=People,dc=example,dc=com It was successfully stripped from user0. 10. restart the server 11. search for user0 and user0 again: ldapsearch -h localhost:389 ... -b dc=example,dc=com -LLL "(uid=user*)" dn dn: uid=user0,ou=Deleted,ou=People,dc=example,dc=com dn: uid=user1,ou=People,dc=example,dc=com Looks like the transaction of MODDN of user1 was aborted.
Related to 47829 & 47833.
I can not reproduce this issue on Master. I believe the fix for https://fedorahosted.org/389/ticket/47526 fixed this ticket as well.
Noriko, if you agree we may close it as duplicate of 47526
Replying to [comment:4 tbordaz]:
I can not reproduce this issue on Master. I believe the fix for https://fedorahosted.org/389/ticket/47526 fixed this ticket as well. Noriko, if you agree we may close it as duplicate of 47526
Yes! Thanks for verifying the fix, Thierry. Please close this ticket as a dup. Thanks!
attachment ticket47833_test.py
Attaching the test case of https://fedorahosted.org/389/ticket/47833, as it is the same problem. Now this ticket 48012 being fixed by 47526, I close it as dup of 47526
Metadata Update from @tbordaz: - Issue set to the milestone: 1.3.4 backlog
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/1343
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.