tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: 8.5 - multiple host configuration question
Date Thu, 07 Sep 2017 21:29:00 GMT
Hash: SHA256


On 9/5/17 3:39 PM, Chris Cheshire wrote:
> On Tue, Sep 5, 2017 at 2:07 PM, Christopher Schultz
>> If I were king, I'd set things up like this:
>> 1. Tomcat is installed in /usr/local/tomcat (or 
>> /usr/local/tomcat-x.y.z, or /opt/whatever, etc.). 2. Tomcat is
>> never launched with CATALINA_BASE=/usr/local/tomcat 3. Each user
>> has their own CATALINA_BASE directory in their own home directory
>> (or wherever in the fs tree). No need to put anything in 
>> /usr/local which is usually considered to be shared and
>> read-only. CATALINA_BASE is just a directory with the following
>> directories in it: work/ logs/ conf/ lib/ webapps/. Anything in
>> there overrides anything in the CATALINA_HOME where Tomcat is
>> installed. I'd recommend using a custom conf/server.xml and
>> leaving everything else pretty much alone except maybe a JDBC
>> driver in CATALINA_BASE/lib that isn't necessary for all the
>> other Tomcats that will be running on the server.
>> This gives you a LOT of flexibility:
>> 1. Users run their own JVMs as their own users. Filesystem
>> permissions become simpler. Applications require less trust (e.g.
>> apps are running at "cschultz" instead of "tomcat7"). 2. Users
>> can select which version of Tomcat they want to use. Just change
>> CATALINA_BASE and restart. (Roughly speaking. If you switch major
>> versions, you'll likely have to update 
>> CATALINA_BASE/conf/server.xml quite a bit). No more "we are all 
>> running x.y.z whether you like it or not".
> Ok this helps a bit for upgrades. I would just expand the new
> tarball in a similar place, update user level conf and restart each
> instance when ready?

Exactly. Your users can even decide when they want to switch to a new
Tomcat version.

>> 3. Users can start/stop their own Tomcat services. No more
>> emailing an administrator and asking for a restart, and having to
>> coordinate it with several other unrelated teams who weren't
>> expecting a service restart in the middle of the day. 4. You
>> (admin) don't have to babysit everyone's web applications. Users
>> simply put their own apps in CATALINA_BASE/webapps and move on 
>> with their lives.
> This means I need to configure each server and connector element
> with different ports for each user, correct?

Yes. A regimented port assignment scheme is recommended. In my shared
development environments, I assign every dev a number and their port
numbers become:

Tomcat AJP:           8[dev #][app #]5
Tomcat shutdown:      8[dev #][app #]6
Tomcat "Secure" port: 8[dev #][app #]7

(the "secure" port is for loopback requests; we have those for certain

So for example, my primary app id is 1 and my dev id is 2:

AJP:      8215
Shutdown: 8216
Secure:   8217

> I am fronting tomcat with httpd using an ajp connector to handle
> ssl certs. I use letsencrypt, and on a production server I can't
> afford to bounce even the connector and lose connections. httpd
> handles it a lot more gracefully. Can I have separate mod_jk.conf
> and files for mod_jk pointing to different ports
> for separate connectors for tomcat?

Absolutely. Using regimented port assignments allows you to set up
everyone's port assignments in advance using a template worker and
then a bunch of workers that all look the same except for the port

Then you just need to map URLs (e.g. /dev1-app1) to the matching port

>>> What about file/directory permissions, assuming tomcat is
>>> running under the 'tomcat' user? I have root access to the
>>> machine, so changing groups, users, permissions is not an
>>> issue.
>> Free yourself from the "tomcat user". It's one of the things I
>> dislike most about the package-managed versions of Tomcat: they
>> tend to run everything as a single user which is completely
>> unnecessary.
> Does this mean I launch tomcat (CATALINA_BASE/bin/ as
> each user (sandbox1, sandbox2 etc)?

Yes. You may see that as a Good Thing or a Bad Thing. I think it's Good.

> Trying to assimilate all this, it sounds like :
> CATALINA_HOME=/usr/local/tomcat-x.y.z 
> CATALINA_BASE=/home/sandbox1/tc
> CATALINA_BASE/conf/server.xml has the entire configuration,
> engine, connector, host etc for that one user.


> Where do I set the variables for CATALINA_BASE/HOME? RUNNING.txt
> says
> "The CATALINA_HOME and CATALINA_BASE variables cannot be configured
> in the setenv script, because they are used to locate that file."

You'll have to set CATALINA_HOME and CATALINA_BASE for the user in
whatever way makes most sense. For example, ~/.profile works, but only
for interactive logins.

> Do I then need to create my own startup script that sets those,
> then calls ${CATALINA_HOME}/bin/, or can I just set the
> variables in .bashrc?

Yeah, .bashrc will work, too, but .profile will be better because it
will effect non-bash shells, of course.

Once those variables are set, just run $CATALINA_HOME/bin/
If CATALINA_BASE/bin/ exists, it will be sourced before
Tomcat starts, so customized environment variables can be set there

> For each other sandbox I replicate that setup, changing the 
> connector and server config elements to listen on a new port, 
> correct?

Correct. I highly recommend writing a script to churn-out a new
sandbox and then ACTUALLY USE THE SCRIPT. Once you start doing it,
you'll wonder why you ever did things any differently.

I have scripts that generate my and httpd.conf
files (snippets, for a single dev), and our builds are all ant-based,
so build.xml knows how to build a CATALINA_BASE for me with the right
directory, merges the server.xml file with the right port numbers, etc.

Moving all of this to demo and production is trivial: everything is
the same, it's just that you have only a single "dev" in production.

- -chris
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message