4 ms·

In reality, this is something that people have been doing to systemd-resolved in desperation since the late 2010s (e.g. https://unix.stackexchange.com/q/421977/

by JdeBP 1y ago

In reality, this is something that people have been doing to systemd-resolved in desperation since the late 2010s (e.g. https://unix.stackexchange.com/q/421977/5132 https://unix.stackexchange.com/q/421977/5132 for one of many examples), and systemd has not been changed in all of that time to undo this. It is actually an unnecessary act of desperation, as systemd does have a way of setting things up so that /etc/resolv.conf is entirely manually configured. It's just (a) not completely obvious to deduce from the systemd doco, and (b) something that gets the blame for things that actually lie elsewhere in the system that also need disconnection, like /etc/nsswitch.conf giving nss-resolve priority over nss-dns. That that situation remains the case today (five years after I wrote https://unix.stackexchange.com/a/612434/5132 https://unix.stackexchange.com/a/612434/5132 for example, and almost a decade since the desperate making resolv.conf immutable idea took off) is a good indicator that the systemd developers aren't in reality in any hurry to force some hypothetical total ownership of /etc/resolv.conf by systemd.

johnisgood 1y ago
The system on which I am using "chattr +i" is not even a systemd one. I forgot why I set the attribute in the first place. I might be able to figure it out, but it was the simplest and least time-consuming yet effective solution at the time. I think there were more than one reasons for it.
- JdeBP 1y ago
  My educated guess would be either NetworkManager or resolveconf (or a DHCP client not even going through resolvconf), with fun with package upgrades resetting customizations as my second choice educated guess. (-:
  - throw0101c 1y ago
    I find it baffling that distributions are making all of these system-level changes away from how a 'traditional' Linux/Unix does/did things, towards handling 'dynamic' situations, when a large portion of the installed of Linux is probably servers: i.e., why would you even consider the DHCP client situation for a server? As a sysadmin I want a static files that never change, and whose mtime is from when I installed the thing two years ago. I'll either launch vi to make changes or Ansible/Puppet/etc. Make the default the default as static-y as possible, and if someone is installing a personal system have a "laptop-config" or "desktop-config" package that adds all the dynamic bits separately.
  - johnisgood 1y ago
    I think the reason was resolveconf and package updates, yes.
deleted 1y ago
[deleted]

by JdeBP 1y ago

johnisgood 1y ago

The system on which I am using "chattr +i" is not even a systemd one. I forgot why I set the attribute in the first place. I might be able to figure it out, but it was the simplest and least time-consuming yet effective solution at the time. I think there were more than one reasons for it.

JdeBP 1y ago
My educated guess would be either NetworkManager or resolveconf (or a DHCP client not even going through resolvconf), with fun with package upgrades resetting customizations as my second choice educated guess. (-:
- throw0101c 1y ago
  I find it baffling that distributions are making all of these system-level changes away from how a 'traditional' Linux/Unix does/did things, towards handling 'dynamic' situations, when a large portion of the installed of Linux is probably servers: i.e., why would you even consider the DHCP client situation for a server? As a sysadmin I want a static files that never change, and whose mtime is from when I installed the thing two years ago. I'll either launch vi to make changes or Ansible/Puppet/etc. Make the default the default as static-y as possible, and if someone is installing a personal system have a "laptop-config" or "desktop-config" package that adds all the dynamic bits separately.
- johnisgood 1y ago
  I think the reason was resolveconf and package updates, yes.

deleted 1y ago

[deleted]