[Nagiosplug-help] RE: [Nagios-users] Use of check_by_ssh

[Ralph.Grothe at itdz-berlin.de]

Hi Marc,

thanks for clarifying the meaning of check_by_ssh.

Since I haven't installed any Nagios stuff (incl. Plugins) on the
DMZ host yet I actually haven't thought of my little script as a
Nagios plugin.
Thus I didn't cling to plugin developer's guidelines.
But you are right.
I should rather use existing Nagios plugins for checking common
services (like check_http) than trying to reinvent something that
already stood proof of time.
The only problem is, as the target box is a DMZ host, there are
no development tools installed on (even no Perl, the CGIs are
closed source binaries coming from third party company who
developped the whole application.
To add to the odds, this is the only HP-UX 10.20 box (still
32bit!) we host.
Even if I found a compiler (e.g. gcc for this platform) I
wouldn't be allowed to install it there for my build.
On the other hand we have many 11.00 and 11i servers, and on some
of them even C compilers.
I'm not sure if I can build 10.20 32bit binaries of
Nagios-plugins on one of them.
Maybe if use the propper compiler flags.
I will see first if my build of check_http for 11.00 will be
executable on the 10.20 host (probably not, as you mentioned
differing libs etc.).
If that doesn't work I will see if I can build for a different
target
(sort of x-compile).
If it all doesn't work I will simply extend my little shell
script to conform to the developer's guidelines (viz. return
codes, messages),
and do my own parsing.
Btw, I saw there is a utils.pm, that I "use"-d in my own Perl
plugins, though it offers very little functionality.
Is there something similar for Bourne shell compatible plugins,
e.g. something you would source like ". $libexec_dir/utils.sh"?

You see, because an SSH installation on every of our hosts was so
obvious and natural to me, I totally missed the idea that
check_by_ssh could just be an offering to those whose Nagios
server lacks such.


> -----Original Message-----
> From: nagios-users-admin at lists.sourceforge.net 
> [mailto:nagios-users-admin at lists.sourceforge.net] On Behalf 
> Of Marc Powell
> Sent: Friday, July 29, 2005 6:05 PM
> To: nagiosplug-help at lists.sourceforge.net; 
> nagios-users at lists.sourceforge.net
> Subject: RE: [Nagios-users] Use of check_by_ssh
> 
> 
> 
> 
> > -----Original Message-----
> > From: nagios-users-admin at lists.sourceforge.net
[mailto:nagios-users-
> > admin at lists.sourceforge.net] On Behalf Of 
> Ralph.Grothe at itdz-berlin.de
> > Sent: Friday, July 29, 2005 7:14 AM
> > To: nagiosplug-help at lists.sourceforge.net; nagios-
> > users at lists.sourceforge.net
> > Subject: [Nagios-users] Use of check_by_ssh
> > 
> > Hi,
> > 
> > I have a bastion host in a dmz that serves HTTP(S) to the
> > internet.
> > 
> > I must monitor the webserver by pulling a certain CGI URI and
see
> > if the Webserver returns a 200.
> > 
> > Unfortunately I don't get another port (e.g. 5666/tcp for
NRPE)
> > opened by the firewall gang.
> > 
> > I only have access from our LAN to the bastion host via SSH.
> > 
> > Thus I wrote a short shell script that resides on the
webserver
> > and GETs the HEAD of this URI
> > through wget (with -S, -C off, --spider).
> > It's called check_dmz_www.sh
> > 
> > So far this script isn't doing any parsing of the output from
the
> > GET.
> > I thought to leave this part to a Nagios check_* plug-in.
> 
> Your script would work and if you pursued that path I would 
> need to put
> in the checking logic and *exit properly* as defined in the
Developer
> Guidelines at http://nagiosplug.sf.net. That being said, you're
just
> duplicating the functionality of the check_http plugin. Why
don't you
> just copy/compile that plugin on the DMZ host and use it to
check your
> web server using check_by_ssh (see below).
> 
> > 
> > In the libexec dir I discovered check_by_ssh.
> > Unfortunately, as most distributed plug-ins, the
documentation is
> > a bit too terse.
> > 
> > From the --help screen I can't see the use of this plug-in,
> > as it doesn't do anything more (i.e. return code parsing
logic
> > etc.) than vanilla ssh client does.
> > 
> > E.g. I would call check_by_ssh from the Nagios server like
this
> > 
> > 
> > $ /opt/sw/nagios/libexec/check_by_ssh -1 -H $hostaddress -l
www
> > -i ~nagios/.ssh/id_rsa1_dmz_www -C
> > /usr/local/sbin/check_dmz_www.sh
> > Connecting to 127.0.0.1:80... connected.
> > HTTP request sent, awaiting response...
> >  1 HTTP/1.1 200 OK
> >  2 Date: Fri, 29 Jul 2005 11:58:47 GMT
> >  3 Server: Apache/1.3.22 (Unix) mod_ssl/2.8.5 OpenSSL/0.9.6b
> >  4 Keep-Alive: timeout=25, max=100
> >  5 Connection: Keep-Alive
> >  6 Content-Type: text/html
> > 200 OK
> > 
> > 
> > 
> > But where's the point in using this plug-in?
> > For that I could as well just call the ssh client.
> 
> It's just a wrapper/proxy. The plugin will ssh to the specified
host,
> run the specified command and return it's output _and_ exit
code to
> nagios, just as if nagios had run the plugin on the remote host
> directly. If you have the check_http plugin in /usr/local/sbin
on the
> remote host you could do something like the following --
> 
> /opt/sw/nagios/libexec/check_by_ssh -1 -H $hostaddress -l www
-i
> ~nagios/.ssh/id_rsa1_dmz_www -C /usr/local/sbin/check_http -S
-I
> 127.0.0.1 -u http://your.host.com/health.cgi -e 200
> 
> *NOTE* you can only _copy_ the plugin to the remote host IFF
it's the
> same arch/os/version and has all the required libraries (ldd
> check_http).
> 
>  
> --
> Marc
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & 
> EXPO September
> 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * 
> Testing & QA
> Security * Process Improvement & Measurement * 
> http://www.sqe.com/bsce5sf
> _______________________________________________
> 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
>