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?
On 7 November 2017 at 21:27, Jeremy Laidman <jlaidman at rebel-it.com.au> wrote:
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
On 8 November 2017 at 04:16, Richard Jones <rich at corporationpop.co.uk> wrote:
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
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon