Hi there,
I am very new to Nagios. I have managed to get it set up and running. This may seem like a dopey question but here goes. I want to add an email check plugin from Nagios Exhange. It is a Python file. What is the procedure to get Nagios to be able to use this plugin?
cedross
Hi
“Normally” 
you would put the check plugin into your libexec directory and give it such permissions (chown nagios:nagios & chmod 755) as to allow nagios to use it (i.e. as per the other checks in libexec dir)…
[root@localhost libexec]# ll check_foo
-rwxr-xr-x 1 nagios nagios 9707 Sep 22 12:09 check_foo
Then you need to define it as a command object (i.e. in commands.cfg in 3.x), e.g. something like
define command{
name check_foo
command_name check_foo
command_line $USER1$/check_foo -I $HOSTADDRESS$ -x $ARG1$ -y $ARG2$...and so on
}
The exact contents of your “command_line” entry will depend on the information that check_foo needs to operate. This is normally along the lines of a host IP address and one or more arguments. Pretty much all check plugins allow you to ./check_foo --help to assist with identifying the syntax and requirements for said plugin. The $USER1$ macro represents the path to your libexec directory. $HOSTADDRESS$ represent’s the IP address of the host from which the service check is called. These are filled in automagically by nagios.
Once that’s done, you may then use check_foo in your service check object, e.g.
define service{
use generic-service ; Inherit default values from a template
host_name remotehost
service_description FOO
check_command check_foo!firstarg!secondarg
}
Notice the check_command delimiter - ! - this seperates the arguments that are passed to the command object. The variable after the initial ! will map to $ARG1$, the one after the second ! to $ARG2$, and so on. When this check is called, nagios executes the following
Happy days! (Normally!)
So that’s it in a nutshell - any further questions, feel free to pipe up
HTH
/S
Thanks very much for the help. I also have another question. In regards to the arguments that the plugins take. Where are those variables set? Where does the plugin get the values for $ARG1$,$ARG2$, $ARG3$ etc?
cedross
From the service check definition. If you re-read the last part of my previous post, the plugin receives its input arguments when nagios runs it - $ARG1$, $ARG2$…$ARGN$ are defined in the command object “command_line” and they map directly to the service object definition variables after each ! delimiter in the “check_command”…
Here it is in colour…
[quote]define command{
name check_foo
command_name check_foo
command_line $USER1$/check_foo -I $HOSTADDRESS$ -x $ARG1$ -y $ARG2$…and so on
}
The exact contents of your “command_line” entry will depend on the information that check_foo needs to operate. This is normally along the lines of a host IP address and one or more arguments. Pretty much all check plugins allow you to ./check_foo --help to assist with identifying the syntax and requirements for said plugin. The $USER1$ macro represents the path to your libexec directory. $HOSTADDRESS$ represent’s the IP address of the host from which the service check is called. These are filled in automagically by nagios.
Once that’s done, you may then use check_foo in your service check object, e.g.
define service{
use generic-service ; Inherit default values from a template
host_name remotehost
service_description FOO
check_command check_foo!firstarg!secondarg
}
Notice the check_command delimiter - ! - this seperates the arguments that are passed to the command object. The variable after the initial ! will map to $ARG1$, the one after the second ! to $ARG2$, and so on. When this check is called, nagios executes the following
/<path_to_libexec>/check_foo -I -x firstarg -y secondarg[/quote]
…of course as always TIMTOWTDI… As a for instance if you had a plugin like check_http or check_snmp with multiple uses you wouldn’t want to go and create lots of different command object definitions for each way you might implement it, so you just have the one and use a singe argument in the command object and a single delimiter followed by multiple argumens in the service object… like if you have check_foo and it can either check for thing1 or thing2 with various ‘thing’ purpose-relevant arguments, you just define check_foo like
[quote]define command{
name check_foo
command_name check_foo
command_line $USER1$/check_foo -I $HOSTADDRESS$ $ARG1$
}[/quote]
you can then use it in different service objects in different ways… like
[quote]define service{
use generic-service
host_name remotehostA
service_description FOO-thing1
check_command check_foo!-x thing1 -y tribbles
}[/quote]
and
[quote]define service{
use generic-service
host_name remotehostB
service_description FOO-thing2
check_command check_foo!-x thing2 -z rhubarb
}[/quote]
Then, when nagios checks service FOO-thing1 for remotehostA it runs check_foo like this
/<path_to_libexec>/check_foo -I -x thing1 -y tribbles
and for FOO-thing2 for remotehostB it runs check_foo like this
/<path_to_libexec>/check_foo -I -x thing2 -z rhubarb
Hope that’s a bit clearer now.
/S