voxpupuli
Allow systemd unit specifiers in path values
Affected Puppet, Ruby, OS and module versions/distributions
- Puppet: 7.29.1 (server), 8.3.1 (agent)
- Ruby: ruby 3.2.4 (2024-04-23 revision af471c0e01) [amd64-freebsd13] (server), ruby 3.2.4 (2024-04-23 revision af471c0e01) [x86_64-linux] (agent)
- Distribution: FreeBSD 13 (server), Fedora Workstation 40 (agent)
- Module version: 7.1.0
How to reproduce (e.g Puppet code you use)
systemd::manage_unit { 'disable-ferdium-update-check.service':
path => '/etc/systemd/user/',
daemon_reload => true,
unit_entry => {
'Description' => "Disable Ferdium's check for updates",
'ConditionPathExists' => '%h/.var/app/org.ferdium.Ferdium/config/Ferdium/config/settings.json'
},
service_entry => {
'Type' => 'oneshot',
'ExecStart' => [
"jq -r '.automaticUpdates = $newValue' --argjson newValue false %h/.var/app/org.ferdium.Ferdium/config/Ferdium/config/settings.json",
'cp /tmp/ferdium_settings.json %h/.var/app/org.ferdium.Ferdium/config/Ferdium/config/settings.json'
],
'StandardOutput' => 'file:/tmp/ferdium_settings.json'
},
install_entry => {
'WantedBy' => 'default.target'
}
}->
systemd::user_service { "enable service to disable Ferdium's update check":
unit => 'disable-ferdium-update-check.service',
enable => true,
global => true,
}
What are you seeing
I see the puppet agent reporting the server complaining about not being able to compile the catalog for the client because ConditionPathExists doesn't match the configured type.
What behaviour did you expect instead
Basically, I want the module to support what systemd itself supports, i.e. to accept specifiers where specifiers are allowed. I worked around the type definition of
Optional['ConditionPathExists'] => Variant[Enum[''],Stdlib::Unixpath,Pattern[/^!.*$/],Array[Variant[Enum[''],Stdlib::Unixpath,Pattern[/^!.*$/]],1]],
by changing it to
Optional['ConditionPathExists'] => Variant[Enum[''],Stdlib::Unixpath,Pattern[/^!.*$/],String,Array[Variant[Enum[''],Stdlib::Unixpath,Pattern[/^!.*$/]],1]],
Output log
Before my hack
wmde@wmde-103174:~$ sudo puppet agent -t
Info: Refreshing CA certificate
Info: CA certificate is unmodified, using existing CA certificate
Info: Refreshing CRL
Info: CRL is unmodified, using existing CRL
Info: Using environment 'production'
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts
Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: Error while evaluating a Resource Statement, Systemd::Manage_unit[disable-ferdium-update-check.service]: parameter 'unit_entry' entry 'ConditionPathExists' expects a match for Variant[Enum[''], Stdlib::Unixpath = Pattern[/\A\/([^\n\/\0]+\/*)*\z/], Pattern[/^!.*$/], Array[Variant[Enum[''], Stdlib::Unixpath = Pattern[/\A\/([^\n\/\0]+\/*)*\z/], Pattern[/^!.*$/]], 1]], got '%h/.var/app/org.ferdium.Ferdium/config/Ferdium/config/settings.json' (file: /usr/local/etc/puppet/code/environments/production/manifests/wmde/linux.pp, line: 248) on node wmde_103174
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run
After my hack
wmde@wmde-103174:~$ sudo puppet agent -t
Info: Refreshing CA certificate
Info: CA certificate is unmodified, using existing CA certificate
Info: Refreshing CRL
Info: CRL is unmodified, using existing CRL
Info: Using environment 'production'
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts
Info: Caching catalog for wmde_103174
Info: Applying configuration version '1721127175'
[…]
Notice: /Stage[main]/Wmde::Linux/Systemd::Manage_unit[disable-ferdium-update-check.service]/Systemd::Unit_file[disable-ferdium-update-check.service]/File[/etc/systemd/user//disable-ferdium-update-check.service]/ensure: defined content as '{sha256}31e564f4c5f7bdd2951a5b4dd11b23fbd3134c5c44cbcc6cce20d43a640a264d'
Info: /Stage[main]/Wmde::Linux/Systemd::Manage_unit[disable-ferdium-update-check.service]/Systemd::Unit_file[disable-ferdium-update-check.service]/File[/etc/systemd/user//disable-ferdium-update-check.service]: Scheduling refresh of Systemd::Daemon_reload[disable-ferdium-update-check.service]
Info: Systemd::Daemon_reload[disable-ferdium-update-check.service]: Scheduling refresh of Exec[systemd-disable-ferdium-update-check.service-systemctl-daemon-reload]
Notice: /Stage[main]/Wmde::Linux/Systemd::Manage_unit[disable-ferdium-update-check.service]/Systemd::Unit_file[disable-ferdium-update-check.service]/Systemd::Daemon_reload[disable-ferdium-update-check.service]/Exec[systemd-disable-ferdium-update-check.service-systemctl-daemon-reload]: Triggered 'refresh' from 1 event
Notice: /Stage[main]/Wmde::Linux/Systemd::User_service[enable service to disable Ferdium's update check]/Exec[Enable user service disable-ferdium-update-check.service globally]/returns: executed successfully
Notice: Applied catalog in 11.62 seconds
Any additional information you'd like to impart
I haven't mentioned the other attributes but there are several with similar limitations.
Is there an explicit list which settings do support specifiers? All I could find is
Many settings resolve specifiers which may be used to write generic unit files referring to runtime or unit parameters that are replaced when the unit files are loaded. Specifiers must be known and resolvable for the setting to be valid.
@TheMeier I asked in the systemd IRC channel yesterday but all they came up with was something along the lines of "specifiers are allowed everywhere, maybe not where boolean values are expected". I think integer values might also use some special handling as there are specifiers for integers, e.g. %U for user ID, %G for user GID. But I assume it's safe to say their use is limited to a handful of options that expect integer values. Everywhere where strings are expected, they don't cause trouble.
Although it's not a 100% related, but the pipe symbol | should also be allowed to make multiple conditions become an OR:
Condition checks can use a pipe symbol ("|") after the equals sign ("Condition…=|…"), which causes the condition to become a triggering condition. If at least one triggering condition is defined for a unit, then the unit will be started if at least one of the triggering conditions of the unit applies and all of the regular (i.e. non-triggering) conditions apply.
