[SSSD] Design discussion: Wildcard Data Provider requests

Jakub Hrozek jhrozek at redhat.com
Mon Mar 9 13:21:18 UTC 2015


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?



More information about the sssd-devel mailing list