Apache Tomcat

Product Description

Apache Tomcat is an Application Server, otherwise known as a Web Container, developed at the Apache Software Foundation (ASF).

Tomcat implements the Java Servlet and the JavaServer Pages (JSP) specifications from Sun Microsystems, providing an environment for Java code to run in cooperation with a web server. In addition, it adds tools for configuration and management, which can also be configured by editing configuration files that are typically .xml formatted, and includes its internal HTTP server.

The pattern also identifies the Pivotal tc Server, which contains all of the vanilla Tomcat. Pivotal tc Server also has a few optional extensions designed to make it easier to deploy and maintain.

An Extended Discovery pattern that models Apache Tomcat web applications is available by using a context.xml file.

Software Pattern Summary

Platforms Supported by the Pattern

The current pattern identifies an instance of Apache Tomcat Application Server or Pivotal tc Server running on both Unix/Linux and Microsoft Windows platforms.

Identification

Software Instance Triggers

The pattern usually triggers on a java, jsvc or jsvc.exec process with "org.apache.catalina.startup.(?:Bootstrap|Tomcat|Main)" in the arguments. Rarely it also triggers on a tomcat[^ \\]*?.exe process, a jk_nt_service.exe process, or, for some embedded systems, binary could have custom process name, but it must have "//RS//" (Run Service) in its arguments. Also pattern will trigger on tomcat process with arguments that matches regex '\-Dcatalina\.home=(?:.+\bpivotal\-tc\-server\\runtimes\\tomcat|.+/rsso/tomcat)'.

If any of the following conditions are true, the pattern stops immediately:

Software Instance type attributes

The patterns in this module will set the following value for the type attribute on a Software Instance:

The patterns will also create the following additional nodes:

Simple Identification Mappings

The following components or processes are identified using the combination of pattern definitions and simple identity mappings, which map other known (but deemed less critical in terms of application modeling) processes. For further details on the processes treated as primes, see paragraph Application Model Produced by Software Pattern.

regex'(^|/)jsvc', regex '^.*org\.apache\.catalina\.startup\.Bootstrap'

regex'(^|/)jsvc', regex '^.*org\.apache\.tomcat\.startup\.Tomcat'

regex'(^|/)jsvc', regex '^.*org\.apache\.tomcat\.startup\.Main'

regex'\-Dcatalina\.home=.+?\bpivotal\-tc\-server\\runtimes\\tomcat'

Versioning

Version information for the product is currently collected using one of three possible methods. We execute the methods in order based on their accuracy, depth, and reliability.

Common Functionality

Obtaining the arguments

The first step for both active versioning techniques is an identification of the base installation directory. This is obtained by parsing the JAVA arguments. On UNIX, these arguments can be obtained by looking at the trigger process arguments.

For Windows, the method of obtaining the arguments is more complicated, and initially, the pattern will obtain the root directory of the trigger process.

This is obtained by applying the following regular expression of the trigger process command-line:

(?i)(^\w:.+)\\bin\\tomcat[^ \\]*?\.exe$

If this fails, the pattern searches for the related Windows service and parses the cmd line attribute using the following regular expression:

(?i)^"?(\w:\\.*)\\bin\\tomcat[^ \\]*?\.exe

Furthermore, on Windows, the arguments of the Tomcat process are not included in the trigger process and must be obtained from the registry.

As there may be more than one installation, the pattern looks in the registry for all subdirectories of:

• HKEY_LOCAL_MACHINE\\SOFTWARE\\Apache Software Foundation\\Procrun 2.0

If it can find a registry key of the form:

• HKEY_LOCAL_MACHINE\\SOFTWARE\\Apache Software Foundation\\Procrun 2.0\\<directory name>\\Paramaters\\Log\\Path

and the path parsed using the regular expression:

(?i)(^\w\:.+)\\logs

matches the root directory, then the pattern will take the java arguments to be in the following registry key:

• HKEY_LOCAL_MACHINE\\SOFTWARE\\Apache Software Foundation\\Procrun 2.0\\<directory name>\\Paramaters\\Java\\Options

• HKEY_LOCAL_MACHINE\\SOFTWARE\\Apache Software Foundation\\Procrun 2.0\\<directory name>\\Paramaters\\Java\\Classpath

• HKEY_LOCAL_MACHINE\\SOFTWARE\\Apache Software Foundation\\Procrun 2.0\\<directory name>\\Paramaters\\Java\\Jvm

Active Versioning

The pattern attempts to get JAVA_HOME from the path to the trigger process. If that fails it checks the JAVA_HOME environment variable

The pattern then attempts to find version information from one of two commands:

(UNIX)

• JAVA_HOME="%java_home%" %catalina_home%/bin/catalina.sh version
• set "CATALINA_HOME=%catalina_home%" && set "JAVA_HOME=%java_home%" && "%catalina_home%\\bin\\catalina.bat" version

(Windows)

• %java_home%/bin/java -cp %catalina_home%/lib/catalina.jar org.apache.catalina.util.ServerInfo
• %java_home%\\bin\\java.exe -cp %catalina_home%\\lib\\catalina.jar org.apache.catalina.util.ServerInfo

• Server number:\s*(\d+(?:\.\d+)*)

• [vV]ersion:\s*Apache Tomcat/(\d+(?:\.\d+)*)

This approach usually returns a version between three to four levels of depth.

File Versioning

The file version method attempts to access the release notes of the identified Tomcat process.

If we have been able to extract the catalina_home directory from the process arguments, then we use the value found in the argument as the base directory.

If catalina_home were not obtained, the pattern would use catalina_base as the base directory. From there, the pattern attempts to open the RELEASE-NOTES.txt (or RELEASE-NOTES) file.

Once opened, the file contents are parsed against a regular expression to extract the version information.

(?i)Apache Tomcat Version\s+(\d+(?:\.\d+)*)

We have found that this approach provides a version number of up to 4 levels of depth.

Path Versioning

If the pattern is unable to acquire the version by using an active versioning method, it will attempt to parse the process's command line.

First, the pattern concatenates the process's command into a single value. This allows it to achieve a greater level of success as the process cmd may not contain a path.

The following regular expression is then applied to this path: (?i)tomcat[-/_ ]?(\d+(?:[\-\.]\d+)+)

If the version is not obtained, an alternative regular expression is tried: (?i)tomcat(\d+(?:[\-\.]\d+)*)

Path versioning usually returns a version between 2 to 4 levels of depth.

We normalize the path version by using the following rules:

• Version 85 and similar is normalized to 8.5
• Version 101 and similar is normalized to 10.1
• Version 10 is normalized to 10 (no change).

Package Versioning

If the pattern is unable to extract the version information from either the Active Command or Path regex, then it will attempt to query the package management system to identify a specific version.

The package query uses a set of regular expressions to be checked for.

Regex List

• (?i)tomcat$
• (?i)tomcat\d+$

This usually returns a version between 3 to 4 levels of depth.

Though this method is often successful, it is not specific to an installation, and this may result in the version information for a Tomcat installation being inaccurate if there are multiple installations on the host.

Alternative Versioning Approach

Registry Versioning

From version 5.0 onwards, Apache Tomcat on Windows has had information stored in the Registry. We have identified the following registry keys that return the information:

Registry Keys

• HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Tomcat\5.0\Version
• HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Tomcat\5.5\version
• HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Tomcat\6.0\version

Risks

1. The product version obtained by reading the registry is only used if no other method succeeds. i.e., if a matcher implements multiple versioning methods, and more than one succeeds, Registry versioning has the lowest precedence and may therefore be ignored.
2. Product version can be obtained through Registry only for Tomcat 5.0 and above - thus if path regex versioning is wholly replaced with Registry-based method, while the depth of versions obtained is likely to increase, the overall coverage may decrease.
3. Tomcat is often bundled with other applications. This may lead to more than one instance of Tomcat being installed and running on a host. At present, there is no way to directly link the detected process with a value obtained from the Registry. This may lead to false positives.

It is our conclusion that this versioning approach could be used but only once an understanding of the customer environment exists and where the risks listed above have been evaluated and found below.

Due to these risks, we have not included it in the versioning techniques in the pattern. In the future, it would be a consideration.

SoftwareInstance versioning

TomcatCluster pattern uses SoftwareInstance versioning, meaning it takes the version from the Apache Tomcat instances it had triggered off.

File versioning for Windows OS

Windows class systems specific method. In case after all previous versions obtain methods we haven't success or obtained an undetailed version(e.g. '7' when it is '7.1.1.1') on Windows OS, we use parsing of log files.

Log files are kept at '%catalina_dir%\logs' under names 'catalina*.log', where the wildcard is the date of the log file before rolling up. Considering log files can be heavy-sized, pattern parses only the first 10 lines of each file that can contain the version. Using PowerShell command:

powershell "Get-ChildItem -Path '%log_dir%\\catalina*.log' -File | Get-Content -First 10 | Select-String -Pattern '(?i)Apache\sTomcat/\d+(?:\.\d+)*' -Encoding utf8

After getting the output, we match the version of Apache against the following regular expression:

(?i)Apache\sTomcat/(\d+(?:\.\d+)+)

Future Considerations

An additional Windows versioning technique that can be used is the Registry query. Once we can execute this query in a more controlled manner, then it will be added to the pattern.

Additional Attributes

Catalina Base and Catalina Home

The pattern first tries to obtain catalina_base and catalina_home from the relevant arguments (-Dcatalina.base and -Dcatalina.home) in the trigger process.

If that fails, it assumes that catalina_base and catalina_home are the same as the path to the triggering tomcat.exe process.

If that fails, it obtains catalina_home from the EM_HOME argument in the trigger process. If -DEM_HOME points to /opt/foo, then this directory would be checked for the existence of file /conf/server.xml, in case it is found - both catalina_home and catalina_base are referred to /opt/foo/etc/emweb, else we will check nested directory /opt/foo/etc/emweb/tomcat and point to it if /conf/server.xml exists in mentioned directory.

Listening Ports

We obtain listening_ports from the <catalina_base>/conf/server.xml file. We part the file with these xpaths:

• /Server/@port
• /Server/Service/Connector/@port

We also check for port information in the -Dcom.sun.management.jmxremote.port argument of the triggered process.

Application Model Produced by Software Pattern

Product Architecture

Tomcat Application Server is a container for other applications to be run in. It allows the running of J2EE applications in a controlled web-based environment.

As such, it sits on top of a web server and processes requests from the user to the Java application that is being hosted. From an external view, there is no visibility of what application Tomcat is hosting, where this application resides, or what its purpose is. All you see is that Tomcat running on a host.

There is no indication that this product branches, has multiple threads, or creates any child processes.

Tomcat Cluster architecture

Tomcat Cluster doesn't do Application replication between the member nodes. Session replication and load balancing may be achieved by using external tools only.

The cluster configuration is stored in server.xml file of the Tomcat instance. There multicast IP address and port are mentioned. This cluster socket is used as cluster ID by ADDM. All member's list can't be obtained, unfortunately, therefore the cluster scale is always unknown.

To extract the cluster_multicast_socket attribute, the Tomcat pattern deploys the following xpath expressions:

The combination of <IP address>:<Port> is used as a cluster ID by TomcatCluster pattern. The cluster key is combined with a cluster-ID and si_type. This pattern also sets the Containment link with all Tomcat instances which have the same cluster_multicast_socket attribute.

Tomcat cluster BMC Discovery model

The following image displays the Apache Tomcat Cluster SoftwareCluster:

Tomcat Cluster visualization

JMX attributes

Various JMX attributes are obtained by the pattern. This is only attempted for Atrium Discovery version 8.1 and above. The attributes are obtained by parsing the Obtaining the arguments using the following regular expressions:

-Dcom\.sun\.management\.jmxremote

-Dcom.sun.management.jmxremote.port=(\d+)

-Dcom\.sun\.management\.jmxremote\.ssl=(\w+)

-Dcom\.sun\.management\.jmxremote\.authenticate=(\w+)

-Dcom\.sun\.management\.jmxremote\.ssl\.need\.client\.auth=(\w+)

Software Pattern Model

The pattern is triggered on any of the many forms that Tomcat can be run in, either on one of the specific binaries or java/class combinations. Once triggered, we are sure that the process is a proper running Tomcat installation.

If the following argument is present in the process arguments: com.springsource.tcserver an instance of Pivotal tc Server is created.

SI Depth

If Catalina base has been discovered, an instance-based Software Instance is created with a key based on Catalina base, type, and host key.

If Catalina home has been discovered (and catalina_base hasn't), a grouped Software Instance is created with a key based on Catalina home, type, and host key.

In all other cases, a grouped Software Instance is created with a key based on trigger process, JAVA classpath, type, and host key.

Subject Matter Expertise

We have received SME input with regard to the Active Versioning technique. It identified the Release Notes text file containing version information in the installation directory of the product.

Any further SME input would be welcome on any other potential approaches to improve Tomcat versioning coverage and depth or with regards to identifying the applications running on a particular installation.

Testing

Testing to ensure that the processes related to Apache Tomcat Server have been correctly identified are performed using record data as well as the live discovery of hosts running Solaris, Linux, and Windows operating systems.

Both live discovery and record data contained enough data to extract the version information using the path regular expression methods.

Information Sources

Tomcat Wikipedia was used to gather information on the product and produced a lot of the product descriptions. It was also used as the source for some of our known versions.

The official Apache Tomcat homepage was used to identify some versioning techniques and complete the information we had on known versions.