Add capability to manage /etc/systemd/*.conf files about puppet-systemd HOT 11 CLOSED

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.

from puppet-systemd.

from puppet-systemd.

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.

from puppet-systemd.

from puppet-systemd.

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.

from puppet-systemd.

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?

from puppet-systemd.

@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. :)

from puppet-systemd.

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.

from puppet-systemd.

Thanks, I think this could be closed.

from puppet-systemd.

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?

from puppet-systemd.

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.

from puppet-systemd.