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

Dmitri Pal dpal at redhat.com
Thu Apr 18 20:29:42 UTC 2013


On 04/18/2013 05:30 AM, John Hodrien wrote:
> 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?
>

Yes, I agree with John.

There is a bit of confusion here.
1) The UID and GID of the user are not frequently changed. It is a bad
practice to change them because all the files owned by user also need to
be chowned. We do not have a good solution for addressing that. We have
a ticket to design something in future bu so far if you change the
UID/GID of the user you have to clean the caches on the systems the user
has access to. This is the flip side of the caching. So think twice
changing UID/GID
2) Changing home directory is fine and would propagate when the user
logs next time. You can't view UID/GID and home directory as similar
attributes. They have different meaning and implications.
3) Group membership is also updated when user logs in or there is a
lookup for user information. Several cache parameters define how
frequently that would happen. Everything is currently optimized for
performance of the applications running on the client. If you want to
get less latency you would have to give up some of the performance gains
the caching presents.

 

> jh
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/






More information about the sssd-devel mailing list