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

[Didier Roche]

Le 18/11/2014 15:55, Tom Gundersen a écrit :
>>> I get where you are coming from, but presets will give you the same
>>> result, no?
>> Apart from what we discussed on this thread with Martin about the "/etc"
>> clutterness having distro-specific information and not only system ones,
>> right.
>>
>> However, this is kind of a complex case in D/U where we have the policy to
>> start most of the service on package installation. For instance, if you apt
>> install docker.io, people using those distros will expect to be then able to
>> do $ docker run <…> (which starts the docker service through socket
>> activation).
> Hm, not following this last paragraph. Are you saying we are missing
> something to do with start-on-install?
Not at all, I was just presenting the difference between Fedora and D/U 
policy for instance, the result with preset will be, as Colin mentioned to:
enable *
disable unit1

The thing I'm afraid of that we won't have a single place to list all 
disable units, and they will be in multiple packages, so (as I'll repeat 
below), I'm unsure that we would able to only load the preset as once 
shot, as we may add some preset files as part of packages later on with 
the current structure (to disable more units by default).

>
>> This would be maybe a nice way for the admin to know what's coming from a
>> distribution default or not. However, let's say I want to ensure that ssh
>> will always be available on my server, I would (even if it's in my server
>> preset) then systemctl enable openssh, no matter whatever future preset
>> updates does (like disable it in the next batch upgrade).
>>
>> With a shared distro/admin /etc, we have no way to take that fact into
>> account and the next one would follow distro policy, right?
>> Also, after running systemctl enable opensshn, systemctl status openssh will
>> still say "enabled (preset)" even if the admin wanted to "stick it for good"
>> as it's part of the preset.
> This is up to the distro I guess, but I would have thought that
> presets should only be applied on install-time, and not on upgrade.

You mean system install time, right? Having it one shot would be more 
complex in our case I think as stated above (I guess, we'll have the 
disable distributed in multiple packages, not all being installed by 
default).
>
>>>> - systemctl enable <unit> will duplicate the symlink in /etc
>>> I guess this should also be dropped (though the situation here is
>>> weird as it anyway is a noop). Maybe a warning should be printed.
>>
>> agreed as well, or, this would be a way for the sysadmin to "stick" this
>> unit/service whatever future distro will choose in the next upgrade.
> Could be, yeah, but moving from static to opt-in during an upgrade
> sounds like a packaging bug to me, so hopefully this situation would
> never be encountered in production.

It should not happen in production, indeed, but packaging errors happen 
and we should maybe be able to recover without having impacts on admins 
who systemctl enable this unit in particular for their needs?
>
>>> Well, the meaning we have been using so far is that statically enabled
>>> units are things that does not really make sense to disable (which is
>>> different from it being enabled by default), and for all other units
>>> the way to enable/disable them (be it by default or manually) is by
>>> installing symlinks in /etc. If the admin wants to insist to ignore
>>> the "does not make sense to disable part" and really force something
>>> to never start, then masking is the tool for that. Either way, the
>>> admin should never (need to) go poking in /etc manually, but use
>>> systemctl as the interface.
>>
>> Indeed, I'm getting where you are coming from now and see the real
>> difference you mean with default symlinks in /usr. However, it would seem
>> weird to me to have to systemctl mask plymouth-quit.service for instance
>> without knowing the internals of systemd to be able to really "disable" (I
>> know the term is wrong, just trying to feel how they could interprete it) a
>> certain class of units.
> Hm, I didn't follow this paragraph, could you rephrase?

I hope this will be a little bit more clear:
Let's say as an admin that I want to disable plymouth-quit.service 
(which is a static unit file and symlinked in /usr/lib… on the 
multi-user target). Without knowing the systemd internals, my natural 
intent would be to use "systemctl disable plymouth-quit.service" which 
is no-op in this case on a static unit enabled on the multi-user target 
with the symlink shipped by the package. This may be perceived as 
unnatural to him to have to use "systemctl mask" to disable it, or am I 
just being too pessimistic?

>
>>> My take on this is: make sure presets are applied on "firstboot"
>>> (which I think they are), so empty /etc works just fine, and then
>>> improve on systemctl to better show the distinction between 'enabled
>>> by default' or 'enabled by choice' (and same for 'disabled').
>>
>> Thanks again for your feedback. If the whole proposal is rejected, I think
>> we'll try to have debian following this as a first step.
> Sounds good, but let's see if maybe Zbigniew or Lennart have any
> comments on your proposal (if my memory serves me right they did most
> of the work in this area).

Sure! Thanks again for your feedback :)

Cheers,
Didier