Tomcat – Frequently Asked Questions
Developer Groups and Tomcat Instances
What is a developer group? What is a Tomcat “instance”?
Tomcat has the ability to run multiple “instances” from a single installation. Each instance is running in its own Java Virtual Machine (JVM), is independently configured, and can be started and stopped without affecting other instances. Web Services has chosen to use these instances to separate various Tomcat developers into groups to minimize the impact that each group will have on the others. For example, the ELT developer group can start and stop, configure logging options, and request other customized configuration from Web Services without impacting the SMAS developer group. Developer groups are how we match developers with Tomcat instances. These are Unix groups and are used to control file permissions, access to sudo commands, etc. Current Tomcat instances and developer groups are:
Tomcat Instance |
Unix Group | Developer Group |
---|---|---|
1.smas | tc-smas | Space Management and Academic Scheduling |
2.elt | tc-elt | Enterprise Learning Technologies |
3.cem | tc-cem | Construction Engineering Management |
The Tomcat Environment
Why not a newer version of Tomcat?
Honestly, we would love to provide Tomcat v9 but we are constrained by what is available from our Linux vendor, unless we chose to download and build from sources. The problem with doing that is that we then have to monitor all of the security patches, bug fixes, and other updates and manually update the systems. We are simply not staffed to be able to support that effort so must rely on our vendor.
Where should I point CATALINA_HOME?
CATALINA_HOME is the Tomcat environment variable that defines where the files are that Tomcat shares across all instances. Of the standard Tomcat directories, lib (for common code) is relative to CATALINA_HOME. On Web Services Tomcat systems, CATALINA_HOME should be /usr/share/tomcat.
Where should I point CATALINA_BASE?
To allow multiple instances of Tomcat to have different configurations, logging, applications, etc, Tomcat uses the environment variable CATALINA_BASE to indicate the directory where the instance-specific files are stored. The standard Tomcat directories conf, lib (shared), logs, temp, webapps, and work are relative to CATALINA_BASE. All files in these directories are private to your group’s instance of Tomcat. On Web Services Tomcat systems, CATALINA_BASE should be /opt/tomcat7-instance/<INSTANCE_NAME>, where INSTANCE_NAME is the Tomcat instance from the table above. For example, the ELT developers would use CATALINA_BASE set to /opt/tomcat7-instance/2.elt.
Why don’t I see a “common” or “server” sub-directory?
The common and server sub-directories were from versions of Tomcat up to 5.5 and were where Tomcat looked for files shared across all instances. These directories were found in CATALINA_HOME. In Tomcat 6 and following, they were combined into a single lib directory (also found in CATALINA_HOME). See the questions above.
Where is catalina.out?
Due to the way that Oracle Enterprise Linux v7 starts Tomcat (using systemd), the output normally captured in catalina.out is, instead, captured by systemd and is not generally available in file format. Most of the output of interest can be found in the various other log files that Tomcat maintains. If you specifically need information from what would have been in catalina.out, please contact Web Services with the instance name and time frame you need. Please note that this information rolls over so timely requests are necessary.
The Java Environment
Why not a newer version of Java?
We had planned to build these systems with OpenJDK v11 but we found that there were significant problems getting Tomcat v7, as provided to us, to run on that version of Java. When and if this situation changes, we can explore updating individual Tomcat instances if desired.
What is the Java Security Manager?
Java is known as a secure language for development because the JVM carefully controls what an application can do to the local host system. But as normally configured, the JVM makes no effort to control what an application can do to the JVM or to other applications running there. For example, nothing prevents an application from calling “system.exit(1)” and shutting down the entire JVM. The Java Security Manager is a standard part of Java that allows us to define policies about what operations code is allowed to perform on a fairly fine granularity. Because of the shared nature of our Tomcat environment, we give the owner of a Tomcat instance the option to enable the Java Security Manager and we will work with developers to enable appropriate privileges for their code.
How does the Java Security Manager work?
The Java Security Manager is configured with a set of policies that define permissions for different code bases. Code bases are individual class or JAR files. Permissions have been defined as part of the Java standard for such activities as reading or writing system properties, manipulating files, and for certain critical functions (such as system.exit()). Before performing one of these actions, a check is made to see if the current code base has the required permission to perform the operation. If it does, the operation continues normally. If not, the Java Security Manager throws a security exception, which typically will halt the application.
I want to use Java package “X”. Will you install it?
Our experience has been that it is best if Tomcat applications are as self-contained as possible. So other than database drivers (which we provide for all ITIS-supported database platforms), it is best if your application contains all the necessary jar files for any packages you want to use. If this is not possible for some reason, please contact Web Services with as much information about the package as you can and we will work with you.
SSL
Is SSL available? How do I make sure that my application uses it?
SSL is available on all three Tomcat tiers and we unconditionally redirect to it. If you wish to go further and ensure that your application uses SSL, add a security constraint to your application’s web.xml file after your servlet-mappings but before closing your web-app as follows:
<security-constraint> <web-resource-collection> <web-resource-name>Protected Content</web-resource-name> <url-pattern>/*</url-pattern> </web-resource-collection> <user-data-constraint> <transport-guarantee> CONFIDENTIAL </transport-guarantee> </user-data-constraint> </security-constraint>
Adjust or add url-pattern elements as needed to define where in your application SSL must be applied.