last_run_report.yaml is not readable by the check_puppet_agent script

[jgrammen-agilitypr]

There is apparently "secure" info in last_run_report so puppetlabs have made the file not world readable. That means that it is not possible for the script to read that file.

[aswen]

Yeah, we ran into this too. We worked around it by running the check using sudo, but that doesn't feel very good.... This is also related to #28, #32 and #37. ( FYI ping @tiernap, @erude1 and @rocco83)

I haven't found time to dive into this and come up with a real good solution though. Anyone has suggestions?

[akomakom]

A workaround for this is to tell puppet to change permissions. See Puppet Docs (not tested in older versions)

puppet.conf (on all nodes):

[agent]
    vardir = /opt/puppetlabs/puppet/cache {mode = 751}
    lastrunreport = $statedir/last_run_report.yaml {mode = 644}

This changes readability for the cache directory from 750 to 751 and makes the yaml file in its subdirectory readable. It is also possible to specify owner, not just mode (or instead of mode):

... { owner = puppet, group = nagios, mode = 750 }

[Rocco83]

@akomakom this is a good workaround, but nevertheless not possible to enforce in the plugin itself. Nevertheless, this should be not probably resolved within the plugin itself, as it is changing a default value.

My 2 cents go over the following approach:

• the script check if the file is readable;
• if the file is not readable try to make use of sudo to read it;
• if not report it as an error and link to a doc section with proper solution for this (which can be sudo OR puppet.conf modification).

Sudo is already required, therefore i see no reason in avoiding the usage.

@aswen i think that you should keep only one bug open among this one, as they share really the same root cause. Maybe one opened by you with all of the details, including the upstream bug.

Comments are welcome!

[bill-mcgonigle]

Don't try to add { group = nagios }, as mentioned above, in Puppet 4/5 (and especially don't push it out to all your puppet clients... oy) - only 'root' and 'service' are valid group values at this point and puppet will fail to run with an invalid group.

I added some sudo tests as suggested instead - see above patch. It's working at least for my puppet 4/5 machines mostly on Debian/Fedora/CentOS.

[lordbink]

We did not like opening up our permissions on the report and cache files so we came up with a slightly awkward solution by creating a cron job that sends results to temp and simply "cat"ing the result.

## Every 30 minutes, sleep for a random interval less than 15 minutes, and drop command result to a temp file
cron {'nagios_puppet_check':
  minute      => '*/30',
  user        => 'root',
  command     => 'sleep $((RANDOM \% 900)) && /usr/lib/nagios/plugins/check_puppet_agent > /tmp/puppet_nagios_result.txt && chown root:nagios /tmp/puppet_nagios_result.txt && chmod 640 /tmp/puppet_nagios_result.txt',
  environment => 'PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/puppetlabs/bin"',
}

command[check_puppet_agent]='cat /tmp/puppet_nagios_result.txt'

[cspeterson]

To add to the list of stopgaps until this is resolved, my solution was to use the puppet configuration variable postrun_command in the puppet.conf on my agents to create an icinga-readable copy of the files:

postrun_command = cp -f /path/to/last_run_summary.yaml /path/to/last_run_summary.icingareadablecopy.yaml && chown icinga:icinga /path/to/last_run_summary.icingareadablecopy.yaml && chmod 0600 /path/to/last_run_summary.icingareadablecopy.yaml && cp -f /path/to/last_run_report.yaml /path/to/last_run_report.icingareadablecopy.yaml && chown icinga:icinga /path/to/last_run_report.icingareadablecopy.yaml && chmod 0600 /path/to/last_run_report.icingareadablecopy.yaml

addendum: it turns out that postrun commands come before the summary file is written , so the copy will always be one run behind with this method ☹️

[joe-at-startupmedia]

https://github.com/aswen/nagios-plugins/issues/38#issuecomment-343587995

lastrunreport = $statedir/last_run_report.yaml {mode = 644}

This is tested on version 3.6.2

In addition to allowing everyone readable permission to the file, I symlinked the file over to the lastrunreport of the sudo user. In my case nrpe is the sudo user which results in puppet config resolving the lastrunreport to its user-specific directly:

/var/run/nrpe/.puppet/var/state/last_run_report.yaml

I solved this by simply creating a symlink:

sudo -u nrpe ln -s /var/lib/puppet/state/last_run_report.yaml /var/run/nrpe/.puppet/var/state/last_run_report.yaml

That can be handled in puppet:

nrpe.pp

  file { '/var/run/nrpe/.puppet/var/state/last_run_report.yaml':
    ensure => 'link',
    target => '/var/lib/puppet/state/last_run_report.yaml',
    owner => 'nrpe',
    group => 'nrpe'
  }

/etc/sudoers.d/nrpe

We also need to add nrpe to sudoers

nrpe ALL=(ALL) NOPASSWD:/usr/bin/puppet