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

[Colin Guthrie]

Hiya,

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

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

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

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


Hope this is useful clarifications.

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/