[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