Re: [Nagios-users] check_http and other response codes
On Thu, Oct 13, 2011 at 09:39:43AM +0200, Jörg Linge wrote: > http://nagiosplugins.org/man/check_http > > Option -e > > -e, --expect=STRING > Comma-delimited list of strings, at least one of them is expected in > the first (status) line of the server response (default: HTTP/1.) > If specified skips all other status line logic (ex: 3xx, 4xx, 5xx > processing) Oh, thanks! I saw that option, but misunderstood it. Now I've got it working. For TRACE, I think the "negate" implementation is actually better. CUPS IPP returns no response code at all to a TRACE request, which is good from my perspective. - Morty -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Nagios-users mailing list Nagios-users@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
Re: [Nagios-users] check_http and other response codes
Am 13.10.2011 um 09:18 schrieb Morty:
> On Wed, Oct 12, 2011 at 11:16:17PM -0500, Frank Bulk wrote:
>> Isn't there some regex matching?
>
> There is. But it didn't help me in either case. check_http
> apparently does an implicit test to make sure it gets a valid response
> code such as 200. And the regex checking is in content, not headers
> or response code. So check_http -H $host -S -r 401 still returns a
> warning with a server that requires auth, and check_http -H $host -S
> -j TRACE -r 405 still returns a warning on a server with TRACE
> disabled.
>
> While reading a different thread on this mailing list, I found Mark
> Thomas's mention of "negate". That actually did workaround my HTTP
> TRACE problem -- TRACE will cause check_http to return a warning when
> it's disabled and ok when it's enabled, so the following command
> definition will test for HTTP TRACE:
>
> define command{
>command_namecheck_http_trace
>command_line$USER1$/negate -sw OK -o CRITICAL -c OK --
> $USER1$/check_http -j TRACE -f sticky -H $HOSTADDRESS$ -p $ARG1$ $ARG2$
>}
>
> But IMHO, that's something of a hack. And it doesn't deal with the 401 issue.
http://nagiosplugins.org/man/check_http
Option -e
-e, --expect=STRING
Comma-delimited list of strings, at least one of them is expected in
the first (status) line of the server response (default: HTTP/1.)
If specified skips all other status line logic (ex: 3xx, 4xx, 5xx
processing)
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Nagios-users mailing list
Nagios-users@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
Re: [Nagios-users] check_http and other response codes
On Wed, Oct 12, 2011 at 11:16:17PM -0500, Frank Bulk wrote:
> Isn't there some regex matching?
There is. But it didn't help me in either case. check_http
apparently does an implicit test to make sure it gets a valid response
code such as 200. And the regex checking is in content, not headers
or response code. So check_http -H $host -S -r 401 still returns a
warning with a server that requires auth, and check_http -H $host -S
-j TRACE -r 405 still returns a warning on a server with TRACE
disabled.
While reading a different thread on this mailing list, I found Mark
Thomas's mention of "negate". That actually did workaround my HTTP
TRACE problem -- TRACE will cause check_http to return a warning when
it's disabled and ok when it's enabled, so the following command
definition will test for HTTP TRACE:
define command{
command_namecheck_http_trace
command_line$USER1$/negate -sw OK -o CRITICAL -c OK --
$USER1$/check_http -j TRACE -f sticky -H $HOSTADDRESS$ -p $ARG1$ $ARG2$
}
But IMHO, that's something of a hack. And it doesn't deal with the 401 issue.
- Morty
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Nagios-users mailing list
Nagios-users@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
Re: [Nagios-users] check_http and other response codes
Isn't there some regex matching? Frank -Original Message- From: Morty [mailto:morty+nag...@frakir.org] Sent: Wednesday, October 12, 2011 9:46 PM To: nagios-users@lists.sourceforge.net Subject: [Nagios-users] check_http and other response codes On some of our apache servers, the normal response code is 401 (authentication required) rather than 200. I'd also like to use nagios to make sure the apache TRACE method stays disabled, with a response code of 405. Problem: check_http returns a warning if the response code is anything but 200. In the first case, both 200 and 401 are acceptable; in the latter case, I want 405 rather than 200. Is there a way to require or allow a different response code? I'm using check_http 1.4.15, as packaged with Debian 5.x. I googled, but didn't find clue. :( Thanks! - Morty -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Nagios-users mailing list Nagios-users@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 -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Nagios-users mailing list Nagios-users@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
[Nagios-users] check_http and other response codes
On some of our apache servers, the normal response code is 401 (authentication required) rather than 200. I'd also like to use nagios to make sure the apache TRACE method stays disabled, with a response code of 405. Problem: check_http returns a warning if the response code is anything but 200. In the first case, both 200 and 401 are acceptable; in the latter case, I want 405 rather than 200. Is there a way to require or allow a different response code? I'm using check_http 1.4.15, as packaged with Debian 5.x. I googled, but didn't find clue. :( Thanks! - Morty -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Nagios-users mailing list Nagios-users@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
