On Fri, 06.02.15 18:29, Didier Roche (didro...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
