Hi,

Removing the 'require' link leads back to the very first problem I've encountered: The files are not regenerated even thought the stored configurations inside the MySQL database changed (I did check the table content before.).

Bernd

On Thu, 17 Nov 2011 04:36:26 +0100, Gabriel Filion <lelu...@gmail.com> wrote:

Hi,

the module I'm using is almost setup the same, but I don't experience
the same issue:

the nagios server collects nagios config resources (and sets the target
file for each kind of resource), and there's a resource for the files
themselves which define the permissions.

however, there's no "require" link between both.

what happens if you try and remove the require link from Nagios_XYZ ->
${baseconfigdir}/${conf_file_srvs} ?

On 11-11-16 05:57 PM, Bernd Adamowicz wrote:
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
>




--
Bernd Adamowicz
Softwaremanagement

Georg-Fahrbach-Straße 21
74653 Ingelfingen-Criesbach
Mobil: +49 (0)171 7278857
Mail: i...@bernd-adamowicz.de
http://www.bernd-adamowicz.de

--
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