[systemd-devel] [PATCH] preset-transient

[Dimitri John Ledkov]

On 11 February 2015 at 20:49, Lennart Poettering <lennart at poettering.net> wrote:
> 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.
>

Noted for the rework.

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

Future TODO, as it is out-of-scope for my current focus in this patch series.

-- 
Regards,

Dimitri.

Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.