1SYSTEMD.PRESET(5)               systemd.preset               SYSTEMD.PRESET(5)
2
3
4

NAME

6       systemd.preset - Service enablement presets
7

SYNOPSIS

9       /etc/systemd/system-preset/*.preset
10
11       /run/systemd/system-preset/*.preset
12
13       /usr/lib/systemd/system-preset/*.preset
14
15       /etc/systemd/user-preset/*.preset
16
17       /run/systemd/user-preset/*.preset
18
19       /usr/lib/systemd/user-preset/*.preset
20

DESCRIPTION

22       Preset files may be used to encode policy which units shall be enabled
23       by default and which ones shall be disabled. They are read by systemctl
24       preset which uses this information to enable or disable a unit.
25       Depending on that policy, systemctl preset is identical to systemctl
26       enable or systemctl disable.  systemctl preset is used by the post
27       install scriptlets of rpm packages (or other OS package formats), to
28       enable/disable specific units by default on package installation,
29       enforcing distribution, spin or administrator preset policy. This
30       allows choosing a certain set of units to be enabled/disabled even
31       before installing the actual package. For more information, see
32       systemctl(1).
33
34       It is not recommended to ship preset files within the respective
35       software packages implementing the units, but rather centralize them in
36       a distribution or spin default policy, which can be amended by
37       administrator policy, see below.
38
39       If no preset files exist, preset operations will enable all units that
40       are installed by default. If this is not desired and all units shall
41       rather be disabled, it is necessary to ship a preset file with a
42       single, catchall "disable *" line. (See example 1, below.)
43
44       When the machine is booted for the first time, systemd(1) will
45       enable/disable all units according to preset policy, similarly to
46       systemctl preset-all. Also see "First Boot Semantics" in machine-id(5).
47

PRESET FILE FORMAT

49       The preset files contain a list of directives, one per line. Empty
50       lines and lines whose first non-whitespace character is "#" or ";" are
51       ignored. Each directive consists of one of the words "enable",
52       "disable", or "ignore", followed by whitespace and a unit name. The
53       unit name may contain shell-style wildcards.
54
55       For the enable directive for template units, one or more instance names
56       may be specified as a space-separated list after the unit name. In this
57       case, those instances will be enabled instead of the instance specified
58       via DefaultInstance= in the unit.
59
60       Presets must refer to the "real" unit file, and not to any aliases. See
61       systemd.unit(5) for a description of unit aliasing.
62
63       Three different directives are understood: "enable" may be used to
64       enable units by default, "disable" to disable units by default, and
65       "ignore" to ignore units and leave existing configuration intact.
66
67       If multiple lines apply to a unit name, the first matching one takes
68       precedence over all others.
69
70       Each preset file shall be named in the style of
71       <priority>-<policy-name>.preset. Files in /etc/ override files with the
72       same name in /usr/lib/ and /run/. Files in /run/ override files with
73       the same name in /usr/lib/. Packages should install their preset files
74       in /usr/lib/. Files in /etc/ are reserved for the local administrator,
75       who may use this logic to override the preset files installed by vendor
76       packages. All preset files are sorted by their filename in
77       lexicographic order, regardless of which of the directories they reside
78       in. If multiple files specify the same unit name, the entry in the file
79       with the lexicographically earliest name will be applied. It is
80       recommended to prefix all filenames with a two-digit number and a dash,
81       to simplify the ordering of the files.
82
83       If the administrator wants to disable a preset file supplied by the
84       vendor, the recommended way is to place a symlink to /dev/null in
85       /etc/systemd/system-preset/ bearing the same filename.
86

EXAMPLES

88       Example 1. Default to off
89
90           # /usr/lib/systemd/system-preset/99-default.preset
91
92           disable *
93
94       This disables all units. Due to the filename prefix "99-", it will be
95       read last and hence can easily be overridden by spin or administrator
96       preset policy.
97
98       Example 2. Enable multiple template instances
99
100           # /usr/lib/systemd/system-preset/80-dirsrv.preset
101
102           enable dirsrv@.service foo bar baz
103
104       This enables all three of dirsrv@foo.service, dirsrv@bar.service and
105       dirsrv@baz.service.
106
107       Example 3. A GNOME spin
108
109           # /usr/lib/systemd/system-preset/50-gnome.preset
110
111           enable gdm.service
112           enable colord.service
113           enable accounts-daemon.service
114           enable avahi-daemon.*
115
116       This enables the three mentioned units, plus all avahi-daemon
117       regardless of which unit type. A file like this could be useful for
118       inclusion in a GNOME spin of a distribution. It will ensure that the
119       units necessary for GNOME are properly enabled as they are installed.
120       It leaves all other units untouched, and subject to other (later)
121       preset files, for example like the one from the first example above.
122
123       Example 4. Administrator policy
124
125           # /etc/systemd/system-preset/00-lennart.preset
126
127           enable httpd.service
128           enable sshd.service
129           enable postfix.service
130           disable *
131
132       This enables three specific services and disables all others. This is
133       useful for administrators to specifically select the units to enable,
134       and disable all others. Due to the filename prefix "00-" it will be
135       read early and override all other preset policy files.
136

MOTIVATION FOR THE PRESET LOGIC

138       Different distributions have different policies on which services shall
139       be enabled by default when the package they are shipped in is
140       installed. On Fedora all services stay off by default, so that
141       installing a package will not cause a service to be enabled (with some
142       exceptions). On Debian all services are immediately enabled by default,
143       so that installing a package will cause its services to be enabled
144       right-away.
145
146       Even within a single distribution, different spins (flavours, remixes,
147       whatever you might want to call them) of a distribution also have
148       different policies on what services to enable, and what services to
149       leave off. For example, Fedora Workstation will enable gdm as display
150       manager by default, while the Fedora KDE spin will enable sddm instead.
151
152       Different sites might also have different policies what to turn on by
153       default and what to turn off. For example, one administrator would
154       prefer to enforce the policy of "sshd should be always on, but
155       everything else off", while another one might say "snmpd always on, and
156       for everything else use the distribution policy defaults".
157
158       Traditionally, policy about which services shall be enabled were
159       implemented in each package individually. This made it cumbersome to
160       implement different policies per spin or per site, or to create
161       software packages that do the right thing on more than one
162       distribution. The enablement mechanism was also encoding the enablement
163       policy.
164
165       The preset mechanism allows clean separation of the enablement
166       mechanism (inside the package scriptlets, by invoking systemctl preset)
167       and enablement policy (centralized in the preset files), and lifts the
168       configuration out of individual packages. Preset files may be written
169       for specific distributions, for specific spins or for specific sites,
170       in order to enforce different policies as needed. It is recommended to
171       apply the policy encoded in preset files in package installation
172       scriptlets.
173

SEE ALSO

175       systemd(1), systemctl(1), systemd-delta(1)
176
177       daemon(7) has a discussion of packaging scriptlets.
178
179       Fedora page introducing the use of presets: Features/PackagePresets[1].
180

NOTES

182        1. Features/PackagePresets
183           https://fedoraproject.org/wiki/Features/PackagePresets
184
185
186
187systemd 254                                                  SYSTEMD.PRESET(5)
Impressum