<div dir="ltr">On Tue, Sep 23, 2008 at 10:50 PM, Gavin Carr <span dir="ltr"><<a href="mailto:gavin@openfusion.com.au">gavin@openfusion.com.au</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Tue, Sep 23, 2008 at 04:42:45PM -0300, Marcel wrote:<br>
> I think you missed the point Andreas tried to make.<br>
><br>
> On Tue, Sep 23, 2008 at 5:48 AM, Kenneth Holter <<a href="mailto:kenneho.ndu@gmail.com">kenneho.ndu@gmail.com</a>>wrote:<br>
><br>
> > Actually, I've done this already. The macro, say, X defines the path to be<br>
> > "/usr/lib64/nagios/plugins". But as far as I can see this does not solve my<br>
> > problem, as the path on a 32-bit systems is different than the path on a<br>
> > 64-bit system.<br>
> ><br>
><br>
> Let's say you have $USER1$ = /path/to/lib32/nagios/plugins, and<br>
> $USER2$=/path/to/lib64/nagios/plugins, thus, you should define x86_32<br>
> commands and x86_64 commands as usual, but using $USER1$ and $USER2$ where<br>
> pertinent, and then, on every x64 system, you should use the _64 commands.<br>
<br>
</div>Although that's a bit of an ugly solution, as you're having to define every<br>
command twice. DRY etc.<br>
<br>
We've found it easier to just leave the plugin invocations unqualified and add<br>
the relevant nagios plugins directory to the $PATH for the remote nagios user.<br>
Works nicely here.<br>
</blockquote><div><br>Well, I was just pointing out the previous thoughts line of reason. At my environment, I do not care if the system is 64 or 32 bits anyway. I've pre-compiled plugins that is deployed at the very same location within /path/to/nagios/libexec, so if it's a 64bit arch, then we deploy that kind of plugins and the same goes to 32bits archs. <br>
<br>So, no resource.cfg macro definitions needed to address this kind of situation.<br></div></div><br>Cheers,</div>