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...")
 
 
(28 intermediate revisions by 5 users not shown)
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 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.


== 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
 
* Name: [[User:kay| Kay Sievers]]
<!-- 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-->
* Email: kay@redhat.com
* Email: <your email address so we can contact you, invite you to meetings, etc.>


== Current status ==
== Current status ==
* Targeted release: [[Releases/<number> | Fedora <number> ]]  
* Targeted release: [[Releases/18 | Fedora 18 ]]  
* Last updated: (DATE)
* Last updated: 12-08-07
* Percentage of completion: XX%
* Percentage of completion: 100%


<!-- CHANGE THE "FedoraVersion" TEMPLATES ABOVE TO PLAIN NUMBERS WHEN YOU COMPLETE YOUR PAGE. -->
''Note: This is a resubmission of a feature for Fedora 17. In Fedora 17 the feature was declined with a referral to FPC to get the updated spec file scriplets accepted. This has happened now (see: https://fedorahosted.org/fpc/ticket/190 ), but FPC wants the feature accepted by FESCO too. Thus this resubmission. FESCO, please accept this feature, so that this deadlock is resolved, thanks!
''


== Detailed Description ==
== Detailed Description ==
<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
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/99-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/50-foobar.preset". Packages are then updated to invoke "systemctl preset" instead of "systemctl enable" in %post in order to ensure that the preset file is honoured during package installation.
 
For further details on this, see:
 
http://lists.freedesktop.org/archives/systemd-devel/2011-July/002830.html
 
and:
 
http://freedesktop.org/wiki/Software/systemd/Preset
 
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 ==
== 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 new unified 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 which might be useful for desktop installations.
 
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 separated 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 at least) live in systemd, in order to make it easy to share it between distros. (DONE)
 
The packaging policy needs to be updated in order to recommend usage of the macros instead of the scriptlets. (i.e. https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd ; FPC Posted, https://fedorahosted.org/fpc/ticket/190 ; DONE)
 
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 systemd.rpm or a similar file. Basically, the data from https://fedoraproject.org/wiki/Starting_services_by_default needs to be turned into a compliant preset file. (DONE: we now have a basic fedora preset file in system.rpm)
 
Optional (can happen bit by bit over the subsequent releases): the various spins should be updated to include their own preset files.
 
Optional: The desktop live CD should probably ship its own preset file that differs slightly from the vanilla one.
 
Optional (can happen bit by bit over the subsequent releases): existing packages using systemctl enable/disable in the RPM scriptlets should be updated to use the new macro and thus honour the presets.
 
Also note the display manager feature ( https://fedoraproject.org/wiki/Features/DisplayManagerRework ) which will be the first user of this logic. (DONE)


== 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/50-foobar.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.
 
FPC needs to accept https://fedorahosted.org/fpc/ticket/190


== 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. -->
 
*
http://www.freedesktop.org/software/systemd/man/systemd.preset.html
 
http://freedesktop.org/wiki/Software/systemd/Preset
 
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, as the fully benefits for users/admins only appear as soon as the .spec files and spins start making use of this feature, which will probably not happen for F18 right away. In F18 we just want to lay the ground work 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:FeatureAcceptedF18]]
<!-- When your feature page is completed and ready for review -->
<!-- When your feature page is completed and ready for review -->
<!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler -->
<!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler -->
<!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete-->
<!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete-->
<!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process -->
<!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process -->

Latest revision as of 17:11, 7 August 2012

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 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.

Owner

Current status

  • Targeted release: Fedora 18
  • Last updated: 12-08-07
  • Percentage of completion: 100%

Note: This is a resubmission of a feature for Fedora 17. In Fedora 17 the feature was declined with a referral to FPC to get the updated spec file scriplets accepted. This has happened now (see: https://fedorahosted.org/fpc/ticket/190 ), but FPC wants the feature accepted by FESCO too. Thus this resubmission. FESCO, please accept this feature, so that this deadlock is resolved, thanks!

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/99-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/50-foobar.preset". Packages are then updated to invoke "systemctl preset" instead of "systemctl enable" in %post in order to ensure that the preset file is honoured during package installation.

For further details on this, see:

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

and:

http://freedesktop.org/wiki/Software/systemd/Preset

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 new unified 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 which might be useful for desktop installations.

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 separated 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 at least) live in systemd, in order to make it easy to share it between distros. (DONE)

The packaging policy needs to be updated in order to recommend usage of the macros instead of the scriptlets. (i.e. https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd ; FPC Posted, https://fedorahosted.org/fpc/ticket/190 ; DONE)

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 systemd.rpm or a similar file. Basically, the data from https://fedoraproject.org/wiki/Starting_services_by_default needs to be turned into a compliant preset file. (DONE: we now have a basic fedora preset file in system.rpm)

Optional (can happen bit by bit over the subsequent releases): the various spins should be updated to include their own preset files.

Optional: The desktop live CD should probably ship its own preset file that differs slightly from the vanilla one.

Optional (can happen bit by bit over the subsequent releases): existing packages using systemctl enable/disable in the RPM scriptlets should be updated to use the new macro and thus honour the presets.

Also note the display manager feature ( https://fedoraproject.org/wiki/Features/DisplayManagerRework ) which will be the first user of this logic. (DONE)

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/50-foobar.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.

FPC needs to accept https://fedorahosted.org/fpc/ticket/190

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

http://www.freedesktop.org/software/systemd/man/systemd.preset.html

http://freedesktop.org/wiki/Software/systemd/Preset

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

Release Notes

There's probably no mentioning necessary for this, as the fully benefits for users/admins only appear as soon as the .spec files and spins start making use of this feature, which will probably not happen for F18 right away. In F18 we just want to lay the ground work for this.

Comments and Discussion