[SSSD] sss_cache --everything

steve steve at steve-ss.com
Fri Aug 9 20:44:40 UTC 2013


On 08/08/13 09:51, Jakub Hrozek wrote:
> On Thu, Aug 08, 2013 at 09:04:37AM +0200, steve wrote:
>> On Thu, 2013-08-08 at 00:15 +0200, Jakub Hrozek wrote:
>>> On Wed, Aug 07, 2013 at 05:25:08PM +0200, steve wrote:
>>>> On Wed, 2013-08-07 at 08:07 -0400, Stephen Gallagher wrote:
>>>>> On 08/07/2013 07:48 AM, steve wrote:
>>>>>> On Wed, 2013-08-07 at 13:17 +0200, Jakub Hrozek wrote:
>>>>>>>>
>>>>>>>
>>>>>>> What kind of script?
>>>>>>
>>>>>> #!/bin/bash systemctl stop sssd rm /usr/local/var/lib/sss/db/*
>>>>>> systemctl start sssd
>>>>>>
>>>>>
>>>>> It's worth noting that sss_cache does not *delete* the cache contents,
>>>>> it only marks them all as expired. This means you don't lose cached
>>>>> credentials and if your LDAP server isn't available to repopulate the
>>>>> cache, you still have access to the old, expired data until it is.
>>>>>
>>>>
>>>> Hi
>>>> OK, maybe I should explain our frustration. A college where students
>>>> come and go and change courses. This involves changes in AD. Just
>>>> something to say e.g. student1 has left or change his group from course1
>>>> to course2 or remove him from that course or group. Something like
>>>> turning off nscd when you run nss-ldapd. Imagine doing it for a whole
>>>> class as and when the student returns, a bit at a time. We don't want
>>>> old expired data. At the end of the class neither we nor the student
>>>> have any need for it.
>>>> Cheers
>>>
>>> And if you ran sss_cache -UG instead, would that still give you wrong data?
>>
>> Yes. -UG is not enough:
>>
>> Here is an AD group with one member:
>>
>> ldbsearch --url=/usr/local/samba/private/sam.ldb cn=staff2
>> # record 1
>> dn: CN=staff2,CN=Users,DC=hh3,DC=site
>> cn: staff2
>> instanceType: 4
>> whenCreated: 20130605160553.0Z
>> uSNCreated: 3922
>> name: staff2
>> objectGUID: 6ce9797b-96db-4e70-97ca-e1a2d8d0b3d1
>> objectSid: S-1-5-21-451355595-2219208293-2714859210-1111
>> sAMAccountName: staff2
>> sAMAccountType: 268435456
>> groupType: -2147483646
>> objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=hh3,DC=site
>> objectClass: top
>> objectClass: posixGroup
>> objectClass: group
>> gidNumber: 21111
>> member: CN=steve2,CN=Users,DC=hh3,DC=site
>> whenChanged: 20130808065259.0Z
>> uSNChanged: 5758
>>
>> Here is sssd showing the member:
>>
>> hh16:/home/steve # getent group staff2
>> staff2:*:21111:steve2
>>
>> We remove the member from the group:
>> hh16:/home/steve # samba-tool group removemembers staff2 steve2
>> Removed members from group staff2
>>
>> Here is the group with steve2 removed:
>>
>>   ldbsearch --url=/usr/local/samba/private/sam.ldb cn=staff2
>> # record 1
>> dn: CN=staff2,CN=Users,DC=hh3,DC=site
>> cn: staff2
>> instanceType: 4
>> whenCreated: 20130605160553.0Z
>> uSNCreated: 3922
>> name: staff2
>> objectGUID: 6ce9797b-96db-4e70-97ca-e1a2d8d0b3d1
>> objectSid: S-1-5-21-451355595-2219208293-2714859210-1111
>> sAMAccountName: staff2
>> sAMAccountType: 268435456
>> groupType: -2147483646
>> objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=hh3,DC=site
>> objectClass: top
>> objectClass: posixGroup
>> objectClass: group
>> gidNumber: 21111
>> whenChanged: 20130808064630.0Z
>> uSNChanged: 5757
>>
>> sssd_cache -UG still shows steve2 as a member:
>>
>> hh16:/home/steve # sss_cache -UG
>> hh16:/home/steve # systemctl restart sssd
>> hh16:/home/steve # getent group staff2
>> staff2:*:21111:steve2
>>
>> The only way this works is to remove the contents
>> of /usr/local/var/lib/sss/db/ and restart sssd.
>> Thanks
>
> This sounds to me like a bug. Even without the restart the sequence of:
>
> sss_cache -UG
> getent group staff2
>
> Is suposed to fetch the new group memberships. You're running a custom
> build, right? Can you please try applying commits
> 9615f4c3c6f6dcc50ee7d4e50020549a2ff720c0 and
> f7aef1e3ca5bdcddb6fb7c7e6556315faa96165d ?
>
> Those landed yesterday and might fix the problem for you..

This is 1.10.1 from the tarball. With Samba4 AD. Is there a how to for 
applying commits?



More information about the sssd-devel mailing list