From 55944e5e40b1be2afc4855d8d2baf4b73d1876b5 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Wed, 10 Apr 2024 22:49:52 +0200 Subject: Adding upstream version 255.4. Signed-off-by: Daniel Baumann --- man/systemd.preset.xml | 222 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 222 insertions(+) create mode 100644 man/systemd.preset.xml (limited to 'man/systemd.preset.xml') diff --git a/man/systemd.preset.xml b/man/systemd.preset.xml new file mode 100644 index 0000000..5d46a88 --- /dev/null +++ b/man/systemd.preset.xml @@ -0,0 +1,222 @@ + + + + + + + + systemd.preset + systemd + + + + systemd.preset + 5 + + + + systemd.preset + Service enablement presets + + + + /etc/systemd/system-preset/*.preset + /run/systemd/system-preset/*.preset + /usr/lib/systemd/system-preset/*.preset + /etc/systemd/user-preset/*.preset + /run/systemd/user-preset/*.preset + /usr/lib/systemd/user-preset/*.preset + + + + Description + + Preset files may be used to encode policy which units shall be enabled by default and which ones + shall be disabled. They are read by systemctl preset which uses this information to + enable or disable a unit. Depending on that policy, systemctl preset is identical to + systemctl enable or systemctl disable. + + systemctl preset is used by the post install scriptlets of rpm packages (or other OS + package formats), to enable/disable specific units by default on package installation, enforcing + distribution, spin or administrator preset policy. This allows choosing a certain set of units to be + enabled/disabled even before installing the actual package. For more information, see + systemctl1. + + It is not recommended to ship preset files within the respective software packages implementing the + units, but rather centralize them in a distribution or spin default policy, which can be amended by + administrator policy, see below. + + If no preset files exist, preset operations will enable all units that are installed by default. If + this is not desired and all units shall rather be disabled, it is necessary to ship a preset file with a + single, catchall "disable *" line. (See example 1, below.) + + When the machine is booted for the first time, + systemd1 will + enable/disable all units according to preset policy, similarly to systemctl + preset-all. Also see "First Boot Semantics" in + machine-id5. + + + + + Preset File Format + + The preset files contain a list of directives, one per line. Empty lines and lines whose first + non-whitespace character is # or ; are ignored. Each directive + consists of one of the words enable, disable, or + ignore, followed by whitespace and a unit name. The unit name may contain shell-style + wildcards. + + For the enable directive for template units, one or more instance names may be specified as a + space-separated list after the unit name. In this case, those instances will be enabled instead of the + instance specified via DefaultInstance= in the unit. + + Presets must refer to the "real" unit file, and not to any aliases. See + systemd.unit5 + for a description of unit aliasing. + + Three different directives are understood: enable may be used to enable units by + default, disable to disable units by default, and ignore to ignore + units and leave existing configuration intact. + + If multiple lines apply to a unit name, the first matching + one takes precedence over all others. + + Each preset file shall be named in the style of + <priority>-<policy-name>.preset. Files + in /etc/ override files with the same name in + /usr/lib/ and /run/. + Files in /run/ override files with the same + name in /usr/lib/. Packages should install + their preset files in /usr/lib/. Files in + /etc/ are reserved for the local + administrator, who may use this logic to override the preset files + installed by vendor packages. All preset files are sorted by their + filename in lexicographic order, regardless of which of the + directories they reside in. If multiple files specify the same + unit name, the entry in the file with the lexicographically + earliest name will be applied. It is recommended to prefix all + filenames with a two-digit number and a dash, to simplify the + ordering of the files. + + If the administrator wants to disable a preset file supplied + by the vendor, the recommended way is to place a symlink to + /dev/null in + /etc/systemd/system-preset/ bearing the same + filename. + + + + Examples + + + Default to off + + # /usr/lib/systemd/system-preset/99-default.preset + +disable * + + + This disables all units. Due to the filename prefix + 99-, it will be read last and hence can easily + be overridden by spin or administrator preset policy. + + + Enable multiple template instances + + # /usr/lib/systemd/system-preset/80-dirsrv.preset + +enable dirsrv@.service foo bar baz + + + This enables all three of dirsrv@foo.service, + dirsrv@bar.service and dirsrv@baz.service. + + + A GNOME spin + + # /usr/lib/systemd/system-preset/50-gnome.preset + +enable gdm.service +enable colord.service +enable accounts-daemon.service +enable avahi-daemon.* + + + + This enables the three mentioned units, plus all + avahi-daemon regardless of which unit type. A + file like this could be useful for inclusion in a GNOME spin of a + distribution. It will ensure that the units necessary for GNOME + are properly enabled as they are installed. It leaves all other + units untouched, and subject to other (later) preset files, for + example like the one from the first example above. + + + Administrator policy + + # /etc/systemd/system-preset/00-lennart.preset + +enable httpd.service +enable sshd.service +enable postfix.service +disable * + + + This enables three specific services and disables all + others. This is useful for administrators to specifically select + the units to enable, and disable all others. Due to the filename + prefix 00- it will be read early and + override all other preset policy files. + + + + Motivation for the preset logic + + Different distributions have different policies on which services shall be enabled by default when + the package they are shipped in is installed. On Fedora all services stay off by default, so that + installing a package will not cause a service to be enabled (with some exceptions). On Debian all + services are immediately enabled by default, so that installing a package will cause its services to be + enabled right-away. + + Even within a single distribution, different spins (flavours, remixes, whatever you might want to + call them) of a distribution also have different policies on what services to enable, and what services + to leave off. For example, Fedora Workstation will enable gdm as display manager by + default, while the Fedora KDE spin will enable sddm instead. + + Different sites might also have different policies what to turn on by default and what to turn + off. For example, one administrator would prefer to enforce the policy of "sshd should + be always on, but everything else off", while another one might say "snmpd always on, + and for everything else use the distribution policy defaults". + + Traditionally, policy about which services shall be enabled were implemented in each package + individually. This made it cumbersome to implement different policies per spin or per site, or to create + software packages that do the right thing on more than one distribution. The enablement mechanism was + also encoding the enablement policy. + + The preset mechanism allows clean separation of the enablement mechanism (inside the package + scriptlets, by invoking systemctl preset) and enablement policy (centralized in the + preset files), and lifts the configuration out of individual packages. Preset files may be written for + specific distributions, for specific spins or for specific sites, in order to enforce different policies + as needed. It is recommended to apply the policy encoded in preset files in package installation + scriptlets. + + + + See Also + + systemd1, + systemctl1, + systemd-delta1 + + + daemon7 + has a discussion of packaging scriptlets. + + Fedora page introducing the use of presets: + Features/PackagePresets. + + + + -- cgit v1.2.3