Closed jskarpe closed 9 years ago
It's correct like this, the module forces the usage of that directory because it's populated by exported resources which have to rely on a fixed, non OS dependent path. Check path issues / PRs for details or directly here: https://github.com/example42/puppet-nagios/blob/master/manifests/target.pp#L16
It's simply not working as it is, because it's not a consistent path. If it's a hardcoded path, then you'd have to ensure that this path is included in nagios.cfg as well. Right now the exported resources are created in /etc/nagios/auto.d, while nagios.cfg includes /etc/nagios3/auto.d
Check the readme: Debian (and derivatives) users must set the top scope variable nagios_customconfigdir to point to the Nagios configuration directory. At the moment, this directory is not parameterized based on operating system
$::nagios_customconfigdir = '/etc/nagios3/auto.d' # Top Scope Variable class { 'nagios': }
In any case the include statement in nagios.cfg needs to be in sync. E.G point to /etc/nagios/auto.d instead of /etc/nagios3/auto.d which it does now
on a debian server the include uses nagios3
Excactly. It shouldn't attempt to include a non-existing/empty folder, but instead include the nagios::target folder which contains the actual auto.d configs.
Maybe it's not clear the reasoning behind and the issue of the whole matter. The modules uses on the nagios server the directory that the OS expects, nagios or nagios3 according to what's defined in params.pp But, since the auto.d directory there is populated by exported resources (in the target class) we can't rely, to detemine it, on the local operating system of the client that exports host and services checks. Hence by default all the clients export to /etc/nagios/auto.d. If you what to export files with a different path, for example to meet the /etc/nagios3 directory on Debian based systems, you have to set the $::nagios_customconfigdir top scope variable. Not particularly elegant but that was the only solution I had at disposal to manage alternative directories on the nagios server.
Why can't the nagios.cfg template use the nagios::target folder for it's include statements? That should solve the problem. It would still create /etc/nagios3 and /etc/nagios folders, but all the appropriate configs should then be loaded by Nagios.
Right now not a single auto.d config is loaded using defaults (E.G following the install guide in the README)
To use directly $::nagios_customconfigdir in nagios.cfg could prevent such misunderstandings but IMHO nagios shoul be configured with the correct dir for the underlying OS. IF your nagios server is on Ubuntu setting: $::nagios_customconfigdir = '/etc/nagios3/auto.d' should do the work. Remember that after you've set it , you should run Puppet on all the nodes where Puppet has been run with the previous (incorrect for such a Nagios server) settings so that they re-export their check files with the correct path.
BTW, rather than using Nagios I suggest to use Icinga2, which makes Puppet configuration much smarter (you just need to export host resources, all the service checks can be defined with direct files via the apply statement.
Hi, i'm new in puppet. I install nagios-puppet(example42) module everything is good. It monitored the basic services for my nagios host. BUT there is one problem i cannot monitor other hosts with the module.
How i can monitor other hosts with the module?
In Ubuntu 14.04, the storeconfigs for hosts and services are created in /etc/nagios/auto.d while they should be created in /etc/nagios3 (which is the correct config dir for Nagios under Ubuntu)
The following folders are created correctly:
commands extra manual settings