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

[Didier Roche]

Le 18/11/2014 15:59, Colin Guthrie a écrit :
> Hiya,
Hey,
> Didier Roche wrote on 18/11/14 13:58:
>> 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).
> For the avoidance of doubt, I believe that running systemctl preset
> should only ever happen on *first* install, never on upgrade or such like.
>
> This also avoids any problems here.
>
> (Of course if /etc is nuked, then reapplying the defaults from *.preset
> should be done!)

See my Michael's answer (and my previous one) on the fact that maybe the 
preset files would be part of multiple packages (to disable certain 
units), and some being only part of packages not installed by default.
Michael's case as well of a unit changing its target on a package 
upgrade (as a packaging fix, maybe) is valid as well.

>
>> 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?
> Yeah, but that's assuming there *is* a next one. Once things are
> installed, the user should *not* be surprised by any action being taken
> without their consent on upgrade.
>
> FWIW, it's probably worth considering how you'd handle not changing
> users current preferences with regards to enabling/disabling things on
> upgrade. I can see this being quite hard for you roll out with your
> current suggestions, but you may have this covered already.

Actually, this reminds me some issues we had with gconf in the past in 
changing distribution's default and deciphering what was users current 
preference or what was distro default behavior.
Gnome-panel was copying its whole distro defaults in ~/.gconf. 
Adding/removing some default layouts and settings from the panel was 
then unnecessary difficult. Some changes was part of new default 
behaviors we wanted that the user never interacted with and was desired 
to be changed (because of some applets getting low maintenance, 
incompatible with newer technology or duplicates…)
As everything was at the same place, it was difficult to know if the 
current value was set because of the previous default, or if the user 
explicitly tweaked and then selected it.

I see the same issue with the shared /etc: is this unit enabled for that 
target because of one the preset config, or did the admin run "systemctl 
enable <unit>" explicitly and want to keep it? I think it's ok to change 
distro defaults on upgrade (will be potentially in major version upgrade 
of course), not user (admin here) preferences, of course. But we do have 
no way to know for sure which is which in the current system.
>
>> 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.
> Not sure what you mean by "stick it for good" here, but my previous
> suggestion was to say "enabled [preset: enabled]" or "enabled [preset:
> disabled]" accordingly which might be clearer (if a bit longer).

Same than in previous case:
I have a preset with
enable docker.socket

systemctl status docker.socket
-> "enabled [preset: enabled]"

systectl enable docker.socket
systemctl status docker.socket
-> "enabled [preset: enabled]"

I guess, it should then just be "enabled". Maybe that will then ask for 
a systemctl reset <unit> command or something like that…
>
>>> Doing 'enable' on a preset unit will then just delete the symlink to
>>> /dev/null from /etc (if it exists) and doing 'disable' will add it.
>>> This would also entail changing the current logic to check the target
>>> of /**/*.wants.d/ symlinks to see if they point to /dev/null, in which
>>> case they should be ignored.
>>>
>>> Did I understand that correctly?
>> Right, maybe the implementation can diverge a little bit from that, but
>> the intent would cover most of the admin/distro separation, while
>> enabling sysadmin to "stick" some of the services disregarding future
>> distro choices and keeping a clean /etc.
> Again, just to clarify, the current implementation intends that
> "systemctl preset myservice.service" is only run on the first
> installation of a package, not on upgrades.
>
> There should be no need to "stick" some of the services as distro
> choices are only applied at install time, and never on upgrade.
>
>
>>>> - 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. On IRC it was suggested that
>>>> those are "static" units, but then it should say at least that.
>>> I agree, this should be fixed to report them as 'static' (as any state
>>> in /etc apart from masking is irrelevant).
>> agreed (if we want to keep the current logic of not shipping other kind
>> of units in /usr)
>>>> - 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.
> Just to reiterate, the need for "sticking" a unit is currently not
> needed, so adding this extra layer of complexity in any future changes
> is not something I'd personally like to see. In my mind any package
> presets (or distro choices or whatever we should call it) should only
> apply on first install and not on future upgrades. I don't want to be
> surprised by a change of behaviour on upgrade.

I don't reiterate the same arguments again, but yeah, it seems that all 
consequences of our discussions are based on the preset usage: having as 
a goal on central place installed by default, where we would list to 
disable all existing units that needs to be disabled we have throughout 
the archive, and be future proof for upgrade (like from a distribution 
upgrade which will enable new upstream packages) seems quite hard to 
reach out.
>
> Hope this is useful clarifications.
It does, thanks!

Cheers,
Didier