summaryrefslogtreecommitdiffstats
path: root/man/systemd.preset.xml
diff options
context:
space:
mode:
authorDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-10 20:49:52 +0000
committerDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-10 20:49:52 +0000
commit55944e5e40b1be2afc4855d8d2baf4b73d1876b5 (patch)
tree33f869f55a1b149e9b7c2b7e201867ca5dd52992 /man/systemd.preset.xml
parentInitial commit. (diff)
downloadsystemd-55944e5e40b1be2afc4855d8d2baf4b73d1876b5.tar.xz
systemd-55944e5e40b1be2afc4855d8d2baf4b73d1876b5.zip
Adding upstream version 255.4.upstream/255.4
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'man/systemd.preset.xml')
-rw-r--r--man/systemd.preset.xml222
1 files changed, 222 insertions, 0 deletions
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 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+ "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="systemd.preset">
+
+ <refentryinfo>
+ <title>systemd.preset</title>
+ <productname>systemd</productname>
+ </refentryinfo>
+
+ <refmeta>
+ <refentrytitle>systemd.preset</refentrytitle>
+ <manvolnum>5</manvolnum>
+ </refmeta>
+
+ <refnamediv>
+ <refname>systemd.preset</refname>
+ <refpurpose>Service enablement presets</refpurpose>
+ </refnamediv>
+
+ <refsynopsisdiv>
+ <para><filename>/etc/systemd/system-preset/*.preset</filename></para>
+ <para><filename>/run/systemd/system-preset/*.preset</filename></para>
+ <para><filename>/usr/lib/systemd/system-preset/*.preset</filename></para>
+ <para><filename>/etc/systemd/user-preset/*.preset</filename></para>
+ <para><filename>/run/systemd/user-preset/*.preset</filename></para>
+ <para><filename>/usr/lib/systemd/user-preset/*.preset</filename></para>
+ </refsynopsisdiv>
+
+ <refsect1>
+ <title>Description</title>
+
+ <para>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 <command>systemctl preset</command> which uses this information to
+ enable or disable a unit. Depending on that policy, <command>systemctl preset</command> is identical to
+ <command>systemctl enable</command> or <command>systemctl disable</command>.
+
+ <command>systemctl preset</command> 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
+ <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para>
+
+ <para>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.</para>
+
+ <para>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 "<filename>disable *</filename>" line. (See example 1, below.)</para>
+
+ <para>When the machine is booted for the first time,
+ <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> will
+ enable/disable all units according to preset policy, similarly to <command>systemctl
+ preset-all</command>. Also see "First Boot Semantics" in
+ <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+ </para>
+ </refsect1>
+
+ <refsect1>
+ <title>Preset File Format</title>
+
+ <para>The preset files contain a list of directives, one per line. Empty lines and lines whose first
+ non-whitespace character is <literal>#</literal> or <literal>;</literal> are ignored. Each directive
+ consists of one of the words <literal>enable</literal>, <literal>disable</literal>, or
+ <literal>ignore</literal>, followed by whitespace and a unit name. The unit name may contain shell-style
+ wildcards.</para>
+
+ <para>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.</para>
+
+ <para>Presets must refer to the "real" unit file, and not to any aliases. See
+ <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ for a description of unit aliasing.</para>
+
+ <para>Three different directives are understood: <literal>enable</literal> may be used to enable units by
+ default, <literal>disable</literal> to disable units by default, and <literal>ignore</literal> to ignore
+ units and leave existing configuration intact.</para>
+
+ <para>If multiple lines apply to a unit name, the first matching
+ one takes precedence over all others.</para>
+
+ <para>Each preset file shall be named in the style of
+ <filename>&lt;priority&gt;-&lt;policy-name&gt;.preset</filename>. Files
+ in <filename>/etc/</filename> override files with the same name in
+ <filename>/usr/lib/</filename> and <filename>/run/</filename>.
+ Files in <filename>/run/</filename> override files with the same
+ name in <filename>/usr/lib/</filename>. Packages should install
+ their preset files in <filename>/usr/lib/</filename>. Files in
+ <filename>/etc/</filename> 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.</para>
+
+ <para>If the administrator wants to disable a preset file supplied
+ by the vendor, the recommended way is to place a symlink to
+ <filename>/dev/null</filename> in
+ <filename>/etc/systemd/system-preset/</filename> bearing the same
+ filename.</para>
+ </refsect1>
+
+ <refsect1>
+ <title>Examples</title>
+
+ <example>
+ <title>Default to off</title>
+
+ <programlisting># /usr/lib/systemd/system-preset/99-default.preset
+
+disable *</programlisting>
+ </example>
+
+ <para>This disables all units. Due to the filename prefix
+ <literal>99-</literal>, it will be read last and hence can easily
+ be overridden by spin or administrator preset policy.</para>
+
+ <example>
+ <title>Enable multiple template instances</title>
+
+ <programlisting># /usr/lib/systemd/system-preset/80-dirsrv.preset
+
+enable dirsrv@.service foo bar baz</programlisting>
+ </example>
+
+ <para>This enables all three of <filename>dirsrv@foo.service</filename>,
+ <filename>dirsrv@bar.service</filename> and <filename>dirsrv@baz.service</filename>.</para>
+
+ <example>
+ <title>A GNOME spin</title>
+
+ <programlisting># /usr/lib/systemd/system-preset/50-gnome.preset
+
+enable gdm.service
+enable colord.service
+enable accounts-daemon.service
+enable avahi-daemon.*</programlisting>
+
+ </example>
+
+ <para>This enables the three mentioned units, plus all
+ <filename>avahi-daemon</filename> 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.</para>
+
+ <example>
+ <title>Administrator policy</title>
+
+ <programlisting># /etc/systemd/system-preset/00-lennart.preset
+
+enable httpd.service
+enable sshd.service
+enable postfix.service
+disable *</programlisting>
+ </example>
+
+ <para>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 <literal>00-</literal> it will be read early and
+ override all other preset policy files.</para>
+ </refsect1>
+
+ <refsect1>
+ <title>Motivation for the preset logic</title>
+
+ <para>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.</para>
+
+ <para>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 <command>gdm</command> as display manager by
+ default, while the Fedora KDE spin will enable <command>sddm</command> instead.</para>
+
+ <para>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 "<command>sshd</command> should
+ be always on, but everything else off", while another one might say "<command>snmpd</command> always on,
+ and for everything else use the distribution policy defaults".</para>
+
+ <para>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.</para>
+
+ <para>The preset mechanism allows clean separation of the enablement mechanism (inside the package
+ scriptlets, by invoking <command>systemctl preset</command>) 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.</para>
+ </refsect1>
+
+ <refsect1>
+ <title>See Also</title>
+ <para>
+ <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+ <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+ <citerefentry><refentrytitle>systemd-delta</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+ </para>
+
+ <para><citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+ has a discussion of packaging scriptlets.</para>
+
+ <para>Fedora page introducing the use of presets:
+ <ulink url="https://fedoraproject.org/wiki/Features/PackagePresets">Features/PackagePresets</ulink>.
+ </para>
+ </refsect1>
+
+</refentry>