How to preset service instances in RPM spec

Question

I am building a private application packaged with RPM, which will be installed on systems that contain the following .preset file statement like enable [email protected] 2 4 12 as an administrative setting in /etc/systemd/system-preset/reviewer-app.preset; each system specifies a different set of instances.

The installed systemd is systemd-219-78.el7

I would like that upon installing the "me-backend" RPM, the proper "systemctl preset 'me-backend@*'" to activate exactly the administratively prescribed instances.

This wildcard command line does not work. It succeeds (returns 0) without activating any services. I've tried various combinations like "me-backend@*.service", "me-backend@", with no success. Variations without an instance name fail with 'Failed to execute operation: Unit name [email protected] is missing the instance name.', and those with wildcards succeed without doing anything.

I expected that instances me-backend@2, me-backend@4 and me-backend@12 to be enabled, by creating symbolic links like '/etc/systemd/system/multi-user.target.wants/[email protected]' for each of the 3 services.

Another approach I tried is "preset-all", however this resets presets on all installed applications, which is wrong for my package to do. I think my package should only touch services/instances that it provides.

What is the right incantation of the systemctl preset command that the rpm spec should run in order to enable the administratively-preset instances of this service at installation time?

Answer 1

I have answered my own related question from StackExchange - the answer is that RPMs that target systemd 219 (such as CentOS 7 rpms) cannot rely on the "systemctl preset [email protected]" syntax because systemd 219 does not support instance presets.

The answer to the question here ("how to write an RPM spec that presets service instances") is:

Step 1

The syntax enable [email protected] 2 4 12 is not valid on CentOS 7 because this feature was not yet supported by systemd 219. Instead, the sysadmin must list the required instances in a local me-backend.target override file using the Requires= pragma. The integrator must list enable me-backend.target in the presets file.

Example /etc/systemd/system/me-backend.target:

[Unit]
Description=Me backend %I-bit
After=network-online.target remote-fs.target nss-lookup.target
Wants=network-online.target
Requires= \
  [email protected] \
  [email protected] \
  [email protected]

[Install]
WantedBy=multi-user.target

Integrator specifies that me-backend.target preset is enabled in /etc/systemd/system-preset/reviewer-app.preset:

enable me-backend.target

Step 2

Developer packages in the RPM:

• [email protected] in /usr/lib/systemd/system/[email protected], describing how an instance is started
• default me-backend.target in /usr/lib/systemd/system/me-backend.target listing a reasonable set of default instances on the Requires= line as shown above:

Step 3

Developer specifies scriptlets that activate the me-backend.target preset:

%post
%systemd_post %{name}.target

%preun
%systemd_preun %{name}.target

%postun
%systemd_postun %{name}.target

Explanation

At RPM install time, the installation scriptlets do systemctl daemon-reload; systemctl preset me-backend.target, triggering the integrator's list of instances to be enabled.

The me-backend.target is enabled by the integrator as a preset, and Requires= the instances specified by the administrator in the me-backend.target /etc override.

On systems where the preset is not set, no instances will start, thanks to the distribution's disable *

On systems where the preset is set, but the administrator has not listed specific instances in the /etc/.../me-backend.target override, the instances deemed reasonable defaults by the developer (ie, the packaged /usr/lib/.../me-backend.targets) will start.

Note: At least one person voted that this question be closed on grounds that it's not a programming question. I argue it is a programming question because the contents of an RPM SPEC file are an installation script that a developer must provide, and the question asks what are the correct, as envisioned by the distribution, installation commands for a specific target, CentOS 7 in this case. The related question is a Unix question. It's not concerned with RPM specs at all, but with what a certain version of systemd is capable of. In this question, the developer needs not concern themselves with what systemd can do, but with how to provide the correct installation.