GitHub puppet-systemd

Puppet module to manage systemd

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

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.

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!

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.

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

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


modulesync 5.4.0

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

• This project has a Contributor Code of Conduct: https://voxpupuli.org/coc/
• Please check that here is no existing issue or PR that addresses your problem.
• Our vulnerabilities reporting process is at https://voxpupuli.org/security/

-->

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
-->

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

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.
- assertType 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':
matchentry => {
'Name' => 'enp0s8',
},
networkentry => {
'Address' => '10.1.1.1/24',
'Gateway' => '10.1.1.1',
},
addressentry => {
'Address' => '10.1.1.2',
},
}
```

This PR might improve speed of rspec tests, ~2k test cases removed.

OS independent tests will be executed only once instead of running for each supported platform.

This gives the possibility to manage all network/netdev/link settings from hashes.

I'm aware of pull request #340 from @rwaffen which started an equal solution last year.
Since the development there does not seem to go on, I started this solution which currrently
gives us the opportunitiy to create any configuration stated in the systemd documentation.

All type defintions are taken out of systemd documentation (not documented, not in our type defintion).
I'm aware, that some types could defined more accurate, but I tried to get a compromise inbetween accurate type and
workload ;).

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

• This project has a Contributor Code of Conduct: https://voxpupuli.org/coc/
• Please check that here is no existing issue or PR that addresses your problem.
• Our vulnerabilities reporting process is at https://voxpupuli.org/security/

-->

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
-->