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.
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.