[systemd-devel] [RFC] Preset Files

[Lennart Poettering]

Heya,

many of you probably saw Frederic's rpm macros suggested here. This got
Kay and me thinking about implementing something like "presets" in
systemd, and before we go and implement that we'd like to hear your
opinions on it. This would go hand in hand with Frederic's macros, and
both would be included in the upstream systemd package.

So what's a "preset" supposed to be?

Distributions have different policies on enabling services by
default. On Fedora services should default to off, with a small number of
exceptions. On Debian OTOH all services are enabled by default. Fedora
spins in turn are based on the default Fedora settings but might end up
enabling a few services not enabled on the unflavoured Fedora. In
general, on desktop systems (i.e. without an educated admin) a default
of "enable what is installed" probably makes sense, while many seasoned
admins will probably opt more towards the other extreme: "I, the admin
am king, and I am the only one enabling services here!". Both approaches
of course are valid approaches.

Now, traditionally whether a service was enabled or not on most distros
was encoded in the packages themselves (i.e. in chkconfig in lines in
the scriptlets, or something equivalent), which makes it very difficult
to apply spin-specific or admin-specific rules on top. This is
information that should not be encoded in the packages, but in some
external database. And this is what "presets" are supposed to
be. Something like a long list that tells systemd which services to
enable by default and which ones not to enable. It's a bit like a SUSE
pattern or a Fedora comps, except that it lists services that shall be
enabled instead of package that shall be installed.

More specifically this is how it should work: We'd have a directory
/lib/systemd/system.preset/. By default it would be empty (or not even
exist), which for simplicity reasons would mean "enable everything
installed" (i.e. the Debian policy). Then, if distros or spins want to
change what is enabled by default, they'd drop in a file (or multiple,
which might be useful for a desktop spin and a graphical design spin
where the latter is a superset of the former) in that
directory. The file would be a trivial text file with lines like this:

<snip>
disable avahi-daemon.service
enable cups.service
disable *
</snip>

Then, we'd add a new command to "systemctl" called "systemctl
preset". It would be equivalent to a "systemctl enable" if the unit file
passed is listed in any of the preset files on lines prefixed with
"enable", or be like a "systemctl disable" if it is listed with a prefix
of "disable". Simple globbing would be supported. If no entry is found
"systemctl preset" would be synonymous with "systemctl enable".

If "systemctl preset" is passed with unit names, those units would
be enable/disabled as listed in the preset file. If no argument is
passed all units would be reset to the preset defaults. (another
long-sought feature...)

A few more things to note:

- systemd would not ship any preset file by default (and probably not
  even the directory), this is left to distributions. Most likely the
  distributions would ship a preset file in some spin-specific RPM,
  which would conflict with the the RPMs for other spins.

- The RPM post macro would always call "systemctl preset" for the units
  passed, and never anything else.

- If an admin wants to manually change "enable-by-default" to
  "disable-by-default" (or vice versa) he could just drop his own file
  with "disable *" (or "enable *") into /etc/systemd/system.preset/ and
  override the vendor/spin settings.

- One nice thing is that this would be dead simple to implement (just 10
  lines of code or so), and would practically not be visible on systems
  who don't need any distro spin crack... ;-)

- This would kinda bring back the ability that some SysV implementations
  had with encoding the default enable/disable state for a service
  somewhere. Some distros had that in the SysV header. With this we now
  have it independently of the init scripts.

- The reason why we'd implement "enable-by-default" instead of
  "disable-by-default" if no preset file is around is simply the idea
  that having to install stuff that is not needed is already a failure
  in itself, and ideally people who want to disable a service would just
  "rpm -e" it.

Anyway, this of course requires some buy-in from the distributions, so
I'd like to ask the distro maintainers for comments on this. Do you
think this would be useful to you? Any other suggestions, ideas?

Note that even if we implement this in systemd (which is very likely) it
is of course up to the distros to make use of this. If they still want
to enable (or disable) all services unconditionally then they can still
do so in RPM scrips, but we'd of course greatly welcome if distros would
support this new scheme instead of cooking their own.

Lennart

--
Lennart Poettering - Red Hat, Inc.