sous-chefs / nrpe

Development repository for the nrpe cookbook

nrpe cookbook

Chef cookbook to install Nagios NRPE client (was previously part of the Nagios cookbook)

Maintainers

This cookbook is maintained by the Sous Chefs. The Sous Chefs are a community of Chef cookbook maintainers working together to maintain important cookbooks. If you’d like to know more please visit sous-chefs.org or come chat with us on the Chef Community Slack in #sous-chefs.

Requirements

Chef

Chef 15.3+

Platform

• Debian
• FreeBSD
• Ubuntu
• RHEL including CentOS and Oracle Linux
• Amazon Linux (2.x cannot be installed via package)
• Fedora
• SUSE / openSUSE

Notes: This cookbook has been tested on the listed platforms. It may work on other platforms with or without modification.

Cookbooks

• yum-epel

Recipes

default

Installs the NRPE client via packages or source depending on platform and attributes set

configure

Configures the NRPE client. This will be called internally by the default recipe but can also be used to re-configure later on.

Attributes

platform specific attributes (auto set based on platform)

• node['nrpe']['install_method'] - whether to install from package or source. Default chosen by platform based on known packages available for NRPE: debian/ubuntu 'package', Redhat/CentOS/Fedora/Scientific: source
• node['nrpe']['home'] - home directory of NRPE
• node['nrpe']['ssl_lib_dir'] - ssl directory used by NRPE
• node['nrpe']['pid_file'] - location to store the NRPE pid file
• node['nrpe']['conf_dir'] - location of the nrpe configuration, default /etc/nagios
• node['nrpe']['bin_dir'] - location of the nrpe binary, default /usr/sbin
• node['nrpe']['packages'] - nrpe / plugin packages to install. The default attribute for RHEL/Fedora platforms contains a bare minimum set of packages. The full list of available packages is available at: http://dl.fedoraproject.org/pub/epel/6/x86_64/repoview/letter_n.group.html
• node['nrpe']['log_facility'] - log facility for nrpe configuration, default nil (not set)
• node['nrpe']['plugin_dir'] - location where Monitoring plugins (aka Nagios plugins) go, default '/usr/lib/nagios/plugins'.

options for package install

• Package manager node['nrpe']['package']['options'] - options when installing nrpe via package manager. The default value for this attribute is nil.`
• EPEL repo node['nrpe']['install_yum-epel'] - whether to install the EPEL repo or not. The default value is true. Set this to false if you do not wish to install the EPEL RPM; in this scenario you will need to make the relevant NRPE packages available via another method e.g. local repo.

nrpe.conf attributes

• Server port: node['nrpe']['server_port'] - the port nrpe will listen on, default 5666
• Address: node['nrpe']['server_address'] - the IP the nrpe server will listen on. This allows you to bind to particular IPs in situations where the system has more than one IP. This is particularly handy in determining if nrpe should bind to the internal or public IP in a cloud environment. Set the attribute to the node attribute for the cloud interface you wish to use. Defaults to nil (not enabled)
• node['nrpe']['log_facility'] - syslog facility to log to, default nil (not set)
• node['nrpe']['command_prefix'] - command to prefix to every nrpe command (like perhaps sudo), default nil (not set)
• node['nrpe']['debug'] - debug level nrpe configuration, default 0
• node['nrpe']['connection_timeout'] - connection timeout for nrpe configuration, default nil (not set)
• node['nrpe']['dont_blame_nrpe'] - allows the server to send additional values to NRPE via arguments. this needs to be enabled for most checks to function
• node['nrpe']['command_timeout'] - the amount of time NRPE will wait for a command to execute before timing out
• node['nrpe']['allow_bash_command_substitution'] - allows bash command substitution in your nrpe commands - defaults to nil

urls for source installations

• node['nrpe']['url'] - url to retrieve NRPE source
• node['nrpe']['version'] - version of NRPE source to download
• node['nrpe']['checksum'] - checksum of the NRPE source tarball
• node['nrpe']['plugins']['url'] - url to retrieve the plugins source from
• node['nrpe']['plugins']['version'] - version of the plugins source to download
• node['nrpe']['plugins']['checksum'] - checksum of the plugins source tarball

authorization and server discovery

• node['nrpe']['server_role'] - the role that the Nagios server will have in its run list that the clients can search for.
• node['nrpe']['allowed_hosts'] - additional hosts that are allowed to connect to this client. Must be an array of strings (i.e. %w(test.host other.host)). These hosts are added in addition to 127.0.0.1, ::1, and IPs that are found via search.
• node['nrpe']['using_solo_search'] - discover server information in node data_bags even with chef solo through the use of solo-search (https://github.com/edelight/chef-solo-search)
• node['nrpe']['multi_environment_monitoring'] - search for nagios servers in all environments not just that of the node when building the array of allowed hosts, default 'false'

user and group attributes

• node['nrpe']['user'] - NRPE user, default 'nagios'.
• node['nrpe']['group'] - NRPE group, default 'nagios'.

Resources/Providers

check

The check resource provides an easy way to add and remove NRPE checks from within cookbooks.

Actions

• :add creates a NRPE configuration file and reloads the NRPE process. Default action.
• :remove removes the configuration file and reloads the NRPE process

Attribute Parameters

• command_name The name of the check. This is the command that you will call from your nagios_service data bag check
• warning_condition String that you will pass to the command with the -w flag
• critical_condition String that you will pass to the command with the -c flag
• command The actual command to execute (including the path). If this is not specified, this will use #{node['nrpe' ['plugin_dir']}/command_name as the path to the command.
• parameters Any additional parameters you wish to pass to the plugin.
• template Use the specific erb template to render NRPE config command.

Examples

# Use resource to define check_load
nrpe_check "check_load" do
  command "#{node['nrpe']['plugin_dir']}/check_load"
  warning_condition '10'
  critical_condition '15'
  action :add
end

# Remove the check_load definition
nrpe_check "check_load" do
  action :remove
end

Using template:

nrpe_check "check_load" do
  template "check_load.cfg.erb"
  action :add
end

Contributors

This project exists thanks to all the people who contribute.

Backers

Thank you to all our backers!

Sponsors

Support this project by becoming a sponsor. Your logo will show up here with a link to your website.

nrpe's Issues

Passing Conditions to Templates

For the ReadMe example how are the warning and critical conditions passed to the template?

nrpe_check "check_load" do
  template "check_load.cfg.erb"
  action :add
end

Issue with nrpe::_source_install recipe

Recipe: nrpe::_source_install

• build_essential[] action install

  • yum_package[autoconf, bison, flex, gcc, gcc-c++, gettext, kernel-devel, make, m4, ncurses-devel, patch] action install

    ================================================================================
    Error executing action install on resource 'yum_package[autoconf, bison, flex, gcc, gcc-c++, gettext, kernel-devel, make, m4, ncurses-devel, patch]'

    RuntimeError

    yum-helper.py had stderr/stdout output:

    Traceback (most recent call last):
    File "/opt/chef/embedded/lib/ruby/gems/2.7.0/gems/chef-16.16.13/lib/chef/provider/package/yum/yum_helper.py", line 209, in
    query(command)
    File "/opt/chef/embedded/lib/ruby/gems/2.7.0/gems/chef-16.16.13/lib/chef/provider/package/yum/yum_helper.py", line 153, in query
    pkgs = base.bestPackagesFromList(pkgs,single_name=True)
    File "/usr/lib/python2.7/site-packages/yum/init.py", line 4449, in bestPackagesFromList
    multi = self._bestPackageFromList(multiLib, req=req)
    File "/usr/lib/python2.7/site-packages/yum/init.py", line 4416, in _bestPackageFromList
    bestlist = self._compare_providers(pkglist, reqpo=None, req=req)
    File "/usr/lib/python2.7/site-packages/yum/depsolve.py", line 1569, in _compare_providers
    lpos[po.name] = self.pkgSack.returnNewestByName(po.name)[:1]
    File "/usr/lib/python2.7/site-packages/yum/packageSack.py", line 539, in returnNewestByName
    raise PackageSackError, 'No Package Matching %s' % ui_pats
    yum.Errors.PackageSackError: No Package Matching kernel-devel
    Loaded plugins: fastestmirror, langpacks, versionlock
    Loading mirror speeds from cached hostfile
    Excluding 2 updates due to versionlock (use "yum versionlock status" to show them)

The release of the new version.

Guys, can you release a new version of cookbook?

nrpe_check raise ResourceNotFound exception on service reload notification

Cookbook version

2.0.0

Chef-client version

12.13.37 (greater than this cookbook requirements)

Platform Details

Centos 6.8 & 7.2

Scenario:

Using nrpe_check to configure a new check.

Steps to Reproduce:

Create a recipe like this

include_recipe 'nrpe'
nrpe_check 'check_name'

Expected Result:

Successful convergence

Actual Result:

  * service[nrpe] action start
    - start service service[nrpe]
  * service[nrpe] action enable
    - enable service service[nrpe]
Recipe: nrpe-wrapper::default
  * nrpe_check[check_name] action add
    
    ================================================================================
    Error executing action `add` on resource 'nrpe_check[check_name]'
    ================================================================================
    
    Chef::Exceptions::ResourceNotFound
    ----------------------------------
    resource file[/etc/nagios/nrpe.d/check_name.cfg] is configured to notify resource service[nrpe] with action restart, but service[nrpe] cannot be found in the resource collection. file[/etc/nagios/nrpe.d/check_name.cfg] is defined in /tmp/kitchen/cache/cookbooks/nrpe/resources/check.rb:51:in `block in class_from_file'
    
    Resource Declaration:
    ---------------------
    # In /tmp/kitchen/cache/cookbooks/nrpe-wrapper/recipes/default.rb
    
     32:   nrpe_check chk_name do
     33:     command command                 unless command.nil?
     34:     parameters params['parameters'] unless params['parameters'].nil?
     35:     action action                   if action
     36:   end
     37: 

This was fixed by #56, but reintroduced with #64. I think notification of an outside resource is not a good pattern, maybe we should instanciate a new service resource per nrpe_check
Cc: @aboten

systemd deployment is broken

Good day.

After 1.5.3 release, I could not help but notice that converging on systemd OSes (> Centos 7) fails.
I suspect that this PR #31 should have changed something very important.

A piece from systemd log:

Jul 20 10:41:21 master0-el7 nrpe[14498]: Unable to open config file '/etc/nagios/nrpe.cfg' for reading
Jul 20 10:41:21 master0-el7 nrpe[14498]: Config file '/etc/nagios/nrpe.cfg' contained errors, aborting...
Jul 20 10:41:21 master0-el7 systemd[1]: nrpe.service: control process exited, code=exited status=2```

`berks install` does not work with Nagios dependency

👻 Brief Description

I try to install this cookbook with Berkshelf but it fails.

🥞 Cookbook version

2.1.0

👩‍🍳 Chef-Infra Version

Chef Infra Client: 15.0.300
Berkshelf 7.0.8

🎩 Platform details

Mac OS X 10.14.6

Steps To Reproduce

Steps to reproduce the behavior:

I add this Berksfile

source 'https://supermarket.chef.io'

cookbook 'npre', '~> 2.1.0'

Then running berks install produces

Resolving cookbook dependencies...
Fetching cookbook index from https://supermarket.chef.io...
Unable to satisfy the following requirements:

- `npre (~> 2.1.0)` required by `user-specified dependency`
Unable to find a solution for demands: npre (~> 2.1.0)

🚓 Expected behavior

I would expect the cookbook to be installed

➕ Additional context

It worked once but since now never again.

failing test in travis

I'm investigating failing builds in travis, and noticed https://travis-ci.org/sous-chefs/nrpe/builds/262477223

Most tests are passing, but for UNIT_AND_LINT=1:

source install on ubuntu 16.04
  templates systemd unit file (FAILED - 1)
Failures:
  1) source install on ubuntu 16.04 templates systemd unit file
     Failure/Error: expect(chef_run).to render_file('/lib/systemd/system/nrpe.service').with_content('/usr/sbin/nrpe')
     
       expected Chef run to render "/lib/systemd/system/nrpe.service" matching:
     
       /usr/sbin/nrpe
     
       but got:

[compatibility improvement] Deprecate use of build-essentials and yum-epel cookbooks

Cookbook version

2.0.5/latest

Chef-client version

>= 14

Platform Details

Any supported

Scenario:

Trying to cut down on deprecation warnings (build-essentials cookbook) or manage Yum EPEL via other means more naturally.

Steps to Reproduce:

Include resources or recipes per README in a Chef 14 environment, attempt to use the Chef 14 build-essential resources manage EPEL (or just yum in general) in other ways outside of the yum-epel cookbook.

Expected Result:

Less dependencies when implementing this cookbook for configuration and letting the implementor manage dependencies outside of this cookbook which should be focused on nrpe, not how one manages yum-epel or build-essentials.

Actual Result:

Unexpected and unpredictable cookbook resolution results, resource naming conflicts, potential cookbook bloat, deprecation warnings in every Chef run. That should about do it for now I think.

Recommendation:

Move any current requirements to the testing fixture area of the cookbook if possible and make a couple more assumptions that things exist before deploying and configuring nrpe services.

Thanks! =)

Run latest cookstyle

🗣️ Foreword

Thank for taking the time to fill this bug report fully. Without it we may not be able to fix the bug, and the issue may be closed without resolution.

👻 Brief Description

Chef have released updated cookstyle rules, we should therefore run the auto fix against the cookbook

1. Ensure you are on the latest stable chef-workstation
2. Run cookstyle -a

Issue sprouted from sous-chefs/meta/issues/111. If not applicable then issue should be closed.

Configuration and compilation assume nagios user and group exists

The default values for node['nrpe']['user'] and node['nrpe']['group'] are currently set to "nagios", however this cookbook doesn't check whether that user or group exists. If this cookbook is used without first creating the "nagios" user and group or changing those values, then the cookbook fails to run.

💭 Given this cookbook was extracted from a Nagios cookbook and appears to be intended to be useable as a standalone cookbook, perhaps those default values should be set to "nrpe" instead.

service[nagios-nrpe-server] cannot be found

I have a node which started failing, and I'm not exactly sure why. Running on Ubuntu 14.04

I have a simple recipe to create a NRPE check

nrpe_check "check_load" do                                                       
    command "#{node['nrpe']['plugin_dir']}/check_load"                           
    warning_condition node['inenrpe']['nrpe']['check_load']['warning_condition'] 
    critical_condition node['inenrpe']['nrpe']['check_load']['critical_condition']
    action :add                                                                  
end 

My runlist installs the default NRPE recipe and my nrpe_check on this node (which is not my nagios server) but now I'm getting an error finding a resource during my chef-client run? I'm running the current version of this cookbook "nrpe": "1.6.0"

* nrpe_check[check_load] action add

    ================================================================================
    Error executing action `add` on resource 'nrpe_check[check_load]'
    ================================================================================

    Chef::Exceptions::ResourceNotFound
    ----------------------------------
    resource file[/etc/nagios/nrpe.d/check_load.cfg] is configured to notify resource service[nagios-nrpe-server] with action reload, but service[nagios-nrpe-server] cannot be found in the resource collection. file[/etc/nagios/nrpe.d/check_load.cfg] is defined in /var/chef/cache/cookbooks/nrpe/providers/check.rb:48:in `block in class_from_file'

    Cookbook Trace:
    ---------------
    /var/chef/cache/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/resource_collection.rb:45:in `find_local'
    /var/chef/cache/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/resource_collection.rb:58:in `find'
    /var/chef/cache/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/runner.rb:41:in `run_action'

    Resource Declaration:
    ---------------------
    # In /var/chef/cache/cookbooks/ine-nrpe/recipes/check_load.rb

     10: nrpe_check "check_load" do
     11:     command "#{node['nrpe']['plugin_dir']}/check_load"
     12:     warning_condition node['inenrpe']['nrpe']['check_load']['warning_condition']
     13:     critical_condition node['inenrpe']['nrpe']['check_load']['critical_condition']
     14:     action :add
     15: end

    Compiled Resource:
    ------------------
    # Declared in /var/chef/cache/cookbooks/ine-nrpe/recipes/check_load.rb:10:in `from_file'

    nrpe_check("check_load") do
      action [:add]
      retries 0
      retry_delay 2
      default_guard_interpreter :default
      declared_type :nrpe_check
      cookbook_name "ine-nrpe"
      recipe_name "check_load"
      command "/usr/lib/nagios/plugins/check_load"
      warning_condition "6,4,2"
      critical_condition "12,10,7"
      command_name "check_load"
    end

monitoring plugins remote_file doesn't check checksum if file was downloaded

Hey,

under some circumstances it happened to me, that the monitoring plugins tarball was downloaded, but the download was broken. When i re-run chef it doesn't re-check the checksum of that tarball and the unzip part is failing constantly. Only logging into the machine, deleting the old file helped.

Is it possible that we remove the action definition on the remote_file resource for the monitoring plugins, so it will default to create - so that the checksum will always be checked? Or at least make it configurable to not break backwards-compatibility?

Thanks.

Update Changelog

🗣️ Foreword

Thank for taking the time to fill this bug report fully. Without it we may not be able to fix the bug, and the issue may be closed without resolution.

👻 Brief Description

Update all CHANGELOGs to follow standard defined at https://keepachangelog.com/

Issue sprouted from sous-chefs/meta/issues/101. If not applicable then issue should be closed.

Error executing action start on resource service[nrpe]

Cookbook version

2.0.0

Chef-client version

13.11.3

Platform Details

AWS AMI

Scenario:

Installing NRPE recipe

Attributes

default['nrpe']['allowed_hosts'] = [ "127.0.0.1,10.20.0.0/16,10.4.0.0/16"]
default['nrpe']['install_method'] = 'package'
default['nrpe']['packages'] = %w(nagios-plugins-perl perl-Sys-Statistics-Linux nagios-plugins-http perl-Nagios-Plugin perl-LWP-Protocol-https perl-JSON nagios-plugins-ntp)

ERROR

service[nrpe]: No custom command for start specified and unable to locate the init.d script!

Stack Trace

Installing Cookbook Gems:
Compiling Cookbooks...
Converging 25 resources
Recipe: nrpe::_package_install

• yum_package[nagios-plugins-perl] action install (up to date)

• yum_package[perl-Sys-Statistics-Linux] action install (up to date)

• yum_package[nagios-plugins-http] action install (up to date)

• yum_package[perl-Nagios-Plugin] action install (up to date)

• yum_package[perl-LWP-Protocol-https] action install (up to date)

• yum_package[perl-JSON] action install (up to date)

• yum_package[nagios-plugins-ntp] action install (up to date)
  Recipe: nrpe::configure

• directory[/etc/nagios/nrpe.d] action create (up to date)

• template[/etc/nagios/nrpe.cfg] action create (up to date)

• service[nrpe] action start

  • service[nrpe]: No custom command for start specified and unable to locate the init.d script!
    ================================================================================
    Error executing action start on resource 'service[nrpe]'
    ================================================================================

  Chef::Exceptions::Service

  service[nrpe]: No custom command for start specified and unable to locate the init.d script!

  Resource Declaration:

  In /var/chef/cache/cookbooks/nrpe/recipes/configure.rb

  70: service node['nrpe']['service_name'] do
  71: action [:start, :enable]
  72: supports :restart => true, :reload => true, :status => true
  73: end
  74:

  Compiled Resource:

  Declared in /var/chef/cache/cookbooks/nrpe/recipes/configure.rb:70:in `from_file'

  service("nrpe") do
  action [:start, :enable]
  default_guard_interpreter :default
  service_name "nrpe"
  enabled nil
  running nil
  masked nil
  pattern "nrpe"
  declared_type :service
  cookbook_name "nrpe"
  recipe_name "configure"
  supports {:restart=>true, :reload=>true, :status=>true}
  end

  System Info:

  chef_version=13.11.3
  platform=amazon
  platform_version=2018.03
  ruby=ruby 2.4.4p296 (2018-03-28 revision 63013) [x86_64-linux]
  program_name=chef-client worker: ppid=32544;start=20:19:22;
  executable=/opt/chef/bin/chef-client

allowed_hosts max limit

Cookbook version

2.0.3

Chef-client version

the latest (doesn't matter)

Platform Details

CentOS6/7

Scenario:

when allowed_hosts in /etc/nagios/nrpe.cfg has more then 144 IPs, nrpe is failing and won't start up

Steps to Reproduce:

edit /etc/nagios/nrpe.cfg, option allowed_hosts with 150 or more IPs
Not sure if it's max limitation of NRPE or NRPE bug, but we should have some max limits to avoid it.

Expected Result:

nrpe up and running

Actual Result:

[2018-04-19T12:57:30+00:00] INFO: template[/etc/nagios/nrpe.cfg] sending restart action to service[nrpe] (delayed)
Recipe: nrpe::configure
 * service[nrpe] action restart[2018-04-19T12:57:30+00:00] INFO: Processing service[nrpe] action restart (nrpe::configure line 84)



================================================================================
   Error executing action `restart` on resource 'service[nrpe]'
   ================================================================================

   Mixlib::ShellOut::ShellCommandFailed
   ------------------------------------
   Expected process to exit with [0], but received '1'
   ---- Begin output of /sbin/service nrpe restart ----
   STDOUT: Shutting down nrpe [  OK  ]
   Starting nrpe [FAILED]
   STDERR:
   ---- End output of /sbin/service nrpe restart ----
   Ran /sbin/service nrpe restart returned 1

warning_condition & crticial_condition should support passing in Integers as well as Strings

Didn't realize the conditions were required to be a string. I don't think it should be necessary, you could call .to_s in the template.

RHEL: nrpe tries to start every chef-client run

Hello,

I'm not sure if this is a RHEL6 specific issue or not, but here is the problem. NRPE is not starting or restarting properly. When I add a nrpe command, I have to manually restart the daemon to get my nagios server to work with the new command. Also, I noticed that chef-client tries to start nrpe during every run, so there may be a problem with runtime detection?

I'm able to help debug, but I'll need some hints to check on and/or try.

node.set not needed in default recipe

There is no need to set the nrpe.checks attribute with the set/normal priority. Default priority should be enough and would not mess with the node's persistent data.

See https://github.com/tas50/chef-nrpe/blob/af28f203aaf35ac6e94931a14de6b89c534ded81/recipes/default.rb#L83

Just to get a bit of context: we are managing nodes with git in our organization in a static way (since they are bare metal) and we have a script that check for synchronization b/t git and the chef server. Normal attributes are persistent data that we store in git as opposed to default/overrides which are generated during each chef run by roles/environments/cookbooks. Having normal attributes on a node mean that the cookbook requested to "store" some attribute across chef runs.

Remove .rubocop.yml with Dangerfile

🗣️ Foreword

Thank for taking the time to fill this bug report fully. Without it we may not be able to fix the bug, and the issue may be closed without resolution.

👻 Brief Description

If the only thing in the .rubocop/yml is Dangerfile
Run the latest cookstyle
Remove .rubpopo.yml

Issue sprouted from sous-chefs/meta/issues/108. If not applicable then issue should be closed.

Windows Client Support

Hi,

This cookbook doesn't support Windows but we use it to create checks using nrpe_check. At the moment the check doesn't work on Windows due to this and this.

To get around this, I've copied the resource into a wrapper cookbook and named it nrpe_check_windows; what are the feels if we add unless platform?('windows') to each of the highlighted lines so this is not needed?

It wouldn't mean Windows support but it would allow people like me to reuse the resource to create checks after installing NSClient++ by whatever means.

Stephen

Deploying nrpe recipe fails when default['nrpe']['allowed_hosts'] is set

Deploying nrpe recipe fails when default['nrpe']['allowed_hosts'] attribute is set in attributes/default.rb with following error:
"
[2014-09-09T09:31:32+02:00] ERROR: can't convert String into Array

Recipe Compile Error in /tmp/chef-solo/cookbooks/nrpe/recipes/default.rb

TypeError

can't convert String into Array

Cookbook Trace:

/tmp/chef-solo/cookbooks/nrpe/recipes/default.rb:52:in concat' /tmp/chef-solo/cookbooks/nrpe/recipes/default.rb:52:infrom_file'
/usr/lib/ruby/vendor_ruby/chef/mixin/from_file.rb:30:in instance_eval' /usr/lib/ruby/vendor_ruby/chef/mixin/from_file.rb:30:infrom_file'
/usr/lib/ruby/vendor_ruby/chef/cookbook_version.rb:237:in load_recipe' /usr/lib/ruby/vendor_ruby/chef/run_context.rb:151:inload_recipe'
/usr/lib/ruby/vendor_ruby/chef/run_context/cookbook_compiler.rb:139:in block in compile_recipes' /usr/lib/ruby/vendor_ruby/chef/run_context/cookbook_compiler.rb:137:ineach'
/usr/lib/ruby/vendor_ruby/chef/run_context/cookbook_compiler.rb:137:in compile_recipes' /usr/lib/ruby/vendor_ruby/chef/run_context/cookbook_compiler.rb:74:incompile'
/usr/lib/ruby/vendor_ruby/chef/run_context.rb:86:in load' /usr/lib/ruby/vendor_ruby/chef/client.rb:250:insetup_run_context'
/usr/lib/ruby/vendor_ruby/chef/client.rb:498:in do_run' /usr/lib/ruby/vendor_ruby/chef/client.rb:199:inblock in run'
/usr/lib/ruby/vendor_ruby/chef/client.rb:193:in fork' /usr/lib/ruby/vendor_ruby/chef/client.rb:193:inrun'
/usr/lib/ruby/vendor_ruby/chef/application.rb:208:in run_chef_client' /usr/lib/ruby/vendor_ruby/chef/application/solo.rb:221:inblock in run_application'
/usr/lib/ruby/vendor_ruby/chef/application/solo.rb:213:in loop' /usr/lib/ruby/vendor_ruby/chef/application/solo.rb:213:inrun_application'
/usr/lib/ruby/vendor_ruby/chef/application.rb:66:in run' /usr/bin/chef-solo:24:in

'

Relevant File Content:

/tmp/chef-solo/cookbooks/nrpe/recipes/default.rb:

45: # the first run on a nagios server wont find itself via search so if we're the nagios server, go
46: # ahead and put our own IP address in the NRPE config (unless it's already there).
47: if node.run_list.roles.include?(node['nrpe']['server_role'])
48: mon_host << node['ipaddress'] unless mon_host.include?(node['ipaddress'])
49: end
50:
51: # add any extra nagios servers defined via the 'allowed_hosts attribute'
52>> mon_host.concat node['nrpe']['allowed_hosts'] if node['nrpe']['allowed_hosts']
53:
54: include_dir = "#{node['nrpe']['conf_dir']}/nrpe.d"
55:
56: directory include_dir do
57: owner node['nrpe']['user']
58: group node['nrpe']['group']
59: mode '0755'
60: end
61:

[2014-09-09T09:31:31+02:00] INFO: Forking chef instance to converge...
[2014-09-09T09:31:32+02:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)"

I've created and tested fix for this issue sbocinec@6645f50

Dangerfile should use failure instead of fail

🗣️ Foreword

Thank for taking the time to fill this bug report fully. Without it we may not be able to fix the bug, and the issue may be closed without resolution.

👻 Brief Description

On the repo, ensure that Dangerfile matches https://github.com/sous-chefs/repo-management/blob/master/Dangerfile

Issue sprouted from sous-chefs/meta/issues/110. If not applicable then issue should be closed.

Update builds to be parallel

🗣️ Foreword

Thank for taking the time to fill this bug report fully. Without it we may not be able to fix the bug, and the issue may be closed without resolution.

👻 Brief Description

As part of our build process we should build each possible operating system separately

1. Ensure you have dokken setup and working:
2. dokken: aliased to KITCHEN_LOCAL_YAML=kitchen.dokken.yml kitchen
3. run dokken list, you should see a list of builds with dokken as the provider
4. download: https://github.com/sous-chefs/repo-management/blob/master/scripts/circleci_maker.rb and make this executable
5. run: dokken list -j | ./circleci_maker.rb > .circleci/config.yml

Issue sprouted from sous-chefs/meta/issues/112. If not applicable then issue should be closed.

Supermarket version "2.0.1" not working

Cookbook version

2.0.1

Chef-client version

chef-12.18.31-1

Platform Details

CentOS

Scenario:

Just include the recipe

Steps to Reproduce:

Just include the recipe

Expected Result:

The template is not valid but the last commit fixed it.

Do you (@damacus & @tas50) have any windows when the latest bug fix will be released?

nrpe-1.4.2 on Supermarket has .DS_Store files in it, berks up failing

Problem

The latest release of nrpe (1.4.2) has .DS_Store files in it. This is causing a cookbook that depends on it to fail when doing a berks up.

curl -Lo nrpe-1.4.2.tgz https://supermarket.getchef.com/cookbooks/nrpe/versions/1.4.2/download
tar -zxf nrpe-1.4.2.tgz
find ./nrpe -name '.DS_Store' -type f

This would output:

./nrpe/.DS_Store
./nrpe/templates/.DS_Store
./nrpe/templates/default/.DS_Store

When doing a berks up I get the following error:

E, [2014-08-25T10:56:15.858649 #29635] ERROR -- : Ridley::Errors::HTTPBadRequest: {"error":["Invalid element in array value of 'templates'."]}
E, [2014-08-25T10:56:15.859677 #29635] ERROR -- : /Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/ridley-4.0.0/lib/ridley/middleware/chef_response.rb:24:in `on_complete'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/faraday-0.9.0/lib/faraday/response.rb:9:in `block in call'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/faraday-0.9.0/lib/faraday/response.rb:57:in `on_complete'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/faraday-0.9.0/lib/faraday/response.rb:8:in `call'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/faraday-0.9.0/lib/faraday/response.rb:8:in `call'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/faraday-0.9.0/lib/faraday/response.rb:8:in `call'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/ridley-4.0.0/lib/ridley/middleware/chef_auth.rb:74:in `call'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/faraday-0.9.0/lib/faraday/request/retry.rb:87:in `call'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/faraday-0.9.0/lib/faraday/rack_builder.rb:139:in `build_response'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/faraday-0.9.0/lib/faraday/connection.rb:377:in `run_request'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/ridley-4.0.0/lib/ridley/connection.rb:104:in `run_request'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/faraday-0.9.0/lib/faraday/connection.rb:177:in `put'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/celluloid-0.16.0.pre3/lib/celluloid/calls.rb:26:in `public_send'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/celluloid-0.16.0.pre3/lib/celluloid/calls.rb:26:in `dispatch'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/celluloid-0.16.0.pre3/lib/celluloid/calls.rb:63:in `dispatch'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/celluloid-0.16.0.pre3/lib/celluloid/cell.rb:60:in `block in invoke'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/celluloid-0.16.0.pre3/lib/celluloid/cell.rb:71:in `block in task'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/celluloid-0.16.0.pre3/lib/celluloid/actor.rb:357:in `block in task'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/celluloid-0.16.0.pre3/lib/celluloid/tasks.rb:57:in `block in initialize'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/celluloid-0.16.0.pre3/lib/celluloid/tasks/task_thread.rb:21:in `block in create'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/celluloid-0.16.0.pre3/lib/celluloid/thread_handle.rb:13:in `block in initialize'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/celluloid-0.16.0.pre3/lib/celluloid/actor_system.rb:32:in `block in get_thread'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/celluloid-0.16.0.pre3/lib/celluloid/internal_pool.rb:130:in `call'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/celluloid-0.16.0.pre3/lib/celluloid/internal_pool.rb:130:in `block in create'
(celluloid):0:in `remote procedure call'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/celluloid-0.16.0.pre3/lib/celluloid/calls.rb:92:in `value'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/celluloid-0.16.0.pre3/lib/celluloid/proxies/sync_proxy.rb:33:in `method_missing'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/celluloid-0.16.0.pre3/lib/celluloid/proxies/cell_proxy.rb:17:in `_send_'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/celluloid-0.16.0.pre3/lib/celluloid/pool_manager.rb:41:in `_send_'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/celluloid-0.16.0.pre3/lib/celluloid/pool_manager.rb:140:in `method_missing'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/celluloid-0.16.0.pre3/lib/celluloid/calls.rb:26:in `public_send'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/celluloid-0.16.0.pre3/lib/celluloid/calls.rb:26:in `dispatch'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/celluloid-0.16.0.pre3/lib/celluloid/calls.rb:63:in `dispatch'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/celluloid-0.16.0.pre3/lib/celluloid/cell.rb:60:in `block in invoke'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/celluloid-0.16.0.pre3/lib/celluloid/cell.rb:71:in `block in task'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/celluloid-0.16.0.pre3/lib/celluloid/actor.rb:357:in `block in task'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/celluloid-0.16.0.pre3/lib/celluloid/tasks.rb:57:in `block in initialize'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/celluloid-0.16.0.pre3/lib/celluloid/tasks/task_fiber.rb:15:in `block in create'
(celluloid):0:in `remote procedure call'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/celluloid-0.16.0.pre3/lib/celluloid/calls.rb:92:in `value'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/celluloid-0.16.0.pre3/lib/celluloid/proxies/sync_proxy.rb:33:in `method_missing'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/ridley-4.0.0/lib/ridley/resource.rb:132:in `raw_request'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/ridley-4.0.0/lib/ridley/resource.rb:123:in `request'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/ridley-4.0.0/lib/ridley/resources/cookbook_resource.rb:160:in `update'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/ridley-4.0.0/lib/ridley/resources/cookbook_resource.rb:228:in `upload'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/celluloid-0.16.0.pre3/lib/celluloid/calls.rb:26:in `public_send'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/celluloid-0.16.0.pre3/lib/celluloid/calls.rb:26:in `dispatch'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/celluloid-0.16.0.pre3/lib/celluloid/calls.rb:63:in `dispatch'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/celluloid-0.16.0.pre3/lib/celluloid/cell.rb:60:in `block in invoke'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/celluloid-0.16.0.pre3/lib/celluloid/cell.rb:71:in `block in task'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/celluloid-0.16.0.pre3/lib/celluloid/actor.rb:357:in `block in task'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/celluloid-0.16.0.pre3/lib/celluloid/tasks.rb:57:in `block in initialize'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/celluloid-0.16.0.pre3/lib/celluloid/tasks/task_thread.rb:21:in `block in create'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/celluloid-0.16.0.pre3/lib/celluloid/thread_handle.rb:13:in `block in initialize'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/celluloid-0.16.0.pre3/lib/celluloid/actor_system.rb:32:in `block in get_thread'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/celluloid-0.16.0.pre3/lib/celluloid/internal_pool.rb:130:in `call'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/celluloid-0.16.0.pre3/lib/celluloid/internal_pool.rb:130:in `block in create'
(celluloid):0:in `remote procedure call'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/celluloid-0.16.0.pre3/lib/celluloid/calls.rb:92:in `value'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/celluloid-0.16.0.pre3/lib/celluloid/proxies/sync_proxy.rb:33:in `method_missing'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/berkshelf-3.1.5/lib/berkshelf/uploader.rb:54:in `block (2 levels) in upload'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/berkshelf-3.1.5/lib/berkshelf/uploader.rb:50:in `each'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/berkshelf-3.1.5/lib/berkshelf/uploader.rb:50:in `block in upload'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/ridley-4.0.0/lib/ridley/client.rb:36:in `open'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/ridley-4.0.0/lib/ridley.rb:51:in `open'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/berkshelf-3.1.5/lib/berkshelf.rb:157:in `ridley_connection'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/berkshelf-3.1.5/lib/berkshelf/uploader.rb:49:in `upload'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/berkshelf-3.1.5/lib/berkshelf/uploader.rb:36:in `run'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/berkshelf-3.1.5/lib/berkshelf/berksfile.rb:542:in `upload'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/berkshelf-3.1.5/lib/berkshelf/cli.rb:208:in `upload'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/thor-0.18.1/lib/thor/command.rb:27:in `run'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/thor-0.18.1/lib/thor/invocation.rb:120:in `invoke_command'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/thor-0.18.1/lib/thor.rb:363:in `dispatch'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/berkshelf-3.1.5/lib/berkshelf/cli.rb:52:in `dispatch'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/thor-0.18.1/lib/thor/base.rb:439:in `start'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/berkshelf-3.1.5/lib/berkshelf/cli.rb:27:in `execute!'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/gems/berkshelf-3.1.5/bin/berks:5:in `<top (required)>'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/bin/berks:23:in `load'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/bin/berks:23:in `<main>'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/bin/ruby_executable_hooks:15:in `eval'
/Users/jrwesolo/.rvm/gems/ruby-2.1.2/bin/ruby_executable_hooks:15:in `<main>'

Manual fix

berks up works after running:

find ~/.berkshelf/cookbooks/nrpe-1.4.2 -name '.DS_Store' -type f | xargs -n1 -p rm

Useful links

Research pointing to this being the issue:
berkshelf/berkshelf#706
berkshelf/berkshelf#894

-f is not a valid option in version 2.15 of nrpe

Good day, so while cleaning up a cookbook that has not been used in a while I upgraded the version of the nrpe cookbook to the latest available and came across this issue on centos-7. We were pulling version 2.15 of nrpe as shown in the logs below. Went digging and saw the cookbook was installing the service file for systemd and is passing the -f flag which is not valid in the version being pulled in. Upgrading to version 3.2.1 has the -f option as valid.

I can work on a fix for this but I want to know the direction that the cookbook authors want to go with to fix this issue. couple ideas I have is to point the nrpe cookbook to the new version of nrpe and/or making the template check what version is being installed and swap to the correct flag in systemd. I have not checked centos 6 yet to see if it is having the same issue.

Log:

Sep 18 23:34:05 lively-vm systemd: Started Nagios Remote Program Executor.
Sep 18 23:34:05 lively-vm systemd: Starting Nagios Remote Program Executor...
Sep 18 23:34:05 lively-vm nrpe: /usr/sbin/nrpe: invalid option -- 'f'
Sep 18 23:34:05 lively-vm nrpe: NRPE - Nagios Remote Plugin Executor
Sep 18 23:34:05 lively-vm nrpe: Copyright (c) 1999-2008 Ethan Galstad ([email protected])
Sep 18 23:34:05 lively-vm nrpe: Version: 2.15
Sep 18 23:34:05 lively-vm nrpe: Last Modified: 09-06-2013
Sep 18 23:34:05 lively-vm nrpe: License: GPL v2 with exemptions (-l for more info)
Sep 18 23:34:05 lively-vm nrpe: SSL/TLS Available: Anonymous DH Mode, OpenSSL 0.9.6 or higher required
Sep 18 23:34:05 lively-vm nrpe: ***************************************************************
Sep 18 23:34:05 lively-vm nrpe: ** POSSIBLE SECURITY RISK - COMMAND ARGUMENTS ARE SUPPORTED! **
Sep 18 23:34:05 lively-vm nrpe: **      Read the NRPE SECURITY file for more information     **
Sep 18 23:34:05 lively-vm nrpe: ***************************************************************
Sep 18 23:34:05 lively-vm nrpe: ***************************************************************
Sep 18 23:34:05 lively-vm nrpe: ** POSSIBLE SECURITY RISK - TCP WRAPPERS ARE NOT AVAILABLE!  **
Sep 18 23:34:05 lively-vm nrpe: **      Read the NRPE SECURITY file for more information     **
Sep 18 23:34:05 lively-vm nrpe: ***************************************************************
Sep 18 23:34:05 lively-vm nrpe: Usage: nrpe [-n] -c <config_file> [-4|-6] <mode>
Sep 18 23:34:05 lively-vm nrpe: Options:
Sep 18 23:34:05 lively-vm nrpe: -n            = Do not use SSL
Sep 18 23:34:05 lively-vm nrpe: <config_file> = Name of config file to use
Sep 18 23:34:05 lively-vm nrpe: -4            = use ipv4 only
Sep 18 23:34:05 lively-vm nrpe: -6            = use ipv6 only
Sep 18 23:34:05 lively-vm nrpe: <mode>        = One of the following operating modes:
Sep 18 23:34:05 lively-vm nrpe: -i          =    Run as a service under inetd or xinetd
Sep 18 23:34:05 lively-vm nrpe: -d          =    Run as a standalone daemon
Sep 18 23:34:05 lively-vm nrpe: -d -s       =    Run as a subsystem under AIX
Sep 18 23:34:05 lively-vm nrpe: Notes:
Sep 18 23:34:05 lively-vm nrpe: This program is designed to process requests from the check_nrpe
Sep 18 23:34:05 lively-vm nrpe: plugin on the host(s) running Nagios.  It can run as a service
Sep 18 23:34:05 lively-vm nrpe: under inetd or xinetd (read the docs for info on this), or as a
Sep 18 23:34:05 lively-vm nrpe: standalone daemon. Once a request is received from an authorized
Sep 18 23:34:05 lively-vm nrpe: host, NRPE will execute the command/plugin (as defined in the
Sep 18 23:34:05 lively-vm nrpe: config file) and return the plugin output and return code to the
Sep 18 23:34:05 lively-vm nrpe: check_nrpe plugin.
Sep 18 23:34:05 lively-vm systemd: nrpe.service: main process exited, code=exited, status=3/NOTIMPLEMENTED
Sep 18 23:34:05 lively-vm systemd: Unit nrpe.service entered failed state.
Sep 18 23:34:05 lively-vm systemd: nrpe.service failed.

attributes:

normal['nrpe']['install_method']      = 'source'
normal['nrpe']['plugins']['version']  = '2.1.2'
normal['nrpe']['plugins']['checksum'] = '76c6b58f0867ab7b6c8c86c7e94fcce7183618f6daab63488990d0355f5600aa'

nrpe::default on Centos 7.x

Hi,

nrpe::default basically works on CentOS 7.x but the user/group in /etc/systemd/system/multi-user.target.wants/nrpe.service is not set according to node['nrpe']['user'] / node['nrpe']['group']

best

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

This repository currently has no open or pending branches.

Detected dependencies

github-actions

.github/workflows/ci.yml

• sous-chefs/.github 3.1.1
• actions/checkout v4
• actionshub/chef-install 3.0.0
• actionshub/test-kitchen 3.0.0

.github/workflows/stale.yml

• actions/stale v9

---

• Check this box to trigger a request for Renovate to run again on this repository

build-essential dependency

Hey there,

I am interested in using this cookbook, but the dependency on build-essential is steering me away... :) Is the only thing mandating that right now the source installation option? Do you know if it is widely used? build-essential definitely makes this quite a heavy install, especially if using a packaged install.

Thanks.

Update builds to be parallel

Thank for taking the time to fill this bug report fully. Without it we may not be able to fix the bug, and the issue may be closed without resolution.

👻 Brief Description

As part of our build process we should build each possible operating system separately

1. Ensure you have dokken setup and working:
2. dokken: aliased to KITCHEN_LOCAL_YAML=kitchen.dokken.yml kitchen
3. run dokken list, you should see a list of builds with dokken as the provider
4. download: https://github.com/sous-chefs/repo-management/blob/master/scripts/circleci_maker.rb and make this executable
5. run: dokken list -j | ./circleci_maker.rb > .circleci/config.yml

notifying the nrpe service to reload itself does not work correctly

Hey,

i'm using ubuntu 12.04LTS and the

file "#{node['nrpe']['conf_dir']}/nrpe.d/#{new_resource.command_name}.cfg" do
  ...
  notifies :reload, 'service[nrpe]'
end

within the check lwrp
doesn't work for me. It always just says:

Recipe: nrpe::default
  * service[nagios-nrpe-server] action reload (up to date)

And using the check_nrpe plugin can't find configured commands until i restart nrpe by hand.

I'm installing nrpe using the source method and the provided init script doesn't support reload as a command, maybe this is the real problem here, not sure.

Determine if a pid file is actually needed correctly

We need to add some better logic to determine if a pid file is needed (temp fix to allow disabling via #67 by @sspans).

RedHat init scripts don't reference a pid file nor does systemd need one.

easy fix: tripping over new platform_family behavior in Amazon Linux

Cookbook version

2.0.5

Chef-client version

14.12.9

Platform Details

Amazon Linux

Scenario:

Default value of node['nrpe']['plugin_dir'] is wrong with newer Chef Clients. Should be /usr/lib64/nagios/plugins, but comes back with /usr/lib/nagios/plugins now. This is because in Chef 13 or 14, Amazon Linux got its own platform_family, so it's no longer synonymous with rhel.

Steps to Reproduce:

Try on Amazon Linux with Chef 14

Super easy to fix. In attributes/default.rb, if we change:

when 'rhel', 'fedora'

...to:

when 'rhel', 'fedora', 'amazon'

...we get the expected behavior.