rsyslog::snippet? about puppet-rsyslog HOT 8 CLOSED

I vote for this enhancement proposal (I'm moving from saz/rsyslog too).
Configuration options are not always available at hiera level, but in my role&profile structure I have syslog options configuring from profiles.
Using a file resource is not an option, because of the order (how can I create a rule with a file between other two rules created from config?).
I think I that directly using rsyslog::component::* defined types could be a workaround but I'm not sure if these are designed for only for internal use or they could be use outside this module too.

from puppet-rsyslog.

We can look into the viability, however this module's primary target rsyslog version is Rsyslog 8.x and greater and as such we can't break that functionality.

Additionally, https://forge.puppet.com/saz/rsyslog should no longer be deprecated on the forge.

from puppet-rsyslog.

The feature in saz/rsyslog literally just wraps a file resource that places the content specified in the correct place. Super simple.

See: https://github.com/saz/puppet-rsyslog/blob/master/manifests/snippet.pp

We want this feature because we have a use case where other modules want to add rsyslog config directly - i.e. the config is tied to the module, not the hiera data. Maybe not best practice, but - meh - it's a real world compromise.

In the interim, we have these modules drop config in the /etc/rsyslog.d/ directory, by just using a file resource. But this means we have to turn off the purging of files in the rsyslog module.

I would strongly prefer that all config was managed by the puppet module, and they I can safely purge anything else.

from puppet-rsyslog.

@christazelaar Unfortunately, unless more users request this feature, it will probably not come to fruition. The option to purge or not purge /etc/rsyslog.d is there specifically for your use case (as is custom config). The purpose of this module was to provide support for rsyslog >= 7/8, specifically rainerscript, which saz/rsyslog doesn't easily support.

I will leave this open for comment for one more month, but as there are few with time to maintain this module, we would need more users that want/need this before implementing it.

from puppet-rsyslog.

What would you need for me to write the patch for you? I was mostly concerned that there were designer philosophical objections to the idea.

from puppet-rsyslog.

Feel free to contribute a PR for this change if you need it. I can definitely say we'll review it and give feedback if necessary.

from puppet-rsyslog.

For what it's worth, I'm not sure that I'll actually use this anymore. The module is now sufficiently different than the original saz module as to require a complete refactor of everything syslog.

My short, untested code that I wrote before I realized just how different it is:

`define rsyslog::snippet (
String $content = '',
Enum['present', 'absent'] $ensure = 'present',
Variant[Undef, String] $file_mode = '0644',
String $group = 'root'
) {
include ::rsyslog

$name_real = regsubst($name,'[/ ]','-','G')

file { "${rsyslog::confdir}${name_real}.conf":
ensure => $ensure,
owner => 'root',
group => 'root',
mode => $file_mode,
content => "# This file is managed by Puppet, changes may be overwritten\n${content}\n",
require => Class['rsyslog::config'],
notify => Class['rsyslog::base'],
}

}`

from puppet-rsyslog.

This is only one possible solution.
Another solution would be to create the defined resource type rsyslog::snippet that just calls rsyslog::component::custom_config with these parameters.
Any feedback would be appreciated.

from puppet-rsyslog.