Fedora.next Per-Product Configuration Packaging
Goals
In the Fedora.next world, we have a set of curated Fedora Products as well as the availability of classic Fedora. Historically, we have maintained a single set of configuration defaults for all Fedora installs, but different target use-cases have different needs. The goal of this document is to set out the guidelines for creating per-Product configuration defaults.
We want to ensure that all packages have sensible defaults for whichever Product on which they are installed, while also avoiding situations where users would have some packages installed with one Product's defaults and some packages with another.
Definitions
Fedora.next: Umbrella term for planning Fedora's future. Currently covering the creation of the Fedora Products, Fedora Base Design and Fedora Environments and Stacks.
$PRODUCT: One of the Fedora.next Product deliverables, currently "Cloud", "Server" and "Workstation".
Per-product Configuration Packaging
Requirements
- All packages must have a global default configuration. This configuration will be used whenever a Product-specific default configuration is not required. (For example, if a non-Product install is in use or only Fedora Cloud has a custom configuration and Fedora Workstation was installed).
- Any package that requires a per-product default configuration must provide all alternate configuration files in the same package.
- Any package that requires a configuration that differs between Products must obtain permission from that Product's Working Group before packaging it.
Global Default Configuration
- The global default configuration must be provided by the package that requires it.
- The global default configuration must be named based on the package's normal naming scheme, with the main part of the name being suffixed by -default. For example, if the package normally uses foo.conf, then the global default configuration must be named foo-default.conf
Per-Product Default Configuration
- For each Product requiring a unique default configuration, the packager must provide a copy of the default configuration file, modified as appropriate for the specific product.
- The product-specific configuration file must be named based on the package's normal naming scheme, with the main part of the name being suffixed by a dash followed by the name of the product. For example, if the package normally uses
foo.conf
, then the Server version must be namedfoo-server.conf
.
Applying Configuration
In order to apply the configuration, the packager must implement a mechanism in the %posttrans
section of the specfile that behaves as follows:
- It must first check whether the final config file already exists. If so, the script must make no changes.
%posttrans if [ ! -e %{_sysconfdir}/foo/foo.conf ]; then ... fi
- Then it must use the value of the Fedora
VARIANT
to symlink one of the divergent config files (or the default) to the final config file location. It will get this value by importing the contents of /etc/os-release as shell values.
. /etc/os-release || : case "$VARIANT" in Server) ln -sf foo-server.conf %{_sysconfdir}/foo/foo.conf || : ;; *) ln -sf foo-default.conf %{_sysconfdir}/foo/foo.conf || : ;; esac
- Lastly, the final config file location must be listed in the %files section with %ghost:
%ghost %config(noreplace) %{_sysconfdir}/foo/foo.conf
- For tracking purposes, the package providing the various configuration files must also contain a virtual Provides: for each variant configuration that may be applied:
Provides: variant_config(Cloud) Provides: variant_config(Server) Provides: variant_config(Workstation)
Example (firewalld)
We will assume for the sake of demonstration that firewalld will need a custom configuration for Fedora Server and Fedora Workstation, but that Fedora Cloud will not require any changes from the global default.
... Provides: variant_config(Server) Provides: variant_config(Workstation) ... %posttrans # If we don't yet have a symlink or existing file for firewalld.conf, # create it. Note: this will intentionally reset the policykit policy # at the same time, so they are in sync. if [ ! -e %{_sysconfdir}/firewalld/firewalld.conf ]; then # Import /etc/os-release to get the variant definition . /etc/os-release || : case "$VARIANT" in Server) ln -sf firewalld-server.conf %{_sysconfdir}/firewalld/firewalld.conf || : ln -sf org.fedoraproject.FirewallD1.server.policy %{_datadir}/polkit-1/actions/org.fedoraproject.FirewallD1.policy || : ;; Workstation) ln -sf firewalld-workstation.conf %{_sysconfdir}/firewalld/firewalld.conf || : ln -sf org.fedoraproject.FirewallD1.desktop.policy %{_datadir}/polkit-1/actions/org.fedoraproject.FirewallD1.policy || : ;; *) ln -sf firewalld-standard.conf %{_sysconfdir}/firewalld/firewalld.conf || : # The standard firewall policy will be the same as Server ln -sf org.fedoraproject.FirewallD1.server.policy %{_datadir}/polkit-1/actions/org.fedoraproject.FirewallD1.policy || : ;; esac fi ... %files -f %{name}.lang ... %attr(0750,root,root) %dir %{_sysconfdir}/firewalld %ghost %config(noreplace) %{_sysconfdir}/firewalld/firewalld.conf %config(noreplace) %{_sysconfdir}/firewalld/firewalld-standard.conf %config(noreplace) %{_sysconfdir}/firewalld/firewalld-server.conf %config(noreplace) %{_sysconfdir}/firewalld/firewalld-workstation.conf ... %ghost %{_datadir}/polkit-1/actions/org.fedoraproject.FirewallD1.policy %{_datadir}/polkit-1/actions/org.fedoraproject.FirewallD1.desktop.policy %{_datadir}/polkit-1/actions/org.fedoraproject.FirewallD1.server.policy