[SSSD] debbuging, how to turn off cache [SOLVED]

John Hodrien J.H.Hodrien at leeds.ac.uk
Thu Apr 18 09:30:53 UTC 2013


On Thu, 18 Apr 2013, steve wrote:

> Having the user login has no effect. getent still shows him as memberOf 
> (he appears alongside his now primary group and not, as should happen, 
> alongside his secondary group).

Perhaps I was misunderstanding.  I thought you were changing a user's primary
group, and weren't seeing that updated.  I'd expect you to have to wait to the
cache to clear, or do:

sss_cache -u thatuser

Maybe I was misunderstanding what you're trying to do.

>> Can I just query one thing?  Why on earth are you changing user attributes
>> for users so frequently?

> Yes. Thanks. We have to justify from winbind, nslcd or sssd for a 
> situation where 600 users can login to any one of around 80 machines in 
> a Samba4 domain. Adding/removing a user to a group is quite common. This 
> is not recognised on the clients unless root intervenes: Impossible! 
> Less common, but common enough in our environment is moving a user's 
> home directory.

It's not recognised on the clients until the cache expires, but I don't see
how that can not be the case.  This'd also be the case with windows, where the
user's PAC will be used to verify group membership, which often means forcing
a user to log off and back on again to update group membership.

> We've eliminated winbind and are left with nslcd which is time consuming 
> to implement (but which passes all the tests), and sssd with it's point 
> and click configuration. We'd really like to go with sssd but we have to 
> prove in a test lab that what we do will be covered. We simply have to 
> maintain the domain centrally. We cannot visit 80 clients everytime a 
> change is made.

Group membership changes propogate in our environment just fine within a
reasonable period of time.  What should we be talking by default, 5 minutes?

>> Forget the effect sssd has, you're completely hanging out to dry any 
>> running
>> processes of these users everytime you do this.
>>
> As I say, nslcd copes with this. I'm trying to get to the stage where we 
> can configure sssd to do it too. sssd is like nslcd running with nscd:
> sssd = nslcd + nscd?

If you're just talking about changing group membership, then yes.  But I
thought you'd also talked of changing uids of existing users.  Equally why
would you be changing primary group membership of users on a frequent basis?

Either you have a cache, or you don't.  If you just disabled the cache (as I
believe has been suggested) does it behave as you think you want?

jh



More information about the sssd-devel mailing list