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

[Martin Pitt]

Hello Colin, all,

Colin Guthrie [2014-11-18 11:30 +0000]:
> I believe that it is generally discouraged to use "systemctl enable"
> indirectly or otherwise during postinst.

Right, I don't like this either, hence this discussion. :-) I don't
know whether Debian's current way of enabling units on package install
has ever been discussed here, but Didier and I would like to
understand the options and some recommendations, to consider whether
it makes sense to change this in D/U.

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

We can certainly ship a preset of "enable *" to reflect the policy
that in general services do get enabled by default. But this still
leaves some issues:

 * I suppose even wich such a policy the post-installation script
   still needs to call some systemd-update-policy-mumble-mumble magic
   to actually apply the new policy?

 * With that, how would a package then say that it does *not* want a
   particular unit to get enabled?

 * This doesn't solve the problem of having these rather uninteresting
   and cluttering symlinks in /etc at all; the wants.d symlinks would
   still be as they are now, just the place that decides when to
   enable them changes.

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

But then you would entirely lose the information into which target a
service belongs by default. In particular, an administrator couldn't
override the default it with "systemd disable" (I know that this
doesn't work right now, but it's part of the discussion).

> 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 think there are some plymouth .service files with that problem,  but
as far as I can see, most upstreams leave it to packagers to enable
their units.

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

I might misunderstand presets, but as I wrote above they don't address
this at all -- even with them you have preset-induced wants.d/
symlinks in /etc.

I. e. my question is not so much about being able to restore the
default wants.d symlinks in /etc after a factory reset -- there are
multiple ways how this can be done: with presets or iterating over the
installed packages and re-enabling them (Debian also does some
house-keeping which unit files got enabled by postinstall scripts,
which can simply be replayed).

I was rather wondering whether we couldn't make all that
post-processing much simpler by not requiring any /etc/**/wants.d/
links at all. And everything which *is* in /etc/**/wants.d/ would then
be explicit admin choices, with both enabling and disabling units.

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

Sure she does, but this still makes it waaay harder to see on a system
how it deviates from the default install.

> 1. Discourage strongly the shipping of enabling symlinks in /usr/lib
> (but aliases are probably OK).

I'm interested in the reason for that. This basically cements the
status quo that one *has* to have a gazillion links in /etc in order
for your system to work, even if they are not at all specific to the
particular system or represent a deviation from the default install.

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

I rather want to discuss this in the general case, to reduce the
clutter in /etc/. I don't  think it's right to remove [Install] for
all units, see above.

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

That part is fair enough, and we can see whether that should be done
in Debian, but in practice it will make absolutely no difference wrt.
file system layout, cleaning up /etc/, and making admin choices more
obvious.

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

I fully agree on these properties; your recommendations from above
(which is essentially the status quo) certainly works for that, but I
really think we can do better here.

With our proposal these properties would also be satisfied, except
with no churn in package install (systemctl enable or preset),
initialization of a system with empty /etc/, and cleanliness of /etc.

Thanks,

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20141118/929e17ba/attachment-0001.sig>