samba - Dec 2022 - accidentally upgraded DC to 4.17.3 ... didn't work

01.12.2022 14:35, Patrick Goetz via samba wrote:
> 
> 
> On 11/22/22 03:04, Rowland Penny via samba wrote:
>>
>> The best fix for that is to turn off systemd-resolved on a Samba DC and
then create /etc/resolv.conf as you require it, that way, it cannot get
>> changed.
> 
> Since I've been dealing with this on a daily basis recently ....
> 
> You don't have to turn off systemd-resolved.? Just delete the symlink
it creates for resolv.conf in /etc, create your own static /etc/resolv.conf file
> and then restart systemd-resolved.? It's smart, and knows how to roll
with this.
> 
> Turning off systemd services is rarely what you want to do, and as more and
more services align themselves with the convenience of systemd, this will
> come back to bite you in the ass eventually. Or never upgrade; your choice.
<:)
I think this is a bit wrong view, and it *is* a way for a disaster you describe
in your other email.

When you keep systemd-resolved running, when *some* parts of the system (the
ones who uses its own resolver lib talking directly to systemd-resolver)
will ask it for the DNS resolution, and the other parts will ask whateve
resolver is configured in /etc/resolv.conf.  *This* is a way to disaster,
to debugging which names resolve to which addresses in which services.

When you turn systemd-resolved off, stuff will query nameservers from
/etc/resolv.conf only, and things will be at least consistent within the
same host.

Whenever samba resolver or DNS should be used at all is another question,
and here, it looks like we have entirely different opinions wiht Rowland.
Samba resolvers have many limitations which don't exist in systemd-resolved
(eg, for stuff like dynamic addresses on a laptop, different networks etc).

But this is a different topic. The main thing I wanted to point out is
consistency (or lack thereof) when using multiple services, exactly like
you already noticed with the logging and systemd-resolved.  So far,
systemd-resolved is not mandatory and /etc/resolv.conf works still.

/mjt

On 01/12/2022 14:01, Michael Tokarev via samba wrote:
> I think this is a bit wrong view, and it *is* a way for a disaster you 
> describe
> in your other email.
No it isn't, I have been doing this for years on Samba AD DC's.
> 
> When you keep systemd-resolved running, when *some* parts of the system 
> (the
> ones who uses its own resolver lib talking directly to systemd-resolver)
> will ask it for the DNS resolution, and the other parts will ask whateve
> resolver is configured in /etc/resolv.conf.? *This* is a way to disaster,
> to debugging which names resolve to which addresses in which services.
Nothing should be asking systemd-resolved for anything, its only job 
(just like resolvconf) should be to update /etc/resolv.conf, everything 
else should check /etc/resolv.conf for what nameserver to use.
> 
> When you turn systemd-resolved off, stuff will query nameservers from
> /etc/resolv.conf only, and things will be at least consistent within the
> same host.
Exactly, as it should be on a Samba AD DC.
> 
> Whenever samba resolver or DNS should be used at all is another question,
> and here, it looks like we have entirely different opinions wiht Rowland.
> Samba resolvers have many limitations which don't exist in
systemd-resolved
> (eg, for stuff like dynamic addresses on a laptop, different networks etc).
If you run a Samba AD DC on a laptop, or move it around, then you are 
asking for trouble. I was talking about something that will not move.
> 
> But this is a different topic. The main thing I wanted to point out is
> consistency (or lack thereof) when using multiple services, exactly like
> you already noticed with the logging and systemd-resolved.? So far,
> systemd-resolved is not mandatory and /etc/resolv.conf works still.
This is Linux and very little should be mandatory, if you want 
mandatory, go and run Windows.

Rowland