[systemd-devel] /usr vs /etc for default distro units enablement

[Colin Guthrie]

Didier Roche wrote on 18/11/14 11:11:
> Fedora doesn't enable and start all units on package installation: there
> are some preset files, based on flavors, which is basically the policy
> stating which units to enable/disable by default. Some other units are
> always enabled (unless masked), by using symlinks directly shipped with
> the package like in /usr/lib/systemd/system/multi-users.target.wants/
> for intance. Contrary to that, Debian/Ubuntu has the policy to
> enable/start services and facilities on package installation during
> postinst. This is done (indirectly) via "systemctl enable", which
> creates symlinks in /etc/systemd/system/*.wants/.

I believe that it is generally discouraged to use "systemctl enable"
indirectly or otherwise during postinst.

You should instead use systemctl preset which uses information in
various distro provided *.preset files that contain rules for which
units should be enabled or disabled.

This allows a "default" /etc tree of symlinks to be repopulated easily.


> This has 3 drawbacks:
> - Duplicate symlinks for the same targets between /etc and units enabled
> in /usr/lib for units which are already enabled via /usr/lib, if the
> admin runs "enable"

If a package ships a unit enabled via a symlink in /usr/lib, then that
same package should ensure the systemd unit does NOT have an [Install]
section.

Doing so is confusing to the user, so if the packager makes this
decision, he should follow it through properly.

If this is an upstream make-install rule, then it should be fixed
upstream to make it consistent - again the rules is "if you ship a
symlink in /usr/lib, you should not have an [Install] section" (I think
this is good advice but I'm sure someone will correct me if I'm wrong!).


I won't discuss the merits of shipping an enabling link in /usr/lib.

> - Wrt. the "golden image, /etc reset" approach of reducing base os
> installation defaults in /etc, this is another instance of "always needs
> to be there" clutter in /etc. If the package default is  to start the
> service, then it's better to just ship that wants.d/ symlink in the
> package (and thus in /usr) instead of always having to create the
> symlink in /etc at package install time or after a factory reset.

Yes and no. Depending on your use case perhaps shipping it in /usr/lib
is OK (e.g. an embedded system that still wants to support factory
reset), but I'd say that generally speaking, this is what *.preset files
and systemctl preset is meant to achieve. They represent the distro
rules, but still give users full control after the default rules are
applied.

> - We are mixing sys admin information and distro default choices in the
> same directories, and can't tell apart what is what.

/etc is admin, and the distro *default* is applied there (via *.preset
files) but the admin still has full control.


> We were thus thinking about having all default distro choices shipping
> target symlinks in /usr/lib, and having the administrator overrides this
> in /etc via systemctl. This could look similar to masking a unit, i. e.
> a symlink "/etc/.../wants.d/foo -> /dev/null" overrides
> "/usr/lib/.../wants.d/foo -> ../foo.service", and would be an explicit
> representation of "the admin does not want foo.service to autostart" in
> /etc.

I really don't think that's a good idea. Just use preset and setup /etc/
by default, but let the admin override it as needed.


> However, we did notice the following: taking an unit, with an [Install]
> section and a symlink to enable in via that target in /usr/lib:
> - systemctl status <unit> will report "disabled", where it's actually
> enabled and starting for that unit. This is a bug which should be fixed
> in any case, as "disabled" is outright wrong.

This is why I stated above that if you ship an enabling symlink in
/usr/lib, you should also remove the [Install] section. I still think
this is the right solution here.


> On IRC it was suggested
> that those are "static" units, but then it should say at least that.
> - systemctl enable <unit> will duplicate the symlink in /etc
> - If we ln -s /dev/null /etc/<…>/<…>.wants/<unit>, then systemctl status
> <unit> will display the unit as being enabled, and it will activated
> once the target is reached.  This is also counterintuitive, as usually
> this means to mask/completely disable the unit.

I don't think this is a good idea. I really think you should just use
*.preset files properly and generally discourage the shipping of any
enabling symlinks in /usr/lib. And if you do have some special cases
where you want to do that, have a policy that bans an [Install] section
in such units.


> It will be great if we can come to some common grounds on how we should
> separate admin choices and default distro choices, while still working
> on the "remove /etc default distro configuration" . I'm happy to give a
> hand on the desired solutions there.

I think the following is best practice and solves the general issues here:

1. Discourage strongly the shipping of enabling symlinks in /usr/lib
(but aliases are probably OK).
2. If a special case arises where a an enabling /usr/lib symlink is
deemed the best option, the unit must not have an [Install] section.
3. Do not use "systemctl enable myunit.service" (directly or indirectly)
in packaging postinst, but rely on "systemctl preset myunit.service"
instead to capture the distribution (or spin) rules.

This deals means:

 1. distro installs the default setup for users, but admins can override
later
 2. factory reset works fine (assuming "systemctl preset-all
--preset-mode=enable" is run after reset)
 3. systemctl status will work (because only units without [Install]
sections will have enabling links in /usr/lib)

Have I missed something or does this sound good to you too?

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/