Re-generate Nagios_service target-files

Some time ago I ran into the the problem that when having a Puppet configuration like this

  Nagios_service <<| |>> {
    target => "${baseconfigdir}/${conf_file_srvs}",

which is about collecting all stored configurations of type nagios_service, this works pretty well when executed for the first time. However, every subsequent Puppet run will not regenerate the target file. I tried to find some help at Puppet’s mailing list but it seemed that I was (and onbiously still am) the only Puppet user facing this problem. I then implemented a more or less pretty workaround which I described here. Now after we recently redesigned our infrastructure and also switched the Puppet master to version 3.x, I didn’t want to reuse the old workaround and instead searched for a better solution – and – fortunately found one.

The basic idea is to delete the files before they get regenerated by the Nagios_service resource. That’s what I also tried some years ago but with no success (for whatever reason). This time I had more luck and found this solution:

class icinga_master::stored_conf {
  $baseconfigdir   = '/etc/icinga/puppet_generated'
  $conf_file_srvs  = 'srvs_pupp_gen.cfg'

  exec { 'purge-config-files':
    before => File["${baseconfigdir}/${conf_file_srvs}"],
    command => "/bin/rm -f ${baseconfigdir}/*",

  Nagios_service <<| |>> {
    target => "${baseconfigdir}/${conf_file_srvs}",
    require => Exec['purge-config-files'],
    notify => Service['icinga'],

  # Though the files are generated automatically,
  # we need different access rights.
  file { "${baseconfigdir}/${conf_file_srvs}":
    ensure  => file,
    require => File[$baseconfigdir],
    owner   => 'icinga',
    group   => 'icinga',
    mode    => '0644',
    backup  => false,
    replace => false,

The exec resource purge-config-files simply deletes all previously generated configuration files. The require attribute inside the Nagios_service resource ensures that the files are deleted before Puppet tries to regenerate the configuration files.

So actually a local change of the configuration files triggers their regeneration. It’s just about having the correct sequence in place: Delete old file -> Recreate with desired access rights -> Regenerate configuration.

, , ,

No comments yet.

Leave a Reply

* Copy This Password *

* Type Or Paste Password Here *