From Fedora Project Wiki
(Created page with "= Package Presets = == Summary == <!-- A sentence or two summarizing what this feature is and what it will do. This information is used for the overall feature summary page for...")
 
No edit summary
Line 1: Line 1:
= Package Presets =
= Package Service Presets =


== Summary ==
== Summary ==
<!-- A sentence or two summarizing what this feature is and what it will do. This information is used for the overall feature summary page for each release. -->
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 distributions, 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 ==
<!--This should link to your home wiki page so we know who you are-->
* Name: [[User:lennart| Lennart Poettering]]
* Name: [[User:FASAcountName| Your Name]]
* Email: lennart at poettering dot net


<!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or  technical issues need to be resolved-->
== Current status ==
* Email: <your email address so we can contact you, invite you to meetings, etc.>
* Targeted release: [[Releases/17 | Fedora 17 ]]
* Last updated: 11-11-01
* Percentage of completion: 25%


== Current status ==
== Detailed Description ==
* Targeted release: [[Releases/<number> | Fedora <number> ]]
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.
* Last updated: (DATE)
 
* Percentage of completion: XX%
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:


<!-- CHANGE THE "FedoraVersion" TEMPLATES ABOVE TO PLAIN NUMBERS WHEN YOU COMPLETE YOUR PAGE. -->
http://lists.freedesktop.org/archives/systemd-devel/2011-July/002830.html


== Detailed Description ==
A subproject of this feature is to provide generic RPM macros for the usual %post scriplets which do the enable/disable correctly using presets.
<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->


== Benefit to Fedora ==
== Benefit to Fedora ==
<!-- What is the benefit to the platform?  If this is a major capability update, what has changed?  If this is a new feature, what capabilities does it bring? Why will Fedora become a better distribution or project because of this feature?-->
 
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.


== Scope ==
== Scope ==
<!-- What work do the developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
 
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 ==
== How To Test ==
<!-- This does not need to be a full-fledged document.  Describe the dimensions of tests that this feature is expected to pass when it is done.  If it needs to be tested with different hardware or software configurations, indicate them.  The more specific you can be, the better the community testing can be.


Remember that you are writing this how to for interested testers to use to check out your feature - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your feature.
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.


A good "how to test" should answer these four questions:
Drop in "enable *" in /etc/systemd/system.preset/fedora.preset and ensure that all packages enable their services by default from then on.
 
0. What special hardware / data / etc. is needed (if any)?
1. How do I prepare my system to test this feature? What packages
need to be installed, config files edited, etc.?
2. What specific actions do I perform to check that the feature is
working like it's supposed to?
3. What are the expected results of those actions?
-->


== User Experience ==
== User Experience ==
<!-- If this feature is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice. -->
The user should not notice any difference, except when he is aware of the preset feature and decides to make use of it.


== Dependencies ==
== Dependencies ==
<!-- What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this feature depends?  In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate?  Other upstream projects like the kernel (if this is not a kernel feature)? -->
The package policy needs to be updated, in addition to the fedora-release.rpm.


== Contingency Plan ==
== Contingency Plan ==
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "None necessary, revert to previous release behaviour."  Or it might not.  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. -->
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.


== Documentation ==
== Documentation ==
<!-- Is there upstream documentation on this feature, or notes you have written yourself?  Link to that material here so other interested developers can get involved. -->
There are man pages, but it's terse. This is the most relevant documentation:
*
 
http://lists.freedesktop.org/archives/systemd-devel/2011-July/002830.html


== Release Notes ==
== Release Notes ==
<!-- The Fedora Release Notes inform end-users about what is new in the release.  Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ -->
There's probably no mentioning necessary for this.
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns.  If there are any such changes involved in this feature, indicate them here.  You can also link to upstream documentation if it satisfies this need.  This information forms the basis of the release notes edited by the documentation team and shipped with the release. -->
*


== Comments and Discussion ==
== Comments and Discussion ==
* See [[Talk:Features/YourFeatureName]] <!-- This adds a link to the "discussion" tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page -->
* See [[Talk:Features/PackagePresets]]  
 


[[Category:FeaturePageIncomplete]]
[[Category:FeaturePageIncomplete]]

Revision as of 18:29, 1 November 2011

Package Service Presets

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 distributions, 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

Current status

  • Targeted release: Fedora 17
  • Last updated: 11-11-01
  • Percentage of completion: 25%

Detailed Description

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:

http://lists.freedesktop.org/archives/systemd-devel/2011-July/002830.html

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.

Scope

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.

User Experience

The user should not notice any difference, except when he is aware of the preset feature and decides to make use of it.

Dependencies

The package policy needs to be updated, in addition to the fedora-release.rpm.

Contingency Plan

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.

Documentation

There are man pages, but it's terse. This is the most relevant documentation:

http://lists.freedesktop.org/archives/systemd-devel/2011-July/002830.html

Release Notes

There's probably no mentioning necessary for this.

Comments and Discussion