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?
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.
Cheers,
Didier
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
