Discussion:
[Xymon] Http Status Column and Https
Richard Jones
2017-11-07 17:16:18 UTC
Permalink
Hi all,

Have finally got around to upgrading our Xymon installation, mostly all
good (still some plugins and extensions to add in), however I'm seeing a
strange issue where the http test is returning a HTTP/1.1 400 Bad Request
for all sites using https. This used to work in our previous (admittedly
VERY out-of date) instance. Any ideas?

Hosts.cfg looks something like this for the affected rows:

1.2.3.4 someurl.com # https://someurl.com COMMENT:somecomment

While I'm at it, I can't recall how to get the ssl certificate test to work
and show the expiry dates, is this related?

Cheers, Rich
Jeremy Laidman
2017-11-07 21:27:21 UTC
Permalink
Rich

All of the SSL checks are enabled by default, so yes, probably related.
However check the command-line parameters for xymonnet (in tasks.cfg) to
ensure you don't have "--no-ssl" or something like that. I suspect the
"400" response code indicates a problem that is also preventing Xymon from
processing the certificate.

Check the web servers' logs to see if they are reporting a fault from the
Xymon probe, which might give clues to the cause of the problem.

Can you provide the exact message that Xymon shows? It may indicate which
part of the code is reporting the error, and hence the problem that's
triggering it. And what version of Xymon did you upgrade to?

It might be worth running xymonnet with the "--debug" option, to see if it
shows more detail in the xymonnet.log file. You can do some reasonably
painless diagnostics by running xymonnet from the command-line, like so:

echo "1.2.3.4 someurl.com # https://someurl.com COMMENT:somecomment" | (
HOSTSCFG=/dev/stdin /usr/lib/xymon/server/bin/xymonnet --debug --no-update
--noping --dns=ip )

This will show you everything xymonnet is doing, but it will only test as
per the details in the "echo" command, and it will report its result to you
rather than updating the status in Xymon.

Note that, even though --dns=ip is set here, xymonnet still performs a DNS
lookup against the hostname part of the URL to determine where to connect.
The debug output will show this. You can force it to connect to a different
IP address by using a URL such as https://someurl.com=1.2.3.99.

J
Post by Richard Jones
Hi all,
Have finally got around to upgrading our Xymon installation, mostly all
good (still some plugins and extensions to add in), however I'm seeing a
strange issue where the http test is returning a HTTP/1.1 400 Bad Request
for all sites using https. This used to work in our previous (admittedly
VERY out-of date) instance. Any ideas?
1.2.3.4 someurl.com # https://someurl.com COMMENT:somecomment
While I'm at it, I can't recall how to get the ssl certificate test to
work and show the expiry dates, is this related?
Cheers, Rich
_______________________________________________
Xymon mailing list
http://lists.xymon.com/mailman/listinfo/xymon
Richard Jones
2017-11-08 10:27:03 UTC
Permalink
Okay so using a site I know was returning everything correctly in the
previous installation, the http task reports the following:

red https://something.co.uk/ - Bad Request
HTTP/1.1 400 Bad Request
Server: cloudflare-nginx
Date: Wed, 08 Nov 2017 10:01:34 GMT
Content-Type: text/html
Content-Length: 275
Connection: close
CF-RAY: -
Seconds: 0.002278000

Looking at the access logs I can see Xymon hitting the server(s), that
looks somethign like this

something.co.uk:443 1.2.3.4 - - [08/Nov/2017:06:40:05 +0000] "GET /
HTTP/1.0" 400 0 "-" "-"

If I perform a curl to the URL https://something.co.uk I get back what I'm
expecting, if I perform the curl as something.co.uk:443 I receive the 400
error with the message... The plain HTTP request was sent to HTTPS port.
This is expected I believe, note that the affected site are all set up to
redirect from 80 to 443 and there are no issues with the sites that I have
noticed.

Running xymonnet in the console doesn't really return much...

echo 5.4.3.2 something.co.uk # https://something.co.uk |
(HOSTSCFG=/dev/stdin /usr/local/xymon/server/bin/xymonnet --debug
--no-update --noping --dns=ip )

Returns:

5.4.3.2 something.co.uk

Any ideas?
Post by Jeremy Laidman
Rich
All of the SSL checks are enabled by default, so yes, probably related.
However check the command-line parameters for xymonnet (in tasks.cfg) to
ensure you don't have "--no-ssl" or something like that. I suspect the
"400" response code indicates a problem that is also preventing Xymon from
processing the certificate.
Check the web servers' logs to see if they are reporting a fault from the
Xymon probe, which might give clues to the cause of the problem.
Can you provide the exact message that Xymon shows? It may indicate which
part of the code is reporting the error, and hence the problem that's
triggering it. And what version of Xymon did you upgrade to?
It might be worth running xymonnet with the "--debug" option, to see if it
shows more detail in the xymonnet.log file. You can do some reasonably
echo "1.2.3.4 someurl.com # https://someurl.com COMMENT:somecomment" | (
HOSTSCFG=/dev/stdin /usr/lib/xymon/server/bin/xymonnet --debug
--no-update --noping --dns=ip )
This will show you everything xymonnet is doing, but it will only test as
per the details in the "echo" command, and it will report its result to you
rather than updating the status in Xymon.
Note that, even though --dns=ip is set here, xymonnet still performs a DNS
lookup against the hostname part of the URL to determine where to connect.
The debug output will show this. You can force it to connect to a different
IP address by using a URL such as https://someurl.com=1.2.3.99.
J
Post by Richard Jones
Hi all,
Have finally got around to upgrading our Xymon installation, mostly all
good (still some plugins and extensions to add in), however I'm seeing a
strange issue where the http test is returning a HTTP/1.1 400 Bad Request
for all sites using https. This used to work in our previous (admittedly
VERY out-of date) instance. Any ideas?
1.2.3.4 someurl.com # https://someurl.com COMMENT:somecomment
While I'm at it, I can't recall how to get the ssl certificate test to
work and show the expiry dates, is this related?
Cheers, Rich
_______________________________________________
Xymon mailing list
http://lists.xymon.com/mailman/listinfo/xymon
Richard Jones
2017-11-08 13:11:59 UTC
Permalink
Im wondering if this is to do with the actual server that is running Xymon.
Performed a clean install of Xymon to 100% ensure OpenSSL was used:

Checking for OpenSSL ...
Compiling with SSL library works OK
Linking with SSL library works OK
Checking if your SSL library has SSLv2 enabled
Makefile.test-ssl2:7: recipe for target 'test-link' failed
SSLv2 support disabled (dont worry, all systems should use SSLv1 or TLS)
Checking if your SSL library has SSLv3 enabled
Makefile.test-ssl3:7: recipe for target 'test-link' failed
SSLv3 support disabled (dont worry, all systems should use SSLv1 or TLS)

Xymon can use the OpenSSL library to test SSL-enabled services like
https-encrypted websites, POP3S, IMAPS, NNTPS and TELNETS. If you have the
OpenSSL library installed, I recommend that you enable this.

Do you want to be able to test SSL-enabled services (y) ?
y

However I'm still seeing the issue. Getting a bit grumbly with it now!

*Rich Jones* | Systems Developer
Corporation Pop
21-23 Shudehill
Manchester M4 2AF
0161 838 0808
www.corporationpop.co.uk
This email message (and any attached file) is intended only for the use of
the individual or entity to whom the sender intended it to be addressed and
may contain information that constitutes a trade secret, or that is
privileged, confidential or subject to copyright. No part of it may be
circulated, quoted, or reproduced without prior written approval from
Corporation Pop Ltd. The contents of this document are strictly
confidential and owned by Corporation Pop Ltd. Copyright © Corporation Pop
Ltd. All rights reserved. Corporation Pop is a limited company registered
in England + Wales. Company number 4869229. VAT number 533 8932 26.
Post by Richard Jones
Okay so using a site I know was returning everything correctly in the
red https://something.co.uk/ - Bad Request
HTTP/1.1 400 Bad Request
Server: cloudflare-nginx
Date: Wed, 08 Nov 2017 10:01:34 GMT
Content-Type: text/html
Content-Length: 275
Connection: close
CF-RAY: -
Seconds: 0.002278000
Looking at the access logs I can see Xymon hitting the server(s), that
looks somethign like this
something.co.uk:443 1.2.3.4 - - [08/Nov/2017:06:40:05 +0000] "GET /
HTTP/1.0" 400 0 "-" "-"
If I perform a curl to the URL https://something.co.uk I get back what
I'm expecting, if I perform the curl as something.co.uk:443 I receive the
400 error with the message... The plain HTTP request was sent to HTTPS
port. This is expected I believe, note that the affected site are all set
up to redirect from 80 to 443 and there are no issues with the sites that I
have noticed.
Running xymonnet in the console doesn't really return much...
echo 5.4.3.2 something.co.uk # https://something.co.uk |
(HOSTSCFG=/dev/stdin /usr/local/xymon/server/bin/xymonnet --debug
--no-update --noping --dns=ip )
5.4.3.2 something.co.uk
Any ideas?
Post by Jeremy Laidman
Rich
All of the SSL checks are enabled by default, so yes, probably related.
However check the command-line parameters for xymonnet (in tasks.cfg) to
ensure you don't have "--no-ssl" or something like that. I suspect the
"400" response code indicates a problem that is also preventing Xymon from
processing the certificate.
Check the web servers' logs to see if they are reporting a fault from the
Xymon probe, which might give clues to the cause of the problem.
Can you provide the exact message that Xymon shows? It may indicate which
part of the code is reporting the error, and hence the problem that's
triggering it. And what version of Xymon did you upgrade to?
It might be worth running xymonnet with the "--debug" option, to see if
it shows more detail in the xymonnet.log file. You can do some reasonably
echo "1.2.3.4 someurl.com # https://someurl.com COMMENT:somecomment" | (
HOSTSCFG=/dev/stdin /usr/lib/xymon/server/bin/xymonnet --debug
--no-update --noping --dns=ip )
This will show you everything xymonnet is doing, but it will only test as
per the details in the "echo" command, and it will report its result to you
rather than updating the status in Xymon.
Note that, even though --dns=ip is set here, xymonnet still performs a
DNS lookup against the hostname part of the URL to determine where to
connect. The debug output will show this. You can force it to connect to a
different IP address by using a URL such as https://someurl.com=1.2.3.99.
J
Post by Richard Jones
Hi all,
Have finally got around to upgrading our Xymon installation, mostly all
good (still some plugins and extensions to add in), however I'm seeing a
strange issue where the http test is returning a HTTP/1.1 400 Bad Request
for all sites using https. This used to work in our previous (admittedly
VERY out-of date) instance. Any ideas?
1.2.3.4 someurl.com # https://someurl.com COMMENT:somecomment
While I'm at it, I can't recall how to get the ssl certificate test to
work and show the expiry dates, is this related?
Cheers, Rich
_______________________________________________
Xymon mailing list
http://lists.xymon.com/mailman/listinfo/xymon
Richard Jones
2017-11-08 14:13:31 UTC
Permalink
Okay, resolved the issue...
Not too sure how but still. I noticed that the xymonnet column was not
showing the OpenSSL version. Not sure why, anyway... *another* clean
install and it's working.
I made sure to do a make clean which may or may not have had an effect.

Anyway, all done...
Jeremy Laidman
2017-11-08 17:41:59 UTC
Permalink
Glad to hear it!

I suspect running xymonnet in the console showed nothing much because you
didn't use quotes for the echo command, so everything from the hash to the
end of the line was treated as a comment.
Post by Richard Jones
Okay, resolved the issue...
Not too sure how but still. I noticed that the xymonnet column was not
showing the OpenSSL version. Not sure why, anyway... *another* clean
install and it's working.
I made sure to do a make clean which may or may not have had an effect.
Anyway, all done...
Continue reading on narkive:
Loading...