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

[Didier Roche]

Le 21/11/2014 12:08, Colin Guthrie a écrit :
> Hello again!

Hey, trying to revive the topic :)
>
> Didier Roche wrote on 18/11/14 15:40:
>> 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.
> I think the distro-wide preset usage would be in a very core package
> that is likely installed very early on (perhaps even the package is
> required by the one that ships systemctl and thus has to be installed
> first).
>
> If you end up shipping random .preset files with the actual packages
> containing the units they affect (which isn't recommend as previously
> noted, but perhaps you still want to do it that way for some special
> cases) then this too will be fine.
>
> I can see some complications here but nothing that isn't manageable.

This is a good news.
>
>
>>>> 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.
> I would personally disagree with this statement that it's OK to change
> the distro defaults on upgrade. As an admin, whether I observe some
> behaviour but do not actively reinforce it (e.g. I see that installing
> httpd enables it by default and thus my server is working fine, so I
> don't need to do "systemctl enable httpd" manually) I now rely on the
> distro default. If that was to be changed on upgrade (whether package or
> whole distro), I'd personally be really annoyed!
>
> With the goal of being able to reset things (i.e. trashing /etc) if
> desired, the admin has a pretty good choice to start again with a clean
> slate after a distro upgrade if they so wish. Otherwise I'd very much
> expect my system to retain as much state as possible (whether that may
> have come from a preset or an active choice is, IMO, irrelevant - it's
> how the system was ultimately configured and what the admin now relies
> on) over the distro upgrade process.

That's what we did in multiple cases in ubuntu in particular. I gave in 
previous emails some desktop-related email. Another one I didn't mention 
is when we changed from gdm to lightdm as the default dm, or gnome-panel 
-> unity. If the user selected another dm or another desktop session, we 
keep user's preference, if they switched and then switched back, we keep 
user's preference as well. We migrate to our new defaults if there was 
trace of new user settings.

I guess different settings and policy from different distro, but it's 
clearly something that was always not easy to managed and having a clean 
/etc will go into that direction in my opinon.
>
>> But we do have
>> no way to know for sure which is which in the current system.
> Yeah, I accept this is a limitation of the current system. I guess I'm
> just making the argument that, IMO, this detail doesn't matter as I
> don't see the need to use this information for anything automated anyway.
>
>
>>>> 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…
> Oh right, so you're very specifically wanting to differentiate from a
> systemctl preset call vs a systemctl enable command and somehow
> recording that state somewhere. I guess that makes sense with some of
> your previous comments. Sorry for not seeing that properly!
>
> FWIW, all I was suggesting with adding the preset information into the
> systemctl status would be to report based on current *.preset files as
> to what the preset state would be if it were run now, as if the package
> was freshly installed. I wasn't suggesting the usage of systemctl enable
> be tracked somehow. So the output you simulated above is what I was
> expecting to see anyway :)
>
>
> As noted previously I think it's very wrong to push the enablement
> policy into the individual packages (thus I think using /usr is not an
> option), so I think it would be very hard to actually track this detail
> anyway if both preset info and normal admin info is both stored in /etc
> (that being the alternative to using /usr).

Yeah, in debian/ubuntu, we would mostly have enable * (which is the same 
as having no pragma in the preset file from what I understood) + some 
specific disablement anyway.
However, I was thinking recently about unit alias and how that would 
work. Let's take display managers as an example.

The distribution comes preinstalled with one dm, enable * -> enable it, 
have the Alias=display-manager.service picking the right one.
However, let's say the user installed then another dm, what happens? 
Both will be enabled if we systemctl preset <new_service> (as the 
discussion was to remove our debian enable <service> that was 
conditioned on the postinst). I don't think we should have systemctl 
preset <new_service> running under any condition as a wipe of /etc and 
then "systemctl preset-all" would give a potential different result (I'm 
not even sure how this will work with those alias, the first matching 
the alias wins and get the symlinks?)

We can of course have an ubuntu-desktop.preset which disables all dms by 
lightdm, and an ubuntu-gnome.preset which disables all dms but gdm (and 
having those settings conflicting with each other), but it's seems that 
for every aliases, we need to maintain such a list (as we enable * by 
default)?

Shipping distro defaults enablement symlinks in /usr would enable 
avoiding that (we need to have package conflicts for lightdm-default and 
gdm-default of course), knowing that we will shadow the alias with a new 
symlink in /etc if the admin changes his name for instance.

Without regarding the /etc vs /usr discussion, I really want to 
experiment with presets instead of our systemctl enable package postinst 
snippets (we don't really run that for the record but make manual 
symlinks and store default symlinks in another directory). However, I 
would appreciate some guidance on a smart way to achieve this in those 
kind of complex cases.
It's too late for that change for debian jessie (getting more and more 
frozen), but we can pilot that in ubuntu vivid before pushing it to 
jessie+1).

>
>
>
> But overall, as is the case I'm trying to make, I really don't see much
> value in differentiating the manually enabled vs enabled by preset
> cases. IMO, that information cannot (or rather should not) be used in
> any automated way, although I do concede that it would be "interesting"
> to know this detail as an administrator.

I agree if that was the only one aspect of the problem, the other one 
(where we started this discussion) was a readable /etc/systemd/ and 
really keeping /etc for machine-specific and admin derivations from 
distro. Keeping /usr for the distro, and /etc for the admin (as Lennart 
told in multiple conferences).
>
>
> This is an interesting discussion, and I'm looking forward to see what
> others think too :)

Same from me, I hope we can see other people jumping from there and 
giving their opinions. :)

Cheers,
Didier