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.