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

Dmitri Pal dpal at redhat.com
Thu Apr 18 21:45:53 UTC 2013


On 04/18/2013 05:07 PM, steve wrote:
> 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)
>

There are several different caches at different levels.
Let us split the authentication and identity lookups.
With authentication there are two types of caching:
* your password hash can be stored in the sssd cache database so that
you can log offline (optional)
* your password in clear is stored in the kernel key ring when you log
while not connected to the network so that when you get on the VPN a
kerberos ticket can be automatically acquired (optional).

With identity lookups you have several caches:
1) fast cache that was added in 6.4 that is equivalent of the NSCD. It
works for users and groups and its purpose is to provide caching for the
cases when a process does multiple lookups per second for the same ID.
2) normal sssd cache. It has a complex algorithm of keeping it up to
date. For more about it see man sssd.conf and parameter
entry_cache_nowait_percentage

When user performs online authentication SSSD would try to fetch the
latest information from the server. At least this is how earlier
versions of SSSD worked. If you do not see this in the 1.9 that might be
a bug. But before opening it please make sure that your client actually
has the connectivity to the server at the moment you re-authenticate. We
would want to see your sssd logs for the authentication attempt with
high debug_level value to detect what is wrong and why you do not see
the group membership coming to the client in a reasonable time.

I suggest the following test:
log into a box via sssd
do id
change user membership on the server
lock screen/unlock screen (login/logout as a variant)
do id

The group change should be propagated because the user has authenticated
and we refetch user data on the re-authentication.
Otherwise if you do not re-authenticate the cache would be updated but
at much slower pace as Jakub mentioned.
If you do not see the changes in groups then send us the sanitized sssd
log for the default domain. Do not forget to set  debug_level to 8 or 9
before running the test.

HTH




> 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
> _______________________________________________
> 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