2
votes

I have a puppet 3.8.5 environment that contains a module that installs an application on 3 servers in identical fashion.

In the module I have the following class

class app::monitoring {

include nrpe
include nagios::export

@@nagios_contactgroup:{ 'APP':
  ensure                        =>  present,
  alias                         => 'APP Developer',
  members                       => 'user1, user2',
  target                        => '/etc/nagios/conf.d/contacts.cfg',
  }

@@nagios_contact {'user1':
  ensure                        => present,
  alias                         => 'user1',
  email                         => '[email protected]',
  service_notification_period   => 'workhours',
  host_notification_period      => 'workhours',
  service_notification_commands => 'notify-service-by-email',
  host_notification_commands    => 'notify-service-by-email',
  target                        => '/etc/nagios/conf.d/contacts.cfg',
  }

@@nagios_service { 'check_app_http_${fqdn}':
  ensure                        => present,
  use                           => "local-service',
  host_name                     => $fqdn,
  service_description           => 'Check App - port 8000',
  check_command                 => 'check_http_app!8000',
  notifications_enabled         => '1',
  target                        => '/etc/nagios/conf.d/service.cfg',
  }

  @@nagios_command {"check_http_app":
    ensure                      => present,
    command_line                => '/usr/lib64/nagios/plugins/check_http -H $HOSTADDRESS$ -p $ARG1$',
    target                      => '/etc/nagios/conf.d/commands.cfg',
    }
  }

As expected all works correctly when puppet runs on each server, but fails with a duplicate entry error when puppet runs on the Nagios server. Is there a way to change the code so that if/when this is run on the subsequent servers I don't get a duplicate resource error?

At the moment I am manually creating the

  • nagios_contactgroup,
  • nagios_contact, and
  • nagios_command

entries in /etc/nagios/objects so they effectively are hard coded into Nagios. I would prefer to have the ability to be able to completely rebuild nagios without human intervention.

2

2 Answers

1
votes

We ran into the same problem and came up with a workaround - a wrapper around nagios_command and other functions:

define ournagios::nagios_command (
  $nagios_title, 
  ... # all other built-in parameters
){
  # some custom code for changing parameters
  # Note that any resource creation here must be
  # wrapped with `if ! defined()`

  if ! defined(Nagios_command["$nagios_title"]) {
    nagios_command { $nagios_title:
      command_name => $command_name,
      ensure       => $ensure,
      command_line => $command_line,
      group        => $group,
      mode         => $mode,
      owner        => $owner,
      poller_tag   => $poller_tag,
      provider     => $provider,
      target       => $_target,
      use          => $use,
    }
  }
}

We use it like this:

@@ournagios::nagios_command { "check_dns-${::hostname}":
  nagios_title => "check_dns",
  command_line => '$USER1$/check_dns -s \'$HOSTADDRESS$\' -H \'$ARG1$\' -a \'$ARG2$\' -w \'$ARG3$\' -c \'$ARG4$\'',
}

Multiple ournagios::nagios_check resources are created, but all of them have different names and the actual nagios_command is only created once.

0
votes

You have to make sure that resources you export with @@ have unique names, so that when they are collected on the Nagios server you don't get duplicate resources.

See the manual.