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

[Colin Guthrie]

Martin Pitt wrote on 18/11/14 13:52:
> Hey Colin,
> 
> thanks for the discussion! Trimming heavily; as you said we should let
> some other upstreams chime in too, I just have some followup
> questions.
> 
> Colin Guthrie [2014-11-18 13:01 +0000]:
>>>  * I suppose even wich such a policy the post-installation script
>>>    still needs to call some systemd-update-policy-mumble-mumble magic
>>>    to actually apply the new policy?
>>
>> Well, the *.policy files are simply read when calling "systemctl preset"
> 
> Right. I meant, even with using presets, a newly installed package
> still needs to call "systemd preset foo.service" for all the units
> that it ships, so that the /etc symlinks are generated. I. e. we
> merely replace "enable" (what the current Debian packages do) with
> "preset" in the postinst.
> 
> We need to do that as systemd doesn't automagically spot newly
> installed units (via inotify or what not) and enable them.
> 
> Or did I misunderstand this?

Oh right I see what you mean.

Well the "upstream blessed" RPM way is to call "%systemd_post" macro in
your %post script, but (personally) I don't like this as it makes the
implementation very much embedded into the RPMs so changing the upstream
macro needs a full package rebuild.

In Mageia we do something similar but we shell out to a script instead.
This allows us to replace the implementation without rebuilding all
packages. This is a double edged sword however, as on distro upgrades
we've got to make sure the package we ship our scripts in is upgraded
before we actually do anything.

Longer term, I want to move this to filetriggers. We have been using
filetriggers for a while via an RPM patch and it looks like some kind of
similar functionality will be (at long last) making it to upstream RPM
in the nearish future. I believe .deb supports something like this?

If this is the case, I'd use a filetrigger to spot the
/usr/lib/systemd/system/*.{service,socket,...} units and then call
systemctl preset on them.

I've not yet switched over to this logic yet myself (mainly due to lack
of time to refactor stuff) so I can't really talk from practical
experience yet or highlight any "gotchas" (one thing I do know is that
any service start/reload/restart we may do in %post would have to be
delayed and left to a filetrigger too because we'd have to do this
*after* the call to preset. So I may have to make the current
%_post_service macro just write out some kind of state somewhere to say
"try to start/reload/restart this service" and then process that state
in another filetrigger with the same matching regexp but which runs
later in the %posttrans)

Sorry if that's a bit RPM specific, but I think the same concepts hold
true in .deb.


>>>  * With that, how would a package then say that it does *not* want a
>>>    particular unit to get enabled?
>>
>> The idea is that you don't really decide that at a package level, but at
>> a distro level.
> 
> We do (and that policy drives the auto-generated postinst), but there
> are always special cases where a package might want to ship a unit
> which doesn't get enabled by default. I was wondering how that could
> be accomodated. So for that, the package itself could ship its own
> preset file, containing a "disable myself.service"? That would make
> sense (if I understood it right). Either way, this is certainly the
> rare exception.

Indeed there is nothing stopping that but it's also perfectly valid to
decide this centrally too, and just ship your default.preset file with:

disable myservice.service
enable *

(perhaps the other order is wrong tho' - I can't remember the semantics!)

As this is the rare exception there shouldn't be too much churn on this
and mentioning things in the default policy that are not installed is
perfectly OK (even if it might waste a few extra bits).

The ensures the policy (even with it's exceptions) is still managed
centrally and individual packagers are not encouraged to deviate from
this policy.

But ultimately this is just a "recommendation" and there is nothing
stopping you being a rebel :D


> snipped a bunch of stuff where I was harping on about how things
currently work, ignoring your ideas to change the status quo ;)


>> 1. It pushes decision making on such policy to be distributed through
>> thousands of packages rather than being centralised and thus makes it
>> very difficult to do respins and change such policy centrally.
> 
> Right, this can't be done with Debian ATM as postinsts use systemctl
> enable. Moving to preset would fix that part. So, thanks again for
> pointing that out, this is something that we should do, independently
> of the (totally orthogonal) discussion of how to treat wants symlinks
> in /etc/ vs. /usr.

Cool.


>> So I guess my reply to this is, this is OK, and I think this goal is not
>> one to aim for. It's "state" information and it should be represented in
>> /etc and I don't think trying to reduce this is a good idea (personally!) :)
> 
> Okay. I was wondering if that was merely an oversight, or if there are
> people who actually want it the way it is currently. Here is the answer :-)

It could be as the /etc/ enablement stuff pre-dates the more aggressive
push towards a nice, empty /etc. But that said, the preset stuff was
done pretty early and I do still think it's can achieve a nicely
structured outcome (albeit retaining the links in /etc) without adding
other complications with regards to more complex semantics (and possibly
changing semantics currently deployed) and without pushing more burden
onto packaging.

>> Perhaps teaching systemd-delta or systemctl status to show you the
>> preset state would solve this problem? e.g. if it showed something like:
>>
>>
>> [colin at jimmy log (master)]$ systemctl status sshd.service
>> ● sshd.service - OpenSSH server daemon
>>    Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled
>> [preset: disabled])
>>
>> Perhaps that would help?
> 
> That would certainly help already, as then admins would have *a* way
> to check what was changed in the system.

Seems Tom made the same suggestion 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/