-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Chris,
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
applications)
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 workers.properties 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
numbers.
Then you just need to map URLs (e.g. /dev1-app1) to the matching port
numbers.
>>> 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/startup.sh) 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.
Yes.
> 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/startup.sh, 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/startup.sh.
If CATALINA_BASE/bin/setenv.sh exists, it will be sourced before
Tomcat starts, so customized environment variables can be set there
(like CATALINA_OPTS).
> 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 jk_workers.properties 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
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJZsbocAAoJEBzwKT+lPKRYtPIP/2MMay9rU85PkBDfmAZA9C/+
NnR91O7ZQEkT6dSiCmDdQLfH8LmQdoZ4G3bV95Rojfi2UJbTB6/OiDEUF7NUfqvz
2OCG1k0lVgEeCMV+FqFZ/YxYJSj8CA8wTvZQGhEfYIwtGpyvnroJKPbOqI2Kk/VE
Y84cqnGPs+MN4hZKlZYDkSQnWDgQ5pHgjE34Q5052l1WNW2b62sRta9r05gLvfG+
kgZAfc86kecUjjBIsCjGiwtubNZDc57PJDS6iYuK2tUKi5b6cUFS2WaQ3WPTgEhM
aA5rCHDkZFI3eP6tiYUn4tjZVV5o+Ix9RUJMx7cyP92yhz2WJdB6QgZSUGm2X9gz
JEzyeTcvRKPmvZTgi+n8N76cL4PGiOek1TIPnEvV9w7J/4q7xuSSayXSDNx4wXok
sdiX1dHqNZEvx7famTx+QsIEbmb/uJfWsk/4k6LU7le5XbsV0sbvyENtvLG3zIra
l02p5SFJxr+S0zMs9C3otzoLcOP8cZE+3kcYtsKjV0Sqql1eeIIasPDCN83LXK4/
WO4bYSMcTa3IhXruZQgLPSGnFSyZYralTqno8cx05zCGqZbW3KVjXE0kE+l/Ok5J
+Q8t7fzja3fyL6t4rkSrxUaS4LcCZMpxLmxErdAWQC9MHidqw50ylbxvIIqnyINk
HtaaoTSHOGIF6lDsVB8/
=V8FA
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
