[SSSD] Group name lost randomly

Qing Chang qchang at sri.utoronto.ca
Mon Apr 22 13:59:53 UTC 2013


just for the record. This is considered solved.

When migrated from OpenLDAP to IPA, inactive user accounts were left out, but
some of the accounts were still in place as secondary group members of a certain
group (mri as example). Nonexistent "member" in "cn=groups,cn=accounts"
causes the lookup of group name to fail. After the removal of that account, the
lookup succeeds.

In looking at all group membership attributes of the group, it seems that the
removal of a "member" of "cn=groups,cn=accounts" (which is done in the Web GUI)
does not translate into the removal of "memberUid" of "cn=groups,cn=accounts",
as well "memberUid" of "cn=groups,cn=compat".

It seems that "member" and "memberUid" attributes are not in sync. Is this
a normal behavior? Another curious situation is that sssd seems to be able to
get the name on some IPA clients not others, as mentioned in my first post...

Thanks,
Qing

On 19/04/2013 1:33 PM, Qing Chang wrote:
> it is 1.9.2-82.4.el6_4. Host is RHEL 6.4 (2.6.32-358.2.1.el6.x86_64)
>
> /var/log/sssd/sssd_nss.log has multiple entries:
> [sssd[nss]] [nss_cmd_getgrgid_search] (0x0010): getgrgid call returned more than one result !?!
>
> It seems to be complaining about duplicate gid entries. How can I have a
> recursive look of all GIDs? "getent group" (with enumerate turned on) returns single entries for the
> GIDs that are involved so far (42, 421 etc,.)
>
> Thanks,
> Qing
>
>
> On 19/04/2013 1:07 PM, Jakub Hrozek wrote:
>> On Fri, Apr 19, 2013 at 01:02:00PM -0400, Qing Chang wrote:
>>> at the same time on different IPA clients, group name could become
>>> unavailable on one but not the other:
>>>
>>> ===== available on fisher =====
>>> fisher:$ groups chuck
>>> chuck : mri hcgrp ccgrp prgrp chuksh crdsh2 ipausers slcc
>>> =====
>>>
>>> ===== unavailable on robin =====
>>> [root at robin ~]# groups chuck
>>> chuck : groups: cannot find name for group ID 422
>>> 422 ipausers prgrp crdsh2 slcc chuksh hcgrp ccgrp
>>> =====
>>>
>>> Note in this case 422 is mri, but it could happen to another
>>> GID.
>>>
>>> Just did a  "\rm /var/lib/sss/db/cache_sri.utoronto.ca.ldb"
>>> and "service sssd restart", the group name still did not
>>> come back.
>> Which version is this? If that's 1.9 you also need to remove the memory
>> cache to be completely sure (/var/lib/sss/mc/*)
>>
>>> A reboot would fix the problem, but it could
>>> creep back some time later.
>>>
>>> Any idea why this is happening?
>> There's not enough information, sorry. Debug logs (nss and domain) would
>> tell us more. Also what version on what OS?
>> _______________________________________________
>> sssd-devel mailing list
>> sssd-devel at lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
>
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel




More information about the sssd-devel mailing list