Debian TC vote on init system coupling

Posted Mar 8, 2014 23:42 UTC (Sat) by anselm (subscriber, #2796)
In reply to: Debian TC vote on init system coupling by dlang
Parent article: Debian TC vote on init system coupling

Here's your system administration convention:

/etc = stuff the local administrator may change
/usr = stuff the local administrator shouldn't change

The distribution provides basic systemd units below /usr, and local changes to those systemd units, or all-new systemd units, go into /etc. Systemd figures out how these go together, and provides tools that make it easy to find the effective configuration that is actually being used. It is actually quite nifty.

Exactly how does systemd »throw away« anything? If anything, System V init is ignoring the convention by putting loads of stuff into /etc that is really quite difficult to change without producing a maintenance nightmare.

Debian TC vote on init system coupling

Posted Mar 9, 2014 4:19 UTC (Sun) by dlang (guest, #313) [Link] (2 responses)

Service startup is an administrator level activity, so configurations for service startups should be under /etc, including ones modified by the local administrator and those that are system defaults.

Debian TC vote on init system coupling

Posted Mar 9, 2014 5:13 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link] (1 responses)

Agreed on everything except the last part. There is no particular reason defaults shipped by the distribution needs to be part of /etc at all and systemd is hardly the only program shipping system configuration defaults in /usr. Dozens and dozens of programs do that. In systemd, you can override only what you want to:

Ex:

--
/etc/systemd/system/httpd.service.d/restart.conf

[Service]
Restart=always
RestartSec=30

man systemd.unit more details

Debian TC vote on init system coupling

Posted Mar 9, 2014 13:25 UTC (Sun) by anselm (subscriber, #2796) [Link]

This is particularly useful because in the systemd setup the configuration files provided by the distribution are cleanly separated from the local settings made by the administrator.

With something like System-V init, everyone unloads their init files in /etc/init.d, and it is difficult for an administrator to (a) see whether any of these scripts have indeed been changed to better suit local preferences, and (b) maintain such changes across updates from the distributor. Systemd makes this much more obvious because anything under /etc is by definition a local change, and updates to the distributor-provided configuration in /usr do not run the risk of either obliterating the local changes or else requiring a tedious manual merge.