systemd

partner
Puppet Systemd module - Temporary Fork

SIMP

simp

5,757 downloads

5,104 latest version

5.0 quality score

Version information

  • 2.1.0 (latest)
  • 1.1.1
released Oct 15th 2018
This version is compatible with:
  • Puppet Enterprise 2018.1.x, 2017.3.x, 2016.4.x
  • Puppet >= 4.10.10 < 6.0.0
  • Debian
    ,
    Ubuntu
    ,
    RedHat
    ,
    CentOS
    , Archlinux

Start using this module

Documentation

simp/systemd — version 2.1.0 Oct 15th 2018

Systemd


THIS IS A FORK OF THE MODULE AND WILL REVERT TO THE ORIGINAL MODULE ONCE THE SIMP PACKAGING SYSTEM HAS BEEN UPDATED.


Puppet Forge Build Status

Overview

This module declares exec resources to create global sync points for reloading systemd.

Version 2 and newer of the module don't work with Hiera 3! You need to migrate your existing Hiera setup to Hiera 5

Usage and examples

There are two ways to use this module.

unit files

Let this module handle file creation and systemd reloading.

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

Or handle file creation yourself and trigger systemd.

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'],
}

You can also use this module to more fully manage the new unit. This example deploys the unit, reloads systemd and then enables and starts it.

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

drop-in files

Drop-in files are used to add or alter settings of a unit without modifying the unit itself. As for the unit files, the module can handle the file and directory creation and systemd reloading:

systemd::dropin_file { 'foo.conf':
  unit   => 'foo.service',
  source => "puppet:///modules/${module_name}/foo.conf",
}
~> service {'foo':
  ensure    => 'running',
}

Or handle file and directory creation yourself and trigger systemd:

include systemd::systemctl::daemon_reload

file { '/etc/systemd/system/foo.service.d':
  ensure => directory,
  owner  => 'root',
  group  => 'root',
}

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

service {'foo':
  ensure    => 'running',
  subscribe => File['/etc/systemd/system/foo.service.d/foo.conf'],
}

tmpfiles

Let this module handle file creation and systemd reloading

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

Or handle file creation yourself and trigger systemd.

include systemd::tmpfiles

file { '/etc/tmpfiles.d/foo.conf':
  ensure => file,
  owner  => 'root',
  group  => 'root',
  mode   => '0644',
  source => "puppet:///modules/${module_name}/foo.conf",
}
~> Class['systemd::tmpfiles']

service limits

Manage soft and hard limits on various resources for executed processes.

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

Or provide the configuration file yourself. Systemd reloading and restarting of the service are handled by the module.

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

network

systemd-networkd is able to manage your network configuration. We provide a defined resource which can write the interface configurations. systemd-networkd needs to be restarted to apply the configs. The defined resource can do this for you:

systemd::network{'eth0.network':
  source          => "puppet:///modules/${module_name}/eth0.network",
  restart_service => true,
}

Services

Systemd provides multiple services. Currently you can manage systemd-resolved, systemd-timesyncd and systemd-networkd via the main class:

class{'systemd':
  manage_resolved  => true,
  manage_networkd  => true,
  manage_timesyncd => true,
}

$manage_networkd is required if you want to reload it for new systemd::network resources. Setting $manage_resolved will also manage your /etc/resolv.conf.

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.

It is possible to configure the default ntp servers in /etc/systemd/timesyncd.conf:

class{'systemd':
  manage_timesyncd    => true,
  ntp_server          => ['0.pool.ntp.org', '1.pool.ntp.org'],
  fallback_ntp_server => ['2.pool.ntp.org', '3.pool.ntp.org'],
}

This requires puppetlabs-inifile, which is only a soft dependency in this module (you need to explicitly install it). Both parameters accept a string or an array.

Resource Accounting

Systemd has support for different accounting option. It can track CPU/Memory/Network stats per process. This is explained in depth at systemd-system.conf. This defaults to off (default on most operating systems). You can enable this with the $manage_accounting parameter. The module provides a default set of working accounting options per operating system, but you can still modify them with $accounting:

class{'systemd':
  manage_accounting => true,
  accounting        => {
    'DefaultCPUAccounting'    => 'yes',
    'DefaultMemoryAccounting' => 'no',
  }
}