On Mon, Mar 09, 2015 at 01:41:15PM +0100, Pavel Březina wrote:
On 03/09/2015 01:30 PM, Jakub Hrozek wrote:
>On Mon, Mar 09, 2015 at 01:25:22PM +0100, Pavel Březina wrote:
>>On 03/09/2015 12:50 PM, Jakub Hrozek wrote:
>>>On Mon, Mar 09, 2015 at 11:52:04AM +0100, Pavel Březina wrote:
>>>>Can we not use the ldap_ prefix since this option is supposed to be
present
>>>>also in responder?
>>>
>>>Well, I don't think it should be used in the responder. I think the
>>>responder should just request whatever it needs to and let storing the
>>>data to cache for the Data Provider.
>>>
>>>What we can do is to return a DP error to make it clear that DP hit a
>>>sizelimit and the result might be incorrect, but that's it.
>>
>>You can have multiple domains, therefore you want to limit both dp request
>>and ifp request. At least this was agreed on.
>
>Maybe :-) I don't remember to be honest. But then I think the responder
>and domain options should be totally independent.
>
>What would the responder option do precisely? Limit replies how, limit
>how many objects are exposed on the bus? The dp request is always sent
>to a particular domain, not all domains, right?
Yes, each dp request is always sent to a particular domain.
The goal is to control how many records are returned from IFP to the caller
of FindUserByNameFilter(filter, limit).
So you send dp request to all domains separately, each domain will store
only a limited number of records. And in IFP you aggregate those records and
return only 'limit' of them or if not set as parameter than you use limit
from sssd.conf [ifp] section.
This is what we have agreed on. We can of course change it that we will only
obey 'limit' parameter in IFP and return all up to date records in cache.
But then we would have to make the parameter mandatory so we don't send
thousands of results. That would make it hardcoded in applications though...
I see and I also see why you wanted to include the same option. I already
see the split responder-provider options are a bit confusing for some
consumers in the IFP case.
So let's turn the question around -- would the domain option inherit the
responder option? With this configuration:
~~~~~~~~~~~~~~
[ifp]
wildcard_limit = 100
[
domain/example.com]
~~~~~~~~~~~~~~
Would the domain limit the wildcard request to 100 entries or just run
the full wildcard request? If not, then we can go with the shared option.
The reason I initially proposed two options is that I suspect we might
be asked to add more listing calls to the NSS responer and the
libnss_sss_idmap library in particular. If the domain should have
inherited the limit from some responder (like we do with the cache
timeouts), then which parameter do we inherit with a setup like:
~~~~~~~~~~~~~~
[ifp]
wildcard_limit = 100
[nss]
wildcard_limit = 200
[
domain/example.com]
~~~~~~~~~~~~~~
So I think we need to solve a tradeoff between using a single option and
administrators being suprised that domain searches are too wide or using
two options and then administrators being confused by two places to set
a seemigly similar option.
Sound like you prefer a single option?