NRPE allows monitoring tools like NAGIOS or ICINGA to connect to clients
-for monitoring purposes.
-
-
cd_nrpe is a fully parameterized Puppet module to automate
-NRPE installation and configuration.
-
-
WARNING
-
-
**__!!! Attention: Never use this puppet module on systems which have
-been previously configured manually. It is impossible to predict how and
-what would have been configured, hence previuos configurations outside the
-scope of this module may be overwritten! Automated configurations require a
-test environment to verify that the module suits the purpose intended by
-the user, as well as tune the parameters, before deploying into live
-production!!! __**
cd_nrpe does typically not need to be specifically declared.
-It will be auto-required by cd_nagios with default settings.
-Only if you want to override settings declare it specifically.
-
-
native Puppet deployment
-
-
via site.pp or nodes.pp
-
-
node 'example.example.net' {
- include cd_puppetdb
-}
-
-
through Foreman:
-
-
In order to apply parameters through Foreman,
-cd_nrpe::params must be added to the host or hostgroup in
-question, unless the defaults are fully acceptable across the estate.
The following parameters are editable via params.pp or through ENC
-(recommended). Values changed will take immediate effect
-at next puppet run. Services will be restarted where neccessary. If you
-want to override parameters, the module must be
-specifically declared to hosts when using ENC.
There are currently no mandatory parameters, i.e. the module will function
-right out of box as is.
-
-
Optional Parameters
-
-
$ne_manage_cmds : Whether to manage check command definitions
-dynamically through a define, i.e. from other Puppet modules or profiles.
-Defaults to true.
-
-
$ne_incl_fw : Whether to manage relevant firewall rules
-through this modules. Defaults to true.
-
-
$ne_include_selinux : Whether to manage selinux exception
-rules. Defaults to true.
-
-
$ne_enable_ssl : Whether to allow SSL settings. See known problems for more details.
-
-
$ne_allow_sudo : Whether to allow the nagios / nrpe user to
-use sudo by default. Controls both the
-settingcommand_prefixand application of a sudo rule. Defaults
-tofalse` as it usually is not required for most of the checks.
-
-
-
Managing Check Commands
-
-
In order to connect a Nagios monitoring server to clients through NRPE, you
-must define commands and the desired argument strings on the clients. The
-default NRPE installation comes with a few examples of such commands, which
-are also included in this module. However, every environment is very
-different in their requirements and Nagios via Puppet is all about the
-ability to dynamicically set command arguments based on default variables /
-overrides. For that reason no hard-coded commands are included, but instead
-all commands are set via argument strings, where possible.
-
-
The commands are created within /etc/nrpe.d/command.cfg , every set of
-instructions creates a new line.
-
-
Defining commands is as simple as
-that:
-<code>
-cd_nrpe::commands::definitions { 'check_users':
-
-ne_check_cmd => 'check_users',
- ne_cmd_argstring
-=> '-w $ARG1$ -c $ARG2$',
- }
-</code>
-It is very
-recommendable to define such commands directly within Puppet modules or
-profiles, so any node running the particular service controlled by the
-module will automatically get the required check commands defined as well,
-while nodes not running the service also do not contain the command check.
-The same then is true for Nagios checks, so you would have both the NRPE
-command definition and the Nagios check contained in Puppet modules or
-profiles to have it in once location.
-
-
SELINUX
-
-
All files and directories are configured with correct selinux context. If
-selinux is disabled, these contexts are ignored.
-
-
Known Problems
-
-
SSL/TLS support: Version 3 of NRPE supposedly has support for SSL/ TLs.
-However, at the time of writing this module, this seems to be buggy, as I
-was unable to start the NRPE service as soon as the
-ssl_cert_file line was uncommented in teh configuration file,
-despite having valid certs in the right position on the node. This happened
-when installing manually, not through this Puppet module. For that reason I
-included the $ne_enable_ssl boolean parameter, which is set to
-false by default, hence disabling SSL/TLS options until this
-has been fixed upstream, or a valid workaround has been found. Setting this
-option to true will include all SSL / TLS settings.
-
-
-
Troubleshooting
-
-
CHECH_NRPE: Unable to read output: Nagios sudo access also
-needs Selinux to allow this. Default settings in this module take care for
-both through $ne_allow_sudo and
-$ne_include_selinux.
-
-
CHECK_NRPE: Receive header underflow - only 0 bytes received (4
-expected): This is down to the new illegal meta characters feature
-vianasty_metachars`, i.e. if you included an additional character
-which actuall be part of a check, or if a custom check contains a default
-illegal character.
-
-
-
Support
-
-
OS: CentOS 6, 7
-
-
Puppet 3.x
-
-
-
Tests
-
-
Puppet Lint
-
-
excluded tests:
-
-
--no-class_inherits_from_params_class-check:relavant only to
-non-supported outdated puppet versions
-
-
--no-variable_scope-check: not applicable as we are inheriting
-parameters from params class. the lint check does not distinguish between
-facts and inherited parameters.
-
-
--no-80chars-check: it is not always possible to stay within
-80 characters, although typically only occurring on the parameter vault
-params.pp.
-
-
--no-arrow_alignment-check: this check leads to actually not
-having am easily readable arrow alignment, as this checks per
-block, not per class.
-
-
-
Puppet Parser
-
-
ERB Template Parser
-
-
Test for unwanted UTF8 files in the Puppet code as this causes problems
-with PuppetDB (see tests/UTF_Files)
ConfDroid as entity is entirely independent from Puppet. We provide custom
-configuration modules, written for specific purposes and specific
-environments.
-The modules are tested and supported only as documented, and
-require testing in designated environments (i.e. lab or development
-environments) for parameter tuning etc. before deploying into production
-environments.
NRPE allows monitoring tools like NAGIOS or ICINGA to connect to clients
-for monitoring purposes.
-
-
cd_nrpe is a fully parameterized Puppet module to automate
-NRPE installation and configuration.
-
-
WARNING
-
-
**__!!! Attention: Never use this puppet module on systems which have
-been previously configured manually. It is impossible to predict how and
-what would have been configured, hence previuos configurations outside the
-scope of this module may be overwritten! Automated configurations require a
-test environment to verify that the module suits the purpose intended by
-the user, as well as tune the parameters, before deploying into live
-production!!! __**
cd_nrpe does typically not need to be specifically declared.
-It will be auto-required by cd_nagios with default settings.
-Only if you want to override settings declare it specifically.
-
-
native Puppet deployment
-
-
via site.pp or nodes.pp
-
-
node 'example.example.net' {
- include cd_puppetdb
-}
-
-
through Foreman:
-
-
In order to apply parameters through Foreman,
-cd_nrpe::params must be added to the host or hostgroup in
-question, unless the defaults are fully acceptable across the estate.
The following parameters are editable via params.pp or through ENC
-(recommended). Values changed will take immediate effect
-at next puppet run. Services will be restarted where neccessary. If you
-want to override parameters, the module must be
-specifically declared to hosts when using ENC.
There are currently no mandatory parameters, i.e. the module will function
-right out of box as is.
-
-
Optional Parameters
-
-
$ne_manage_cmds : Whether to manage check command definitions
-dynamically through a define, i.e. from other Puppet modules or profiles.
-Defaults to true.
-
-
$ne_incl_fw : Whether to manage relevant firewall rules
-through this modules. Defaults to true.
-
-
$ne_include_selinux : Whether to manage selinux exception
-rules. Defaults to true.
-
-
$ne_enable_ssl : Whether to allow SSL settings. See known problems for more details.
-
-
$ne_allow_sudo : Whether to allow the nagios / nrpe user to
-use sudo by default. Controls both the
-settingcommand_prefixand application of a sudo rule. Defaults
-tofalse` as it usually is not required for most of the checks.
-
-
-
Managing Check Commands
-
-
In order to connect a Nagios monitoring server to clients through NRPE, you
-must define commands and the desired argument strings on the clients. The
-default NRPE installation comes with a few examples of such commands, which
-are also included in this module. However, every environment is very
-different in their requirements and Nagios via Puppet is all about the
-ability to dynamicically set command arguments based on default variables /
-overrides. For that reason no hard-coded commands are included, but instead
-all commands are set via argument strings, where possible.
-
-
The commands are created within /etc/nrpe.d/command.cfg , every set of
-instructions creates a new line.
-
-
Defining commands is as simple as
-that:
-<code>
-cd_nrpe::commands::definitions { 'check_users':
-
-ne_check_cmd => 'check_users',
- ne_cmd_argstring
-=> '-w $ARG1$ -c $ARG2$',
- }
-</code>
-It is very
-recommendable to define such commands directly within Puppet modules or
-profiles, so any node running the particular service controlled by the
-module will automatically get the required check commands defined as well,
-while nodes not running the service also do not contain the command check.
-The same then is true for Nagios checks, so you would have both the NRPE
-command definition and the Nagios check contained in Puppet modules or
-profiles to have it in once location.
-
-
SELINUX
-
-
All files and directories are configured with correct selinux context. If
-selinux is disabled, these contexts are ignored.
-
-
Known Problems
-
-
SSL/TLS support: Version 3 of NRPE supposedly has support for SSL/ TLs.
-However, at the time of writing this module, this seems to be buggy, as I
-was unable to start the NRPE service as soon as the
-ssl_cert_file line was uncommented in teh configuration file,
-despite having valid certs in the right position on the node. This happened
-when installing manually, not through this Puppet module. For that reason I
-included the $ne_enable_ssl boolean parameter, which is set to
-false by default, hence disabling SSL/TLS options until this
-has been fixed upstream, or a valid workaround has been found. Setting this
-option to true will include all SSL / TLS settings.
-
-
-
Troubleshooting
-
-
CHECH_NRPE: Unable to read output: Nagios sudo access also
-needs Selinux to allow this. Default settings in this module take care for
-both through $ne_allow_sudo and
-$ne_include_selinux.
-
-
CHECK_NRPE: Receive header underflow - only 0 bytes received (4
-expected): This is down to the new illegal meta characters feature
-vianasty_metachars`, i.e. if you included an additional character
-which actuall be part of a check, or if a custom check contains a default
-illegal character.
-
-
-
Support
-
-
OS: CentOS 6, 7
-
-
Puppet 3.x
-
-
-
Tests
-
-
Puppet Lint
-
-
excluded tests:
-
-
--no-class_inherits_from_params_class-check:relavant only to
-non-supported outdated puppet versions
-
-
--no-variable_scope-check: not applicable as we are inheriting
-parameters from params class. the lint check does not distinguish between
-facts and inherited parameters.
-
-
--no-80chars-check: it is not always possible to stay within
-80 characters, although typically only occurring on the parameter vault
-params.pp.
-
-
--no-arrow_alignment-check: this check leads to actually not
-having am easily readable arrow alignment, as this checks per
-block, not per class.
-
-
-
Puppet Parser
-
-
ERB Template Parser
-
-
Test for unwanted UTF8 files in the Puppet code as this causes problems
-with PuppetDB (see tests/UTF_Files)
ConfDroid as entity is entirely independent from Puppet. We provide custom
-configuration modules, written for specific purposes and specific
-environments.
-The modules are tested and supported only as documented, and
-require testing in designated environments (i.e. lab or development
-environments) for parameter tuning etc. before deploying into production
-environments.