[systemd-devel] [PATCH] preset-transient

[Lennart Poettering]

On Fri, 06.02.15 18:29, Didier Roche (didrocks at ubuntu.com) wrote:

> Le 05/02/2015 17:11, Dimitri John Ledkov a écrit :
> >Some context for this patch.
> 
> Hey Dimitri, thanks for working on that. I'm just giving a broader context
> for everyone who followed the past discussion we had in december/january.
> 
> This is a followup on our discussion and what we discussed on the "/usr vs
> /etc" email thread (to give the full context).
> >
> >I would like to support a new preset model, which has the following properties:
> >
> >  - distribution shipped defaults are enabled
> >  - and are applied to each boot/upgrade
> >  - without overriding any user configuration
> Said differently, the Debian/Ubuntu needs are that distro defaults are
> migrated. We would prefer an upstream solution for this than the current
> cache implementation by our install helper tools that Dimitri described
> below.
> We should be able to handle defaults per flavors in the ubuntu case
> (meaning, alternatives are respected, with a priority order based on
> filename), admins should be able to disable services that are enabled by
> default on the distro and admins overrides are always respected, even if the
> distro changed its default policy for a service from disabled to enabled or
> the contrary.
> 
> We need for this to work the /dev/null symlink in /etc patch to disable
> known services that was discussed in the previous thread and agreed on.
> 
> From the past discussions and during the hackfest, we agreed that presets
> were the way to go forward, but with slight changes that Dimitri explains
> below.
> 
> >
> >In many ways it is very similar to existing functionality but not
> >quite possible to achieve all of the above.
> >
> >Thus, I'm introducing a new optional functionality, new unit
> >configuration directory, and new transient-preset configurations.
> >
> >On each boot, if TransientPreset=yes, presets from
> >/usr/lib/systemd/system-preset-transient/*.preset are applied into
> >configuration path /run/systemd/system-preset-transient/.
> 
> Hum, we told at the sprint that we wanted to be that available for everyone,
> and not having any conditions. Distros which still desires only the existing
> behavior would not ship files in *-preset-transient directories.
> 
> >
> >An upgrade tool, sysadmin can repeat that action at appropriate points
> >by also calling: systemctl --runtime preset-all.
> 
> This command is only for sys admins, on package upgrade/installation/removal
> (having units file or a new preset file), we would call as a trigger
> systemctl --daemon-reload, which then, would purge the transient runtime
> directories and reapply needed changes.
> 
> >
> >If distribution integrates usage of Transient Presets, it gains a few
> >very nice properties. Fresh installations, much upgrades. User/admin
> >modifications are preserved. And there is no additional logic required
> >to maintain separation / diffs between system-defaults and
> >user-modifications. At the moment distributions like Debian (where
> >most things are enabled by default) maintain a complex state in /var/
> >which tracks which things were distro-enabled before/after the
> >upgrade, as well as whether user/admin has disabled/enabled things
> >before/after the upgrade and try hard to correctly reconcile the
> >correct state for all units. However, with this patch, most of this
> >segregation moves away.
> 
> We discussed first that this could have gone in /var (this transient layer
> state is under our control) so that it's not called at every boot, however,
> /var isn't required at this very early stage to load units from systemd.
> We would like to not add those in another /etc directory on the broader goal
> of "empty /etc by default".
> >
> >The remaining part, which is not addressed in this patch series, yet,
> >is the ability to override .wants/ symlink from a higher order
> >configuration directory. That is if the following symlinks are present:
> >  /etc/systemd/system/foo.service.wants/bar.service -> /dev/null
> >  /usr/lib/systemd/system/foo.service.wants/bar.service -> ../bar.service
> >There is no wants dependency added from foo.service -> bar.service.
> >This bit is discussed in details and agreed upon on the mailing
> >list. (Unwants thread has urls to the messages)
> >
> >Regards,
> >
> >Dimitri.
> >
> >Dimitri John Ledkov (1):
> >   Add support for transient presets, applied on every boot.
> >
> >  man/systemd-system.conf.xml |  1 +
> >  src/core/main.c             | 30 +++++++++++++++++++++++
> >  src/core/system.conf        |  1 +
> >  src/core/unit.c             |  2 +-
> >  src/shared/install.c        | 59 ++++++++++++++++++++++++++++++---------------
> >  src/shared/install.h        |  2 +-
> >  src/shared/path-lookup.c    |  2 ++
> >  7 files changed, 76 insertions(+), 21 deletions(-)
> >
> 
> 
> Right now, I think that we shouldn't have a configuration flag for it, this
> should apply (as stated above) to any setup, and distros can opt in or out
> just by shipping those transient preset files.
> 
> It seems to me that this code has some flaw on first boot: As no preset file
> (not in the transient directory) is comparable to "enable *", that would
> mean that on a freshly installed system (without a /etc/machine-id file),
> systemd is going to apply systemctl enable on all services before the
> transient preset, and thus, will create enablement symlinks in /etc for
> every services available with an Install stenza on the system.
> 
> I guess the condition should rather be: have an implicit enable * for
> permanent preset if there is no transient preset files detected.
> 
> Does it make sense?

Yeah, something like this would make sense.

> Another opened question: (to me, the answer should be yes): should we have
> user-transient-preset as well so that we can have the same behavior and
> options for user-level systemd management.

We currently do not have such a concept for applying user preset files
on "first logins" in place, but I figure that might actually make sense.

Lennart

-- 
Lennart Poettering, Red Hat