| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
With this you can disable collection of exported resources.
On masterless setups, this module would otherwise complain.
|
|
|
|
Nrpe params
The nagios::nrpe class is currently completely unusable with puppet 3.x+
This is because it's still relying on global variables. When one tries to setup an nrpe client with nagios::nrpe with puppet 3.x, the following error occurs:
~~~
==> jessiepuppet: Error: Failed to parse template nagios/nrpe/nrpe.cfg:
==> jessiepuppet: Filepath: /usr/lib/ruby/vendor_ruby/puppet/parser/templatewrapper.rb
==> jessiepuppet: Line: 81
==> jessiepuppet: Detail: Could not find value for 'nagios_nrpe_pid_file' at /etc/puppet/modules/nagios/templates/nrpe/nrpe.cfg:19
==> jessiepuppet: at /etc/puppet/modules/nagios/manifests/nrpe/base.pp:22 on node jessie.vagrantup.com
==> jessiepuppet: Error: Failed to parse template nagios/nrpe/nrpe.cfg:
==> jessiepuppet: Filepath: /usr/lib/ruby/vendor_ruby/puppet/parser/templatewrapper.rb
==> jessiepuppet: Line: 81
==> jessiepuppet: Detail: Could not find value for 'nagios_nrpe_pid_file' at /etc/puppet/modules/nagios/templates/nrpe/nrpe.cfg:19
==> jessiepuppet: at /etc/puppet/modules/nagios/manifests/nrpe/base.pp:22 on node jessie.vagrantup.com
~~~
This is because the values of variables defined within nagios::nrpe are not propagated into other classes anymore.
This series also changes a default behaviour for creating saner configurations by default: the dont_blame_nrpe option is changed to disable command arguments by default.
It also adds some documentation for the nagios::nrpe class since it had no explanation whatsoever of how it should be used in the README.
See merge request !18
|
|
We missed this module reference. Starting with puppet 3.x, modules with
a dash in them are not recognized by puppet anymore, so only the file
from the "nagios" module is found.
|
|
setting dont_blame_nrpe is useful for some, but it's generally dangerous
and should be disabled if it's not used.
In this sense, it's a better idea to disable this by default.
|
|
This value is used in order to enable or disable arguments to nrpe
commands. Since some ppl might need to enable it, we should parametrize
it.
|
|
the current code for configuring NRPE is still relying on global
variables. This is not working at all with puppet 3.x and forward, so in
order to make this code functional, we need to parametrize values that
are used.
|
|
|
|
|
|
|
|
|
|
|
|
On jessie hosts, pnp4nagios-web defaults now to
pnp4nagios-web-config-icinga, so we install
pnp4nagios-web-config-nagios3 manually.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Conflicts:
manifests/apache.pp
|
|
one line is too long, break the code block into multiple lines to fix
this issue. it also creates more breathing space and makes the code
easier to read.
|
|
Currently the nagios::apache class manages some files for debian. This
means that when using the main class for setting up nagios with apache
(which is the default!) lacks those files and the setup doesn't work.
Split out management of those files into another class to avoid making
the code in the main class too encumbered and make the main class
include that (instead of nagios::apache). nagios::apache will include
the main class anyway.
Adjust README file so that all cases of http management are done through
the "nagios" class.
|
|
puppet 3.x refuses to run when there are non-ASCII chars in comments
(wth!). so replace that char with an ASCII representation of it.
|
|
The mail subject line is too long for some mail clients, so i removed
the $NOTIFICATIONTYPE$ variable from it, because it is not needed to
understand the problem/recovery.
|
|
|
|
Conflicts:
README
manifests/base.pp
manifests/defaults/commands.pp
manifests/nrpe.pp
manifests/service.pp
manifests/target.pp
templates/nrpe/nrpe_command.erb
|
|
|
|
In the current state of the module, almost 100% of the time nagios
doesn't install correctly since ordering of the resources is not
enforced.
|
|
stop defining an alias by default for hosts
Since the "alias" attribute is special for puppet in that it needs to be
a string that's unique throughout all of the resources on a given host's
catalogue, we shouldn't always define an alias unless users really want
them.
This alias might (and did for some ppl) create a conflict when using a
class that is named the same as $::hostname.
We've just hit hit limitation on a Koumbit node. The alias attribute is legitimate in terms of nagios host attributes, but the name of the attribute clashes with the special-purpose attribute for puppet. So one might argue that the native puppet types are flawed, and they would be correct! but getting those types fixed would be a pain in the ass since they haven't been maintained for quite some time.
See merge request !10
|
