On Wed, Apr 09, 2014 at 08:07:25PM +0200, Pavel Reichl wrote:
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.
That would work for me. I don't think we should over-engineer the
solution, after all, the goal was to make it clear to the admin that
they need to tune the config themselves..
>
> >
> > 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'?
What I meant is that this addition:
+ if (req_type == SSS_DP_NETGR &&
+ dctx->domain->refresh_expired_interval != 0) {
+ ret = EOK;
Makes sense as well to me, because this way neither midpoint refresh nor
expired record request would be scheduled. What I'm not sure about is --
would we expand this condition in the future when we add more background
refresh types?
>
> 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.