Add capability to manage /etc/systemd/*.conf files

[micah]

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.

[traylenator]

I think anything generic would just be a trivial wrapper around puppetlabs-inifile so may as well just use inifile type.
The benefit of having things in this module is the strong validation.

[micah]

On 2021-10-06 08:13:31, Steve Traylen wrote: I think anything generic would just be a trivial wrapper around puppetlabs-inifile so may as well just use inifile type.

Agreed, I've used the `puppetlabs-inifile` for the configuration myself, for example: ``` ini_setting { 'ManageForeignRoutes': ensure => present, path => '/etc/systemd/networkd.conf', section => 'Network', setting => 'ManageForeignRoutes', value => 'false' } ```

The benefit of having things in this module is the strong validation.

Precisely.

[kenyon]

Many of those configs can already be managed with this module. See https://github.com/voxpupuli/puppet-systemd/tree/master/manifests where we have journald.pp, logind.pp, networkd.pp, system.pp, and timesyncd.pp.

[micah]

On 2021-10-06 12:10:39, Kenyon Ralph wrote: Many of those configs can already be managed with this module. See https://github.com/voxpupuli/puppet-systemd/tree/master/manifests where we have `journald.pp`, `logind.pp`, `networkd.pp`, `system.pp`, and `timesyncd.pp`.

If you look at https://github.com/voxpupuli/puppet-systemd/blob/master/manifests/networkd.pp you will find that the `/etc/systemd/networkd.conf` is not managed by that file.

[kenyon]

Sounds like that would be something nice to add with a pull request if you need that functionality. I use this module to configure my systems to use systemd-networkd, but didn't need to change anything in /etc/systemd/networkd.conf.

[n3mawashi]

I think the benefit of this module is to allow hiera to manage most of the data change, which when looking at the mentioned services is the creation of ".d" directories, file creation with content and reload of service. This seems more than just a simple wrapper of the "puppetlabs-inifile" library.

I'm sure that with a little bit of tweeting, we can get systemd::dropin to do the heavy lifting. Is anyone working on a PR for this? If not, I might look to raise one?

[geor-g]

@ptiggerdine Can't tell if someone is working on this, but I believe it would be valuable if someone did, and so far no one raised their voice. Therefore, please do. :)

[traylenator]

Since ticket was written , logind.conf , crashcore.conf journald.conf and others are all supported.

Doing each file one file at a time makes sense.

Configuring systemd-X.conf is often more than just doing the file, e.g packages have to be installed , services restarted ,...

Re the networkd.conf for sure open a particular issue.

Can we close this.

[micah]

Thanks, I think this could be closed.

[derekmpage]

I really don't understand the logic and decision here to "not" control /etc/systemd/*.conf files.
After all this is the systemd module but we can't configure basic systemd settings.

Then someone goes and does something like this?

https://github.com/voxpupuli/puppet-systemd/blob/master/manifests/system.pp#L8

Technically, I can define any setting in system.conf with this very class, however the was implemented to only consider accounting settings and forces them.

So something like this:

hiera.yaml

---
systemd::manage_accounting: true
systemd::accounting:
    DefaultLimitNOFILE: '1024:262144'

results:

nfo: Applying configuration version '1706563751'
Notice: /Stage[main]/Systemd::System/Ini_setting[DefaultCPUAccounting]/ensure: created
Notice: /Stage[main]/Systemd::System/Ini_setting[DefaultBlockIOAccounting]/ensure: created
Notice: /Stage[main]/Systemd::System/Ini_setting[DefaultMemoryAccounting]/ensure: created
Notice: /Stage[main]/Systemd::System/Ini_setting[DefaultTasksAccounting]/ensure: created
Notice: /Stage[main]/Systemd::System/Ini_setting[DefaultIOAccounting]/ensure: created
Notice: /Stage[main]/Systemd::System/Ini_setting[DefaultIPAccounting]/ensure: created
Notice: /Stage[main]/Systemd::System/Ini_setting[DefaultLimitNOFILE]/value: value changed [redacted sensitive information] to [redacted sensitive information]

Why not make make make control of these files configurable?

manage_system_conf: BOOL
manage_user_conf: BOOL
manage_network_conf: BOOL
...

I would be happy to submit a PR but I don't want to put in the effort if the community does not agree with this module taking control of these files.

Thoughts?

[kenyon]

I really don't understand the logic and decision here to "not" control /etc/systemd/*.conf files. After all this is the systemd module but we can't configure basic systemd settings.

@derekmpage there is no such single thing as "/etc/systemd/*.conf". There are files matching that pattern, some of which can be managed with this module. See #232 (comment)

Then someone goes and does something like this?

https://github.com/voxpupuli/puppet-systemd/blob/master/manifests/system.pp#L8

That was added in 2018 with #65. This issue was created in 2021.

Why not make make make control of these files configurable?

manage_system_conf: BOOL
manage_user_conf: BOOL
manage_network_conf: BOOL
...

I would be happy to submit a PR but I don't want to put in the effort if the community does not agree with this module taking control of these files.

Thoughts?

Being able to manage more of system.conf, and systemd in general, sounds like a good enhancement to me.