Bernd Adamowicz
2011-Nov-08 16:47 UTC
[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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Bernd Adamowicz
2011-Nov-09 12:43 UTC
[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- > users@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+unsubscribe@googlegroups.com. > 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 puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Bernd Adamowicz
2011-Nov-10 10:16 UTC
[Puppet Users] AW: nagios_service does not replace target file
Well, it turned out that I was not able to create a Puppet configuration which does a reliable re-creation of the Nagios configuration files. My workaround is now to restart the Puppet agent with a cron job and before restarting I delete the 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 be reflected 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 before the Nagios_* resources, I encounter alternating creation and deletion of the configuration files - as describe in my second mail. Maybe (2.) was some kind of misconfiguration I did, but at least (1.) could be a bug. Since I got no reply from the list, it seems that I''m the only one ever running into this problem. So I''d like to ask this list and mainly the Puppet guys if you think this is worth filing a bug? Thanks Bernd> -----Ursprüngliche Nachricht----- > Von: puppet-users@googlegroups.com [mailto:puppet- > users@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- > > users@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+unsubscribe@googlegroups.com. > > 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 puppet-users@googlegroups.com. > To unsubscribe from this group, send email to puppet- > users+unsubscribe@googlegroups.com. > 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 puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.