Expand the capabilities of your Tomcat Web server

Additional administration tips

This section outlines a few tasks that you may need to perform as you navigate your server, stop and start processes, troubleshoot, and so on. You can employ these tips could before, after, or during the steps for securing your server or setting up your database.

Granting access to the Tomcat Web Server Administration tool

The Tomcat Web Server Administration tool allows you to see server information, edit connections, modify resources, and more. It also gives you a nice interface in which to manage, create, and change user names and passwords for your main Tomcat admin user as well as add new roles and new users.

This tool is defined in $CATALINA_HOME/webapps/admin.xml. The initial login administrative user must be defined in the same tomcat-users.xml file in which your Tomcat Web Server Administration tool role and user is set up. First, add these two lines between the two <tomcat-users> tags:

cd $CATALINA_HOME/conf
vi tomcat-users.xml

Then, add the code in Listing 21 to the tomcat-users.xml file to grant access to Tomcat Web Application Manager by adding users and roles.

	
<tomcat-users>
<role rolename="admin"/>
<user username="admin" password="s3cur3" roles="admin"/></user>
</tomcat-users>

You must restart Tomcat to access the Tomcat Web Server Administration tool using the http://localhost:8080/admin URL. To restart the server, use the code in Listing 22.

	
cd $CATALINA_HOME/bin
./shutdown.sh 
./startup.sh ;tail -f ../logs/catalina.out

You should see something similar to this when you tail your catalina.out log file:

May 15, 2008 4:08:12 PM org.apache.jk.server.JkMain start
INFO: Jk running ID=0 time=0/74  config=null
May 15, 2008 4:08:12 PM org.apache.catalina.startup.Catalina start
INFO: Server startup in 6271 ms

Type the URL http://localhost:8080/admin in your Web browser's address bar. If your changes were successful, you'll see the page shown in Figure 3..

Back to top

Run the server under a non-root user ID

If you have a true multi-user system with many people logging in and out of your Web server, consider running your Tomcat installation under a Tomcat user that has specific access to your directories and processes. Also, if you have multiple software installations on that server, such as a database installation or a down-version or alternative Web or application server, you need a way to differentiate them. The best way to administer them using a specific ID for each installation. It's definitely good practice in a production environment and something you will typically find when you have segregated administration and deployment teams administering the same server. The administrators are typically given greater control and grant only certain accesses to deployment teams.

First, you must create your user ID and group. If you worked through the previous Tomcat tutorial, you will already have done this. Simply run the following commands:

• To create a group for Tomcat to run under, use the following code:

  /usr/sbin/groupadd -g {specific gid. Leave this blank, and the operating system will assign you a gid} {group name} ie. /usr/sbin/groupadd -g 10004 tomcatgroup

  
  
• To create a unique user for Tomcat to run under, use the following code:

  /usr/sbin/useradd -d {user home directory} -g {user primary group} -u {specific UID. You can leave this blank, and the operating system will assign you a UID.) -s {default shell path for this user} -c "{Description of the user}" {username} ie. /usr/sbin/useradd -d /export/home/tomcat -g tomcatgroup -u 10010 -s /bin/ksh -c "Main Tomcat Administrative User" tomcat

  
  

To change ownership of all $CATALINA_HOME directories to the Tomcat user and Tomcat group, type:

Chown -R tomcat:tomcat $CATALINA_HOME

Note: The -R option specifies a fully recursive change of ownership.

Next, start Tomcat using the jsvc daemon but with the -user option specified. You can do this by directly editing the $CATALINA_HOME/bin/jsvc/native/tomcat.sh script and changing the following parameter to your ID:

TOMCAT_USER=tomcat

Note: You'll find the above variable grouped with other variables such as $JAVA_HOME, $CATALINA_HOME just under the comment section of the script. Use vi or your editor of choice to change that.

You can also make this change by running the jsvc service manually while specifying the -user option:

Cd $DAEMON_HOME (where this is the location of your jsvc-src dir)
Bash#./jsvc -user tomcat -cp ./bin/bootstrap.jar \
-outfile ./logs/catalina.out -errfile ./logs/catalina.err \
        org.apache.catalina.startup.Bootstrap

This is assuming that JAVA_HOME and CATALINA_HOME are already specified. If not, you can add those directories to the above manual startup:

Bash#./jsvc -user tomcat -home /usr/jdk/instances/jdk1.5.0 \
-Dcatalina.home=/opt/apache-tomcat-6.0.16 \
-cp ./bin/bootstrap.jar -outfile ./logs/catalina.out \
-errfile ./logs/catalina.err \
        org.apache.catalina.startup.Bootstrap

Both methods technically start as root and change the user running this process to the user specified.

Back to top

Determining whether Tomcat is running

Tomcat has no status. So, to determine whether Tomcat is running, you must type:

ps -ef |grep java |grep server

You should see output similar to Listing 23 if you started as the root user with the default startup.sh script.

	
bash-3.00# ps -ef | grep java|grep server
noaccess   720     1   0 16:35:05 ?           5:06 /usr/java/bin/java -server 
-Xmx128m -XX:+BackgroundCompilation -XX:PermSize=32m

If you started the server using the jsvc daemon manually or Tomcat started upon server startup through the tomcat.sh script under $CATALINA_HOME/bin/jsvc/native/tomcat.sh, you can check to see if the server is running by checking for the existence of the Tomcat .pid file:

Ls -l var/run/tomcat.pid

or by viewing or use Cat on the pid file:

Cat /var/run/tomcat.pid

Check for the .pid file, then use grep on the pid process to see if it's running:

Ps -ef | grep {pid}

Back to top

Altering the JVM settings

This tip is in particular reference to JVM-allowable memory. The main reason why you would need to raise this value is if you have a large application, plan to use the Tomcat server in a production environment, or plan to run certain controlled load tests against your application with various JVM memory levels to see where memory heap exhaustion takes place. Usually, when running controlled tests, you will set the minimum and maximum heap at the same size until you reach your peak load and gain your desired data. Then, you can change the settings back to normal.

The Tomcat default is set to a maximum of 128MB. To see the value, the line server -Xmx128m appears when you use the status check command. If you're running multiple JVMs, remember not to set the accumulate total of the maximum JVM heap sizes greater than the available memory on your server.

In this case, you can edit the tomcat.sh script or run the jsvc daemon manually with the following options included in the startup line:

server -Xms128m -Xmx512m

Use the command shown in Listing 24 to configure your JVM settings.

	
#./jsvc -user tomcat -home /usr/jdk/instances/jdk1.5.0 \
-Dcatalina.home=/opt/apache-tomcat-6.0.16 \
-cp ./bin/bootstrap.jar -outfile ./logs/catalina.out \
-errfile ./logs/catalina.err \
-server -Xms128m -Xmx512m \
        org.apache.catalina.startup.Bootstrap

Typical advanced application server best practices state that it's best to set the minimum JVM heap size to one-quarter of the maximum. Try to avoid changing the memory settings arbitrarily, especially when trying to fix a problem that likely isn't related to the JVM memory in the first place. Increasing the maximum heap size has pros and cons: It's important to understand both.

When your JVM is tuned correctly, 99% of the time, garbage collection (GC) will take less than one second. The remainder will only take a few seconds. Rarely should a GC process take more than 10 seconds.

7 of 10 | Previous | Next

Comments

Back to top

Table of contents

• Before you start
• What you need to know
• Application deployment
• Database connections
• Security
• Expandability
• Additional administration tips
• Summary
• Resources
• About the author

---

7 of 10 | Previous | Next

Next steps from IBM

Rational Application Developer features provide the comprehensive Integrated Development Environment (IDE) used to develop J2EE applications requiring Servlets and JavaServer Pages (JSPs).

---

• Try: Try the free Rational Application Developer, which helps developers quickly design, develop, test, analyze, and deploy high-quality Java, Javaserver pages, and J2EE applications.
• Article: Learn how you can deliver accurate, higher-quality J2EE apps with Rational Application Developer, open source JUnit and JUnitEE test frameworks.
• Tutorial: Build a Facebook application using PHP, the Spring framework, and J2EE.
• Demo: This demo shows how to use the new Java EE 5 Java Persistence API (JPA) framework.
• Buy: Rational Application Developer

Dig deeper into AIX and UNIX on developerWorks

IBM SmartCloud trial. No charge.

Unleash the power of hybrid cloud computing today!

---

Public and private solutions in one trial.

Special offers