[agarzenm]

From the article.

>My main gripe is that the files under /etc/rc.d/ are immutable scripts.

If the files/config (I know the author argues they aren't config files) are truely immutable why would the system upgrade command modify them? and how would it as if they are immutable in the same way that running chattr +i somefile on Linux will make a file immutable even to root then I don't understand how the upgrade command is modifying them.

Systemd-d is growing on me, partly because it is being forced upon us but also because once you get over the initial carpet pull from beneath you, you don't need to be exposed to the extra bullshit it brings.

If you want to experience pain with System-d, install a fresh copy of Ubuntu and try to setup /etc/resolv.conf, for an extra challenge try setup /etc/resolv.conf using unbound as a stub resolver.

I was amazed at how much effort I had to spend fighting the OS to just say "Stop managing this file, do not load this file, I am going to manage it"

I spend most of my time with Linux systems so I admire the simplicity of the System V approach. It is interesting to see other people discuss this from a BSD perspective as I have very little exposure to BSD like systems.

BSD seems great, I love reading the security.html page of the OpenBSD project, it has so many great ideas + implementations.

https://www.openbsd.org/security.html

[mioelnir]

They are not immutable in the 'chflags uchg,schg ' sense.

Updating these files is not in any way shape or form a hassle anymore if you do not update them. etcupdate has that solved. Even mergemaster has specific options to handle unchanged /etc that only diffs in svn-id tags and similar.

But in my opinion the basic premise of the article is false. mergemaster and etcupdate with their diff and 3-way merge capabilities are there because these files are assumed to have local edits.

The startup procedure, scripts, options are expected to be customized; thus the update procedure has handling to preserve local edits.

[tssva]

At least with Ubuntu server it is pretty easy. The system generated /etc/resolv.conf file even tells you how to disable system control in the comments of the file.

sudo apt install -d -y unbound sudo systemctl stop systemd-resolved sudo systemctl disable systemd-resolved sudo unlink /etc/resolv.conf sudo sh -c 'echo "nameserver ::1 127.0.0.1" >/etc/resolve.conf sudo apt install -y unbound

[segfaultbuserr]

> If the files/config (I know the author argues they aren't config files) are truely immutable why would the system upgrade command modify them?

You are confusing the two different scenarios that you need to distinguish.

The first scenario is when a config file is simply a part of a package, managed by the package manager. In any reasonable package manager, if you ever edited a config file manually under /etc, the package manager will never attempt to update it automatically. For example, apt-get will ask you whether you need to preserve the old file, use the new file, or diff-and-edit it manually. This is the reason why the author suggests to move rc.d from /etc to /libexec, because every time you upgrade your system, the package manager will ask you to diff-and-update some random runscripts that you've never written.

The author's point here is that the rc files do not behave like config files, they are closer to programs or executables, the package manager should be able to update them when a new version in installed without annoying the user, just like any other binaries.

---

The second scenario is when a config file is managed by the init system, a script, or a daemon in the system. For example, /boot/grub.cfg is managed by update-grub & os-prober, and ideally one should never edit the file manually.

In this scenario, it's completely off-topic and irrelevant to the original topic of whether rc.d should be treated as libexec, but here's my opinion anyway...

> I was amazed at how much effort I had to spend fighting the OS to just say "Stop managing this file, do not load this file, I am going to manage it"

Never attempt to fight with the system in a brute force manner - edit this file, later the file is edited back, edit again, edit back, and finally "chattr +i" the file, I never understand this mentality. Using "chattr +i" is almost never the correct solution.

All you need to do is politely tell your intention to the daemon in charge, spending 30 minutes (or each time after a system upgrade) to fight with it, can easily save your 5 minutes to read the documentation.

> for an extra challenge try setup /etc/resolv.conf using unbound as a stub resolver.

If you read the documentation, you'll sometimes find your needs are already supported, and managing it manually is not needed in the first place. For example, NetworkManager already comes with builtin, automatic support of a stub resolver. Not only that, it supports both dnsmasq and unbound, and even has extra logic to help you updating the DNS when you're connected to a VPN. All of these features are here to make one's work easier.

Yet one still chooses to fight with the system in the most brute force way such as "chattr +i", at the very least you can turn it off smoothly and it'll never bother you again.

For example,

$ man NetworkManager.conf

> dns

> Set the DNS processing mode.

> default: NetworkManager will update /etc/resolv.conf to reflect the nameservers provided by currently active connections.

> dnsmasq: NetworkManager will run dnsmasq as a local caching nameserver, using "Conditional Forwarding" if you are connected to a VPN, and then update resolv.conf to point to the local nameserver. It is possible to pass custom options to the dnsmasq instance by adding them to files in the "/etc/NetworkManager/dnsmasq.d/" directory. Note that when multiple upstream servers are available, dnsmasq will initially contact them in parallel and then use the fastest to respond, probing again other servers after some time. This behavior can be modified passing the 'all-servers' or 'strict-order' options to dnsmasq (see the manual page for more details).

> systemd-resolved: NetworkManager will push the DNS configuration to systemd-resolved

> unbound: NetworkManager will talk to unbound and dnssec-triggerd, using "Conditional Forwarding" with DNSSEC support. /etc/resolv.conf will be managed by dnssec-trigger daemon.

> none: NetworkManager will not modify resolv.conf. This implies rc-manager unmanaged.

$ man systemd-networked

> by one of the .network files will be ignored. It is also possible to

> explicitly tell systemd-networkd to ignore a link by using

> Unmanaged=yes option, see systemd.network(5).

I guess one reason that everyone's fighting with the system is not realizing the official way of telling one's intention to the system. Perhaps everyone should learn the way GRUB warns its user.

    #
    # DO NOT EDIT THIS FILE
    #
    # It is automatically generated by grub2-mkconfig using templates
    # from /etc/grub.d and settings from /etc/default/grub
    #

Perhaps someone should contribute a patch to NetworkManager to add a similar warning.

    # DO NOT EDIT THIS FILE. This file is currently under the management
    # of NetworkManager. It's automatically generated according to the
    # DNS configuration of the current network connection in NetworkManager.
    # Any change to this file will be overwritten. 
    #
    # If you are trying to change your DNS resolver per connection, use "nmtui", "nmcli", 
    # or alternatively, edit "/etc/NetworkManager/system-connections/".
    #
    # To stop NetworkManager from managing it altogether, edit 
    # /etc/NetworkManager.conf, set the following and
    # restart NetworkManager, before you edit /etc/resolve.conf.
    #
    # [main]
    # dns=none
    #
    # If you are trying to set up a stub DNS resolver, it's recommended to
    # NetworkManager's builtin support. Set "dns=dnsmasq" or "dns=unbound"
    #
    # See "man 5 NetworkManager.conf" for more details.

[yellowapple]

> Perhaps someone should contribute a patch to NetworkManager to add a similar warning

Worth noting that NetworkManager does indeed add a shorter and milder version of such a warning (at least on my machine):

    # Generated by NetworkManager
    search blah.blah.blah
    nameserver x.x.x.x
    nameserver y.y.y.y
    nameserver z.z.z.z