1SYSTEMD.PRESET(5) systemd.preset SYSTEMD.PRESET(5)
2
6 systemd.preset - Service enablement presets
7
9 /etc/systemd/system-preset/*.preset
10 /run/systemd/system-preset/*.preset
12 /usr/lib/systemd/system-preset/*.preset
14 /etc/systemd/user-preset/*.preset
16 /run/systemd/user-preset/*.preset
18 /usr/lib/systemd/user-preset/*.preset
20
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 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 If no preset files exist, systemctl preset 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
45 The preset files contain a list of directives consisting of either the
46 word "enable" or "disable" followed by a space and a unit name
47 (possibly with shell style wildcards), separated by newlines. Empty
48 lines and lines whose first non-whitespace character is "#" or ";" are
49 ignored. Multiple instance names for unit templates may be specified as
50 a space separated list at the end of the line instead of the customary
51 position between "@" and the unit suffix.
52 Presets must refer to the "real" unit file, and not to any aliases. See
54 systemd.unit(5) for a description of unit aliasing.
55 Two different directives are understood: "enable" may be used to enable
57 units by default, "disable" to disable units by default.
58 If multiple lines apply to a unit name, the first matching one takes
60 precedence over all others.
61 Each preset file shall be named in the style of
63 <priority>-<policy-name>.preset. Files in /etc/ override files with the
64 same name in /usr/lib/ and /run/. Files in /run/ override files with
65 the same name in /usr/lib/. Packages should install their preset files
66 in /usr/lib/. Files in /etc/ are reserved for the local administrator,
67 who may use this logic to override the preset files installed by vendor
68 packages. All preset files are sorted by their filename in
69 lexicographic order, regardless of which of the directories they reside
70 in. If multiple files specify the same unit name, the entry in the file
71 with the lexicographically earliest name will be applied. It is
72 recommended to prefix all filenames with a two-digit number and a dash,
73 to simplify the ordering of the files.
74 If the administrator wants to disable a preset file supplied by the
76 vendor, the recommended way is to place a symlink to /dev/null in
77 /etc/systemd/system-preset/ bearing the same filename.
78
80 Example 1. Default to off
81 # /usr/lib/systemd/system-preset/99-default.preset
83 disable *
85 This disables all units. Due to the filename prefix "99-", it will be
87 read last and hence can easily be overridden by spin or administrator
88 preset policy.
89 Example 2. Enable multiple template instances
91 # /usr/lib/systemd/system-preset/80-dirsrv.preset
93 enable dirsrv@.service foo bar baz
95 This enables all three of dirsrv@foo.service, dirsrv@bar.service and
97 dirsrv@baz.service.
98 Example 3. A GNOME spin
100 # /usr/lib/systemd/system-preset/50-gnome.preset
102 enable gdm.service
104 enable colord.service
105 enable accounts-daemon.service
106 enable avahi-daemon.*
107 This enables the three mentioned units, plus all avahi-daemon
109 regardless of which unit type. A file like this could be useful for
110 inclusion in a GNOME spin of a distribution. It will ensure that the
111 units necessary for GNOME are properly enabled as they are installed.
112 It leaves all other units untouched, and subject to other (later)
113 preset files, for example like the one from the first example above.
114 Example 4. Administrator policy
116 # /etc/systemd/system-preset/00-lennart.preset
118 enable httpd.service
120 enable sshd.service
121 enable postfix.service
122 disable *
123 This enables three specific services and disables all others. This is
125 useful for administrators to specifically select the units to enable,
126 and disable all others. Due to the filename prefix "00-" it will be
127 read early and override all other preset policy files.
128
130 Different distributions have different policies on which services shall
131 be enabled by default when the package they are shipped in is
132 installed. On Fedora all services stay off by default, so that
133 installing a package will not cause a service to be enabled (with some
134 exceptions). On Debian all services are immediately enabled by default,
135 so that installing a package will cause its services to be enabled
136 right-away.
137 Even within a single distribution, different spins (flavours, remixes,
139 whatever you might want to call them) of a distribution also have
140 different policies on what services to enable, and what services to
141 leave off. For example, Fedora Workstation will enable gdm as display
142 manager by default, while the Fedora KDE spin will enable sddm instead.
143 Different sites might also have different policies what to turn on by
145 default and what to turn off. For example, one administrator would
146 prefer to enforce the policy of "sshd should be always on, but
147 everything else off", while another one might say "snmpd always on, and
148 for everything else use the distribution policy defaults".
149 Traditionally, policy about which services shall be enabled were
151 implemented in each package individually. This made it cumbersome to
152 implement different policies per spin or per site, or to create
153 software packages that do the right thing on more than one
154 distribution. The enablement mechanism was also encoding the enablement
155 policy.
156 The preset mechanism allows clean separation of the enablement
158 mechanism (inside the package scriptlets, by invoking systemctl preset)
159 and enablement policy (centralized in the preset files), and lifts the
160 configuration out of individual packages. Preset files may be written
161 for specific distributions, for specific spins or for specific sites,
162 in order to enforce different policies as needed. It is recommended to
163 apply the policy encoded in preset files in package installation
164 scriptlets.
165
167 systemd(1), systemctl(1), systemd-delta(1)
168 daemon(7) has a discussion of packaging scriptlets.
170 Fedora page introducing the use of presets: Features/PackagePresets[1].
172
174 1. Features/PackagePresets
175 https://fedoraproject.org/wiki/Features/PackagePresets
176systemd 251 SYSTEMD.PRESET(5)