Thoughts about a custom plugin

[stan]

I have a number of isolated networks, that is networks which are
deliberately non-routable to. On each of these networks, I have a single
host that has a 2nd NIC thta is on the general network. I don't can't to
turn on forwarding on this host. I would like to monitor some statuses on
the machines on the isolated networks.

I am thinking of doing this using a Nagios plugin. My first thoughts on
this plugin are to have the plugin execute a script on the dual homed
machines. This script would, as a first cut, ping the internal machines, and
return up/down statuses. Later I might want too expand on this by having
the script do some other checks on the isolated machines.

After having looked at the way Nagios plugins work, i have a couple of
concerns about this design. The first is the rule that says the status
returned by a plugin should be less than 8 characters. The 2nd is that, for
the first version of the remote script, if a machine is down, the ping could
take a while to timeout.

I can see how to address the 2nd concern by having a "checker script" on
the dual homed machine, that maintains a "state" file, which the script called
by the Nagios plugin could simply read. But how can I address the firs
concern?


Any other thoughts to improve this design?

-- 
One of the main causes of the fall of the roman empire was that, lacking
zero, they had no way to indicate successful termination of their C
programs.

-------------------------------------------------------------------------
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=/
_______________________________________________
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