[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Unable to do connection Testing via https
From: |
Marcus Mülbüsch |
Subject: |
Re: Unable to do connection Testing via https |
Date: |
Fri, 10 Oct 2014 14:52:32 +0200 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 |
Am 02.10.2014 um 18:51 schrieb Jan-Henrik Haukeland:
On 02 Oct 2014, at 18:30, Jan-Henrik Haukeland <address@hidden>
wrote:
Your base64 encoded string seems wrong if credentials are what you
say they are
My bad, my method included a new line :-/ Your Authorization header
is fine and should work. The 401 status reply you get from the server
indicate that the credentials are not accepted by the server or at
that path. The 407 status reported by your HTTP server indicate that
you have or require a Proxy server authentication!? Maybe try the
test at a different path which goes directly to the HTTP server?
Thanks to the help of another list member who contacted me off list I
tried it with a different syntax (had to shorten the password to simply
"open" because the space created problems):
if failed (url
https://Aladdin:address@hidden/LOG0/FAULT/mod_cmd.xml?cmd=something
with content == 'alarms') then alert
This works and results in:
'uri.to.check' succeeded connecting to
INET[1.2.3.4:443/LOG0/FAULT/mod_cmd.xml?cmd=something] via TCPSSL
HTTP: Regular expression matches
However, the syntax from the monit manual:
if failed host 1.2.3.4 port 443 type tcpssl protocol http http
headers [Authorization: Basic QWxhZGRpbjpvcGVu] and request
/LOG0/FAULT/mod_cmd.xml?cmd=something with content == 'alarms' then
alert
results in:
'uri.to.check' failed protocol test [HTTP] at
INET[1.2.3.4:443/LOG0/FAULT/mod_cmd.xml?cmd=something] via TCPSSL --
HTTP error: Server returned status 401
So:
I can do my connection testing with the "old" syntax, which solves
my immediate problem.
But: how long will that syntax be supported by monit?
And since I get these 401-errors (no 407 errors, there is no proxy
inbetween), either my base64 encoding is wrong, or I did some other
simple error in my configuration, or both of the syntaxes do not do the
same...
Any help on that point is still appreciated.
Marcus