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/
signature.asc
Description: OpenPGP digital signature
