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

[Martin Pitt]

Hey Colin,

thanks for the discussion! Trimming heavily; as you said we should let
some other upstreams chime in too, I just have some followup
questions.

Colin Guthrie [2014-11-18 13:01 +0000]:
> >  * 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?
> 
> Well, the *.policy files are simply read when calling "systemctl preset"

Right. I meant, even with using presets, a newly installed package
still needs to call "systemd preset foo.service" for all the units
that it ships, so that the /etc symlinks are generated. I. e. we
merely replace "enable" (what the current Debian packages do) with
"preset" in the postinst.

We need to do that as systemd doesn't automagically spot newly
installed units (via inotify or what not) and enable them.

Or did I misunderstand this?

> The idea is that there are very few policy files shipped in a distro

Indeed. A generic distro should have exactly one, with "disable *"
(Fedora policy) or "enable *" (Debian policy). Anything more special
would be customization for specialized images/spins/etc.

> >  * With that, how would a package then say that it does *not* want a
> >    particular unit to get enabled?
> 
> The idea is that you don't really decide that at a package level, but at
> a distro level.

We do (and that policy drives the auto-generated postinst), but there
are always special cases where a package might want to ship a unit
which doesn't get enabled by default. I was wondering how that could
be accomodated. So for that, the package itself could ship its own
preset file, containing a "disable myself.service"? That would make
sense (if I understood it right). Either way, this is certainly the
rare exception.

> >  * 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.
> 
> Indeed, but ultimately if you want to make something configurable in
> some capacity, you have to put that configuration somewhere and /etc is
> the defacto place to put it.

Fully agreed. Any admin change should go into /etc. My point is,
distro/package defaults should *not*.

> But I'd say that if you, as a vendor, are shipping an enabling symlink
> in /usr/lib in the first place, you're making a concious decision that
> this is something you don't generally want an admin to override easily.
> The admin only really has the choice of masking it.

Yeah, that's not what I had in mind. I want to keep the interface and
notion of enable/disable for admins, just implement the
representation of these choices differently in /etc/ (i. e. just
represent the admin changes, not distro defaults plus admin changes).

> I think moving enabling symlinks into the packages (and thus /usr) has
> several drawbacks:
> 
> 1. It pushes decision making on such policy to be distributed through
> thousands of packages rather than being centralised and thus makes it
> very difficult to do respins and change such policy centrally.

Right, this can't be done with Debian ATM as postinsts use systemctl
enable. Moving to preset would fix that part. So, thanks again for
pointing that out, this is something that we should do, independently
of the (totally orthogonal) discussion of how to treat wants symlinks
in /etc/ vs. /usr.

> 2. It makes the packaging task more complex - these links have to be
> created during packaging (although I'm sure this could be mostly automated).

Yeah, it is.

> So I guess my reply to this is, this is OK, and I think this goal is not
> one to aim for. It's "state" information and it should be represented in
> /etc and I don't think trying to reduce this is a good idea (personally!) :)

Okay. I was wondering if that was merely an oversight, or if there are
people who actually want it the way it is currently. Here is the answer :-)

> Perhaps teaching systemd-delta or systemctl status to show you the
> preset state would solve this problem? e.g. if it showed something like:
> 
> 
> [colin at jimmy log (master)]$ systemctl status sshd.service
> ● sshd.service - OpenSSH server daemon
>    Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled
> [preset: disabled])
>
> Perhaps that would help?

That would certainly help already, as then admins would have *a* way
to check what was changed in the system.

> Well, I really think that pushing policy down to the package level is a
> real backward step. I mean, it's one of the main principles that the
> systemctl preset feature was developed to *avoid* in the first place!

Indeed! I think the current packaging scripts in Debian still date
from the time when presets didn't exist, so systemctl enable is all we
had.

Thanks,

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)