I'm trying to monitor a VHost on the local Apache instance via Monit. The same domain accepts both http and https traffic, so I wanted to monitor both.
Also, the IP that the domain resolves to goes to a server that load balances the traffic between the current Apache instance and another server running Apache. I need Monit to monitor the local instance, and I was hoping to avoid adding any records in the /etc/hosts file, so I was thinking that Monits config setting with http headers [] would suffice, and I think it is (Just monitoring localhost, but setting the headers Host to the vhost domain).
Anyways, the main problem I seem to be running into, is even though I configure Monit to monitor the host via both http and https protocols, it monitors both hosts via just http, however the port is set to 443 for the one I need using https protocol.
The Monit config file for Apache is:
check process httpd with pidfile /var/run/httpd/httpd.pid
start program = "/bin/systemctl restart httpd.service" with timeout 60 seconds
stop program = "/bin/systemctl stop httpd.service"
check host localhost with address localhost
if failed
port 80
protocol http
with http headers [Host: www.domain.com, Cache-Control: no-cache]
and request / with content = "www.domain.com"
then restart
if failed
port 443
protocol https
with http headers [Host: www.domain.com, Cache-Control: no-cache]
and request / with content = "www.domain.com"
then restart
if 5 restarts within 5 cycles
then timeout
And here's the Monit status for that check:
[root#server enabled-monitors]# monit status localhost
The Monit daemon 5.14 uptime: 14m
Remote Host 'localhost'
status Connection failed
monitoring status Monitored
port response time FAILED to [localhost]:443/ type TCPSSL/IP protocol HTTP
port response time 0.001s to [localhost]:80/ type TCP/IP protocol HTTP
data collected Tue, 26 Apr 2016 10:44:32
So it's fairly obvious to me that the https is failing because its still trying to use port HTTP, even though I have protocol https in the configuration.
Any input would be much appreciated. I have a feeling this may be a bug, and ill create an issue in the Monit Github repo, but I wan't to make sure it's not something silly that I overlooked.
Thank you!
Late reply here, but I thought I would still post for readers who stumbled upon the same issue.
The problem seems to be not with Monit using port HTTP despite check configured for HTTPS. It always reports HTTP protocol in status (a display bug).
The real issue is likely with Monit not supporting SNI for SSL, so it ignores the with http headers [Host: www.domain.com ... in your https check. Thus the check fails because Monit is actually testing https://localhost.
I've filed bug with Monit developers here.
Related
Someone expert in Apache God level raised to infinity: please help:
I have a Tomcat application server, and to access it I have an Apache as a proxy (mod_proxy, ProxyPass), with SSL operating under port 443.
The issue is that I have an endpoint (Tomcat) that takes about 3 minutes to respond (that is, I don't need to be asked why it takes so long or if you can change that or anything similar, please). The issue is that after 2 minutes the proxy invokes the Tomcat endpoint again, aborting the previous request). I have reviewed timeout settings and everything is fine.
The most curious thing is that it only happens if the HTTPS operates under port 443, if I change it to another port, for example, 70, it works without any problem, that is, it expects the endpoint to end and respond, but if I leave it at 443 The request aborts me.
Does anyone have any idea what it could be?
We have Nginx running and multiple (around 80) server blocks/websites configured with both HTTPS and HTTP. Now adding another server blocks with website name e.g. xyz.com, then only HTTPS websites stop working. On checking the access.log, I found below logs
[23/Apr/2019:15:06:02 +0530] "\x16\x03\x01\x02\x00\x01\x00\x01\xFC\x03\x039\xAD$\xB4\xBB\x94\x98\xB8Q9\x84\xE4C\xB7\x98Z8\x9E#\x8E\xF8\xD79Jl\xA3\xAEY\xB9\xDA\x1A> \x04\xD7\x1B\xE7\x1Ch\xC3`\x81?g}\xE1y\x8D\x8E\x07\xDA;\x0F\x9D\x0B\xFF\xA2p\x0F\xB5&\xDFa\xF0\xF9\x00\x22ZZ\x13\x01\x13\x02\x13\x03\xC0+\xC0/\xC0,\xC00\xCC\xA9\xCC\xA8\xC0\x13\xC0\x14\x00\x9C\x00\x9D\x00/\x005\x00" 400 182 "-" "-"
This strange http request is getting printed for HTTPS websites hit.
What can be the possible reason for this? Is there any limit on number of server blocks files in /sites-available or /sites-enabled?
Thanks!
... "\x16\x03\x01...\x03\x03...
...This strange http request...
This is an attempt to do HTTPS on a port where you have configured HTTP. What you see is the byte sequence of a TLS 1.2 ClientHello, i.e. the start of a TLS handshake.
Now adding another server blocks with website name e.g. xyz.com, then only HTTPS websites stop working.
Likely there happened a misconfiguration while adding the new domain which caused port 443 to be plain HTTP and no longer HTTPS. Any attempt to speak HTTPS to this port (i.e. anything https://example.com since this uses 443 by default) will cause the strange entries in the access log file. Please look at the error log for hints what might have gone wrong with your configuration.
We have a server running Apache providing services via a simple API. We now stumbled upon the problem that we cannot access the API using a third-party library, altough the resulting HTTP request are ALMOST the same. The only difference - as far as we can tell from Wireshark - is the presence or absence of the explicit information about port 80. For example:
curl -d "..." http://www.example.com/foo/bar/
curl -d "..." http://www.example.com:80/foo/bar/
Both work, and Wireshark shows Host: www.example.com, i.e., without the port 80. As far as I understand cURL as well as browser or most other clients remove port 80. So far, all fine.
Now, a third-party library to make requests requires to set a port, and we need to set it to 80. If the library makes a request, Wiresharks now shows Host: www.example.com:80 - note the additional port information. This request fails, and as far as we can see in Wiresharks, this failing request only differs with respect to the host field.
Can this be a configuration issue of Apache? We currently have no direct access to the server to check the conf files. Or are we missing something completely different here.
From rfc 2616:
Host = "Host" ":" host [ ":" port ] ; Section 3.2.2
So "Host: www.example.com:80" is perfectly legitimate. But I have never seen port 80 (or 443 in the case of HTTPS) in the host field of a HTTP request. It is obviously required where the request is routed via a proxy to a non-standard port.
This would give me some concerns as to the quality of the "third-party library". My first of port of call in resolving this would be to speak to the providers of the component - they have presumably come across the problem before.
You did not mention what access you have to the library - did you check that this is not a configurable option? Do you have access to the source code, and the permission to modify it? (if not, that would imply it is commercial, paid-for software - which should give you the right to some support).
I don't know what the solution is, but some obvious things to try would be:
configure the URL at the default vhost for webserver rather than explicitly for www.example.com
or use mod_headers to rewrite the host field
or put a forward proxy in front of the webserver e.g. squid and add a url rewriter (if squid does not automatically strip the port from the host field)
Apache performs string matching with the Host field. So when the :80 is attached, the string matching will fail and Apache will consider it a URL it does not handle and reject it. That is why curl stripped it.
You can read more about the ServerName field here, which is the setting in which Apache matches against Host.
Update
So the :80 has no effect and the string matching still works.
On my production server, I did not change Apache's configuration. I wrote some quick PHP to send out the GET request on a socket, and Apache still responded correctly with the :80 attached to the Host: field.
I also checked on the server itself and see the request come in with the errant :80 attached to it and Apache answers with the status of 200 and presents the HTML.
There is something else wrong with the third party software's request.
we have apache in front of tomcat. it happens that the tomcat crashes and the apache still serve the webpage with a 503 page.
there's a way, via HAProxy to check both ports: 80 and 8080 and then bring the node up?
I added the http-check expect rstatus (2|3)[0-9][0-9] and the http-check expect ! rstatus ^5 but none of the 2 detected that tomcat was unreachable while the apache was providing the service.
thank you a lot
Nick
If your health check is configured correctly, you don't have to test both ports -- just configure the health check to send a request to apache that will be served by tomcat, using option httpchk. A 503 response will cause cause that server to be declared unhealthy.
the problem was the / at the end that did a redirect. once modified, works correctly with the expect 200.
I've got a web app running on localhost:3000. I also have an apache server. I would like to reverse proxy the apache server so that requests to /mywebapp get forwarded to the server running on localhost:3000.
I currently have the following config at the bottom of my httpd.conf file, but I'm getting a server error when I try to access it:
ProxyPass /mywebapp http://localhost:3000
ProxyPassReverse /mywebapp http://localhost:3000
Edit - further details:
I'm running a jetty server with java -jar myapp.jar. I'd like to forward requests to an apache server listening on :80 to the jetty server.
I've got mod_proxy_http.so and mod_proxy.so enabled.
I can tell the server is running on localhost - it responds to curl with the appropriate http response. So I'm pretty sure the issue is with my apache setup, but I can't think what the problem would be.
Apache conf file in conf.d for reference: http://pastebin.com/vhXwjbQe
And I've got this in my httpd.conf:
Include conf.d/*.conf
It's hard to give a generic answer because every situation is different so here are some debugging questions to ask yourself:
if the protocol and port correct on the internal service, http and 3000.
Is the service actually listening for connections from localhost? is it running in a docker container etc that would require it to be listening on a different interface? You can check for this by looking at the output from mywebapp's logs and see if the request are making it through the proxy.
Do the paths on the internal service include the prefix that is being passed to Apache or does apache need to strip these off. if for instance mywebapp expects the path "/foo/bar" and apache's reverse proxy is sending it with the context path included "/mywebapp/foo/bar" then it will not match any path in mywebapp.