--- /dev/null
+# Systemd
+
+[](https://forge.puppetlabs.com/camptocamp/systemd)
+[](https://travis-ci.org/camptocamp/puppet-systemd)
+
+## 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.
+
+```puppet
+systemd::unit_file { 'foo.service':
+ source => "puppet:///modules/${module_name}/foo.service",
+}
+~> service {'foo':
+ ensure => 'running',
+}
+```
+
+Or handle file creation yourself and trigger systemd.
+
+```puppet
+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.
+
+```puppet
+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:
+
+```puppet
+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:
+
+```puppet
+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
+
+```puppet
+systemd::tmpfile { 'foo.conf':
+ source => "puppet:///modules/${module_name}/foo.conf",
+}
+```
+
+Or handle file creation yourself and trigger systemd.
+
+```puppet
+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.
+
+```puppet
+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.
+
+```puppet
+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:
+
+```puppet
+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:
+
+```puppet
+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:
+
+```puppet
+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](https://www.freedesktop.org/software/systemd/man/systemd-system.conf.html).
+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`:
+
+```puppet
+class{'systemd':
+ manage_accounting => true,
+ accounting => {
+ 'DefaultCPUAccounting' => 'yes',
+ 'DefaultMemoryAccounting' => 'no',
+ }
+}
+```
projects / mirror / dsa-puppet.git / blobdiff