On Fri, May 31, 2013 at 04:15:18PM +0200, Jakub Hrozek wrote:
On Fri, May 31, 2013 at 01:37:11PM +0200, Sumit Bose wrote:
> recently the patch "Allow flat name in the FQname format" was commit to
> master. The flat domain name is determined at runtime but currently only when
> the responders receive a request with an unknown domain name.
> If now the flat domain name is used in the FQname and the nss responder
> receives e.g. a 'getent passwd DOM\username' request with the flat
> domain name after startup everything is fine. Because after startup the
> domain part of the given fully qualified user name is not know and a
> request will be send to the backends to look it up. If the request is
> done the flat domain name is know and can be used in the returned
> if on the other hand the nss responder receives a 'getent passwd
> username(a)domain.name' with the domain name from sssd.conf the domain
> part of the user name is known and there is no reason to send a
> get_domains request to the backend. Hence the flat domain name is not
> known when the FQname for the response is constructed and will be
> replaced by the full name.
> To avoid this the following patch will always run a get_domains request
> at startup to get the needed domain data.
> Fixes https://fedorahosted.org/sssd/ticket/1951
Works fine, after startup there is a subdomain created and the flat name
But I wonder if it was worth it to add some kind of check in
be_get_subdomains() to avoid issuing another request if the previous
came within some interval and if it did just return success. Currently
this patch triggers an LDAP search per responder.
The downside I see is that there is already a similar check in the
responders themselves, so this would be a bit of duplication.
Thank you for the review. I've added two patches which adds a generic
request queue to the data provider code and let the get_subdomains
request use it. With this you should only see two requests going to the
server, one triggered by the starting responders and the other is the
online callback. I think it is not worth the time to try to optimize
this out as well, because there are different requirements for the
responders and the online callback.