Hi all,

I'm a little bit confused that I did not get a single reply from the list concerning the problem of not re-created configuration files when using stored configurations for generating an Icinga/Nagios configuration. Please tell me at least if my question if this could be a bug seems to be reasonable (see below).

Is there no one else having the same problem? Any ideas from Puppetlabs?

Thanks Bernd

Well, it turned out that I was not able to create a Puppet configuration whichdoes a reliable re-creation of the Nagios configuration files. My workaround >isnow to restart the Puppet agent with a cron job and before restarting I deletethe old configuration files like this:

/bin/logger "$0: Preparing Puppet agent for execution"
/bin/rm -f ${CFG_DIR}/*
/bin/logger "$0: Deleted Icinga configuration files below $CFG_DIR"
/bin/logger "$0: Starting Puppet agent now"
/usr/bin/puppet agent $PUPPET_OPTS
/bin/logger "$0: Puppet run finished"

Though a little bit ugly, this is now a reliable solution.

I'd like to summarize the problems I've encountered:

1. If stored configurations change within the MySQL database, this will not bereflected in the Nagios configuration files created by the Nagios_* resources >-as described in my first mail.

2. If I try to do delete the configuration files using a exec resource beforethe Nagios_* resources, I encounter alternating creation and deletion of theconfiguration files - as describe in my second mail.


Maybe (2.) was some kind of misconfiguration I did, but at least (1.) could bea bug. Since I got no reply from the list, it seems that I'm the only one everrunning into this problem. So I'd like to ask this list and mainly the Puppetguys if you think this is worth filing a bug?

Thanks
Bernd

-----Ursprüngliche Nachricht-----
Von: puppet-users@googlegroups.com [mailto:puppet-
us...@googlegroups.com] Im Auftrag von Bernd Adamowicz
Gesendet: Mittwoch, 9. November 2011 13:44
An: 'puppet-users@googlegroups.com'
Betreff: [Puppet Users] AW: nagios_service does not replace target file
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: puppet-users@googlegroups.com [mailto:puppet-
> us...@googlegroups.com] Im Auftrag von Bernd Adamowicz
> Gesendet: Dienstag, 8. November 2011 17:48
> An: 'puppet-users@googlegroups.com'
> 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 puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Reply via email to