voxpupuli / puppet-systemd Goto Github PK
View Code? Open in Web Editor NEWPuppet module to manage systemd
Home Page: https://forge.puppet.com/puppet/systemd
License: Apache License 2.0
Puppet module to manage systemd
Home Page: https://forge.puppet.com/puppet/systemd
License: Apache License 2.0
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
.
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.
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.
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:
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)
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.
0.4.0 was pushed in August and service_limits was added in October.
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.
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?
Since content this is just passed through to a file resource allow to pass Sensitive values also
Please add merge options, so one can add entries in all hiera layers.
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.
common.yaml:
# ...
lookup_options:
systemd::loginctl_users:
merge: deep
# ...
Thank you
#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.
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.
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.
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)
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
Should be great if one could publish a new version to the forge
Grts and Thx
Johan
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)
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.
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.
Can support for drop-in files to override package units be added to this module?
Please mark the old camptocamp module as deprecated, so that people (and API using programs) see the transfer to the new author.
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!
If you were using MemoryLimit feature in systemd, your Puppet catalog will broke because of #18.
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]
.
class demo {
class { 'systemd':
manage_resolved => true,
resolved_ensure => 'stopped',
}
file { '/etc/resolv.conf':
ensure => 'file',
}
}
Catalog compilation fails with with a duplicate resource declaration error.
File[/etc/resolv.conf]
should not be managed when systemd-resolved
is managed to the stopped
state.
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 ...
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
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+)$'],
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?
Camptocamp module has issues with puppet 4 at the moment.
#18
Utilizing justin8's module until camptocamp has the issues resolved.
Using systemd::unit_file in multiple, strictly ordered classes, causes a cyclic dependency error.
Consider the following code:
class role::base {
contain profile::systemd
contain profile::base_os
contain profile::monitoring
Class['profile::systemd']
-> Class['profile::base_os']
-> Class['profile::monitoring']
}
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)>'
I'll be submitting a PR as soon as I update the tests
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
Due to systemd design, this module is not indempotent.
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 changedFile[foo2.service]
file fails during catalog execution (imagine that group xyz does not exist)Exec['systemctl-daemon-reload']
is not called because File[foo2] failedService[foo]
is not restarted because Exec['systemctl-daemon-reload']
is skippedFix File[foo2.service]
.
Second run:
File[foo.service]
is not changedFile[foo2.service]
file is changedExec['systemctl-daemon-reload']
istriggeredService[foo]
is not restarted because File[foo.service]
has not been changed uring this run.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':
}
It makes the module indempotent if used as described here.
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':}
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
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.
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
.
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.
Path: ~/.config/systemd/user/example.service
Command: systemctl --user enable example.service
(as user)
Path: /etc/systemd/user/example.service
Command: systemctl --user --global enable example.service
(as root)
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!
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.
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
The README currently says:
When configuring
systemd::resolved
you could setdns_stub_resolver
tofalse
(default) to use a standard /etc/resolved.conf, or you could set it totrue
to use the local resolver provided bysystemd-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. :)
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
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'
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
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
.
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.
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
Nvm.
module should supply sensible defaults for systemd::accounting, because class fails, for example, on Amazon Linux, even though accounting is not used
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 ...
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.