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

Simo Sorce simo at redhat.com
Fri Jan 6 00:57:53 UTC 2012


On Thu, 2012-01-05 at 18:17 -0500, Stephen Gallagher wrote:
> 
> 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.

Good point.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York




More information about the sssd-devel mailing list