Monitoring 64-bit and 32-bit servers - plugin path problem

[Kenneth Holter]

Quite a lot of ways to solve this issue, it seem. :)

I have a working configuration in which the $USER macro is defined with
"/usr/lib*64*/nagios/plugins/check_disk", and on 32-bit systems I make a
symlink from /usr/lib64/nagios to /usr/lib/nagios. This works like a charm,
and doesn't seem to be very messy.

I may consider the Gavins approach setting the PATH environment though,
since it looked like a very neat solution.



On 9/25/08, Tom Throckmorton <throck at gmail.com> wrote:
>
> On Sep 23 08:18, Kenneth Holter wrote:
> > Hello all.
> >
> >
> > I've set up Nagios to monitor a few 64-bit machines, and this seems to be
> > working correctly. For example, my command for checking a remote disk is
> > defined like this:
> >
> >
> > define command{
> >         command_name    check_remote_disk
> >         command_line    /somepath/check_by_ssh <args> -C
> > "/usr/lib64/nagios/plugins/check_disk <remote args>"
> > }
> >
> > This command executes /usr/*lib64*/nagios/plugins/check_disk on the
> remote
> > system. On 32-bit systems, on the other hand, the path to the plugin is
> > /usr/*lib*/nagios/plugins/check_disk. It thus looks like I have to
> > differentiate between 32-bit and 64-bit commands, and in effect devide
> the
> > configuration itself in a 32-bit section and 64-bit section.
> >
> > I'm sure there is a neat way of solving this, and could use some advice.
> I
> > guess I could symlink all over the place to get things going, but there
> are
> > probably a better way of doing this.
>
> Kenneth,
>
> Here are two more ideas for you:
>
> 1) You could add some test logic into your command def, like so:
>
> $USER1$/check_by_ssh <args> -C "if [ -e /usr/lib64/nagios/plugins/ ] ; then
> /usr/lib64/nagios/plugins/check_disk <remote args> ; else
> /usr/lib/nagios/plugins/check_disk <remote args> ; fi"
>
> Rather ugly, but I think that would do what you want.
>
> 2) configure the remote ssh client to know it's local path to the plugins;
> you
> could do this either in the public key, by using something like
> 'environment="NAGIOSPATH=/usr/lib64/plugins' after your command and host
> restrictions (you _are_ using command and host restrictions in your public
> keys, right? ;-), or in ~/.ssh/environment on the remote host.  Note that
> to
> use either of those, you'd need to set PermitUserEnvironment=yes in your
> sshd_config - see sshd(8) and sshd_config(5).  Once that's set, you should
> be
> able to run:
>
> $USER1$/check_by_ssh <args> -C "\$NAGIOSPATH\/check_disk <remote_args>"
>
> ...which would also get you there, I think.
>
> Couple of disclaimers...
> - allowing user environments to be set via sshd can be a security risk
> - I've only tried this from the command line; you'll likely need to do some
> interesting escaping to get it to work correctly.
>
> Also,
>
> Gavin Carr wrote:
> > We've found it easier to just leave the plugin invocations unqualified
> and
> > add the relevant nagios plugins directory to the $PATH for the remote
> nagios
> > user.  Works nicely here.
>
> +1 on that one, too - simple is good.
>
> Cheers,
>
> -tt
>
> --
> Tom Throckmorton
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/users/attachments/20080926/67127a7d/attachment.html>
-------------- next part --------------
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
-------------- next part --------------
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null