voxpupuli / puppet-systemd Goto Github PK

The internal service names eg: service {'systemd-journald': } doesn't adhere to the enforced pattern in Systemd::Unit.

This means that any service that needs to notify any systemd service cannot enforce that the service name value is of type Systemd::Unit

puppet facts throws a warning:

Facter: Fact resolution fact='systemd_internal_services', resolution='' resolved to an invalid value: Expected disabled to be one of [Integer, Float, TrueClass, FalseClass, NilClass, String, Array, Hash], but was Symbol

And there was no fact "systemd_internal_services"

Removing .to_sym from result[service] = status.to_sym in /lib/facter/systemd.rb (line 55) fixed it for me.

Camptocamp module has issues with puppet 4 at the moment.
#18

Utilizing justin8's module until camptocamp has the issues resolved.

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: all
• Ruby: all
• Distribution: Ubuntu 20.04 (client)
• Module version: 3.0.0, 3.1.0

How to reproduce (e.g Puppet code you use)

class demo {
  class { 'systemd':
    manage_resolved => true,
    resolved_ensure => 'stopped',
  }

  file { '/etc/resolv.conf':
    ensure => 'file',
  }
}

What are you seeing

Catalog compilation fails with with a duplicate resource declaration error.

What behaviour did you expect instead

File[/etc/resolv.conf] should not be managed when systemd-resolved is managed to the stopped state.

Output log

Duplicate declaration: File[/etc/resolv.conf] is already declared at (.../modules/systemd/manifests/resolved.pp, line: 77); cannot redeclare (.../modules/demo/manifests/init.pp, line: 7) (file: .../modules/demo/spec/fixtures/modules/demo/manifests/init.pp, line: 7, column: 3) on node ...

Any additional information you'd like to impart

Just stopping systemd-resolved on a system that has had it configured completely breaks name resolution. Something else needs to manage /etc/resolv.conf afterward, or at least to update it once, but the module interferes with that.

For context, on domain-joined Ubuntu 20.04, systemd-resolved needs to be disabled in order for sssd to authenticate users against Active Directory.

Here is the RSpec test used to demonstrate the issue:

# frozen_string_literal: true

require 'spec_helper'

describe 'demo' do
  on_supported_os.each do |os, os_facts|
    context "on #{os}" do
      let(:facts) { os_facts.merge(systemd_internal_services: { 'systemd-resolved.service' => 'enabled' }) }

      it { is_expected.to compile }
    end
  end
end

Need a new release so that e556d27 is included.

The issue voxpupuli/puppet-rabbitmq#836 needs a new release of puppet-systemd so it can raise it's minimum requirement and start using the change.

Please add merge options, so one can add entries in all hiera layers.

Example:

You have three hiera layers (common, env, node) and you'd like to merge "systemd::loginctl_users" from env and node, it's currently not possible.

Solution

common.yaml:

# ...
lookup_options:
  systemd::loginctl_users:
    merge: deep
# ...

Docs: https://puppet.com/docs/puppet/7.6/hiera_merging.html#setting_lookup_options_to_refine_the_result_of_a_lookup

Thank you

Hello puppet-systemd,
I just found that the metadata file contains incorrect information about the puppet version compatibility.
For instance, it claims it is compatible with versions < 3.7 . However the parametrized arguments in init.pp do not agree.
Is it possible to have a cleaned up version of metadata file ?

Regards.

It would be nice to have a possibility to use LimitNPROC with an infinity option.

I've checked out PRs and see that the next PR adds this opportunity:
https://github.com/camptocamp/puppet-systemd/pull/152/files

Reference:
https://www.freedesktop.org/software/systemd/man/systemd.exec.html

Can support for drop-in files to override package units be added to this module?

Since content this is just passed through to a file resource allow to pass Sensitive values also

while its great to see that there is now a type for drop ins i am missing a migration path from handling drop-in file with systemd::unit_file.
if i ugrade from 0.x to 1.x have to change all of my modules using something like this

systemd::unit_file{'myserviceservice.d/10-disable.conf':
   ...

at the same time. otherwise my code breaks at assert_type(Systemd::Unit, $name)

Hi, why is LimitNOFILE an integer type? AFAIK infinity can be used with LimitNOFILE on systemd.
Should not be this more appropriate?

    Optional['LimitNOFILE']         => Pattern['^(infinity|(\d+)$'],

While this module does give you the capability to configure some systemd configurations (eg. /etc/systemd/logind.conf), it would be nice if it was able to configure the other configurables available (eg. /etc/systemd/networkd.conf).

I don't know if a generic mechanism would be the way to approach that, or to have specific entry points into the different config files and track them over time, adding them as they appear in systemd versions.

At the moment I see on my system journald.conf, logind.conf, networkd.conf, pstore.conf, resolved.conf, sleep.conf, system.conf, timesyncd.conf, and user.conf.

hi,

just a short question: can I call the systemd::unit_file from Hiera too ? I tried was included the systemd class and

systemd::unit_file:
  'foo':
    ensure: 'running'
    source: 'puppet:///...foo.service'

but it seems, that I have to use a create_resource manifest wrapper .., or maybe I just call the class wrong ...

If you define multiple drop-in for the same service using the new systemd::dropin_file::daemon_reload parameter on more then one of them puppet will fail with a duplicate declaration error for Exec[<servicename>.service-systemctl-daemon-reload].

Please mark the old camptocamp module as deprecated, so that people (and API using programs) see the transfer to the new author.

#103 was merged to allow stdlib 6 report, but there is no new release on the forge. Modules that depend on this but that support stdlib 6 are failing beaker tests. Thank you.

The recommended test for init=systemd fails on systems where the init binary is named "/sbin/init" rather than "systemd".

The following test works on every system I've tried so far:

/proc/1/exe --version | grep -q 'systemd'

I want to setup some systemd limits for a service so I have included ...

    include ::systemd

... in my manifest. And I have this hiera data:

systemd::service_limits:
    'openstack-nova-compute.service':
        limits:
                LimitNOFILE: 32768

But when puppet on my node I get this error:

Error while evaluating a Function Call, Class[Systemd]: parameter 'service_limits' unrecognized key 'openstack-nova-compute.service' at ...

I have looked at the docs and they do not explain how to form the hash in hiera, they just give this example:

::systemd::service_limits { 'foo.service':
  limits => {
    'LimitNOFILE' => 8192,
    'LimitNPROC'  => 16384,
  }
}

So how would I do that in hiera/yaml?

One of the benefits to Systemd is spawning a Systemd user instance where a user can edit, start, and stop their own services, timers, etc. without requiring permissions to the system-level resources.

While I understand that managing user configurations with Puppet is not advisable, It would be nice to manage the global Systemd user units for secured systems. For services, this means that any user that logs in, a service is started under their Systemd instance and will continue to run until the user logs out.

It is my understanding that the Puppet service resource does not support user-based services. I believe any implementation this the above use-cases would require an exec resource to enable or disable them.

Standalone User Service

Path: ~/.config/systemd/user/example.service
Command: systemctl --user enable example.service (as user)

Global User Service

Path: /etc/systemd/user/example.service
Command: systemctl --user --global enable example.service (as root)

References

• https://www.freedesktop.org/software/systemd/man/[email protected]
• https://wiki.archlinux.org/index.php/Systemd/User

Hello,

The readme gives the following example:

include systemd::systemctl::daemon_reload

file { '/usr/lib/systemd/system/foo.service':
  ensure => file,
  owner  => 'root',
  group  => 'root',
  mode   => '0644',
  source => "puppet:///modules/${module_name}/foo.service",
} ~> Class['systemd::systemctl::daemon_reload']

service {'foo':
  ensure    => 'running',
  subscribe => File['/usr/lib/systemd/system/foo.service'],
}

But from what I know, this won't force the daemon reload to happen before the service 'foo' is refreshed. Instead, it should be safer to have it explicitly set with a require:

service { 'foo':
  ensure    => 'running',
  subscribe => File['/usr/lib/systemd/system/foo.service'],
  require   => Class['systemd::systemctl::daemon_reload'],
}

Please let me know if I'm wrong here.

in manifests/resolved.pp
the $cache param is defined as:
Optional[Variant[Boolean,Enum['no-negative']]] $cache = $systemd::cache,

in init.pp , the no-negative option is not included.

It would be nice to be able to mask unit files using enable => mask but although this value is an accepted parameter, it doesn't set target => '/dev/null' as expected.

After updating to 3.0.0 limits configuration seems to be broken.
In the manifest I have:

systemd::service_limits { 'php7.4-fpm.service':
  limits => {
    'LimitNOFILE' => 1048576,
  }
}

Puppet applied this code and tried to perform service restart:
Exec[restart php7.4-fpm.service because limits]

But in fact, new limits were not applied, because of lack of daemon reload. By code I see there is call of:
systemctl restart php7.4-fpm.service

By running it by hand after puppet run, I got:

~# systemctl restart php7.4-fpm.service
Warning: The unit file, source configuration file or drop-ins of php7.4-fpm.service changed on disk. Run 'systemctl daemon-reload' to reload units.

So, I need to reload daemon manually, and then restart the service.

OS Debian 10.9
Puppet server 7.1.0
Puppet agent 7.5.0

When importing this module and then running spec tests I get the following:

Failure/Error: it { should compile.with_all_deps }
  error during compilation: Validation of Exec[systemctl-daemon-reload] failed: 'systemctl daemon-reload' is not qualified and no path was specified. Please qualify the command or specify a path. at /mnt/spec/fixtures/modules/systemd/manifests/init.pp:11

The fix appears to be to change:

  Exec {
    refreshonly => true,
    path        => $::path,
  }

to:

  Exec {
    refreshonly => true,
    path        => split($::path, ':'),
  }

Not sure if this breaks other things though.

The README currently says:

When configuring systemd::resolved you could set dns_stub_resolver to false (default) to use a standard /etc/resolved.conf, or you could set it to true to use the local resolver provided by systemd-resolved.

But the dns_stub_resolver parameter doesn't exist anywhere. There are dns_stub_listener and use_stub_resolver in systemd::resolved but neither do what is described above (which is, i guess, to leave resolv.conf alone?)

Anyways, this is rather all unclear and i suspect it should instead document whatever it is that use_stub_resolver does, but even that is not quite clear to me. :)

0.4.0 was pushed in August and service_limits was added in October.

I'll be submitting a PR as soon as I update the tests

It would be helpful if the README file had a complete example containing both a systemd::unit_file and a service resource. In particular, it wasn't immediately obvious that the ordering needs to be made explicit:

::systemd::unit_file { 'foo.service':
 source => "puppet:///modules/${module_name}/foo.service",
}

service { foo:
  enable  => true,
  ensure  => running,
  require => Systemd::Unit_file['foo.service']
}

Without the explicit ordering, Puppet will attempt to start the service before the unit file has been created.

There is no easy way to use
systemctl reload <service>
for a specified service. Puppet will always restart it.

I suggest adding some parameter like $use_reload to systemd::unit_file that will set the restart argument of service.

systemd provides a cron-like system replacement, through the use of unit configuration files that end in ".timer". These unit configurations encode information about timers controlled and supervised by systemd, for timer-based activation.

It would be excellent if this module provided a mechanism for managing these!

There are a few ini_setting resources being used in this module. It doesn't seem included in the requirement list. I'll do a MR if/when I have some time.

Hello,
i've following issue (Module Version 2.10):

In Hiera, i've the following Statement:

systemd::timer { 'mlocate-updatedb.timer':
active => true,
enable => true,
}

By a Puppet Run, he will created a Custom Timer File:

Notice: /Stage[main]/Profile::Linux::Rhel8/Systemd::Timer[mlocate-updatedb.timer]/Systemd::Unit_file[mlocate-updatedb.timer]/File[/etc/systemd/system/mlocate-updatedb.timer]/ensure: created (corrective)

But i've no Parameter like "service_content or service_source" defined and according to the Doku , the Default Value for both are "undefined". So i expect that he doesnt create a custom systemd Unit File.

It this a bug ?

Regards
Oliver

Hi,

In this commit:
97dd16f

you are dropping puppet 5 support. Unfortunately, in Debian, we were not able to package Puppet 6, due to some problems packaging jruby. So Bullseye will continue to contain Puppet 5. Therefore, I would like to kindly ask you to continue to support us for at least the following 2 to 3 years.

Cheers,

Thomas Goirand (zigo)

If I'm not mistaken there currently is no support for parameterized timer units, at least I have not found a way to model the result of these commands with the module:

systemctl enable borgwrapper-backup@<config_name>.timer
systemctl start borgwrapper-backup@<config_name>.timer

Could this be added or the documentation improved if this is already supported?

Error: Evaluation Error: Error while evaluating a Resource Statement, Evaluation Error: Unknown function: 'validate_hash'. at /etc/puppetlabs/code/environments/production/modules/systemd/manifests/service_limits.pp:13:5 at /etc/puppetlabs/code/environments/production/modules/systemd/foo.pp:1 on node localhost.localdomain

module should supply sensible defaults for systemd::accounting, because class fails, for example, on Amazon Linux, even though accounting is not used

If you were using MemoryLimit feature in systemd, your Puppet catalog will broke because of #18.

I think it would make more sense to use this module like this:

file { '/lib/systemd/system/my.service':
   [...]
} ~> Class[Systemd::DaemonReload]

Reasons I can think of:

• make code be easier to modify without changing interface
• make code more portable: one dist may need executing something, the other noop

Nvm.

Would you be willing to mark this code as released under a specific OSI license? That would make using it in a corporate setting easier. Thanks.

Description

systemd version: 219
module version: 2.12.0

definition of worker.target

root@tst-api01 ~ # systemctl cat worker.target
# /etc/systemd/system/worker.target
[Unit]
Description=Queue Workers
Wants=rabbitmq-server.service [email protected] api-default-queue

[Install]
WantedBy=multi-user.target

Definition of api-default-queue.service (instantiated from template) in hiera:

systemd::manage::unit_file:
  [email protected]:
    content: |
      [Unit]
      Description=default-queue-%i
      BindsTo=worker.target

      [Service]
      Type=simple
      ExecStart=FOO
      SyslogIdentifier=default-queue-%i
      Group=FOO
      User=FOO
      Restart=on-failure
      RestartSec=10
      TimeoutStartSec=10
  [email protected]:
    enable: true
    active: true

Expected behaviour:

Puppet tries to enables that unit but realizes that it's a static unit and does nothing.

Actual behaviour

Puppet restarts the unit

Debug: Executing: '/bin/systemctl is-enabled -- [email protected]'
Debug: Executing: '/bin/systemctl unmask -- [email protected]'
Debug: Executing: '/bin/systemctl enable -- [email protected]'
Debug: Executing: '/bin/systemctl is-enabled -- [email protected]'
Debug: Unable to enable or disable static service [email protected]
Notice: /Stage[main]/Systemd::Manage/Systemd::Unit_file[[email protected]]/Service[[email protected]]/enable: enable changed 'false' to 'true'

leads to

Feb 20 19:18:28 prd-api01 systemd[1]: Stopped api-default-queue-1.
Feb 20 19:18:28 prd-api01 systemd[1]: Started api-default-queue-1.

Suggested behaviour:

It's eventually a clash of responsibilites between systemd and puppet. Meaning: "who is, in the end, reponsible for managing the state of that unit". With harder dependencies, it seems to rather be within system`s jurisdiction, on the other hand though, when there are no hard bindings between units, it makes sense for puppet to manage that unit.

Since it obviously does not make sense for the module to try to understand the interdependency between defined units (in order to not allow enable: true for static units), I'd suggest that this module accepts "static" as a valid return-value (instead of only "enable" now, probably - not verified) for systemctl is-enabled $UNIT.

As far as I understand one should be able to set the value of Cache to 'yes' or 'no' in /etc/systemd/resolved.conf via systemd::resolved.

But in systemd::resolved the variable named $cache is a Boolean and if it is set to false, the value does not get rendered to /etc/systemd/resolved.conf:

$_cache = $cache ? {
    true    => 'yes',
    false   => 'no',
  }

  if $cache {
    ini_setting{ 'cache':
      ensure  => 'present',
      value   => $_cache,
      setting => 'Cache',
      section => 'Resolve',
      path    => '/etc/systemd/resolved.conf',
      notify  => Service['systemd-resolved'],
    }
  }

So only setting it to true will render it to the file with Cache=yes (which under Ubuntu is the default anyway) and one can never set Cache=no. Because using only a Boolean will mean you have to render it out everywhere (even on installations where you are not concerned with this value and would like not to have this file modified), I would hope for a different solution (e.g. not using a Boolean or two variables).

Thank you so much!

Red Hat Enterprise Linux 7 Security Technical Implementation Guide
Release: 4
Benchmark Date: 26 Jan 2018
Vuln ID: V-72065
Rule ID: SV-86689r1_rule
STIG ID: RHEL-07-021340

Check Text: Verify that a separate file system/partition has been created for "/tmp".
Check that a file system/partition has been created for "/tmp" with the following command:
# systemctl is-enabled tmp.mount
enabled
If the "tmp.mount" service is not enabled, this is a finding.
Fix Text: Start the "tmp.mount" service with the following command:
# systemctl enable tmp.mount

It is not obvious if the module will do this, but I am going to give it a try

I would like to clean up entries older than n days.
A cleanup option $vacuum_time='35d' which results in a daily cron entry

journalctl --vacuum-time=35d 

would be fine.
One could consider --vacuum-size and --vacuum-files, too.

Using systemd::unit_file in multiple, strictly ordered classes, causes a cyclic dependency error.

Consider the following code:

1. Role:

class role::base {
  contain profile::systemd
  contain profile::base_os
  contain profile::monitoring

  Class['profile::systemd']
  -> Class['profile::base_os']
  -> Class['profile::monitoring']
}

2. Profiles
   2.1. profile::systemd

class profile::systemd {
  class { 'systemd':
    manage_resolved => false,
    manage_networkd => false,
  }
}

2.2. profie::base_os

class profile::base_os {
  systemd::unit_file { 'remove_check_mk_cache.service':
    content => file('profile/remove_checkmk_cache.service'),
    active  => true,
    notify  => Service['remove_check_mk_cache'],
  }
  service { 'remove_check_mk_cache':
    ensure => running,
    enable => true,
    require => Class['systemd::systemctl::daemon_reload'],
  }
}

2.3. profile::monitoring

class profile::monitoring {
  systemd::unit_file { 'send_downtime.service':
    content => file('profile/send_downtime.service'),
    active  => true,
    notify  => Service['send_downtime'],
  }
  service { 'send_downtime':
    ensure => running,
    enable => true,
    require => Class['systemd::systemctl::daemon_reload'],
  }
}

Unit tests or using this code on a system produce cyclic dependency error:

role::base on centos-7-x86_64 is expected to compile into a catalogue without dependency cycles
     Failure/Error: it { is_expected.to compile }
       dependency cycles found: (Exec[systemctl-daemon-reload] => Class[Systemd::Systemctl::Daemon_reload] => Service[remove_check_mk_cache] => Class[Profile::Base_os] => Class[Profile::Monitoring] => Systemd::Unit_file[send_downtime.service] => File[/etc/systemd/system/send_downtime.service] => Class[Systemd::Systemctl::Daemon_reload] => Exec[systemctl-daemon-reload])
     # ./spec/classes/base_spec.rb:10:in `block (4 levels) in <top (required)>'

Hi,

When running Puppet interactively the value of $::path might differ from background runs as the former is taken from the login shell. This generates a catalog diff that perhaps will not apply any change on the target system but it will force a catalog replacement on PuppetDB which is kind of unnecessary IMHO.

I, [2018-02-27T09:38:52.953787 #3195]  INFO -- : Catalogs compiled for foo.example.com
I, [2018-02-27T09:38:54.314022 #3195]  INFO -- : Diffs computed for foo.example.com
  Exec[systemctl-daemon-reload] =>
   parameters =>
     path =>
      - /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin
      + /usr/sue/sbin:/usr/sue/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/opt/puppetlabs/bin:/root/bin:/sbin

https://github.com/camptocamp/puppet-systemd/blob/20a465b0d8751bc08913b556d0a5b7fdac139271/manifests/systemctl/daemon_reload.pp#L8

Regex error when tying to set CPUQuota service limit.

systemd::service_limits { 'foo.service':
  limits => {
    'CPUQuota' => '75%'
  }
}

The first part of the regex Optional['CPUQuota'] => Pattern['^([1-9][0-9]?$|^100)%$'], never allows a value < 100%

Seems to be working with the '^([1-9][0-9]?|^100)%$' regex (Tested regex with https://www.freeformatter.com/regex-tester.html)

Due to systemd design, this module is not indempotent.

The problem

include ::systemd
file { '/usr/lib/systemd/system/foo.service':
  ensure => file,
  owner  => 'root',
  group  => 'root',
  mode   => '0644',
  source => "puppet:///modules/${module_name}/foo.service",
} ~>
Exec['systemctl-daemon-reload']

service{
  'foo':
    ensure => started,
    subscribe => File['/usr/lib/systemd/system/foo.service']
    require => Exec['systemctl-daemon-reload']
  }
}

file { '/usr/lib/systemd/system/foo2.service':
  ensure => file,
  owner  => 'root',
  group  => 'xyz',
  mode   => '0644',
} ~>
Exec['systemctl-daemon-reload']

First run:

• File[foo.service] is changed
• File[foo2.service] file fails during catalog execution (imagine that group xyz does not exist)
• Exec['systemctl-daemon-reload'] is not called because File[foo2] failed
• Service[foo] is not restarted because Exec['systemctl-daemon-reload'] is skipped

Fix File[foo2.service].

Second run:

• File[foo.service] is not changed
• File[foo2.service] file is changed
• Exec['systemctl-daemon-reload'] istriggered
• Service[foo] is not restarted because File[foo.service]has not been changed uring this run.

Proposal

Use Defines instead of classee

file { '/usr/lib/systemd/system/foo.service':
  ensure => file,
  owner  => 'root',
  group  => 'root',
  mode   => '0644',
  source => "puppet:///modules/${module_name}/foo.service",
} ~>
systemd::daemonreload{
  'foo.service':
}

service{
  'foo':
    ensure => started,
    subscribe => File['/usr/lib/systemd/system/foo.service']
    require => Systemd::Daemonreload['foo']
  }
}

file { '/usr/lib/systemd/system/foo2.service':
  ensure => file,
  owner  => 'root',
  group  => 'root',
  mode   => '0644',
  source => "NONEXISTANT",
} ~>
systemd::daemonreload{
  'foo2.service':
}

Upides of proposal

It makes the module indempotent if used as described here.

Downsides

calling systemd daemon-reload is blocking and may cause problems in very large systems.

Mitigation: Use only one reload.

Backwards compatibility: Offer a class which contains systemd::daemonreload {'generic':}

TODO

• Collect some comments
• Implement the define
• Implement backward compatibility
• Document that in README

Should be great if one could publish a new version to the forge

Grts and Thx

Johan