|Line 2:||Line 2:|
== Summary ==
== Summary ==
So far, whether a service is enabled or disabled after package installation is encoded in the %post scripts of the RPM, and decided globally for the entire
So far, whether a service is enabled or disabled after package installation is encoded in the %post scripts of the RPM, and decided globally for the entire , ignoring the particular needs of spins. With the introduction of "presets" we'd like to remove this policy from the packaging scripts and place them in explicit "preset" files instead which can be different for the various spins, and even for systems.
== Owner ==
== Owner ==
Revision as of 18:31, 1 November 2011
Package Service Presets
So far, whether a service is enabled or disabled after package installation is encoded in the %post scripts of the RPM, and decided globally for the entire distribution, ignoring the particular needs of spins. With the introduction of "presets" we'd like to remove this policy from the packaging scripts and place them in explicit "preset" files instead which can be different for the various spins, and even for individual systems.
- Name: Lennart Poettering
- Email: lennart at poettering dot net
- Targeted release: Fedora 17
- Last updated: 11-11-01
- Percentage of completion: 25%
Starting with Fedora 16, systemd's "systemctl" command supports a verb "preset" that is used in a similar way to the well-known "enable" and "disable": "systemctl enable foo.service" causes a service "foo.service" to be enabled according to the installation information in the service file. "systemctl disable foo.service" undoes this work and disables a service. "systemctl preset foo.service", otoh acts either as equivalent of the former or of the latter, depending on information stored in preset files in /lib/systemd/system.preset/. In this directory a number of simple text files may be stored, consisting of lines such as "enable avahi-daemon.service", "disable rsyslog.service" and suchlike. There's support for wildcards, which can be used to match multiple units at once (useful for example for services which need both a .service and a .socket file) and for setting a global default.
Fedora will ship one default file /lib/systemd/system.preset/fedora.preset (maintained in fedora-release.rpm or so), and each spin another file like that on top. Files are read in alphabetical order, and the first matching line matters thus allowing spins to override the global fedora defaults. In addition, administrators can easily apply their own policy. For example, if they want a Debian-style "enable all" policy, they can easily do that by doing "echo 'enable *' > /etc/systemd/system.preset/fedora.preset".
For further details on this, see:
A subproject of this feature is to provide generic RPM macros for the usual %post scriplets which do the enable/disable correctly using presets.
Benefit to Fedora
The lifes of Fedora spin maintainers become much easier: by dropping in a spin specific preset file they can override vanilla fedora policies.
The lifes of package maintainers become much easier: by using the RPM macros the .spec file code is simplified a lot. Also, as the RPM macros will be shared with other distributions porting .spec files between distributions will be much easier.
Administrators can deploy their own policies overriding the Fedora defaults. For example, an admin with a Debian background can trivially enable Debian-style "always on" policy on a Fedora system.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=630174 as admins can easily return to fedora defaults with the enable/disable status of services, by executing "systemctl preset" on the services in question.
The overall design is much cleaner, as mechanism in the RPM scriptlets is cleanly seperated from policy in the systemd preset files.
systemd needs to be patched to support presets (DONE)
Generic RPM macros for applying preset information in %post (replacing the current scriptlets for enabling services on %post) need to be written (There's work from SUSE in this direction we can base our stuff on). This RPM macro should for the beginning live in systemd, in order to make it easy to share it between distros.
The packaging policy needs to be updated in order to recommend usage of the macros instead of the scriptlets.
Some core package needs to be updated to include the default fedora preset file which lists the very few services that may be enabled by default according to the current policy for "enable" and "disable *" to disable the rest. Probably should be fedora-release.rpm or a similar file.
Optional: the various spins should be updated to include their own preset files.
Optional: the existing packages using systemctl enable/disable in the RPM scriptlets should be updated to use the new macro and thus honour the presets.
How To Test
After a default installation use "systemctl list-unit-files" to determine that only those services that are mandated by the policy are enabled, nothing else.
Drop in "enable *" in /etc/systemd/system.preset/fedora.preset and ensure that all packages enable their services by default from then on.
The user should not notice any difference, except when he is aware of the preset feature and decides to make use of it.
The package policy needs to be updated, in addition to the fedora-release.rpm.
If package .spec files that have been upgraded to use the macro just revert back to invoking systemctl enable/disable directly everything should be fine again.
There are man pages, but it's terse. This is the most relevant documentation:
There's probably no mentioning necessary for this.