Bug 1118066

MODDN and MODRDN fail when entry doesn't have memberOf attribute and new DN is in the scope of memberOfExcludeSubtree.
I see 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)

Steps to reproduce:
1. make a fresh install of DS

2. enable memberOf plugin:
$ ldapmodify -v -h localhost:389 -D "cn=Directory Manager" -w "Secret123" << 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 -D "cn=Directory Manager" -w "Secret123" << 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 -D "cn=Directory Manager" -w "Secret123" << 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 -D "cn=Directory Manager" -w "Secret123" << 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 -D "cn=Directory Manager" -w Secret123 -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 -D "cn=Directory Manager" -w "Secret123" << 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 -D "cn=Directory Manager" -w "Secret123" << 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 -D "cn=Directory Manager" -w Secret123 -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 -D "cn=Directory Manager" -w Secret123 -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.

Created attachment 959205 [details]
valgrind-20141120-001350-rhel7ds.out

Thanks to your test case, I reproduced the bug but in python.

I my test we can see that the MODRDN of the 'user2' ('user1' in your TC) reports a failure:

[26/Nov/2014:18:02:28 +0100] conn=2 op=12 MODRDN dn="cn=user2,cn=accounts,cn=in,dc=example,dc=com" newrdn="cn=user2" newsuperior="cn=deleted users,cn=provisioning,cn=in,dc=example,dc=com"
[26/Nov/2014:18:02:28 +0100] conn=2 op=12 RESULT err=16 tag=109 nentries=0 etime=0

I believe it is related to ticket https://fedorahosted.org/389/ticket/47833.
Where the memberof post op plugin try to remove 'memberof' attribute from an entry where the it does not exists.

Thank you for the clarification, Thierry!

Since we pushed #47833 to 1.3.4, the failed test case is not included in the rhel-7.1.  We should exclude the case from this bug and treat it as a known issue.

Setting the status back to ON_QA.

Feature seems to be working fine as per Noriko's comment. The failed test case should be filed as a new bug.
Hi Viktor, can you open a new bug for this test case failure?

New bug opened: https://bugzilla.redhat.com/show_bug.cgi?id=1171663

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2015-0416.html