check_by_ssh and banner

Karl DeBisschop karl at debisschop.net
Sun Feb 22 21:06:26 CET 2004


On Sun, 2004-02-22 at 00:47, Jason Martin wrote:

> On Fri, 20 Feb 2004, Karl DeBisschop wrote:
> 
> > On Fri, 2004-02-20 at 19:14, Jason Martin wrote:
> >
> > > On Fri, 20 Feb 2004 Andrew_Hoying at blm.gov wrote:
> > > 
> > > > I'm trying to set up check_by_ssh, but with a banner turned on it always
> > > > returns the top line of the banner instead of the command. Is there any way
> > > > to avoid this?
> > > 
> > > I believe changing the plugin to use the -q flag will do that. It'd 
> > > require a very simple patch to the source.
> >
> > To be sure that I'm targetting the right issue, the banner is in the as
> > specified in the sshd_config Banner directive, right? As far as I can
> > see, the '-q' option will not suppress that banner. Has anyone done
> > actual testing to show otherwise? Can you share ssh/sshd version info if
> > so? (I tested on FC1 openssh-3.6.1p2-19).
> > 
> > It wouldn't be too hard to allow you to specify some number n of lines
> > to skip. Ii would be a little bit of a hack because the local admin
> > could change the text of the message and throw you off again. But I
> > cannot think of any better approaches.
>
> If -q doesn't work, you could also just generically utilize the last line
> of output;  that should have the banner in it.

Some plugins can return extra lines for human consumption. This has
alway been OK, because the nagios interface has always said it will
alway ignore everything after the first line. If we took the last line
in this case, we'd be assured to miss the intended output.

Further, my testing has indicated that the banner is printed on STDERR,
not STDOUT. So the patch I have committed to CVS ignores a user
specified number of lines at the start of STDERR. 

It would be nice to have a general solution, but we cannot look only at
the last line of STDERR - of there are no transport errors, the last
line of STDERR is part of the banner but would not actually indicate any
error condition. Conversely, if there are transport errors, the last
lines of the error report may be among the least informative, yet we
would still want to make sure we set a WARNING if there is unexpected
output on STDERR.

Maybe there's a better solution, but I'm afraid I don't see it yet.

-Karl



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
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





More information about the Users mailing list