Hello Colin, all, Colin Guthrie [2014-11-18 11:30 +0000]: > I believe that it is generally discouraged to use "systemctl enable" > indirectly or otherwise during postinst.
Right, I don't like this either, hence this discussion. :-) I don't know whether Debian's current way of enabling units on package install has ever been discussed here, but Didier and I would like to understand the options and some recommendations, to consider whether it makes sense to change this in D/U. > You should instead use systemctl preset which uses information in > various distro provided *.preset files that contain rules for which > units should be enabled or disabled. > > This allows a "default" /etc tree of symlinks to be repopulated easily. We can certainly ship a preset of "enable *" to reflect the policy that in general services do get enabled by default. But this still leaves some issues: * I suppose even wich such a policy the post-installation script still needs to call some systemd-update-policy-mumble-mumble magic to actually apply the new policy? * With that, how would a package then say that it does *not* want a particular unit to get enabled? * This doesn't solve the problem of having these rather uninteresting and cluttering symlinks in /etc at all; the wants.d symlinks would still be as they are now, just the place that decides when to enable them changes. > If a package ships a unit enabled via a symlink in /usr/lib, then that > same package should ensure the systemd unit does NOT have an [Install] > section. > > Doing so is confusing to the user, so if the packager makes this > decision, he should follow it through properly. But then you would entirely lose the information into which target a service belongs by default. In particular, an administrator couldn't override the default it with "systemd disable" (I know that this doesn't work right now, but it's part of the discussion). > If this is an upstream make-install rule, then it should be fixed > upstream to make it consistent - again the rules is "if you ship a > symlink in /usr/lib, you should not have an [Install] section" (I think > this is good advice but I'm sure someone will correct me if I'm wrong!). I think there are some plymouth .service files with that problem, but as far as I can see, most upstreams leave it to packagers to enable their units. > > - Wrt. the "golden image, /etc reset" approach of reducing base os > > installation defaults in /etc, this is another instance of "always needs > > to be there" clutter in /etc. If the package default is to start the > > service, then it's better to just ship that wants.d/ symlink in the > > package (and thus in /usr) instead of always having to create the > > symlink in /etc at package install time or after a factory reset. > > Yes and no. Depending on your use case perhaps shipping it in /usr/lib > is OK (e.g. an embedded system that still wants to support factory > reset), but I'd say that generally speaking, this is what *.preset files > and systemctl preset is meant to achieve. They represent the distro > rules, but still give users full control after the default rules are > applied. I might misunderstand presets, but as I wrote above they don't address this at all -- even with them you have preset-induced wants.d/ symlinks in /etc. I. e. my question is not so much about being able to restore the default wants.d symlinks in /etc after a factory reset -- there are multiple ways how this can be done: with presets or iterating over the installed packages and re-enabling them (Debian also does some house-keeping which unit files got enabled by postinstall scripts, which can simply be replayed). I was rather wondering whether we couldn't make all that post-processing much simpler by not requiring any /etc/**/wants.d/ links at all. And everything which *is* in /etc/**/wants.d/ would then be explicit admin choices, with both enabling and disabling units. > > - We are mixing sys admin information and distro default choices in the > > same directories, and can't tell apart what is what. > > /etc is admin, and the distro *default* is applied there (via *.preset > files) but the admin still has full control. Sure she does, but this still makes it waaay harder to see on a system how it deviates from the default install. > 1. Discourage strongly the shipping of enabling symlinks in /usr/lib > (but aliases are probably OK). I'm interested in the reason for that. This basically cements the status quo that one *has* to have a gazillion links in /etc in order for your system to work, even if they are not at all specific to the particular system or represent a deviation from the default install. > 2. If a special case arises where a an enabling /usr/lib symlink is > deemed the best option, the unit must not have an [Install] section. I rather want to discuss this in the general case, to reduce the clutter in /etc/. I don't think it's right to remove [Install] for all units, see above. > 3. Do not use "systemctl enable myunit.service" (directly or indirectly) > in packaging postinst, but rely on "systemctl preset myunit.service" > instead to capture the distribution (or spin) rules. That part is fair enough, and we can see whether that should be done in Debian, but in practice it will make absolutely no difference wrt. file system layout, cleaning up /etc/, and making admin choices more obvious. > This deals means: > > 1. distro installs the default setup for users, but admins can override > later > 2. factory reset works fine (assuming "systemctl preset-all > --preset-mode=enable" is run after reset) > 3. systemctl status will work (because only units without [Install] > sections will have enabling links in /usr/lib) I fully agree on these properties; your recommendations from above (which is essentially the status quo) certainly works for that, but I really think we can do better here. With our proposal these properties would also be satisfied, except with no churn in package install (systemctl enable or preset), initialization of a system with empty /etc/, and cleanliness of /etc. Thanks, Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
signature.asc
Description: Digital signature
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
