On Thu, Sep 7, 2017 at 5:29 PM, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> -----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.
>
Thank you for the explanations, this helps considerably.
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
