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 sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users