Hash: SHA256


On 9/5/17 10:54 AM, Chris Cheshire wrote:
> I am migrating from 7 (yum repo installation) to 8.5 (direct from 
> apache) and looking to improve configuration where possible.
> Currently (on *nix) I have a machine that runs sandboxes for my 
> domain, call them sb1.dom.com and sb2.dom.com. They each have
> their own (system) user and in tomcat's system.xml

Nit: server.xml

> I have a host for each :
> <Host name="sb1.dom.com" appBase="/home/sandbox1/webapps" ... />
> <Host name="sb2.dom.com" appBase="/home/sandbox2/webapps" .... />
> Each has access to the host-manager app via a hardlink to
> manager.xml through
> /usr/share/tomcat/conf/Catalina/${hostname}/manager.xml. Each user
> belongs to the tomcat group, and has their webapps directory group
> readable so Tomcat can deploy the apps. Each host may have multiple
> contexts within it representing code branches. The env variables
> have CATALINA_HOME and CATALINA_BASE pointing to 
> /usr/share/tomcat.
> Reading RUNNING.txt, it says that HOME and BASE can point to
> different locations for a multi-user environment, which sounds like
> what I am doing. How do I go about configuring it this way?

It depends upon your goals. If you want to run a single JVM, then it
really doesn't matter whether you have a "single" Tomcat where
CATALINA_HOME == CATALINA_BASE. If you want to run multiple JVMs, it's
pretty much required that you use a split configuration.

I'd argue that you should always have a split configuration, because
it allows you to upgrade/downgrade almost trivially without disturbing
your application's (Tomcat) configuration.

> Assume I put the tomcat installation in /usr/local, with a symlink 
> from /usr/local/tomcat to
> /usr/local/tomcat/apache-tomcat-${version}
> Would it be better to put the webapps for each user under 
> /usr/local/tomcat/webapps and symlink to them from the users home 
> directory? What would the structure look like and what would I set 

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".
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.

> 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.

- -chris
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/


To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to