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

steve steve at steve-ss.com
Thu Apr 18 21:07:23 UTC 2013


On 04/18/2013 10:29 PM, Dmitri Pal wrote:
> 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.
>
>   
Hi
Thanks for the explanation. There seem to be two different caches for sssd.
1. the cache for the user authentication credentials
2. the cache for ldap attributes (like nscd)

Is that correct? What you are saying is that when a user logs in that 
the cache is not consulted: the user login ALWAYS reads directly from 
the directory. Yes? If so, we are not observing that behavior. Even 
after a fresh user login after adding or removing a group membership, it 
can take up to 1/2 hour for the change to propogate so that id, getent 
or user permissions take effect. Are you absolutely certain that the 
login reads from the directory every time? If this were to be the case, 
then our problem would be solved.

We have no intention of randomly changing uid/gid. These are purely and 
simply evaluation tests that we are obliged to perform so thanks for the 
warning.

Could we request that an option is present e.g. in sssd.conf for each 
login to query LDAP and _not_ the cache?

Cheers and thanks for your help.
Steve



More information about the sssd-devel mailing list