When memberof is configured to scope only a subtree. An entry is outside of the memberof scope and the entry belongs to a group.
When renaming the entry SLAPI_PLUGIN_BE_TXN_POST_MODRDN_FN calls memberof_postop_modrdn that try to remove 'memberof' from the entry. But as the entry is not in the memberof scope, 'memberof' attribute has not been added then memberof_del_dn_type_callback fails (err=16 NO_SUCH_ATTRIBUTE).
The reveal two issues
Attached automatic TC
attachment ticket_fail_modrdn_test.py
Additional weird symptoms like if dn2entry index got invalid for some time.
After the MODRDN, I attempt 10 times (1s interval) to do base search on the target entry. It fails. Then I do a subtree search, it succeeds to find the entry. Then the base search on the target entry succeeds:
{{{ [27/Jun/2014:10:20:55 +0200] conn=2 op=92 MODRDN dn="cn=stage guy,cn=staged users,cn=provisioning,cn=in,dc=example,dc=com" newrdn="cn=xstage guy" newsuperior="cn=staged users,cn=provisioning,cn=in,dc=example,dc=com" [27/Jun/2014:10:20:55 +0200] conn=2 op=92 RESULT err=16 tag=109 nentries=0 etime=0 [27/Jun/2014:10:20:55 +0200] conn=2 op=93 SRCH base="cn=xstage guy,cn=staged users,cn=provisioning,cn=in,dc=example,dc=com" scope=0 filter="(cn=stage guy)" attrs=ALL [27/Jun/2014:10:20:55 +0200] conn=2 op=93 RESULT err=32 tag=101 nentries=0 etime=0 [27/Jun/2014:10:20:56 +0200] conn=2 op=95 SRCH base="cn=xstage guy,cn=staged users,cn=provisioning,cn=in,dc=example,dc=com" scope=0 filter="(cn=stage guy)" attrs=ALL [27/Jun/2014:10:20:56 +0200] conn=2 op=95 RESULT err=32 tag=101 nentries=0 etime=0 [27/Jun/2014:10:20:57 +0200] conn=2 op=96 SRCH base="cn=xstage guy,cn=staged users,cn=provisioning,cn=in,dc=example,dc=com" scope=0 filter="(cn=stage guy)" attrs=ALL [27/Jun/2014:10:20:57 +0200] conn=2 op=96 RESULT err=32 tag=101 nentries=0 etime=0 [27/Jun/2014:10:20:59 +0200] conn=2 op=97 SRCH base="cn=xstage guy,cn=staged users,cn=provisioning,cn=in,dc=example,dc=com" scope=0 filter="(cn=stage guy)" attrs=ALL [27/Jun/2014:10:20:59 +0200] conn=2 op=97 RESULT err=32 tag=101 nentries=0 etime=0 [27/Jun/2014:10:21:00 +0200] conn=2 op=98 SRCH base="cn=xstage guy,cn=staged users,cn=provisioning,cn=in,dc=example,dc=com" scope=0 filter="(cn=stage guy)" attrs=ALL [27/Jun/2014:10:21:00 +0200] conn=2 op=98 RESULT err=32 tag=101 nentries=0 etime=0 [27/Jun/2014:10:21:01 +0200] conn=2 op=99 SRCH base="cn=xstage guy,cn=staged users,cn=provisioning,cn=in,dc=example,dc=com" scope=0 filter="(cn=stage guy)" attrs=ALL [27/Jun/2014:10:21:01 +0200] conn=2 op=99 RESULT err=32 tag=101 nentries=0 etime=0 [27/Jun/2014:10:21:02 +0200] conn=2 op=101 SRCH base="cn=xstage guy,cn=staged users,cn=provisioning,cn=in,dc=example,dc=com" scope=0 filter="(cn=stage guy)" attrs=ALL [27/Jun/2014:10:21:02 +0200] conn=2 op=101 RESULT err=32 tag=101 nentries=0 etime=0 [27/Jun/2014:10:21:03 +0200] conn=2 op=102 SRCH base="cn=xstage guy,cn=staged users,cn=provisioning,cn=in,dc=example,dc=com" scope=0 filter="(cn=stage guy)" attrs=ALL [27/Jun/2014:10:21:03 +0200] conn=2 op=102 RESULT err=32 tag=101 nentries=0 etime=0 [27/Jun/2014:10:21:04 +0200] conn=2 op=103 SRCH base="cn=xstage guy,cn=staged users,cn=provisioning,cn=in,dc=example,dc=com" scope=0 filter="(cn=stage guy)" attrs=ALL [27/Jun/2014:10:21:04 +0200] conn=2 op=103 RESULT err=32 tag=101 nentries=0 etime=0 [27/Jun/2014:10:21:05 +0200] conn=2 op=104 SRCH base="cn=xstage guy,cn=staged users,cn=provisioning,cn=in,dc=example,dc=com" scope=0 filter="(cn=stage guy)" attrs=ALL [27/Jun/2014:10:21:05 +0200] conn=2 op=104 RESULT err=32 tag=101 nentries=0 etime=0 [27/Jun/2014:10:21:06 +0200] conn=2 op=105 SRCH base="cn=staged users,cn=provisioning,cn=in,dc=example,dc=com" scope=2 filter="(cn=stage guy)" attrs=ALL [27/Jun/2014:10:21:06 +0200] conn=2 op=105 RESULT err=0 tag=101 nentries=1 etime=0 [27/Jun/2014:10:21:06 +0200] conn=2 op=106 SRCH base="cn=xstage guy,cn=staged users,cn=provisioning,cn=in,dc=example,dc=com" scope=0 filter="(cn=stage guy)" attrs=ALL [27/Jun/2014:10:21:06 +0200] conn=2 op=106 RESULT err=0 tag=101 nentries=1 etime=0
}}}
Related to 47829 & 48012.
no cloning, upstream tests already written.
attachment ticket47833_test.py
I can not reproduce this issue on Master. I believe the fix for https://fedorahosted.org/389/ticket/47526 fixed this ticket as well.
To be closed as duplicate of 47526. Just waiting some feedback to know if I commit or not the updated version of the test case
With agreement of Noriko, I am pushing the test case (47526 and 48012 have no test case for this specific bug).
git push origin master Counting objects: 8, done. Delta compression using up to 4 threads. Compressing objects: 100% (5/5), done. Writing objects: 100% (5/5), 2.84 KiB, done. Total 5 (delta 3), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git 3c0d3c5..065b511 master -> master
Then closing this ticket as duplicate of 47526
Metadata Update from @nhosoi: - 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/1164
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.