GitHub puppet-systemd
Puppet module to manage systemd

Repo Checks ( 21 of 32 successfull )
Metadata Valid
No translation
passed
Correct Puppet Version Range
Supported Puppet version range is %{PUPPET_SUPPORT_RANGE}
passed
With Puppet Version Range
Puppet version range is present in requirements in metadata.json
passed
With Operatingsystem Support
No translation
passed
Operatingsystems
No translation
passed
Supports Only Current Debian
No translation
failed
Supports Latest Debian
No translation
passed
Supports Only Current Ubuntu
No translation
failed
Supports Latest Ubuntu
No translation
failed
Supports Only Current Sles
No translation
passed
Supports Latest Sles
No translation
failed
Supports Only Current Redhat
No translation
passed
Supports Latest Redhat
No translation
passed
Supports Only Current Virtuozzolinux
No translation
passed
Supports Latest Virtuozzolinux
No translation
failed
Supports Only Current Centos
No translation
passed
Supports Latest Centos
No translation
passed
Supports Only Current Oraclelinux
No translation
passed
Supports Latest Oraclelinux
No translation
failed
Supports Only Current Archlinux
No translation
failed
Supports Latest Archlinux
No translation
failed
Supports Only Current Gentoo
No translation
failed
Supports Latest Gentoo
No translation
failed
Supports Only Current Fedora
No translation
passed
Supports Latest Fedora
No translation
failed
In Modulesync Repo
Is listed as a module managed using modulesync_config
passed
Synced
Has a .msync.yml file
passed
Latest Modulesync
Has been synchronized with the latest tagged version of modulesync_config
passed
Has Modulesync
Is present in voxpupuli/modulesync_config/managed_modules.yml
passed
Released
Is in modulesync_config and in forge releases.
passed
Valid Sync File
If a (optional) sync file is present, it must not contain a `.travis.yml` entry.
passed
Reference Dot Md
The repository has a REFERENCE.md. It needs to be generated / puppet-strings documentation is missing.
passed

Open Pull Requests

Remove restart_service on service_limits define
merge-conflicts
backwards-incompatible
backwards-incompatible

Since 97dd16fa32886b5b0f77a6f38a4953d4c1511c0e this parameter is a bad idea. It doesn't do a daemon reload and it may restart at the wrong time. In fact, I'd argue it's always been a bad idea.

The recommended alternative to this is to manage the service explicitly and let Puppet handle it. There is an automatic notify that takes care of it.

Fixes #190

Open PR in GitHub
Notify services by default on drop in files

This builds on 81f3eb5e7612e50726fa8450ca161bbe271419a1 which allowed services to be notified automatically. This changes it to default behavior.

Fixes #74

It's currently a draft since it includes https://github.com/camptocamp/puppet-systemd/pull/193 which I think it may depend on.

Open PR in GitHub
systemd::unit_file: remove hasrestart/hasstatus params
backwards-incompatible
backwards-incompatible

This removes two parameters from systemd::unit_file. In release 3.8.0 on 2022-03-02 we introcuced the deprecation warnings. We should merge this PR somewhere in the future when we've other breaking changes. Do not merge at the moment!

Open PR in GitHub
Add a socket_service definition

For systemd socket activated services it's needed to have both the .socket and .service unit defintions in place when starting the service. Prior to 97dd16fa32886b5b0f77a6f38a4953d4c1511c0e the systemctl daemon-reload took care of it, but now this must be done explicitly.

This new defined type makes it easy and reduces the burden on modules that define the unit/service pair.

I haven't tested this yet, but submitting it early so I can run CI on it and link it elsewhere.

Open PR in GitHub
Update supported OS releases
backwards-incompatible

Drop a few OS releases that are EOL and add some fresh Fedora ones.

Open PR in GitHub
[RFC] add udevadm & udev facts

I want to be able to identify / construct the /dev/disk/by-id/<foo> paths for nvme devices on Linux to be used in EL kickstart scripts and have been unable to identify an existing fact which makes this data available.

The approach taken with the udev fact is to dump the entire udev dev db as it seems likely that there will be other uses for this data. Devices without a /dev/<foo> file are filtered out (E.g. ACPI devices). Even with filtering, this is a fairly large structured fact as the data describes every file under /dev.

QUESTION(S):
* Is this module the correct place for these facts?
* Is there a use case for information on devices which do not have a block/special file?
* Is the data structure of this fact reasonable?
* Should the /dev devices be moved under a sub hash key such as udev::dev::<device name> to allow for all devices to be exposed as udev::path::<device> in the future?

Example CLI usage of the `udev fact:

bash
$ FACTERLIB=$(pwd)/lib/facter be facter udev.nvme0n1
{
name => "nvme0n1",
path => "/devices/pci0000:00/0000:00:01.0/0000:01:00.0/nvme/nvme0/nvme0n1",
priority => 0,
property => {
CURRENT_TAGS => ":systemd:",
DEVLINKS => [
"/dev/disk/by-id/nvme-Samsung_SSD_960_EVO_1TB_S3ETNX0J208970A",
"/dev/disk/by-path/pci-0000:01:00.0-nvme-1",
"/dev/disk/by-id/nvme-eui.0025385271b166c9"
],
DEVNAME => "/dev/nvme0n1",
DEVPATH => "/devices/pci0000:00/0000:00:01.0/0000:01:00.0/nvme/nvme0/nvme0n1",
DEVTYPE => "disk",
DISKSEQ => "3",
ID_MODEL => "Samsung SSD 960 EVO 1TB",
ID_PART_TABLE_TYPE => "gpt",
ID_PART_TABLE_UUID => "369c0ca0-758a-44d5-abe3-0d81c7a73b51",
ID_PATH => "pci-0000:01:00.0-nvme-1",
ID_PATH_TAG => "pci-0000_01_00_0-nvme-1",
ID_REVISION => "2B7QCXE7",
ID_SERIAL => "Samsung_SSD_960_EVO_1TB_S3ETNX0J208970A",
ID_SERIAL_SHORT => "S3ETNX0J208970A",
ID_WWN => "eui.0025385271b166c9",
MAJOR => "259",
MINOR => "0",
SUBSYSTEM => "block",
TAGS => ":systemd:",
USEC_INITIALIZED => "63550668378"
},
symlink => [
"disk/by-id/nvme-Samsung_SSD_960_EVO_1TB_S3ETNX0J208970A",
"disk/by-path/pci-0000:01:00.0-nvme-1",
"disk/by-id/nvme-eui.0025385271b166c9"
]
}
$ FACTERLIB=$(pwd)/lib/facter be facter udev.nvme0n1.symlink
[
"disk/by-path/pci-0000:01:00.0-nvme-1",
"disk/by-id/nvme-Samsung_SSD_960_EVO_1TB_S3ETNX0J208970A",
"disk/by-id/nvme-eui.0025385271b166c9"
$ FACTERLIB=$(pwd)/lib/facter be facter udev.nvme0n1.property.DEVLINKS
[
"/dev/disk/by-id/nvme-Samsung_SSD_960_EVO_1TB_S3ETNX0J208970A",
"/dev/disk/by-id/nvme-eui.0025385271b166c9",
"/dev/disk/by-path/pci-0000:01:00.0-nvme-1"
]
$ FACTERLIB=$(pwd)/lib/facter be facter udev.nvme0n1.property.ID_SERIAL
Samsung_SSD_960_EVO_1TB_S3ETNX0J208970A

Open PR in GitHub
add manage_network to manage networks in code

add managenetwork so that one can define networks in code like one can do it with unitfiles and manage_unit.

missing:
- maybe more complex types to check the *entry in managenetwork like in manageunit.
- assert
Type does somehow not work in my local tests (Says its expecting a Resource Statement but got String)

early tests with code like this seem to work

```
include systemd

systemd::managenetwork { 'myhome.network':
match
entry => {
'Name' => 'enp0s8',
},
networkentry => {
'Address' => '10.1.1.1/24',
'Gateway' => '10.1.1.1',
},
address
entry => {
'Address' => '10.1.1.2',
},
}
```

Open PR in GitHub
modulesync 5.4.0
modulesync

modulesync 5.4.0

Open PR in GitHub
Test beaker-hcloud
skip-changelog

<!--
Thank you for contributing to this project!

-->

Pull Request (PR) description

<!--
Replace this comment with a description of your pull request.
-->

This Pull Request (PR) fixes the following issues

<!--
Replace this comment with the list of issues or n/a.
Use format:
Fixes #123
Fixes #124
-->

Open PR in GitHub
Add support for timezone and hardware clock

<!--
Thank you for contributing to this project!

-->

Pull Request (PR) description

Add support for timedatectl to set timezone and hardware clock

This Pull Request (PR) fixes the following issues

Fixes: #377

Open PR in GitHub
fix: refresh service only based on drop-in file changes
enhancement

Pull Request (PR) description

Since multiple drop-in files of the same unit notify the same Systemd::Daemon_reload resource, changing a drop in file without notify_service still triggers a service refresh if at least one other drop-in file has notify_service set (default) regardless of it being changed.

Therefore, the Systemd::Daemon_reload should only be ordered before the Service but not notify it. The service will already be refreshed if the drop-in file changes and notify_service is set (default).

This Pull Request (PR) addresses the following issues

Consider the following Puppet code snippet with two drop-in files for the service nginx.service:

```Puppet
systemd::dropinfile {
default:
unit => 'nginx.service',
;
"restart.conf":
notify
service => false,
content => @(EOT)
[Service]
Restart=on-failure
| EOT
,
;
"ulimit.conf":
content => @(EOT)
[Service]
LimitNOFILE=4096
| EOT
,
}

``
On the first Puppet-run, this code will correctly refresh the service, as the
ulimit.conf`-file will be written. Once the drop-in files are in sync with this configuration, no more SystemD daemon reloads and service refreshes happen.

Now, changing the Restart configuration of nginx.service doesn't need the service itself to be restarted.

However, due to the second drop-in file specifying notify_service => true (default), this will lead to Systemd::Daemon_reload[$unit] being triggered (expected due to daemon_reload => true (default)), which then in turn triggers Service[nginx.service] and Service[nginx] if they exist.

Open PR in GitHub
Add options to manage file system access options to Service
needs-tests
enhancement

Add options to manage file system access options to Service

Added in version 231, systemd provides options to manage file system access options to processes executed by systemd services. Adding these as valid options.

See https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html#ReadWritePaths= for docs.

This Pull Request (PR) fixes the following issues

n/a

Open PR in GitHub