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

[Lennart Poettering]

On Tue, 02.12.14 12:50, Didier Roche (didrocks at ubuntu.com) wrote:

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

Hmm, I am pretty sure interactive updates are a bad idea. But then
again, I know that Debian likes them.

I think, if you install something new that conflicts with something
installed, then you should enable it if the policy says so and if the
existing package isn't enabled already. But if it is already enabled,
or if the policy says no, then leave it alone.

If you really want an UI in the mix here, I'd recommend just altering
the symlinks directly. (I mean, altering the symlinks manually is
completely OK. systemctl enable/disable/preset is simply supposed to
be a nicer helper there, but in no way should be the exclusive way to
access them).

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

Hmm, this is actually undefined currently. THe code for preset-all
iterates through the unit paths and processes the files in the order
they are read by readdir(), which is pretty much undefined. We really
should investigate what to do about that. Probably just order things
lexicographically. I added this to the TODO list for now.

> >>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 overrides the lightdm line, and enables
> >gdm instead).
> 
> You meant disable, right? As our default is to enable all services.

Yeah, "overrides" meant disabling.

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

Hmm, indeed I guess...

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

Hmm, yuck. No good suggestion. I figure this problem doesn't exist
with the fedora default of everything is disabled by default...

All open to ideas...

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

Yeah, not sure how you can provide that with the scheme we devised
there in systemd. Sorry!

All ears for ideas...

> So, I think we should really be able to fix case I. 

I mean, you can fix case I, by explicitly storing the state away
before you remove a package.

How does this all precisely work on sysvinit?

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

Hmm, not following? .deb packages scriptlets can determine if they are
running on first install or on upgrade, right? So you can invoke
"systemctl preset" in the first case only, right?

Lennart

-- 
Lennart Poettering, Red Hat