On 22 Mar 2016, at 20:35, Simo Sorce <simo(a)redhat.com> wrote:
On Sun, 2016-03-20 at 21:28 +0100, Jakub Hrozek wrote:
>> On 16 Mar 2016, at 13:45, Petr Cech <pcech(a)redhat.com> wrote:
>>
>> Hi,
>>
>> I will work on $subject [1] and I have discussed this topic with
> Jakub a week ago. There are some open questions, so I will be glad if
> you say your opinion.
>>
>> There could be heavy traffic between SSSD client and server coused
> by local users. We need longer timeout in negative cache for local
> users.
>>
>> Questions are:
>>
>> a) Is better hack negative_cache or responder?
>>
>
> I would say that this solution should be reusable by other responders
> like ifp as well. Therefore I would say either negcache (but there I
> would say a new function, not extend the generic one) or a reusable
> function in responder/common.
>
>> b) Is better set timeout = 0 (it means permanently in negative
> cache) or set something really big like 12 hours?
>> * We couldn't remove local users from permanent negative cache (only
> by restart).
>> * Is timeout = 12 hours means some kind of network peak?
>>
>
> I guess some long timeout is slightly more flexible for cases where
> the admin would add the local user to LDAP groups. A couple of hours
> should be enough, as long as the negative entries are cached across
> all clients, then if a single client queries the server once a couple
> of hours, that should not bring the server down..
12 hours is a lot, if you made a mistake and want to correct it (eg some
software install created a local user by mistake that the admin removes
because they want it in LDAP) you do not want to wait for hours.
The main issue with the initgroups calls is not the load o the server,
but the slowdown of the call which ends up contacting a network (slower)
store for a local user.
I would use a smaller timeout here, like 10 minutes, but potentially add
a midway cache check, like we do for positive results. so after 5 min,
The admins actually complained about a load on the servers from users like postfix IIRC.
That's the reason I suggested a long timeout.
But I guess even a short timeout would work, but I would vote for defaulting to the
entry_cache_timeout then (with a midway check perhaps..). I guess the biggest gain for
admins would be to be able to specify a timeout for all passwd users at once and avoid
putting them one-by-one into filter_users/filter_groups.
if a request comes in we do an asynchronous positive check to see if
we
still need to extend the negative cache for another 10 minutes. If the
local user disappeared we drop the negative cache.
This is a good idea.
> btw do you think this feature should be enabled or disabled by
> default?
Good q. how often does this problem happen ?
>> c) Is it enough to do it only for initgroups?
>
> Hmm, not sure, by convention initgroups is the most frequent example
> (maybe there will be some users of the new libc merge feature), but at
> the same time special-casing initgroups doesn't gain much..
>
> I guess I would personally do this for all lookups that the NSS
> interface can do (by name, by id) but I'm not 100% for or against
> either..
I agree, keep it generic.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
Thank you for taking the time to review the design!