You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "James H. H. Lampert" <ja...@touchtonecorp.com> on 2020/04/06 19:53:10 UTC
Setting up Tomcat behind an existing Apache httpd server (on Amazon
Linux 2)
Here is the situation:
We have an existing Amazon EC2 instance, running Amazon Linux 2, with an
Apache httpd server already running our web sites (for argument's sake,
"foo.com," "bar.com," and "baz.com."), and already getting its certs
from Let's Encrypt, using "foo.com" as the CN, with "www.foo.com,"
"bar.com," "www.bar.com," "baz.com," and "www.baz.com" as SANs. And it
seems to be working quite nicely.
Now, we want to add a Tomcat server, which would then serve several
webapp contexts at "qux.baz.com," and maybe also "corge.baz.com,"
running behind the httpd server (which is something I've never done
before; I've always set up Tomcat directly facing the outside world, so
with this, I frankly haven't a clue what I'm doing).
First of all, which is currently considered the easier/better way to get
Tomcat running behind httpd, given the above scenario? "mod_proxy," or
"mod_jk?" Or is there something else I haven't heard of?
Second of all, I found this step-by-step procedure.
> https://preview.tinyurl.com/vwnutqj
Is it any good?
Third, am I correct in assuming that all we need to do in order for the
existing Let's Encrypt setup to cover the new "qux" and "corge"
subdomains is to add them to the SANs already listed?
Finally, are there any "gotchas" I need to be concerned with?
--
James H. H. Lampert
Touchtone Corporation
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Setting up Tomcat behind an existing Apache httpd server (on
Amazon Linux 2)
Posted by Mark Eggers <it...@yahoo.com.INVALID>.
Hi Jerry / James,
On 4/6/2020 1:59 PM, Jerry Malcolm wrote:
> Hi James,
>
> I've been using this precise setup for years, first on a dedicated
> hosted server and recently on EC2/Linux2. I use mod_jk.
>
> The first step is to make sure httpd recognizes all of the domain names
> and subdomains. That includes the vhost definitions of all of the
> domains and subdomains, either as separate virtual hosts or as host
> alias names. Then, as you described, you need to make sure the
> certificates include all of the domain and subdomain names. LetsEncrypt
> will 'expand' an existing cert if you just add another host name to the
> LetsEncrypt call.
>
> You are probably doing this already. But just for completeness.... you
> should support both http://foo.com (port 80) and https://foo.com. That
> way, users aren't required to enter https. I just add a 'redirect
> permanent' in the port 80 vhost def to route it to https://foo.com.
> Once you are 'in' with ssl into httpd at 443 the certificate work is
> done. No need to set up any certificates into tomcat unless you have a
> specific reason to use ssl/tls between httpd and tomcat (unlikely if you
> running both on the same EC2).
>
> The biggest area of concentration is setting up the url patterns that
> httpd will route to tomcat via mod_jk. These are defined in httpd.conf
> as global or in virtual host configuration sections You can explicitly
> list the url patterns to send to tomcat:
>
> JkMount /*.json worker1
> JkMount /*.jsp worker1
> JkMount /*/*.json worker1
> JkMount /*/FileUpload worker1
>
> or you can send 'all' (*) and define exceptions using JkUnMount
> (example; /css/*). The mod_jk log is a lifesaver when you are setting
> this up. Set the mod_jk log level to debug and see how mod_jk is
> deciding whether to pass a url to tomcat or pass it back to httpd for
> processing.
>
> Once you get to tomcat, you just have to define all of the same host
> domain and subdomains in tomcat's server.xml to ensure tomcat is going
> to accept the requests that mod_jk has decided to send to it.
>
> Let me know as you encounter issues. I'll be glad to assist.
>
> Jerry
>
> On 4/6/2020 2:53 PM, James H. H. Lampert wrote:
>> Here is the situation:
>>
>> We have an existing Amazon EC2 instance, running Amazon Linux 2, with
>> an Apache httpd server already running our web sites (for argument's
>> sake, "foo.com," "bar.com," and "baz.com."), and already getting its
>> certs from Let's Encrypt, using "foo.com" as the CN, with
>> "www.foo.com," "bar.com," "www.bar.com," "baz.com," and "www.baz.com"
>> as SANs. And it seems to be working quite nicely.
>>
>> Now, we want to add a Tomcat server, which would then serve several
>> webapp contexts at "qux.baz.com," and maybe also "corge.baz.com,"
>> running behind the httpd server (which is something I've never done
>> before; I've always set up Tomcat directly facing the outside world,
>> so with this, I frankly haven't a clue what I'm doing).
>>
>> First of all, which is currently considered the easier/better way to
>> get Tomcat running behind httpd, given the above scenario?
>> "mod_proxy," or "mod_jk?" Or is there something else I haven't heard of?
>>
>> Second of all, I found this step-by-step procedure.
>>
>>> https://preview.tinyurl.com/vwnutqj
>>
>> Is it any good?
>>
>> Third, am I correct in assuming that all we need to do in order for
>> the existing Let's Encrypt setup to cover the new "qux" and "corge"
>> subdomains is to add them to the SANs already listed?
>>
>> Finally, are there any "gotchas" I need to be concerned with?
>>
>> --
>> James H. H. Lampert
>> Touchtone Corporation
I also prefer mod_jk. It's a little bit trickier to set up. You have to
worry about timings, and getting them to agree between
workers.properties and server.xml. Fortunately, there's a very good
sample workers.properties file in the mod_jk source code.
My local setup is as follows:
#
# This file will configure three Tomcat workers
# The Tomcat workers are using differing ports and the same (localhost)
address
#
#
# adding all of the workers in a list at once
# not strictly necessary, since the use of the list is additive
#
worker.list=jk-status,jk-manager,titan
#
# status manager for read-only
# manager manager for read/write
#
worker.jk-status.type=status
worker.jk-status.read_only=true
worker.jk-manager.type=status
#
# template
#
# Notes on configuration
# type - ajp13 which is the protocol and the default
# socket_connect_timeout - in milliseconds (what happens when Tomcat
# is started later?
# socket_keepalive - send keep alive packets when connection is
# idle
# ping - how to do the keep alive (see
# documentation)
# ping_timeout - default in milliseconds
# minsize - minimum pool size - drops to zero after a
# while
# timeout - pool timeout should match AJP connector in
# Tomcat. Note time here is in seconds and
# must match the AJP connector in
# server.xml. Note, there is no timeout by
# default in server.xml
# reply_timeout - timeout for a reply. The default is no
# timeout. The value is in milliseconds. Make
# longer than the longest Tomcat will process
# a request, otherwise an error will be
# returned.
# recovery_options - a bitmapped flag for recovery when a
# request is successfully sent but no reply
# is received. 0 is the default, 3 says don't
# retry on another backend
worker.template.type=ajp13
worker.template.host=127.0.0.1
worker.template.socket_connect_timeout=5000
worker.template.socket_keepalive=true
worker.template.ping_mode=A
worker.template.ping_timeout=10000
worker.template.connection_pool_minsize=0
worker.template.connection_pool_timeout=600
worker.template.reply_timeout=300000
worker.template.recovery_options=3
#
# now to define the actual workers
#
worker.titan.reference=worker.template
worker.titan.port=8009
With the template set up above, it's easy to add multiple Tomcats
listening on different ports / different hosts, without having to edit a
long list of parameters by referring to the template.
The key points that you have to match in server.xml are the connection
pool timeout (seconds in the properties file, milliseconds in
server.xml) and the port.
Here's the connector configuration for Apache Tomcat 7.0.103 on my local
machine.
<Connector protocol="AJP/1.3"
URIEncoding="UTF-8"
connectionTimeout="600000"
secretRequired="false"
port="8009"
redirectPort="8443" />
Yes, I'm using secretRequired="false" since the port is only bound to
the local address, and I'm behind a NAT.
You might have to adjust max* settings if you bump into limits. See the
fine Tomcat documentation for particulars.
. . . just my two cents
/mde/
Re: Setting up Tomcat behind an existing Apache httpd server (on
Amazon Linux 2)
Posted by Jerry Malcolm <te...@malcolms.com>.
Hi James,
I've been using this precise setup for years, first on a dedicated
hosted server and recently on EC2/Linux2. I use mod_jk.
The first step is to make sure httpd recognizes all of the domain names
and subdomains. That includes the vhost definitions of all of the
domains and subdomains, either as separate virtual hosts or as host
alias names. Then, as you described, you need to make sure the
certificates include all of the domain and subdomain names. LetsEncrypt
will 'expand' an existing cert if you just add another host name to the
LetsEncrypt call.
You are probably doing this already. But just for completeness.... you
should support both http://foo.com (port 80) and https://foo.com. That
way, users aren't required to enter https. I just add a 'redirect
permanent' in the port 80 vhost def to route it to https://foo.com.
Once you are 'in' with ssl into httpd at 443 the certificate work is
done. No need to set up any certificates into tomcat unless you have a
specific reason to use ssl/tls between httpd and tomcat (unlikely if you
running both on the same EC2).
The biggest area of concentration is setting up the url patterns that
httpd will route to tomcat via mod_jk. These are defined in httpd.conf
as global or in virtual host configuration sections You can explicitly
list the url patterns to send to tomcat:
JkMount /*.json worker1
JkMount /*.jsp worker1
JkMount /*/*.json worker1
JkMount /*/FileUpload worker1
or you can send 'all' (*) and define exceptions using JkUnMount
(example; /css/*). The mod_jk log is a lifesaver when you are setting
this up. Set the mod_jk log level to debug and see how mod_jk is
deciding whether to pass a url to tomcat or pass it back to httpd for
processing.
Once you get to tomcat, you just have to define all of the same host
domain and subdomains in tomcat's server.xml to ensure tomcat is going
to accept the requests that mod_jk has decided to send to it.
Let me know as you encounter issues. I'll be glad to assist.
Jerry
On 4/6/2020 2:53 PM, James H. H. Lampert wrote:
> Here is the situation:
>
> We have an existing Amazon EC2 instance, running Amazon Linux 2, with
> an Apache httpd server already running our web sites (for argument's
> sake, "foo.com," "bar.com," and "baz.com."), and already getting its
> certs from Let's Encrypt, using "foo.com" as the CN, with
> "www.foo.com," "bar.com," "www.bar.com," "baz.com," and "www.baz.com"
> as SANs. And it seems to be working quite nicely.
>
> Now, we want to add a Tomcat server, which would then serve several
> webapp contexts at "qux.baz.com," and maybe also "corge.baz.com,"
> running behind the httpd server (which is something I've never done
> before; I've always set up Tomcat directly facing the outside world,
> so with this, I frankly haven't a clue what I'm doing).
>
> First of all, which is currently considered the easier/better way to
> get Tomcat running behind httpd, given the above scenario?
> "mod_proxy," or "mod_jk?" Or is there something else I haven't heard of?
>
> Second of all, I found this step-by-step procedure.
>
>> https://preview.tinyurl.com/vwnutqj
>
> Is it any good?
>
> Third, am I correct in assuming that all we need to do in order for
> the existing Let's Encrypt setup to cover the new "qux" and "corge"
> subdomains is to add them to the SANs already listed?
>
> Finally, are there any "gotchas" I need to be concerned with?
>
> --
> James H. H. Lampert
> Touchtone Corporation
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: {[OT] Re: Setting up Tomcat behind an existing Apache httpd
server (on Amazon Linux 2)
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
> I don't have enough reputation points to comment on your question on
> serverfault.
>
> Is your DocumentRoot (/var/www/html/test) underneath the default
> DocumentRoot (normally /var/www/html)?
I found the problem, and it wasn't a [profanity] server problem; it was
a [profanity] client problem!
This morning, I looked at the server access log, and found that I was
only showing up if I explicitly asked for the test page.
So then, I used a utility called "Postman" to do a GET on
"http://qux.baz.com", and THAT retrieved the test page just fine.
So then, I bit the [profanity] bullet, and cleared
every-[profanity]-thing out of both Firefox and Chrome: history,
cookies, persistent sign-ons, everything.
And suddenly, "http://qux.baz.com" started working just fine.
And I'm suddenly very fluent in "Army Creole," and when I'm no longer
swearing every other [profanity] word, ready to take the next step with
this thing.
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
{[OT] Re: Setting up Tomcat behind an existing Apache httpd server
(on Amazon Linux 2)
Posted by Mark Eggers <it...@yahoo.com.INVALID>.
On 4/6/2020 5:47 PM, James H. H. Lampert wrote:
> As it happens, I'm now struggling with an issue just trying to get a new
> virtual host up and running on the httpd server. I've put it on Server
> Fault, at: https://preview.tinyurl.com/rr3rxwa
>
> While it may not be necessary to solve this problem in order to get the
> httpd server to proxy the Tomcat server, this certainly *looks* like
> something that might pick a fight with what's being proxied to Tomcat.
>
> --
> JHHL
I don't have enough reputation points to comment on your question on
serverfault.
Is your DocumentRoot (/var/www/html/test) underneath the default
DocumentRoot (normally /var/www/html)?
If so, try moving the DocumentRoot to /var/www/test. I don't know how
Apache HTTPD deals with overlapping DocumentRoots (I suppose I should go
read the docs).
. . . just my two cents
/mde/
Re: Setting up Tomcat behind an existing Apache httpd server (on
Amazon Linux 2)
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
As it happens, I'm now struggling with an issue just trying to get a new
virtual host up and running on the httpd server. I've put it on Server
Fault, at: https://preview.tinyurl.com/rr3rxwa
While it may not be necessary to solve this problem in order to get the
httpd server to proxy the Tomcat server, this certainly *looks* like
something that might pick a fight with what's being proxied to Tomcat.
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Setting up Tomcat behind an existing Apache httpd server (on
Amazon Linux 2)
Posted by Mark Eggers <it...@yahoo.com.INVALID>.
James,
On 4/6/2020 3:09 PM, James H. H. Lampert wrote:
> First of all, thank you, Mr. Malcom, Herr Kreuser, and Mr. Eggers.
>
> One thing I will note is that near as I can tell, mod_proxy and
> mod_proxy_http are already present on the system (I can find
> "mod_proxy.so" and "mod_proxy_http.so"), but mod_jk does not appear to
> be present (no sign of a "mod_jk.so" anywhere).
>
> Second, we do indeed have an "00-ssl.conf" file in conf.modules.d, and
> an "ssl.conf" in conf.d. The conf.d directory also has .conf files for
> all the domain names, in the form domain.conf and domain-le-ssl.conf,
> each containing the VirtualHost configurations for the various domains.
>
> Now obviously, the very last thing I want to do is disrupt the existing
> web sites being served.
>
> Mr. Eggers: Not quite sure I understand the "No virtual host for now"
> bit, at the top of your sample proxy configuration; I thought everything
> in httpd had to be in a virtual host.
>
> Something I just noticed myself: if I go to http://www.baz.com, it
> *doesn't* immediately redirect me to https://www.baz.com, but if I go to
> http://www.foo.com or http://www.bar.com, it *does* immediately switch
> me to https. This seems like some sort of an oversight by my colleague,
> who configured the sites.
>
> From what I can see, "mod_proxy" seems easier to set up (and one less
> thing to download); what are the disadvantages, if any?
>
> --
> JHHL
I iust meant that my example didn't have a virtual host. In your
requirement, you'd probably put the LoadModule and <Proxy>
configurations in the main httpd.conf section so it'll be inherited by
the named virtual hosts.
In each named virtual host, you would then place the ProxyPass /
ProxyPassReverse pairs for a targeted (named) host. You could even have
one Apache HTTPD talk to different back-end Tomcats (one for each named
host in domain-le-ssl.conf).
There are a lot of ways to slice and dice this. It all depends on your
requirements.
. . . just my two cents
/mde/
Re: Setting up Tomcat behind an existing Apache httpd server (on
Amazon Linux 2)
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
First of all, thank you, Mr. Malcom, Herr Kreuser, and Mr. Eggers.
One thing I will note is that near as I can tell, mod_proxy and
mod_proxy_http are already present on the system (I can find
"mod_proxy.so" and "mod_proxy_http.so"), but mod_jk does not appear to
be present (no sign of a "mod_jk.so" anywhere).
Second, we do indeed have an "00-ssl.conf" file in conf.modules.d, and
an "ssl.conf" in conf.d. The conf.d directory also has .conf files for
all the domain names, in the form domain.conf and domain-le-ssl.conf,
each containing the VirtualHost configurations for the various domains.
Now obviously, the very last thing I want to do is disrupt the existing
web sites being served.
Mr. Eggers: Not quite sure I understand the "No virtual host for now"
bit, at the top of your sample proxy configuration; I thought everything
in httpd had to be in a virtual host.
Something I just noticed myself: if I go to http://www.baz.com, it
*doesn't* immediately redirect me to https://www.baz.com, but if I go to
http://www.foo.com or http://www.bar.com, it *does* immediately switch
me to https. This seems like some sort of an oversight by my colleague,
who configured the sites.
From what I can see, "mod_proxy" seems easier to set up (and one less
thing to download); what are the disadvantages, if any?
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Setting up Tomcat behind an existing Apache httpd server (on
Amazon Linux 2)
Posted by Mark Eggers <it...@yahoo.com.INVALID>.
James,
On 4/8/2020 5:41 PM, James H. H. Lampert wrote:
> On 4/8/20 4:57 PM, Mark Eggers wrote:
>> See
>> https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxy
>> for some examples.
>
> Yes. That's the very point in the documentation that has my head spinning:
>>> For example, the following will allow only hosts in
>>> yournetwork.example.com to access content via your proxy server:
>
>>>> <Proxy "*">
>>>> Require host yournetwork.example.com
>>>> </Proxy>
>
> *Access* content?? I thought the Tomcat server is *serving* content.
>
>> So if I remember everything correctly, you could be really specific with
>> the following:
>>
>> <Proxy "https://qux.baz.com">
>> Require ip 127.0.0.1
>> </Proxy>
>>
>> Place this inside the virtual host defined in the appropriate ssl.conf
>> snippet. I think that you have an ssl.conf file per domain, right?
>>
>> Then in the non-ssl snippet, you would rewrite all the requests to go to
>> HTTPS.
>
> That part makes sense, although I'm not entirely sure why I would want
> to "be really specific" about the domain in the Proxy container, unless
> it's to keep it from fighting with the other VirtualHosts. And actually,
> I put the SSL and non-SSL VirtualHost blocks for the new domain in a
> single .conf file.
>
James,
This is going to be way off topic, and may not be completely correct.
While I'm pretty good with Apache Tomcat, I'm still learning about
Apache HTTPD. We should probably have further discussions off the
mailing list.
Anyway from an overview standpoint, think of a proxy as a virtual file
system.
Instead of serving information from a directory subject to <Directory>
constraints, Apache HTTPD is serving information from a proxy.
From the browser's standpoint, the information is being served by Apache
HTTPD, even though you're proxying Apache Tomcat.
For example, on my mod_jk connected Apache Tomcat, the server is
reported as:
Server: Apache/2.2.15 (CentOS)
This is what CentOS's patched Apache HTTPD 2.2 server reports, and is
not indicative of the Apache Tomcat that I'm running behind mod_jk.
So Apache HTTPD matches an incoming request to the most specific URL
that it can, and then applies rules.
This allows me to restrict HTTPD methods, do rewrites, and then passes
the results off to Apache Tomcat (if configured to do so).
When Apache Tomcat gets done with whatever it does (renders JSPs,
creates / serves JSON, serves JS/CSS, etc.), it sends this back to
Apache HTTPD.
Apache HTTPD then does things like compress the output, edits / adds
cookies, and edits / adds headers.
Finally, the result gets sent to the browser.
The browser has no idea that the response is generated via Apache
Tomcat. OK, if someone notices a JSESSIONID, the user might have a clue.
Other than that, no.
I proxy behind Apache HTTPD for several reasons. Until recently, SAN
certificates, Java, and Tomcat didn't play nicely together. That's changed.
It's also easier to add some headers and cookies in Apache HTTPD than in
Apache Tomcat. This is especially true for SameSite cookies, where
certain browsers are broken and cannot handle SameSite=None. I have to
do some ugly browser sniffing (fragile, not recommended) so that cookies
generated by Apache Tomcat work inside an iframe.
Now the order that all of this stuff happens is an entirely new
discussion that might be better off-list, or on the Apache HTTPD mailing
list.
Think of Apache HTTPD as a Valve / Filter combination in the Apache
Tomcat sense, if that helps.
Oh, and being specific has some nice benefits. You can create different
rules for different URLs before passing it off to a back end Apache
Tomcat. Access control is just ONE of the things that you can do with
Apache HTTPD sitting in front of Apache Tomcat.
Running all of this in a cloud environment brings its own set of challenges.
. . . just my two cents
/mde/
Re: Setting up Tomcat behind an existing Apache httpd server (on
Amazon Linux 2)
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
On 4/8/20 4:57 PM, Mark Eggers wrote:
> See
> https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxy
> for some examples.
Yes. That's the very point in the documentation that has my head spinning:
>> For example, the following will allow only hosts in
>> yournetwork.example.com to access content via your proxy server:
>>> <Proxy "*">
>>> Require host yournetwork.example.com
>>> </Proxy>
*Access* content?? I thought the Tomcat server is *serving* content.
> So if I remember everything correctly, you could be really specific with
> the following:
>
> <Proxy "https://qux.baz.com">
> Require ip 127.0.0.1
> </Proxy>
>
> Place this inside the virtual host defined in the appropriate ssl.conf
> snippet. I think that you have an ssl.conf file per domain, right?
>
> Then in the non-ssl snippet, you would rewrite all the requests to go to
> HTTPS.
That part makes sense, although I'm not entirely sure why I would want
to "be really specific" about the domain in the Proxy container, unless
it's to keep it from fighting with the other VirtualHosts. And actually,
I put the SSL and non-SSL VirtualHost blocks for the new domain in a
single .conf file.
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Setting up Tomcat behind an existing Apache httpd server (on
Amazon Linux 2)
Posted by Mark Eggers <it...@yahoo.com.INVALID>.
On 4/8/2020 4:11 PM, James H. H. Lampert wrote:
> On 4/8/20 3:52 PM, Mark Eggers wrote:
>>>> <Proxy "*">
>>>> Require ip 127
>>>> </Proxy>
>
> Dear Mr. Eggers (et al.):
>
> I'm still not clear on what that even *does* (and the official docs
> leave me even more confused: "only allow hosts in . . . to access
> content via your proxy"); could you (or somebody else) explain it?
> Remember, while I may be (deservedly or otherwise) a guru on getting
> Tomcat running on an IBM Midrange box, I have no illusions about having
> the slightest clue what I'm doing with httpd. Yesterday, I was tearing
> my hair out because certbot wasn't working, only to discover that I had
> a malformed VirtualHost.
>
> And as to vendor-supplied installations, I agree with you. I'm rather
> irritated with the "Debianism" of splitting Tomcat up so completely that
> webapp contexts can be in at least two different places, and the general
> "Linuxism" of *not* including manager and host-manager (although I've
> never needed the latter) in the basic installation, and sometimes not
> even including a default root.
>
> --
Basically, the <Proxy *> is applied to all the proxy statements in your
configuration.
See
https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxy
for some examples.
The Require statement means only allow connections from what is required
- in my example 127 gets mapped to 127.0.0.1 (localhost).
So the configuration that I have given restricts all proxy connections
to localhost, which means that no outside proxy connections are
possible. This is a good thing, I think.
So if I remember everything correctly, you could be really specific with
the following:
<Proxy "https://qux.baz.com">
Require ip 127.0.0.1
</Proxy>
Place this inside the virtual host defined in the appropriate ssl.conf
snippet. I think that you have an ssl.conf file per domain, right?
Then in the non-ssl snippet, you would rewrite all the requests to go to
HTTPS.
Again, please verify this with an Apache HTTPD expert, and discuss this
on the Apache HTTPD mailing list. I do all of this with mod_jk, so my
configuration is quite a bit different.
Again, I personally like the broad brush approach and then override
specifics per virtual host. Sort of a combination of least permissions
plus management by exception.
. . . just my two cents
/mde/
Re: Setting up Tomcat behind an existing Apache httpd server (on
Amazon Linux 2)
Posted by Mark Eggers <it...@yahoo.com.INVALID>.
On 4/8/2020 6:42 PM, calder wrote:
> On Wed, Apr 8, 2020, 18:11 James H. H. Lampert <ja...@touchtonecorp.com>
> wrote:
>
>>
>> And as to vendor-supplied installations, I agree with you. I'm rather
>> irritated with the "Debianism" of splitting Tomcat up so completely that
>> webapp contexts can be in at least two different places, and the general
>> "Linuxism" of *not* including manager and host-manager (although I've
>> never needed the latter) in the basic installation, and sometimes not
>> even including a default root.
>>
>
> It's not just a Debian thing - it's a Linux distro idiosyncrasy.
>
> And you don't have to use a distro's Tomcat layout / configuration. We
> don't - we download P.V. Tomcat and extract to /opt (obviously, one could
> choose to install to /usr/local if building) and use separate CATALINA_BASE
> and CATALINA_HOME.
>
That's what I do as well. I use Ant scripts plus some property files to
configure things. When a new version is rolled out, I edit a property
file, build the new CATALINA_BASE directories with the Ant scripts, and
I've got the new setup.
To put the new setup into production, I shut down the existing Tomcats,
move some links around, and bring up the new Tomcats. If the new Tomcats
fail to come up properly, I swap the links back, bring up the old
Tomcats, and then take a look at the logs in the appropriate CATALINA_BASE.
The advantage to this setup is that I can do all of my upgrading except
for the link swap at any time. The actual outage time is minutes.
I should script the link swapping as well to shorten the down time and
remove the chance of fat-fingering things.
. . . just my two cents
/mde/
Re: Setting up Tomcat behind an existing Apache httpd server (on
Amazon Linux 2)
Posted by calder <ca...@gmail.com>.
On Wed, Apr 8, 2020, 18:11 James H. H. Lampert <ja...@touchtonecorp.com>
wrote:
>
> And as to vendor-supplied installations, I agree with you. I'm rather
> irritated with the "Debianism" of splitting Tomcat up so completely that
> webapp contexts can be in at least two different places, and the general
> "Linuxism" of *not* including manager and host-manager (although I've
> never needed the latter) in the basic installation, and sometimes not
> even including a default root.
>
It's not just a Debian thing - it's a Linux distro idiosyncrasy.
And you don't have to use a distro's Tomcat layout / configuration. We
don't - we download P.V. Tomcat and extract to /opt (obviously, one could
choose to install to /usr/local if building) and use separate CATALINA_BASE
and CATALINA_HOME.
Re: Setting up Tomcat behind an existing Apache httpd server (on
Amazon Linux 2)
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
On 4/8/20 3:52 PM, Mark Eggers wrote:
>>> <Proxy "*">
>>> Require ip 127
>>> </Proxy>
Dear Mr. Eggers (et al.):
I'm still not clear on what that even *does* (and the official docs
leave me even more confused: "only allow hosts in . . . to access
content via your proxy"); could you (or somebody else) explain it?
Remember, while I may be (deservedly or otherwise) a guru on getting
Tomcat running on an IBM Midrange box, I have no illusions about having
the slightest clue what I'm doing with httpd. Yesterday, I was tearing
my hair out because certbot wasn't working, only to discover that I had
a malformed VirtualHost.
And as to vendor-supplied installations, I agree with you. I'm rather
irritated with the "Debianism" of splitting Tomcat up so completely that
webapp contexts can be in at least two different places, and the general
"Linuxism" of *not* including manager and host-manager (although I've
never needed the latter) in the basic installation, and sometimes not
even including a default root.
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Setting up Tomcat behind an existing Apache httpd server (on
Amazon Linux 2)
Posted by Mark Eggers <it...@yahoo.com.INVALID>.
James,
On 4/8/2020 3:27 PM, James H. H. Lampert wrote:
> Dear Mr. Eggers, et al.:
>
> Well, after running test installations of Tomcat on a whole string of
> EC2 spot instances, I went ahead and installed it on the target server.
> I've got it running, and enabled to start automatically, and I've added
> a security group to temporarily open 8080 to my office IP address, so
> that I can reach it directly and verify that it works (it does). And
> I've also verified that mod_proxy and mod_proxy_http are enabled (they
> already were; I didn't have to lift a finger)
>
> On 4/6/20 2:13 PM, Mark Eggers wrote:
>> # Secure your proxy - localhost for now - this is IMPORTANT
>> <Proxy "*">
>> Require ip 127
>> </Proxy>
>>
>> # Map applications
>> # You could just use / if you're proxying all requests
>> # Pick the correct Apache Tomcat port
>>
>> ProxyPass "/foo" "http://127.0.0.1:8080/foo"
>> ProxyPassReverse "/foo" "http://127.0.0.1:8080/foo"
>
> Now I'm not sure I understand the <Proxy "*"> container and its
> contents. The httpd and Tomcat servers are both running on the same box.
> "Require ip 127" sounds like it's specifying an incomplete IP address.
>
> I can sort-of understand the ProxyPass and ProxyPassReverse directives.
> Given that all requests to this particular VirtualHost ("qux.baz.com" to
> speak metasyntactically) should be going to Tomcat (which will have a
> root context and at least four [including manager] named contexts),
> would this be:
>
> ProxyPass "/" "http://127.0.0.1:8080/"
> ProxyPassReverse "/" "http://127.0.0.1:8080"
>
> ???
>
> Conversely, none of the other VirtualHosts would be proxying Tomcat (or
> anything else), so should all this be within the VirtualHost?
>
> --
> JHHL
>
See the following for IP address configuration in Apache HTTPD 2.4:
https://httpd.apache.org/docs/2.4/mod/mod_authz_host.html
I think putting the proxy restriction in the virtual host would be OK,
but I'm a belt and suspenders kind of person. Putting it in the default
host makes sure that someone doesn't inadvertently open up your server
later. You can always override it at the virtual host level if you wish.
Finally, one of my pet peeves concerning vendor-supplied Apache HTTPD
installations is that they turn on a lot of modules by default. The
first thing I do with such an installation is to turn off everything
that is not being used in an installation. This usually includes all of
the _dav, _user, and proxy_ modules.
. . . just my two cents
/mde/
Re: Setting up Tomcat behind an existing Apache httpd server (on
Amazon Linux 2)
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
Dear Mr. Eggers, et al.:
Well, after running test installations of Tomcat on a whole string of
EC2 spot instances, I went ahead and installed it on the target server.
I've got it running, and enabled to start automatically, and I've added
a security group to temporarily open 8080 to my office IP address, so
that I can reach it directly and verify that it works (it does). And
I've also verified that mod_proxy and mod_proxy_http are enabled (they
already were; I didn't have to lift a finger)
On 4/6/20 2:13 PM, Mark Eggers wrote:
> # Secure your proxy - localhost for now - this is IMPORTANT
> <Proxy "*">
> Require ip 127
> </Proxy>
>
> # Map applications
> # You could just use / if you're proxying all requests
> # Pick the correct Apache Tomcat port
>
> ProxyPass "/foo" "http://127.0.0.1:8080/foo"
> ProxyPassReverse "/foo" "http://127.0.0.1:8080/foo"
Now I'm not sure I understand the <Proxy "*"> container and its
contents. The httpd and Tomcat servers are both running on the same box.
"Require ip 127" sounds like it's specifying an incomplete IP address.
I can sort-of understand the ProxyPass and ProxyPassReverse directives.
Given that all requests to this particular VirtualHost ("qux.baz.com" to
speak metasyntactically) should be going to Tomcat (which will have a
root context and at least four [including manager] named contexts),
would this be:
ProxyPass "/" "http://127.0.0.1:8080/"
ProxyPassReverse "/" "http://127.0.0.1:8080"
???
Conversely, none of the other VirtualHosts would be proxying Tomcat (or
anything else), so should all this be within the VirtualHost?
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Setting up Tomcat behind an existing Apache httpd server (on
Amazon Linux 2)
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
On 4/9/20 1:37 PM, Peter Kreuser wrote:
> It should be sufficient to just do a Location directive and then Require.
>
> <Location /manager>
> Require ....
> </Location>
Dear Herr Kreuser:
Thanks. I was beginning to wonder if Location might be the answer.
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Setting up Tomcat behind an existing Apache httpd server (on
Amazon Linux 2)
Posted by Peter Kreuser <lo...@kreuser.name>.
Mark, James
> Am 09.04.2020 um 22:14 schrieb Mark Eggers <it...@yahoo.com.invalid>:
>
> James,
>
>> On 4/9/2020 12:11 PM, James H. H. Lampert wrote:
>>> On 4/6/20 2:13 PM, Mark Eggers wrote:
>>> # Secure your proxy - localhost for now - this is IMPORTANT
>>> <Proxy "*">
>>> Require ip 127
>>> </Proxy>
>>
Isn‘t this for CONNECT Requests?
The Backend proxying happens with GET POST PUT to httpd and then apache opens the connect to backend.
No Proxying in the sense of the PROXY directive...
>> Dear Mr. Eggers:
>>
>> It seems I was right about how what you said about this, and what the
>> docs say about it, appeared to contradict each other: with that in the
>> VirtualHost with the ProxyPass and ProxyPassReverse directives, it
>> blocked all outside access through the proxy.
>>
>> Once I commented out those lines, I got proxied straight to the default
>> ROOT context.
>>
>> Then, when I reactivated the valve in the manager app, I found that I
>> was still able to get into it via the proxy, but not directly.
>>
>> I've now put this in
>>> <Proxy "https://qux.baz.com/manager">
>>> Require ip xx.yy.zz.qq
>>> </Proxy>
>>> <Proxy "https://corge.bax.com/manager">
>>> Require ip xx.yy.zz.qq
>>> </Proxy>
>>
It should be sufficient to just do a Location directive and then Require.
<Location /manager>
Require ....
</Location>
Maybe also LocationMatch.
>> where xx.yy.zz.qq is my office IP address. I could get in just fine.
>> Then I changed the IP address to something different, restarted my
>> browser, and I could still get in. I also tried it with "/*" on the ends
>> of the URLs, and with "/html" on the ends, and with "/html/*" on the
>> ends. I also went back to the original "*" on one of them, and it went
>> back to locking me out of everything. Something doesn't seem right here.
>>
>
> I'll play with this a little later.
Me too.
>
> Please note that when you change Apache HTTPD configurations you must
> restart Apache HTTPD.
>
An apachectl graceful reloads the config without downtime.
> This is one of the reasons why I prefer mod_jk. I can change the mapped
> URLs on the fly without having to restart Apache HTTPD (albeit with some
> small hit to performance).
>
> The way that I have things set up for a client is to have a machine with
> two interfaces and use an <Alias> directive in server.xml.
>
> I then run an additional HTTP/1.1 connector and bind it to the internal
> interface only. The internal interface is protected by VPN with a two
> factor authentication.
>
Interesting idea.
> I could further protect the sensitive applications by using the remote
> address filter and restricting access to the management and build
> systems subnets.
>
> To access the manager application, you have to connect to the VPN, and
> then browse to the following:
>
> http://internal.dns.domain.com:port/manager/html
>
> This will will bring up a manager interface that is appropriate for:
>
> https://external.dns..domain.com
>
> and all the applications running there. This is mostly used by the
> client's internal Jenkins build system to publish applications to the
> appropriate Tomcat server. It can also be used by a JMX application for
> Tomcat monitoring.
>
> My urimapping.properties file contains lines like:
>
> !/manager|/*=worker_name
> !/jmxmonitor|/*=worker_name
>
> This blocks proxying the manager and JMX applications by mod_jk.
>
> This has been running in production since I set it up, and has survived
> both random script kiddie attacks and security audits by the client's
> customers.
>
> You could look at mimicking this behavior with mod_proxy by using an
> exclamation mark (not tested).
>
> Something like the following:
>
> ProxyPass /manager !
> ProxyPass /jmxmonitor !
>
> per the documentation here:
>
> https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxypass
>
> Apparently, the documentation would recommend something like the following:
>
> <Location "/manager">
> ProxyPass "!"
> </Location>
> <Location "/jmxmonitor">
> ProxyPass "!"
> </Location>
>
> I think that the above is probably easier to read and more specific.
> Place the directives in the appropriate virtual host.
>
> You could also be more expressive with LocationMatch and regular
> expressions.
>
> Once this is done you could access the manager application directly by
> using the appropriate port and configuring AWS's firewall rules to allow
> your office IP address through the port.
>
> Again, I have not tried this since I use mod_jk. Again, please remember
> to restart Apache HTTPD after any configuration changes.
>
>
> . . . just my two cents
> /mde/
Peter
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Setting up Tomcat behind an existing Apache httpd server (on
Amazon Linux 2)
Posted by Mark Eggers <it...@yahoo.com.INVALID>.
James,
On 4/9/2020 12:11 PM, James H. H. Lampert wrote:
> On 4/6/20 2:13 PM, Mark Eggers wrote:
>> # Secure your proxy - localhost for now - this is IMPORTANT
>> <Proxy "*">
>> Require ip 127
>> </Proxy>
>
> Dear Mr. Eggers:
>
> It seems I was right about how what you said about this, and what the
> docs say about it, appeared to contradict each other: with that in the
> VirtualHost with the ProxyPass and ProxyPassReverse directives, it
> blocked all outside access through the proxy.
>
> Once I commented out those lines, I got proxied straight to the default
> ROOT context.
>
> Then, when I reactivated the valve in the manager app, I found that I
> was still able to get into it via the proxy, but not directly.
>
> I've now put this in
>> <Proxy "https://qux.baz.com/manager">
>> Require ip xx.yy.zz.qq
>> </Proxy>
>> <Proxy "https://corge.bax.com/manager">
>> Require ip xx.yy.zz.qq
>> </Proxy>
>
> where xx.yy.zz.qq is my office IP address. I could get in just fine.
> Then I changed the IP address to something different, restarted my
> browser, and I could still get in. I also tried it with "/*" on the ends
> of the URLs, and with "/html" on the ends, and with "/html/*" on the
> ends. I also went back to the original "*" on one of them, and it went
> back to locking me out of everything. Something doesn't seem right here.
>
I'll play with this a little later.
Please note that when you change Apache HTTPD configurations you must
restart Apache HTTPD.
This is one of the reasons why I prefer mod_jk. I can change the mapped
URLs on the fly without having to restart Apache HTTPD (albeit with some
small hit to performance).
The way that I have things set up for a client is to have a machine with
two interfaces and use an <Alias> directive in server.xml.
I then run an additional HTTP/1.1 connector and bind it to the internal
interface only. The internal interface is protected by VPN with a two
factor authentication.
I could further protect the sensitive applications by using the remote
address filter and restricting access to the management and build
systems subnets.
To access the manager application, you have to connect to the VPN, and
then browse to the following:
http://internal.dns.domain.com:port/manager/html
This will will bring up a manager interface that is appropriate for:
https://external.dns..domain.com
and all the applications running there. This is mostly used by the
client's internal Jenkins build system to publish applications to the
appropriate Tomcat server. It can also be used by a JMX application for
Tomcat monitoring.
My urimapping.properties file contains lines like:
!/manager|/*=worker_name
!/jmxmonitor|/*=worker_name
This blocks proxying the manager and JMX applications by mod_jk.
This has been running in production since I set it up, and has survived
both random script kiddie attacks and security audits by the client's
customers.
You could look at mimicking this behavior with mod_proxy by using an
exclamation mark (not tested).
Something like the following:
ProxyPass /manager !
ProxyPass /jmxmonitor !
per the documentation here:
https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxypass
Apparently, the documentation would recommend something like the following:
<Location "/manager">
ProxyPass "!"
</Location>
<Location "/jmxmonitor">
ProxyPass "!"
</Location>
I think that the above is probably easier to read and more specific.
Place the directives in the appropriate virtual host.
You could also be more expressive with LocationMatch and regular
expressions.
Once this is done you could access the manager application directly by
using the appropriate port and configuring AWS's firewall rules to allow
your office IP address through the port.
Again, I have not tried this since I use mod_jk. Again, please remember
to restart Apache HTTPD after any configuration changes.
. . . just my two cents
/mde/
Re: Setting up Tomcat behind an existing Apache httpd server (on
Amazon Linux 2)
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
On 4/6/20 2:13 PM, Mark Eggers wrote:
> # Secure your proxy - localhost for now - this is IMPORTANT
> <Proxy "*">
> Require ip 127
> </Proxy>
Dear Mr. Eggers:
It seems I was right about how what you said about this, and what the
docs say about it, appeared to contradict each other: with that in the
VirtualHost with the ProxyPass and ProxyPassReverse directives, it
blocked all outside access through the proxy.
Once I commented out those lines, I got proxied straight to the default
ROOT context.
Then, when I reactivated the valve in the manager app, I found that I
was still able to get into it via the proxy, but not directly.
I've now put this in
> <Proxy "https://qux.baz.com/manager">
> Require ip xx.yy.zz.qq
> </Proxy>
> <Proxy "https://corge.bax.com/manager">
> Require ip xx.yy.zz.qq
> </Proxy>
where xx.yy.zz.qq is my office IP address. I could get in just fine.
Then I changed the IP address to something different, restarted my
browser, and I could still get in. I also tried it with "/*" on the ends
of the URLs, and with "/html" on the ends, and with "/html/*" on the
ends. I also went back to the original "*" on one of them, and it went
back to locking me out of everything. Something doesn't seem right here.
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Setting up Tomcat behind an existing Apache httpd server (on
Amazon Linux 2)
Posted by Mark Eggers <it...@yahoo.com.INVALID>.
James,
On 4/6/2020 12:53 PM, James H. H. Lampert wrote:
> Here is the situation:
>
> We have an existing Amazon EC2 instance, running Amazon Linux 2, with an
> Apache httpd server already running our web sites (for argument's sake,
> "foo.com," "bar.com," and "baz.com."), and already getting its certs
> from Let's Encrypt, using "foo.com" as the CN, with "www.foo.com,"
> "bar.com," "www.bar.com," "baz.com," and "www.baz.com" as SANs. And it
> seems to be working quite nicely.
>
> Now, we want to add a Tomcat server, which would then serve several
> webapp contexts at "qux.baz.com," and maybe also "corge.baz.com,"
> running behind the httpd server (which is something I've never done
> before; I've always set up Tomcat directly facing the outside world, so
> with this, I frankly haven't a clue what I'm doing).
>
> First of all, which is currently considered the easier/better way to get
> Tomcat running behind httpd, given the above scenario? "mod_proxy," or
> "mod_jk?" Or is there something else I haven't heard of?
>
> Second of all, I found this step-by-step procedure.
>
>> https://preview.tinyurl.com/vwnutqj
>
> Is it any good?
>
> Third, am I correct in assuming that all we need to do in order for the
> existing Let's Encrypt setup to cover the new "qux" and "corge"
> subdomains is to add them to the SANs already listed?
>
> Finally, are there any "gotchas" I need to be concerned with?
>
> --
> James H. H. Lampert
> Touchtone Corporation
I prefer mod_jk to mod_proxy for a variety of reasons. Chief among those
is its ability to change web applications on the fly (albeit with some
performance loss).
Unfortunately, there is discussion on the dev list indicating that AJP
may be deprecated in the future. Thus, mod_proxy seems to be the way to go.
I've not put together a mod_proxy_http connection before, so I thought
that I would try it on a Windows 10 Professional system with Tomcat
7.0.103 and Apache HTTPD 2.4.38 (yes, yes, I'll upgrade soon).
First of all, I think that the following is very suspicious.
<Directory /var/lib/tomcat8/webapps/>
AllowOverride All
Require all granted
Options Indexes FollowSymLinks
</Directory>
This appears to establish a set of Apache HTTPD directives for the
Tomcat - served web applications. This is completely unnecessary. The
entire point of a proxy is to pass information from Apache HTTPD to
Apache Tomcat via a network protocol (in this case HTTP).
Second of all, the proxy_pass statements appear to do some rewriting.
This is in general not a good idea, since cookie paths will get munged.
You'll have to use mod_rewrite in order to straighten out cookie paths,
and you may break website links which would require rewriting. In
general, it's a very good idea to keep the path the same between Apache
HTTPD and Apache Tomcat.
At least the above is the case for mod_ajp.
Third of all, I have no idea why there's a Location directive with
"/webapps" in the configuration. Since there's no DocumentRoot for this
virtual host, I suspect it will be in reference to the parent's
(default) DocumentRoot. What that serves is a mystery to me given the
configuration fragment.
Maybe some Apache HTTPD experts on the list have some ideas.
Also note that this isn't HTTPS. Typically, an HTTPS Apache HTTPD
configuration lives in ssl.conf, and you protect HTTP access by doing a
redirect in httpd.conf to the HTTPS site.
You could terminate HTTPS on Apache HTTPD, and then connect Apache HTTPD
via HTTP to Apache Tomcat.
Also note that referencing Apache Tomcat's webapps directory in Apache
HTTPD is a VERY BAD THING. Apache HTTPD has no concept of WEB-INF or
META-INF, so it's conceivable that you could serve and expose secrets
from appname/META-INF or appname/WEB-INF. It's best to just not do this.
Given the above, I thought that I would hack together a quick and dirty
proxy configuration. Again I use mod_jk, so please let some of the more
experienced people chime in on this.
On UNIX / Linux you could also probably use UNIX sockets instead of
HTTP, HTTPS, or AJP.
# No virtual host for now
# No SSL for now
# enabling proxy and http proxy (note, you could use HTTP/2 as well)
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
# Secure your proxy - localhost for now - this is IMPORTANT
<Proxy "*">
Require ip 127
</Proxy>
# Map applications
# You could just use / if you're proxying all requests
# Pick the correct Apache Tomcat port
ProxyPass "/foo" "http://127.0.0.1:8080/foo"
ProxyPassReverse "/foo" "http://127.0.0.1:8080/foo"
This works on my local machine. I hope this is useful.
. . . just my two cents
/mde/
Re: Setting up Tomcat behind an existing Apache httpd server (on
Amazon Linux 2)
Posted by Peter Kreuser <lo...@kreuser.name>.
James,
> Am 06.04.2020 um 21:53 schrieb James H. H. Lampert <ja...@touchtonecorp.com>:
>
> Here is the situation:
>
> We have an existing Amazon EC2 instance, running Amazon Linux 2, with an Apache httpd server already running our web sites (for argument's sake, "foo.com," "bar.com," and "baz.com."), and already getting its certs from Let's Encrypt, using "foo.com" as the CN, with "www.foo.com," "bar.com," "www.bar.com," "baz.com," and "www.baz.com" as SANs. And it seems to be working quite nicely.
>
> Now, we want to add a Tomcat server, which would then serve several webapp contexts at "qux.baz.com," and maybe also "corge.baz.com," running behind the httpd server (which is something I've never done before; I've always set up Tomcat directly facing the outside world, so with this, I frankly haven't a clue what I'm doing).
>
Don‘t be scared!
> First of all, which is currently considered the easier/better way to get Tomcat running behind httpd, given the above scenario? "mod_proxy," or "mod_jk?" Or is there something else I haven't heard of?
>
> Second of all, I found this step-by-step procedure.
>
>> https://preview.tinyurl.com/vwnutqj
>
> Is it any good?
>
Sounds reasonable.
Are you going to host tomcat on the same „server“ or are you proxying to a different instance? Then mod_proxy and ssl (!) should be the way to go. If you are on the same instance, you may want to see if mod_jk is an option.
> Third, am I correct in assuming that all we need to do in order for the existing Let's Encrypt setup to cover the new "qux" and "corge" subdomains is to add them to the SANs already listed?
>
That and the additional Serveralias‘ or VirtualHosts that proxy the tomcat requests.
> Finally, are there any "gotchas" I need to be concerned with?
>
Any headers that are necessary for your tomcat application need to be sent or maybe rewritten.
You may need to set the correct attributes on your connector, so the URLs are correctly rewritten (port 8080/8443 in tomcat should be https 443 to the outside! Cookies may need the correct path and secure flag.)
That may be a second round of tweaking. First get to serve the pages on the right Uri.
Let us know how you get along and we can add to the config if necessary.
Peter
> --
> James H. H. Lampert
> Touchtone Corporation
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Setting up Tomcat behind an existing Apache httpd server (on
Amazon Linux 2)
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
Dear Mr. Schultz:
Delighted to hear from you, and delighted that you weighed in on this.
You've already earned my undying respect and gratitude. This also allows
us to drop one more cert that we have to pay for, and I think it could
lead to an easy way to drop yet another.
On 4/9/20 3:31 PM, Christopher Schultz wrote:
. . .
> First of all, definitely use mod_proxy and definitely use
> mod_proxy_http (and not mod_proxy_ajp).
It seemed the more straightforward of the two options. And it was
already there.
> 0. DO NOT TRY TO USE YOUR PROXY TO RE-WRITE URL-SPACES
And you still don't talk about Fight Club . . . ;P
> If you have an application hosted on Tomcat in /foo then map it to
> /foo on the proxy.
Done. That was also the advice I got from Mr. Eggers, and with multiple
contexts, I saw no reason to copy that particular mistake that somewhat
untrustworthy tutorial page.
> 1. Configure your Tomcat connector
I left it "stock"; given that I'm going to be removing the extra
security group that temporarily gave me direct access to the Tomcat
port, I saw no reason to go with a nonstandard port number.
> 2. Configure mod_proxy to act as a proxy
>
> ProxyRequests Off # this is to disable forward-proxying (!!)
Done, but that's the default anyway.
> ProxyPass /context1/ http://localhost:1234/context1/
> ProxyPassReverse /context1/ http://localhost:1234/context1/
>
> 3. Celebrate
Not much time for that: I'm still in the process of reconstructing a WAR
file for one of the contexts. I had to reconstruct an Eclipse project in
order to do so. And I'm not much more knowledgable about Eclipse than I
am about httpd.
> 4. If localhost, use http; otherwise, use https. This requires a TLS
> cert, which may be irritating to accomplish with an "internal" host.
> Note that httpd isn't terribly picky about the signature on the TLS
> certificate of the origin server (Tomcat), so you can self-sign if
> you'd like.
It's localhost.
> 5. Without additional configuration on the Tomcat side, you'll find
> that your access logs tell you that all visitors have the same IP
> address (surprise! it's your reverse-proxy!). Have a look at the
> RemoteIPValve[1] to get that all fixed up.
Not something we pay a lot of attention to.
> 6. If you have your static content files on the web server, you may be
> able to improve performance a bit by NOT proxying requests to the
> static content.
Not enough static content to bother with.
> 7. Adding more origin servers requires a slightly different
> configuration.
Not even remotely enough traffic to warrant a load balancer. We have
another product that's running behind a load balancer, in an Elastic
Beanstalk stack; outside of torture-testing and some occasional early
bugs, we haven't actually seen it spawn off a second node. Then again,
that product is very new.
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Setting up Tomcat behind an existing Apache httpd server (on
Amazon Linux 2)
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
James,
On 4/6/20 15:53, James H. H. Lampert wrote:
> Here is the situation:
>
> We have an existing Amazon EC2 instance, running Amazon Linux 2,
> with an Apache httpd server already running our web sites (for
> argument's sake, "foo.com," "bar.com," and "baz.com."), and already
> getting its certs from Let's Encrypt, using "foo.com" as the CN,
> with "www.foo.com," "bar.com," "www.bar.com," "baz.com," and
> "www.baz.com" as SANs. And it seems to be working quite nicely.
>
> Now, we want to add a Tomcat server, which would then serve
> several webapp contexts at "qux.baz.com," and maybe also
> "corge.baz.com," running behind the httpd server (which is
> something I've never done before; I've always set up Tomcat
> directly facing the outside world, so with this, I frankly haven't
> a clue what I'm doing).
>
> First of all, which is currently considered the easier/better way
> to get Tomcat running behind httpd, given the above scenario?
> "mod_proxy," or "mod_jk?" Or is there something else I haven't
> heard of?
>
> Second of all, I found this step-by-step procedure.
>
>> https://preview.tinyurl.com/vwnutqj
>
> Is it any good?
>
> Third, am I correct in assuming that all we need to do in order for
> the existing Let's Encrypt setup to cover the new "qux" and
> "corge" subdomains is to add them to the SANs already listed?
>
> Finally, are there any "gotchas" I need to be concerned with?
I've just read through your saga thus-far, and I have some comments
that I hope will help you with your efforts.
First of all, definitely use mod_proxy and definitely use
mod_proxy_http (and not mod_proxy_ajp).
Once you have made those decisions (or had them made for you), it
should be as simple as this:
0. DO NOT TRY TO USE YOUR PROXY TO RE-WRITE URL-SPACES
If you have an application hosted on Tomcat in /foo then map it to
/foo on the proxy. If you want it on /bar, then re-name the darned
thing on the Tomcat side so it's got the context-path you want FIRST,
then map it through the proxy. To do otherwise is to descend into a
whirling maelstrom of unending pain and torture, and you'll get
nothing but "change your application context-path" responses if you
ask for help "fixing" your configuration so it works.
1. Configure your Tomcat connector
<Connector port="1234"
protocol="HTTP/1.1"
[etc] />
2. Configure mod_proxy to act as a proxy
ProxyRequests Off # this is to disable forward-proxying (!!)
ProxyPass /context1/ http://localhost:1234/context1/
ProxyPassReverse /context1/ http://localhost:1234/context1/
3. Celebrate
There are a bunch of other things you can do, too.
Some additional thoughts:
4. If localhost, use http; otherwise, use https. This requires a TLS
cert, which may be irritating to accomplish with an "internal" host.
Note that httpd isn't terribly picky about the signature on the TLS
certificate of the origin server (Tomcat), so you can self-sign if
you'd like.
5. Without additional configuration on the Tomcat side, you'll find
that your access logs tell you that all visitors have the same IP
address (surprise! it's your reverse-proxy!). Have a look at the
RemoteIPValve[1] to get that all fixed up.
6. If you have your static content files on the web server, you may be
able to improve performance a bit by NOT proxying requests to the
static content. Be very careful with this: you probably do NOT want to:
Alias /context1/ /var/tomcat/webapps/mywebapp/
ProxyPassMatch /context1/.*\.xml !
With that configuration (which may be invalid; it's just an example),
any remote user can read your application's WEB-INF/web.xml file. Or
whatever else you have laying around. Make sure you secure your
disk-files from the incoming URL space.
7. Adding more origin servers requires a slightly different
configuration. It looks like this:
<Proxy "balancer://context1">
BalancerMember https://host1:1234/context1/
BalancerMember https://host2:1234/context1/
[etc]
</Proxy>
ProxyPass /context1/ balancer://context1
ProxyPassReverse /context1/ balancer://context1
If you intend to use a load-balancer, you should make sure you read
all about the various parameters for the balancer members (like
timeouts, live-checks, ttl, etc.) to maintain a sane configuration.
I hope that helps,
- -chris
PS If ApacheCon NA happens this year, I'm expecting to give a talk on
migrating from mod_jk to mod_proxy if anyone if interested.
[1]
http://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Remote_IP_Valv
e
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6Poj8ACgkQHPApP6U8
pFghpA/8DP8tbNTzoOC12dg1D3JxI9QFEB1psXv8yZcqhNzYy5fr7iWm9aWAQJYC
j5TuBD4lbp3dR2jzjVFu7BKUDX/vwLdqQyZ3+EedBZQbMia5sq4tHDxce9oOzC52
nrAcJfvISuMVcfY6UE6VfYTIaRCO4V3GdRo2r0d2E6+tjnZxYYyIu8HsORZy7BRK
+NVRJOUllbNVM13F7SqCE+JnOqO+v718Suj6ClxwiIDaXwb0POKr9YZgdapeiuYX
k/OMf9iyf74+3IW2Aub4b8/ufT53jrr/LYcn24aQzt+n2lxzoe9bZcAMkDevNjSN
Ymjo70kjlxJbck38eRm3P6HXEPW2Jru41bHhjnXrfzXcSkVECWBLzvHekXIWZ+Tk
RCd3i8XtJ42D3G6GN8XOy+ocRQ7+kDMBKSCh8JU3Kbd9F9N0MrpQC0TaXaEyr/vD
CH5z/r9a9mJ5+hRwbGsEcgpwOyE5xA3BNc7eBRynVCDmV1yglr0j2tyFl3QBHvr+
QmYNU/lOevefcJPEs7j7PmuzNaH/V8E6ij/2bkXJYcLiUlb0zeGlTq6n0gbc4AeU
/El1yCMYnE0BSKQ3N+ezN6j2DfLDcLp0/GV1zbS/XwA7G+S16sfxec3Zyhok848g
K8wk8oumnfQExK1dKaQ/MUGUvZQxN2GQGKDb9DU06v4mPZctvcA=
=5OZf
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org