On Mon, 2014-04-07 at 19:07 +0200, Jakub Hrozek wrote:
On Thu, Feb 27, 2014 at 05:15:00PM +0100, Pavel Reichl wrote:
> On Thu, 2014-02-27 at 11:55 +0100, Pavel Březina wrote:
> [snip]
> > Nack.
> > It is still possible having a netgroup expired if
> > refresh_expired_interval is misconfigured (> entry_cache_timeout). Thus
> > you still need to check if the netgroup is valid, maybe throw a visible
> > warning if it is expired and periodic refresh is enabled.
> >
> [snip]
>
Reviving another stalled thread :-)
> So how about checking that:
>
> refresh_expired_intervat < entry_cache_timeout
Are you proposing to abort startup in this case? That sounds like a bit
too heavy solution..
No, I would rather log loudly about this problem and then I would set
refresh_expired_interval to entry_cache_timeout * 3/4 as is advised in
man pages. And again I would log this action loudly.
>
> when configuration is loaded?
>
> I thing these values are never changed although they are not const.
Yeah, I'm not worried about these values changing at runtime.
In general I see the point of your patch in that the netgroups are only
ever refreshed by the periodical task and no refreshes are scheduled by
the nss frontend..
I'm sorry, I'm not sure I fully understand - by 'point of my patch' you
actually mean 'problem of my patch'?
btw can we get into this situation where the refresh is on but a netgroup
is expired even without misconfiguration? For instance if a netgroup was
saved to the cache right before the backend was about to schedule the
periodic task, then before the next task the netgroup was requested and
already expired? Is it OK in this case to just return stale data and let
the next periodic update refresh the netgroup? I think so, because the
cache would eventually converge..
I'm not sure about this, I'll run some
tests tomorrow and I'll let you
know.
_______________________________________________
sssd-devel mailing list
sssd-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel