[Pkg-nagios-devel] Bug#730195: Bug#730195: check_raid depends on root PATH

Daniel Pocock daniel at pocock.com.au
Mon Jan 6 13:23:24 UTC 2014


On 06/01/14 14:06, Jan Wagner wrote:
> Hi Daniel,
>
> thanks for taking time and reporting your issue.
>
> Am 22.11.13 15:16, schrieb Daniel Pocock:
> > check_raid uses "which" to try and work out which RAID utilities
> > are on the system
>
> > However, because nagios and nrpe run as a non-root user, it fails
> > to discover RAID utilities in /usr/sbin, /sbin, ... and therefore
> > it doesn't check those that it can't find
>
> > For nrpe, it is possible to work around it with the following in
> > /etc/nrpe.cfg:
>
> > command_prefix=/usr/sbin:/sbin:$PATH
>
> > I observed this particular problem with the hpacucli - I use the
> > packaged version which is in /usr/sbin
>
> As check_raid makes extensive use of sudo, you just need to install
> sudo and add something like the following to /etc/sudoers.d/
>
> # cat /etc/sudoers.d/check_raid
> nagios  ALL=NOPASSWD: /usr/sbin/hpasmcli


Not quite ... if the hpacucli binary can't be found by "which" in $PATH,
then it won't even try to run it with or without sudo

That is why I made this a bug - maybe the "which" command should search
using the root path too or some other improvement to the script

Could you please re-open the bug until somebody comes up with a strategy
for that?  If you want to downgrade the severity that is up to you, but
as long as there is confusion in the way it searches for binaries, that
appears to be a bug.

>
> > I've marked this bug as important because not monitoring RAID
> > correctly may lead to data loss
>
> This bug would indeed just severity 'normal' as check_raid is just a
> part of a plugins collection.
>
> Anyways ... hpasmcli isn't part of Debian, so there is nothing to
> worry about that.
>
I agree hpasmcli is not free software - but check_raid does interact
with it and HP servers are fairly common



More information about the Pkg-nagios-devel mailing list