On 11 February 2015 at 20:49, Lennart Poettering <lenn...@poettering.net> wrote: > 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. >
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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
