-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Ted,
(I apologize, I didn't see your message from he 5th until just now. I would have replied earlier.) On 10/27/16 12:21 PM, Ted Spradley wrote: On Wed, Oct 5, 2016 at 7:52 PM, Christopher Schultz wrote: >> Explicit descriptor XML file placed in >> CATALINA_HOME/conf/[service]/[ host]/[app].xml? > > Yes - with a caveat. The path is CATALINA_HOME/conf/[service]/[ > host]/context.xml Do you mean a /literal/ context.xml? That will deploy your application to /context. > The only contents being one empty <Context> element with the > docBase attribute defined > > <Context docBase="CATALINA_HOME/exampledotcomapps"> > > </Context> That's just fine. > The CATALINA_HOME/exampledotcomapps directory contains three > applications deployed using the manager application. 1. > "http:example.com/mycontext" 2. "http:example.com/anotherContext" > 3. "http:example.com/stillAnontherContext" Okay, so you have a <Host> with appBase set to CATAINA_HOME/exampledotcomapps. Note that you aren't using the manager, here. The manager is a web application that lets you upload and manage running applications via an HTTP interface. Putting files on the disk under CATALINA_HOME/conf will generally just go ahead and deploy them under a default configuration -- that is, one where autoDeploy is set to true. > All three applications are reached as expected through the proxy on > port 80. > > The path CATALINA_HOME/exampledotcomapps matches the appBase > attribute in the <Host> element for example.com in > CATALINA_HOME/conf/server.xml Gotcha. > I've since defined a separate Connector to listen for the redirect > from Apache on port 8082 because I thought there was a > possibility the proxyPort directive would need to be specifically > port 443 instead of port 80. Several things: mod_proxy isn't redirecting anything... it's proxying the connection. It sounds pedantic but it's important to use the right terminology here since both proxying and redirects are valid ways to change where the data is coming from. A redirect would involve the client making a follow-up HTTP request. mod_proxy is instead handling the client's connection on behalf of the client through to Tomcat. The "redirect port" is the port that will be used to redirect the user if a security-constraint cannot be fulfilled using the current connector. Most practically, it means that if the application says "I need TLS" and the connection isn't a TLS connection, then Tomcat will redirect the user to the same URL but with an https:// protocol and that port number you specify. It comes preconfigured as 8443 since that will generally get you back to Tomcat instead of some other service. For a real service, you probably want that set to "443". This is the port number that the CLIENT will end up using. Using port 80 for the redirectPort will basically never work. You should leave it as 443 if you want httpd to do the TLS termination (which it's pretty obvious you are in fact trying to do). > So now I have a Connector to receive the port 80 traffic and > another for the port 443 traffic. I've tried it with and without > the redirectPort attribute. Still no success. Okay. This is IMO the best configuration especially if you want to treat some applications as secure and others as insecure. (In my environment, everything is secure, so I use only a single Connector.) > The Connectors appear in this order in server.xml > > <Connector port="8081" protocol="HTTP/1.1" > connectionTimeout="20000" proxyName="www.example.com" > proxyPort="80" redirectPort="8443" xpoweredBy="false" > server="Apache TomEE" /> <Connector port="8082" > protocol="HTTP/1.1" connectionTimeout="20000" > proxyName="www.example.com" proxyPort="443" redirectPort="8443" > xpoweredBy="false" server="Apache TomEE" /> I think you want redirectPort="443" for both of those connectors. Assuming that you want port 8082 to be used for proxying HTTPS connections, you are going to want to set these attributes at well: scheme="https" secure="true" This will let your application know that the connection is secure (but it's up to you to make sure that it actually IS by not e.g. proxying a non-TLS connection to port 8082). There are ways to get this to work with a single connector and have the reverse proxy (that's httpd_+mod_proxy, here) tell Tomcat what kind of connection it is. But you have to configure a proxy listener and configure more stuff on the httpd end. That's one of the reasons I like mod_jk better since it automatically sends all that stuff to the back-end. Something you aren't getting unless you are using the RemoteIPValve[1] is the ability to tell anything about the client's connection (origin IP, protocol, etc.) as well as possibly the hostname they were requesting. I have much less experience with mod_proxy_http than I do with mod_proxy_ajp/mod_jk which "just handles it". I would recommend using the RemoteIPValve on the Tomcat end. > Note: It is curious to me that when I enter https://example.com/ > into a browser, Apache serves the page at /var/www/html/index.html > which is in the document root defined in > /etc/httpd/conf/httpd.conf with the directive DocumentRoot > "/var/www/html" Why is that curious? > My expectation is that the call to https://example.com/ would be > redirected with the pair ProxyPass / http://example.com:8082/ > ProxyPassReverse / https://example.com:8082/ in the virtual host > element for port 443. I'll bet that a file in the DocumentRoot takes precedence over the proxy configuration. Someone with a better understanding of the internals of httpd would have to comment on that. I *always* proxy a sub-path and never the root... otherwise, what's the point of having the reverse proxy in the first place? > To refresh, the virtual host definitions are currently: > > <VirtualHost *:80> ServerName www.example.com ServerAlias > *.example.com ProxyRequests off ProxyPreserveHost on ProxyPass > / http://example.com:8081/ ProxyPassReverse / > http://example.com:8081/ ProxyPass /mycontext > http://example.com:8081/mycontext ProxyPassReverse /mycontext > http://example.com:8081/mycontext ProxyPass /anotherContext > http://example.com:8081/anotherContext ProxyPassReverse > /anotherContext http://example.com:8081/anotherContext > </VirtualHost> Okay, that probably won't work (unless it will!). I believe that ProxyPass directives match in the order in which they are present in the file: first one wins. So after our first ProxyPass directive, the others are irrelevant. Since you have them all pointing to the same place, it probably doesn't matter in this case. But you should know that the /mycontext and /anothercontext mappings are always being ignored. If you wanted them to matter, you would have to reverse them: ProxyPass /mycontext http://example.com:8081/mycontext ProxyPassReverse /mycontext http://example.com:8081/mycontext ProxyPass /anotherContext http://example.com:8081/anotherContext ProxyPassReverse /anotherContext http://example.com:8081/anotherContext ProxyPass / http://example.com:8081/ ProxyPassReverse / http://example.com:8081/ That way, the longer context-names are matched (and proxied) first. > <VirtualHost *:443> ServerName www.example.com ServerAlias > *.example.com <Proxy *> Order deny,allow Allow from all </Proxy> That <Proxy> section looks worthless, since you don't have any other allow/deny directives. > ProxyRequests off This is the default. I'm not sure it's worth putting into your configuration. > ProxyPreserveHost on This is essential, if you are going to have Tomcat manage virtual hosts (which you are doing). > CustomLog "/etc/httpd/logs/examplessl.log" "%h %l %u %t \"%r\" %>s > %b" ErrorLog "/etc/httpd/logs/examplessl_error.log" SSLEngine on > SSLProxyEngine on SSLCertificateFile > /etc/pki/tls/certs/certfile.crt SSLCertificateKeyFile > /etc/pki/tls/private/example.key ProxyRequests off > ProxyPreserveHost on Again? > ProxyPass / http://example.com:8082/ ProxyPassReverse / > https://example.com:8082/ ProxyPass /mycontext > http://example.com:8082/mycontext ProxyPassReverse /mycontext > http://example.com:8082/mycontext ProxyPass /anotherContext > http://example.com:8082/anotherContext ProxyPassReverse > /anotherContext http://example.com:8082/anotherContext > </VirtualHost> Same ordering issue down here: reverse those or just proxy / and be done with it. > Any other thoughts as to what I may not be seeing here? I think > I've read the docs exhaustively. Your responses are much > appreciated. Enable the RemoteIPValve in your <Engine> in Tomcat. I think that will help tremendously. If it's not super-important to manage multiple virtual hosts on the Tomcat side, I'd simplify your configuration and remove the virtual host stuff from Tomcat. For example, if all your context names are unique across all virtual hosts (including / !!) then you can seriously simplify everything. - -chris [1] http://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#Proxies_Suppor t -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJYEjoQAAoJEBzwKT+lPKRYxqwP/AnA2WKORaokWX0cQOuBlZQB h2bzUqHvMm+sI9OwPJ19ISODl0vR9eHU/f/UurCgoUGsPpKkoAmcIr6ZaFT+DU+B GKTmMH9W9mBPnSenKQf4NkUNeR6HMr4FL74vNA6apTKbU+DFow4ba/YRMTGxtjea tCRPMOjUmIAH2mvTQe1S9q9PjyuKCY/FxMxBsMEf/geZ3ljEYUKLT+d0X3BU7vBt LJRYIF48OdQattgpacFRtob/CJLr+tM1+tjb3No8agPF+AZ8WQz0j3fi4E1yPnns 7TLNHBfGbKb3Rlt2pGiB6lCPRkpAo7x+LW0bLj0XSs70BnqUareU9qao9uUDV94R Da9G8f58dx8rRTLBF2hD6HaZR/4b+ir0diPOjgLdJI6WgJuvD59YGy6TlCyR5T5E q2SO+SUT5md4+X/4gq8OGSbTZKaoq00EOYpoTXT+qeAXQMJsNgYwaPyb2gnnNzBj wdn72EE3MIwMLseqhdNDQWLFHgaY4Gb2TXBFzls8O1pI/gGNPoPtXjqcnMWAs5Sk cdhakykHiLWk1BAowPGTCseNW+I6NO6rTCt/NP7PI0aaQYgfa2e8DYp4Olsdw5In wzWjl7frQnrNP5FBAx8RBbzZ1VvvTLO+xzE7A/qqQG5hEd8XdShzBrmpNfcp1Tb7 1XMjXU8KYo073+GciKxU =n4zM -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
