Now I tried this:
exec {"/bin/rm -f ${icinga::baseconfigdir}/${conf_file_hosts}":
require => File["${icinga::baseconfigdir}"],
}
Nagios_host <<||>> {
target => "${icinga::baseconfigdir}/${conf_file_hosts}",
require => Exec["/bin/rm -f ${icinga::baseconfigdir}/${conf_file_hosts}"],
before => File["${icinga::baseconfigdir}/${conf_file_hosts}"],
}
file { "${icinga::baseconfigdir}/${conf_file_hosts}":
ensure => "present",
owner => "puppet",
group => "puppet",
mode => "0644",
backup => false,
replace => false,
}
This created alternating behavior of the file
'${icinga::baseconfigdir}/${conf_file_hosts}'. If the file was generated, the
next run will leave it empty. If it's empty, the next run will regenerate the
content as expected and so on.
I encountered the same behavior when using real Nagios resources like
'nagios_hostgroup' for example. Is there something special about Nagios
resources which will create this strange behavior?
Bernd
> -----Ursprüngliche Nachricht-----
> Von: [email protected] [mailto:puppet-
> [email protected]] Im Auftrag von Bernd Adamowicz
> Gesendet: Dienstag, 8. November 2011 17:48
> An: '[email protected]'
> Betreff: [Puppet Users] nagios_service does not replace target file
>
> Hi all,
>
> I'm using Puppet 2.6.6 on both clients and master along with stored
> configurations. My clients provide Nagios configurations like this
> example:
>
> @@nagios_service { "check_ping_${hostname}":
> check_command => "check_ping!100.0,20%!500.0,60%",
> use => "generic-service",
> host_name => "$fqdn",
> service_description => "${prefix}PING: ${hostname}",
> }
>
> They are realized on the master with the Nagios_service:
>
> Nagios_service <<||>> {
>
> target => "${baseconfigdir}/${conf_file_srvs}",
> require => File["${baseconfigdir}/${conf_file_srvs}"],
> }
>
> Since I needed special access rights for the target file (it's rsynced
> from another host), I added an appropriate file resource:
>
> file { "${baseconfigdir}/${conf_file_srvs}":
> ensure => "present",
> owner => "puppet",
> group => "puppet",
> mode => "0644",
> backup => false,
> require => File["${baseconfigdir}"],
> }
>
> Everything works fine on the first run. But once a client changes its
> Nagios resources, the new configuration will not end up in the target
> file of Nagios_service.
>
> I checked the table 'resources' within the MySQL database after the
> client executes - the changes to the exported resources are definitely
> done there. (E.g.: mysql> select title,restype from resources where
> host_id=6 and exported=1;)
>
> I tried to poke around and added
>
> content => " "
>
> to the file resource. Or I removed the 'require' attribute from the
> Nagios_service resource. I also tried to keep the "${baseconfigdir}
> clean by adding this resource:
>
>
> file {"${baseconfigdir}":
> ensure => "directory",
> owner => "puppet",
> group => "puppet",
> mode => "0755",
> backup => false,
> recurse => true,
> purge => true,
> source => "puppet:///modules/icinga/puppet_generated",
> }
>
> Within 'puppet:///modules/icinga/puppet_generated' there's only a
> README file. And I thought with 'recurse' and 'purge' this will clean
> all other files. But obviously not. The only thing that currently helps
> is manually deleting the target files.
>
> There are no errors in the log files, the catalog compiles without
> errors, I couldn't find any related bug entry, so I'm a little bit lost
> at the moment.
>
> Thanks for any help
> Bernd
>
> --
> You received this message because you are subscribed to the Google
> Groups "Puppet Users" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to puppet-
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
