The ticket created as per comment https://pagure.io/389-ds-base/issue/49031#comment-441593
386ds v.1.3.6.5on CentOS7.3 compiled from sources, memeberOf plugin activated:
cn=MemberOf Plugin,cn=plugins,cn=config ... nsslapd-pluginEnabled: on memberofgroupattr: uniqueMember memberofattr: memberOf memberofautoaddoc: X-Misc
We don't have circular groups. And the particular group that was emptied/recreated is a simple one, without any nesting. But each user is a member of 20-30 other groups on the average.
After some research i think i have found out the exact situation when it happens. The person needs to be explicitly and implicitly a member of the same group. If that person is "touched" during any group membership change, the error will pop.
Here is an example: cn=Utilisateurs Service Lambda,ou=Groupes Globaux,ou=Groupes,dc=example,dc=com cn: Utilisateurs Service Lambda objectClass: groupofuniquenames objectClass: top uniqueMember: cn=Management Team,ou=Administration,ou=Groupes,dc=example,dc=com uniqueMember: uid=unfortunate_user,ou=personnel,ou=utilisateurs,dc=example,dc=com
cn=Management Team,ou=Administration,ou=Groupes,dc=example,dc=com cn: Management Team objectClass: groupofuniquenames objectClass: top uniqueMember: uid=unfortunate_user,ou=Personnel,ou=Utilisateurs,dc=example,dc=com memberOf: cn=Utilisateurs Service Lambda,ou=Groupes Globaux,ou=Groupes,dc=example,dc=com
With this configuration each time we add (or delete?) the uid=unfortunate_user to a third group, the error message will pop:
/May/2017:14:06:57.552645685 +0200] - ERR - memberof-plugin - memberof_fix_memberof_callback: Weird, uid=unfortunate_user,ou=Personnel,ou=Utilisateurs,dc=example,dc=com is not in the cache
Maybe it happens because uid=unfortunate_user is evicted from ancestor cache first time due to the implicit group membership and second time because of the entry's explicit membership...
The tests are made on development server so if necessary, i can easily enable debug logging, recompile a modified memberOf plugin etc.
Metadata Update from @tbordaz: - Issue assigned to tbordaz
@pj101 Thanks for you perfect description of the test case. I prepared this lib389 test case and reproduced the issue <img alt="ticket49265_test.py" src="/389-ds-base/issue/raw/files/c302f0f3e161a4c9c84f49d4e048d94dd13df46bf6f94c0b8a6b4c301d5be398-ticket49265_test.py" />
Metadata Update from @tbordaz: - Custom field type adjusted to defect
@tbordaz hi, strange, but I have "Page not found (404)" on your file...
<img alt="ticket49265_test.py" src="/389-ds-base/issue/raw/c302f0f3e161a4c9c84f49d4e048d94dd13df46bf6f94c0b8a6b4c301d5be398-ticket49265_test.py" />
@spichugi good catch, I do not know what happened. I attached the file again.
Metadata Update from @mreynolds: - Issue set to the milestone: 1.3.6.0
Metadata Update from @mreynolds: - Issue set to the milestone: 1.3.7 backlog (was: 1.3.6.0)
Metadata Update from @mreynolds: - Custom field origin adjusted to None - Custom field reviewstatus adjusted to None - Issue set to the milestone: 1.4.2 (was: 1.3.7 backlog)
Metadata Update from @vashirov: - Issue set to the milestone: 1.4.3 (was: 1.4.2)
Metadata Update from @mreynolds: - Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1859286
Issue linked to Bugzilla: Bug 1859286
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/2324
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 - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.