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

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. <:)

On 01/12/2022 11: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. <:)
> 
> 
That is your perspective and I fail to see how something that is turned 
off can bite you in the ass (by the way, 'ass' is another name for a 
donkey, I think you mean the old English 'arse'). from my perspective, 
anything that can alter something that you do not want altering is a bad 
thing. I also cannot understand why breaking the symlink is any 
different to turning off systemd-resolved. With my way, you do not have 
an orphaned program left running.

I initially thought that systemd was a bad thing, but as an init system, 
it seems pretty good, it is all the other things that it has spawned 
that are not really worth the effort.

Rowland

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