[SSSD] remove nisNetgroupTriple or memberNisNetgroup from server bug sssd did not reflect it.

Stephen Gallagher sgallagh at redhat.com
Thu Jan 5 23:17:50 UTC 2012



On Jan 5, 2012, at 6:00 PM, Jakub Hrozek <jakub.hrozek at gmail.com> wrote:

> On Thu, Jan 5, 2012 at 3:27 PM, Simo Sorce <simo at redhat.com> wrote:
>> On Thu, 2012-01-05 at 15:07 +0100, Jakub Hrozek wrote:
>>> On Thu, Jan 05, 2012 at 12:33:24PM +0800, Joe Jin wrote:
>>>> On 01/05/12 11:43, Stephen Gallagher wrote:
>>>>> On Thu, 2012-01-05 at 11:26 +0800, Joe Jin wrote:
>>>>>> Hi,
>>>>>> 
>>>>>> When I did sssd + openLDAP tests I found if remove nisNetgroupTriple or
>>>>>> memberNisNetgroup attribute, sssd did not reflected the changed,
>>>>>> "getent netgroup <group_name>" return unchanged result.
>>>>> 
>>>>> Did you wait for the entry_cache_timeout period? Cached entries aren't
>>>>> updated instantaneously.
>>>> 
>>>> Yes I did, I set entry_cache_timeout to 120s, when I add new entry to
>>>> nisNetgroupTriple or memberNisNetgroup, it updated in 120s, but if I
>>>> removed any one of the attributes, getent still return former result,
>>>> even after more than 120s.
>>>> 
>>> 
>>> Sorry I could not reproduce that behaviour - neither with master nor 6.2
>>> 
>>> One twist is that the cache expiry time is saved into the cache so if
>>> you save an item, then change the entry_cache_timeout, the entry keeps
>>> its original expiry timeout.
>>> 
>>> I would recommend to purge the cache altogether (or at least the netgroup
>>> items) if you need to reflect a changed entry_cache_timeout value.
>> 
>> I wonder if we should think about changing how this work, and instead of
>> saving the expiration time save the update time instead and always
>> calculate expiration time at check time.
>> 
>> I am sure this can cause issues where we want to use the expire time to
>> set a non default value,
> 
> Sorry, but I'm not sure what problematic use cases do you have in
> mind. Those such as fake users? We should be fine there as long as we
> use some ridiculous expiry value such as the Epoch.
> 
>> but it is worth thinking if it makes sense to
>> change this behavior as it may confuse admins greatly when they are
>> testing stuff or need to change values to a shorter cache time.
>> 
>> Simo.
>> 
> 
> Yes, I think we might want to change this behaviour. It has bitten me
> once or twice in the past.

For what it's worth, I think the cache management tool will mitigate a lot of this. If a customer really needs an entry updated, they can just run "sss_cache -U username" or similar.

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



More information about the sssd-devel mailing list