Hide Forgot
Description of problem: id user command does not list all groups after upgrade from sssd-1.12.4-47.el6.x86_64 to sssd-1.13.3-22.el6.x86_64 Version-Release number of selected component (if applicable): sssd-1.13.3-22.el6.x86_64 How reproducible: always Actual results: :: [ BEGIN ] :: bis_group_group_user2 :: actually running 'strict eval 'verify_output getent group bis_group_group_user2'' :: [ PASS ] :: bis_group_group_user2 (Expected 0, got 0) :: [ BEGIN ] :: bis_broken_user2 :: actually running 'strict eval 'verify_output id bis_broken_user2'' Unexpected output of id bis_broken_user2: uid=50002(bis_broken_user2) gid=60002(bis_broken_group_user2) groups=60002(bis_broken_group_user2) expecting: uid=50002(bis_broken_user2) gid=60002(bis_broken_group_user2) groups=60002(bis_broken_group_user2),60001(bis_broken_group_user1) :: [ FAIL ] :: bis_broken_user2 (Expected 0, got 1) :: [ BEGIN ] :: Running 'strict eval 'id localuser1 | grep localgroup1'' uid=1011(localuser1) gid=1011(localuser1) groups=1011(localuser1),1010(localgroup1) :: [ PASS ] :: Command 'strict eval 'id localuser1 | grep localgroup1'' (Expected 0, got 0) :: [ BEGIN ] :: Running 'strict eval 'su_success localuser1 Local_123'' :: [ PASS ] :: Command 'strict eval 'su_success localuser1 Local_123'' (Expected 0, got 0) Expected results: [root@vm-idm-003 ~]# id bis_broken_user2 uid=50002(bis_broken_user2) gid=60002(bis_broken_group_user2) groups=60002(bis_broken_group_user2),60001(bis_broken_group_user1) Additional info: purging the logs resolves the issue, but only a sssd restart does not resolve the issue [root@vm-idm-007 ~]# date Tue Mar 22 17:15:05 IST 2016 [root@vm-idm-007 ~]# id bis_broken_user2 uid=50002(bis_broken_user2) gid=60002(bis_broken_group_user2) groups=60002(bis_broken_group_user2) [root@vm-idm-007 ~]# service sssd restart Stopping sssd: [ OK ] Starting sssd: [ OK ] [root@vm-idm-007 ~]# id bis_broken_user2 uid=50002(bis_broken_user2) gid=60002(bis_broken_group_user2) groups=60002(bis_broken_group_user2) [root@vm-idm-007 ~]# date Tue Mar 22 17:15:32 IST 2016
(In reply to Steeve Goveas from comment #0) Additional info: purging the cache resolves the issue, a sssd restart without purging does not resolve the issue > [root@vm-idm-007 ~]# date > Tue Mar 22 17:15:05 IST 2016 > [root@vm-idm-007 ~]# id bis_broken_user2 > uid=50002(bis_broken_user2) gid=60002(bis_broken_group_user2) > groups=60002(bis_broken_group_user2) > [root@vm-idm-007 ~]# service sssd restart > Stopping sssd: [ OK ] > Starting sssd: [ OK ] > [root@vm-idm-007 ~]# id bis_broken_user2 > uid=50002(bis_broken_user2) gid=60002(bis_broken_group_user2) > groups=60002(bis_broken_group_user2) > [root@vm-idm-007 ~]# date > Tue Mar 22 17:15:32 IST 2016
This bug report has no details to work with. Please follow https://fedorahosted.org/sssd/wiki/Reporting_sssd_bugs to see what information we generally need to fix a bug. Thank you for reporting the bug nonetheless!
Created attachment 1139364 [details] sssd logs
The most suspicious thing is that invalidation of sssd cache does not help. There are more more domains defined: rfc2307, rfc2307bis, rfc2307bis_broken, proxy, LOCAL and only problematic is "rfc2307bis_broken". I do not know how it is broken. But I can see the same bug in following upgrades rhel6.7 -> rhel6.8 rhel6.6 -> rhel6.8 rhel6.5 -> rhel6.8 rhel6.6 -> rhel6.7 rhel6.8 -> sssd upstrem master.
Please try to collect the sssd_nss logs as well. It looks like after the upgrade the fc2307bis_broken backend does not receive any requests for object from its domain. Maybe there is a collision with one of the other backends?
Not a regression -> removing the Regression keyword.
Since this issue is not affecting a real deployment and there is an easy workaround, I'm moving this bug to RHEL-7 and reproposing to 7.3
Upstream ticket: https://fedorahosted.org/sssd/ticket/2979
Petr did some work in this area and fixed a number of bugs. Petr, I wonder if you have time to re-test this bug? (Not totally urgent, but please add this to your todo list..)
Needinfo flag was removed without providing any info. Setting it back.