On Wed, Jun 25, 2014 at 11:00:47AM -0400, Simo Sorce wrote: > On Wed, 2014-06-25 at 16:22 +0200, Jakub Hrozek wrote: > > On Wed, Jun 25, 2014 at 04:07:12PM +0200, steve wrote: > > > On Wed, 2014-06-25 at 15:43 +0200, Jakub Hrozek wrote: > > > > On Wed, Jun 25, 2014 at 09:34:25AM -0400, Simo Sorce wrote: > > > > > On Wed, 2014-06-25 at 09:30 +0000, Longina Przybyszewska wrote: > > > > > > With correct domain ;)... > > > > > > > > > > > > >By default, we contact the server we establish the LDAP connection > > > > > > >with. I’m sorry, I got a bit lost in the thread — what was >the > > > > > > >difference between the right server and the wrong server in your > > > > > > >setup. > > > > > > > > > > > > In our case, DNS server is not LDAP - it is separate win DNS serer. > > > > > > There is also split DNS server resolving all in/out requests from > > > > > > intern clients. > > > > > > This one is known for resolver on all clients, but can't be used > > > > > > for dyndns updates. > > > > > > > > > > > > >In general, SSSD tries to do as little as possible and we try to > > > > > > >let nsupdate do its job right.. > > > > > > > > > > > > > > > > > > But sssd supplies data for update record for nsupdate, right? > > > > > > > > > > Please open a bug against sssd. > > > > > > > > Please don't (yet). > > > > > > > > > > > > > > For some reason the server name is being forcibly served top nsupdate > > > > > and that shouldn't be the case, passing a "server" option should be > > > > > only > > > > > a fallback case. > > > > > > > > It is only a fallback, the way I read the code. I haven't seen the full > > > > domain logs, so I can't tell if the sssd falls back to trying the server > > > > or tries the server right away (which would be a bug). > > > > > > > > > > > > > > Nsupdate should be let the ability to discover the correct server by > > > > > querying the DNS and picking the available authoritative server. > > > > > > > > > > Feel free to quote the above ion the ticket. It is definitely a bug in > > > > > sssd. > > > > > > > > No, it's not. > > > > > > But if we already know the answer for which DNS server to use, surely > > > sssd should not override what has been set locally at /etc/resolv.conf > > > should it? If you must pass the server name then choose the one which > > > has already been given, not the one which you've found via SRVs. > > > Just our €0,02 > > > Steve > > > > You're describing something different than what Simo was describing. > > > > So you're proposing that the 'server' directive is a server from > > /etc/resolv.conf, not whatever server we are talking to? > > > > If that's the case, then it wouldn't work. Quite often, the server in > > resolv.conf would be just 127.0.0.1 and a local dnsmasq or similar would > > be running on the client machine. Or the AD server could be resolved > > with the help of /etc/hosts.. > > Correct, however the way the AD code uises the server names makes little > sense. It uses the name used to connect to the LDAP server. Although > this is generally a Domain Controller, it is not necessarily a DNS > server (can be even a RODC). So if we need a fallback that should be an > option specified in sssd.conf: something like: fallback_dns_master or > similar.
Yes, I agree with this, a new option seems like the only way. I will open a ticket. > Deriving the DNS server from the LDAP name will be wrong more times than > it is right in large environments. OK, perhaps, I guess your experience here is better than mine and the fact we're debugging the problem at all proves there /is/ a problem. > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > _______________________________________________ > sssd-users mailing list > [email protected] > https://lists.fedorahosted.org/mailman/listinfo/sssd-users _______________________________________________ sssd-users mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/sssd-users
