Hey Colin, thanks for the discussion! Trimming heavily; as you said we should let some other upstreams chime in too, I just have some followup questions.
Colin Guthrie [2014-11-18 13:01 +0000]: > > * 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? > > Well, the *.policy files are simply read when calling "systemctl preset" Right. I meant, even with using presets, a newly installed package still needs to call "systemd preset foo.service" for all the units that it ships, so that the /etc symlinks are generated. I. e. we merely replace "enable" (what the current Debian packages do) with "preset" in the postinst. We need to do that as systemd doesn't automagically spot newly installed units (via inotify or what not) and enable them. Or did I misunderstand this? > The idea is that there are very few policy files shipped in a distro Indeed. A generic distro should have exactly one, with "disable *" (Fedora policy) or "enable *" (Debian policy). Anything more special would be customization for specialized images/spins/etc. > > * With that, how would a package then say that it does *not* want a > > particular unit to get enabled? > > The idea is that you don't really decide that at a package level, but at > a distro level. We do (and that policy drives the auto-generated postinst), but there are always special cases where a package might want to ship a unit which doesn't get enabled by default. I was wondering how that could be accomodated. So for that, the package itself could ship its own preset file, containing a "disable myself.service"? That would make sense (if I understood it right). Either way, this is certainly the rare exception. > > * 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. > > Indeed, but ultimately if you want to make something configurable in > some capacity, you have to put that configuration somewhere and /etc is > the defacto place to put it. Fully agreed. Any admin change should go into /etc. My point is, distro/package defaults should *not*. > But I'd say that if you, as a vendor, are shipping an enabling symlink > in /usr/lib in the first place, you're making a concious decision that > this is something you don't generally want an admin to override easily. > The admin only really has the choice of masking it. Yeah, that's not what I had in mind. I want to keep the interface and notion of enable/disable for admins, just implement the representation of these choices differently in /etc/ (i. e. just represent the admin changes, not distro defaults plus admin changes). > I think moving enabling symlinks into the packages (and thus /usr) has > several drawbacks: > > 1. It pushes decision making on such policy to be distributed through > thousands of packages rather than being centralised and thus makes it > very difficult to do respins and change such policy centrally. Right, this can't be done with Debian ATM as postinsts use systemctl enable. Moving to preset would fix that part. So, thanks again for pointing that out, this is something that we should do, independently of the (totally orthogonal) discussion of how to treat wants symlinks in /etc/ vs. /usr. > 2. It makes the packaging task more complex - these links have to be > created during packaging (although I'm sure this could be mostly automated). Yeah, it is. > So I guess my reply to this is, this is OK, and I think this goal is not > one to aim for. It's "state" information and it should be represented in > /etc and I don't think trying to reduce this is a good idea (personally!) :) Okay. I was wondering if that was merely an oversight, or if there are people who actually want it the way it is currently. Here is the answer :-) > Perhaps teaching systemd-delta or systemctl status to show you the > preset state would solve this problem? e.g. if it showed something like: > > > [colin@jimmy log (master)]$ systemctl status sshd.service > ● sshd.service - OpenSSH server daemon > Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled > [preset: disabled]) > > Perhaps that would help? That would certainly help already, as then admins would have *a* way to check what was changed in the system. > Well, I really think that pushing policy down to the package level is a > real backward step. I mean, it's one of the main principles that the > systemctl preset feature was developed to *avoid* in the first place! Indeed! I think the current packaging scripts in Debian still date from the time when presets didn't exist, so systemctl enable is all we had. Thanks, Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel