[SSSD-users] FW: 1.11.5 ddns failure on Ubuntu 14.04[SOLVED]

Jakub Hrozek jhrozek at redhat.com
Thu Jun 26 11:52:27 UTC 2014


On Wed, Jun 25, 2014 at 04:59:28PM +0200, steve 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.
> > 
> Quite possible, but I'm trying to stick to the thread and trying to help
> the OP by describing her observations. IOW, don't send the wrong server
> to nsupdate.

Sorry, I didn't mean to offend you, I'm really glad you're helping us
debug the problem, it's a huge help.

> If dns is working correctly, you do not need to specify the
> server anyway.

Right.

> 
> > 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..
> 
> That would never be the case as you would not be able to join the
> domain. The primary DNS _must_ point at the server responsible for the
> zone.

Yes, but the local DNS server can just point to the right servers in its
configuration, in other words redirect to the AD DC. So SRV records
realmd uses would still be valid, but the address of the resolver in
resolv.conf wouldn't be usable for dyndns purposes.

> Your method with realmd may get around that but unless you get the
> dns perfect you can forget about joining AD. 
> 
> If as you say, you wish sssd to do as little as possible, then don't
> overwrite what dns does anyway by overriding the server which is sent to
> nsupdate. It is then up to the admin to sort out the dns when it doesn't
> work.

I agree with this completely. I need to run some tests and re-read the
code more carefully later to verify if we're indeed using the server always
(which would be a bug) or just as a fallback (which would be OK and could
be improved even more with the option Simo suggested).

> Thanks,
> Steve

Thanks again for helping us on this list!


More information about the sssd-users mailing list