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
>>> >
>
--
Gabriel Filion
--
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.
