I'd like to hear some feedback on the proposal below so that we can pass it on to the systemd developers, Andreas ---------- Forwarded Message ---------- Subject: [systemd-devel] [RFC] Preset Files Date: Tuesday, July 05, 2011, 21:21:03 From: Lennart Poettering <lennart@poettering.net> To: systemd Mailing List <systemd-devel@lists.freedesktop.org> Heya, many of you probably saw Frederic's rpm macros suggested here. This got Kay and me thinking about implementing something like "presets" in systemd, and before we go and implement that we'd like to hear your opinions on it. This would go hand in hand with Frederic's macros, and both would be included in the upstream systemd package. So what's a "preset" supposed to be? Distributions have different policies on enabling services by default. On Fedora services should default to off, with a small number of exceptions. On Debian OTOH all services are enabled by default. Fedora spins in turn are based on the default Fedora settings but might end up enabling a few services not enabled on the unflavoured Fedora. In general, on desktop systems (i.e. without an educated admin) a default of "enable what is installed" probably makes sense, while many seasoned admins will probably opt more towards the other extreme: "I, the admin am king, and I am the only one enabling services here!". Both approaches of course are valid approaches. Now, traditionally whether a service was enabled or not on most distros was encoded in the packages themselves (i.e. in chkconfig in lines in the scriptlets, or something equivalent), which makes it very difficult to apply spin-specific or admin-specific rules on top. This is information that should not be encoded in the packages, but in some external database. And this is what "presets" are supposed to be. Something like a long list that tells systemd which services to enable by default and which ones not to enable. It's a bit like a SUSE pattern or a Fedora comps, except that it lists services that shall be enabled instead of package that shall be installed. More specifically this is how it should work: We'd have a directory /lib/systemd/system.preset/. By default it would be empty (or not even exist), which for simplicity reasons would mean "enable everything installed" (i.e. the Debian policy). Then, if distros or spins want to change what is enabled by default, they'd drop in a file (or multiple, which might be useful for a desktop spin and a graphical design spin where the latter is a superset of the former) in that directory. The file would be a trivial text file with lines like this: <snip> disable avahi-daemon.service enable cups.service disable * </snip> Then, we'd add a new command to "systemctl" called "systemctl preset". It would be equivalent to a "systemctl enable" if the unit file passed is listed in any of the preset files on lines prefixed with "enable", or be like a "systemctl disable" if it is listed with a prefix of "disable". Simple globbing would be supported. If no entry is found "systemctl preset" would be synonymous with "systemctl enable". If "systemctl preset" is passed with unit names, those units would be enable/disabled as listed in the preset file. If no argument is passed all units would be reset to the preset defaults. (another long-sought feature...) A few more things to note: - systemd would not ship any preset file by default (and probably not even the directory), this is left to distributions. Most likely the distributions would ship a preset file in some spin-specific RPM, which would conflict with the the RPMs for other spins. - The RPM post macro would always call "systemctl preset" for the units passed, and never anything else. - If an admin wants to manually change "enable-by-default" to "disable-by-default" (or vice versa) he could just drop his own file with "disable *" (or "enable *") into /etc/systemd/system.preset/ and override the vendor/spin settings. - One nice thing is that this would be dead simple to implement (just 10 lines of code or so), and would practically not be visible on systems who don't need any distro spin crack... ;-) - This would kinda bring back the ability that some SysV implementations had with encoding the default enable/disable state for a service somewhere. Some distros had that in the SysV header. With this we now have it independently of the init scripts. - The reason why we'd implement "enable-by-default" instead of "disable-by-default" if no preset file is around is simply the idea that having to install stuff that is not needed is already a failure in itself, and ideally people who want to disable a service would just "rpm -e" it. Anyway, this of course requires some buy-in from the distributions, so I'd like to ask the distro maintainers for comments on this. Do you think this would be useful to you? Any other suggestions, ideas? Note that even if we implement this in systemd (which is very likely) it is of course up to the distros to make use of this. If they still want to enable (or disable) all services unconditionally then they can still do so in RPM scrips, but we'd of course greatly welcome if distros would support this new scheme instead of cooking their own. Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ----------------------------------------- -- Andreas Jaeger, Program Manager openSUSE aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org