tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Eggers <>
Subject Re: install war with xml and define environment values
Date Mon, 02 Dec 2013 16:23:19 GMT
On 12/1/2013 10:49 PM, Philipp Kraus wrote:
> Hello,
> Am 01.12.2013 um 23:40 schrieb Mark Eggers <>:
>> Run Tomcat as an unprivileged user.
>> If you need to have Tomcat serve on port 80, use jsvc, iptables to
>> map port 80 to port 8080, or place an Apache HTTPD server in front
>> of Tomcat using mod_proxy_http, mod_proxy_ajp, or mod_jk.
>> You could also unpack the WAR file, change the param value, and
>> repackage the WAR file. Of course, the user Tomcat is running under
>> will need to have privileges to the directory you change the param
>> value to.
> On my test system Tomcat 7 runs with root access, but on my
> production system it runs with an unprivileged user on port 9090 and
> a Nginx works like a proxy for https. This works fine, but on the
> Tomcat runs Jenkins and a project planning system. My Jenkins
> installation is configures by a XML file in the /etc/tomcat7
> directory with this content:
> <Context docBase="/usr/share/jenkins/jenkins.war" privileged="true"
> allowLinking="true" crossContext="true" autoDeploy="true" >
> <Environment name="JENKINS_HOME" value="/home/jenkins/"
> type="java.lang.String"/> </Context>
> With the value JENKINS_HOME I can change the data directory of
> Jenkins.
> The project planning system uses only ${user.home}, so I would like
> to redefine this environment value for this war only (because the
> backup system runs over the /home dir). I'm working the first time
> with tomcat but not with java.
> Thanks Phil

I don't know about your project planning system, but my installation of 
Jenkins doesn't need crossContext, privileged, or allowLinking. I'm not 
sure what autoDeploy accomplishes as a Context attribute (nothing?).

Do other people use your machine, or are you the sole user?

If you're the sole user, set up Tomcat within your home directory, take 
the defaults, drop the WAR files in $CATALINA_BASE/webapps, and you're done.

If not, then set up your system much like your production system. That 
way others can access it on port 80, the unprivileged user gets 
everything backed up (provided the account is in /home/unprivileged), 
and again you can just take the defaults.

This really is a Java issue and not a Tomcat issue. The application is 
using the environment variable user.home. Setting aside whether this is 
a good idea or not, I think you have a few alternatives (if you don't 
set things up as above).

1. Unpack the WAR, change the param, repack the WAR, run the altered WAR

This may or may not work, and depends on whether the application uses 
System.getenv("user.home") elsewhere to write to the directory.

2. Set the environment variable user.home

I don't know what other impacts this will have. You can do this by the 

a. create a file called in $CATALINA_BASE/bin
b. in that file put something like the following:


This should set user.home for Tomcat, but leave it set to the account's 
default for all other processes. You may actually have to set JAVA_OPTS 
rather than CATALINA_OPTS . . . depends on how user.home is used.

$CATALINA_BASE is where you're running Tomcat from. $CATALINA_HOME is 
where Tomcat is installed (roughly). Read RUNNING.txt for a more 
complete explanation and usage.

Since it looks like you're using an OS-repackaged Tomcat, I have no idea 
where the above directories are, or where you should place

As most people on this mailing list will recommend, I recommend the 

1. create an unprivileged account
2. unpack the tar.gz file for the desired Tomcat in this account
    a. get the file from
    b. I use RUNNING.txt to run multiple Tomcats, you may not
3. use the defaults
    a. start out with running WAR files in $CATALINA_HOME/webapps
    b. don't add crossContext, privileged, linking unless needed

If you need the Tomcat instance to start up at boot time, either write a 
script, or run it using jsvc. The nice thing about running it under jsvc 
is that you can then run Tomcat on a privileged port in Linux / UNIX. 
Other ways to get Tomcat to serve content on port 80 include fronting it 
with a web server or using iptables.

. . . just my two cents

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

View raw message