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

[Colin Guthrie]

Hello again!

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.


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

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



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.


This is an interesting discussion, and I'm looking forward to see what
others think too :)

Cheers!

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/