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.
As far as I can read the AD code always put the server there.
Down below the pure nsupdate code can cope with the server name missing, but the AD code doesn't, unless I am missing something.
Simo.