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

[Didier Roche]

Just to sum up other branches of this thread: we are trying to avoid 
having systemctl calls in debian/ubuntu postinst (or duplicated manual 
symlinks logic as we currently have).
systemctl preset seems the cleanest path, but we want to ensure corner 
cases can be handled.

d/u policy is to enable newly installed package by default (difference 
from other distributions)

Le 02/12/2014 01:59, Lennart Poettering a écrit :
> On Fri, 28.11.14 11:15, Didier Roche (didrocks at ubuntu.com) wrote:
>
>> 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).
> "systemctl preset" will fail if there are already conflicting
> symlinks. Hence the first installed DM wins, the second loses.

Ok, that works with the initial install case then.
However, if lightdm is installed and the admin install gdm, he will get 
a prompt (from postinst) asking him which dm to choose. How would you 
handle that (without messing manually with the symlinks or systemctl 
enable --force in the postinst?). Writing new presets in /etc which 
enables the chosen dm and disable other, then reloading preset file to 
reset that display-manager.service alias?

>
>> 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?)
> Dont follow? "wipe"?

I meant deleting the entire "/etc" content (or I guess as you told using 
systemctl preset-all to reset to default):

1. lightdm and gdm were installed on my system.
2. gdm was enabled as the default display-manager.
3. I then use "systemctl preset-all"
-> how the behavior of selecting the display-manager will be determined? 
See below implementing this with presets where enabling all services is 
the default.
>
>> 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)?
> Not following here. Different flavours of Ubuntu should probably just
> ship different preset files. (Or well, the main ubuntu should ship one
> that enables lightdm, and then the gnome flavour ship another preset
> file, with a lower name, tht overries the lightdm line, and enables
> gdm instead).

You meant disable, right? As our default is to enable all services.
So we need for any services shipping Aliases to have a preset list per 
flavor (if their behaviors differs) with:
99-ubuntu-desktop.preset:
enable lightdm.service
disable kdm.service
disable gdm.service
disable nodm.service
(and whatnot… dm files in distro)

Then, we would have 01-ubuntu-gnome.preset:
enable gdm.service
disable lightdm.service
disable kdm.service
…

It seems maintaining this list in sync for all flavors would be a 
growing pain (this is a positive effect of the disable by default: you 
don't have to maintain such a list), or do you think we can come with 
something better?


Finally, on the "know what the administrator did on this machine", here 
are two cases that we can identify:

I. if the administrator removes the service package, we usually keep 
current service state (enabled/disabled) on reinstall.
So:
<foo.service> enabled by default
1. systemctl disable foo.service
2. apt-get remove foo
3. apt-get install foo
-> foo should still be disabled. However, that won't be the case as on 
reinstall, systemctl preset will re-enable the service as of the preset 
policy.
Indeed, we don't have any record that the admin disabled it compared 
default distro policy as there is no difference between: "no previous 
installation state" and "service being disabled state" (no symlink).

Same for enabling a service that is by default disabled: next systemctl 
call on reinstall will remove the symlinks (Alias included).


II. if the adminstrator purges the service package, we usually expect 
that reinstalling it will reset the service to the default 
enablement/disablement state.
So:
<foo.service> enabled by default
1. systemctl disable foo.service
2. apt-get remove --purge foo
3. apt-get install foo
-> foo should be enabled as this is the default state in distro.
This use case works because the previous one doesn't :)

So, I think we should really be able to fix case I. Also, we would have 
to condition the systemctl preset call (we have idempotent postinst 
script, and need to track new installs from upgrade, as we run those 
during postinst configure). We proposed the separate /usr vs /etc as 
this would have been a simple way to know what the admins changed 
compared to the default. Any idea on how we can solve that with the 
existing concepts?


Cheers,
Didier