#48012 MODDN fails when entry doesn't have memberOf attribute and new DN is in the scope of memberOfExcludeSubtree
Closed: wontfix None Opened 9 years ago by nhosoi.

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!

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

7 years ago

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.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Duplicate)

3 years ago

Login to comment on this ticket.

Metadata