Chris,
Problem solved.
On Thu, Oct 27, 2016 at 12:32 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
> -----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.
>
> Yes to the literal context.xml. I'm assuming the applications get deployed
to the proper context because of the appBase attribute in the host
definition.
<Host name="www.example.com" appBase="exampleapps"
unpackWARs="true" autoDeploy="true" >
<Alias>example.com</Alias>
<Valve className="org.apache.catalina.valves.AccessLogValve"
directory="logs"
prefix="example_access_log." suffix=".txt"
pattern="%h %l %u %t "%r" %s %b" />
<Valve className="org.apache.catalina.valves.RemoteIpValve"
remoteIpHeader="x-forwarded-for"
trustedProxies="172.99.112.138"
httpServerPort="80"
httpsServerPort="443"
/>
</Host>
> > 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.
>
>
There is an instance of manager in CATALINA_HOME/exampledotcomapps
that I use to deploy those applications.
> 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.
>
>
Thank you for this.
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 one of the key changes that solved the https access issue.
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:
>
Done.
>
> scheme="https"
> secure="true"
>
>
Done.
> 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.
>
Done.
>
> > 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?
>
>
This was at the core of the problem. The proxy was never reaching
the Tomcat connector. See the ServerAlias change below.
> 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?
>
>
If I don't proxy root, a call to www.example.com will then truly go
to the document at Apache's document root. The behavior I want
is for root (www.example.com) to go to Tomcat that does a redirect (a true
redirect :D )
to www.example.com/mycontext.
The server is being used for other uses besides the applications served by
Tomcat. https://anotherexample.com/repos/ ...
> 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>
>
>
The key change was simply adding 'example.com' to the ServerAlias directive.
ServerAlias example.com *.example.com
> 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.
>
"Okay, that probably won't work (unless it will!)." :) The port 80 vhost
was already working. I reversed the order anyway. Seems to work both
ways.
>
> > <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?
>
Victim of copy and paste programming.
>
> > 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.
>
>
Done. Thanks.
> 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.
>
Many, many thanks for your detailed comments. Mission accomplished.
Best,
Ted S.
>
> - -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
>
>
