Tomcat

Replace the n with your installed version (8, 9, 10).

Tomcat can also be controlled directly using upstream scripts:

/usr/share/tomcat/bin/{startup.sh,shutdown.sh,..}

This can be useful to debug applications or even debug Tomcat, but do not use it to start Tomcat for the first time as doing so can set some permissions wrongly and stop web apps from working. In order to be able to use these scripts, some further configuration may be needed. Be aware that using these scripts prevents the jsvc security advantage described above.

Probably the easiest way is to use the manager webapp http://localhost:8080/manager/html. Use the username/password you defined as in tomcat-users.xml. Once logged in, you can see five already deployed web applications. Add yours through the "Deploy" area and then stop/start/undeploy it with the "Applications" area.

One can also just copy the WAR file of the application to directory . For that later, be sure that the option is still set for the right host as shown here:

/etc/tomcat''n''/server.xml

...
<Host name="localhost"  appBase="webapps"
      unpackWARs="true" '''autoDeploy="true"'''>
...

If you want to keep your project outside the webapps folder, this is possible by creating a . Go to and create your context. A context is a simple xml file which specifies where tomcat should look for the project. The basic format of the file is:

/etc/tomcat''n''/Catalina/localhost/whatShouldFollowLocalhost.xml

<Context path="/whatSholdFollwLocalhost" docBase="/where/your/project/is/" reloadable="true"/>

A working example is as follows. This assumes that the project is hosted somewhere in the users /home-folder.

The files can now be hosted in . To see the project in your webbrowser, go to http://localhost:8080/myProject. If tomcat is unable to load the files, it might be an issue with permissions. Making executable should fix the issue.

As said in the introduction, Tomcat 10 does not deprecate Tomcat 9, Tomcat 9 does not deprecate Tomcat 8 and so on. They all are implementations of Servlet/JSP standards. Hence you must first determine which version of Tomcat you need depending on the versions of Servlet/JSP your application uses. If you need to migrate, the official website gives instructions on how to handle such a process.

Apart from installing the desired JRE/JDK, the only requirement is to set the TOMCAT_JAVA_HOME variable with a drop-in file:

This page gives the bare minimum to get your first web application to run on Tomcat. It is not intended to be the definitive guide to administering Tomcat (it is a job of its own). The official Tomcat website will provide all necessary official matter. One could also refer to this O'Reilly page and this unidata one. Still, here are some security tips to get you started:

• Keep your Tomcat installation up to date to get the latest fixes to security issues
• Remove unwanted default applications such as , , default home page ("_" in the webapp). This prevents potential security holes to be exploited. Use the for that.

For more security, you could even remove the host-manager and manager web applications. Keep in mind that the later is useful to deploy web applications.

• Disable the WAR auto-deploy option. This would prevent someone who gained restricted access to the server to copy a WAR into the directory to get it running. Edit server.xml and set the to :

/etc/tomcat''n''/server.xml

...
<Host name="localhost"  appBase="webapps"
      unpackWARs="true" '''autoDeploy="false"'''>
...

• Anonymize Tomcat's default error page to prevent potential attackers to retrieve Tomcat's version. To see what Tomcat says by default, just visit an nonexistent page such as http://localhost:8080/I_dont_exist. You get a 404 error page with Tomcat's version at the bottom.

To anonymize this, edit/open the following JAR (Editors like can edit zips directly)

/usr/share/tomcatn/lib/catalina.jar

And edit the following file:

• Disable unused connectors in server.xml
• Keep restricted access to . Only user and/or should be able to read and write this.
• Keep usage. Do not use upstream startup scripts unless particular reason as explained in the security note above.
• Use strong different passwords for each user in tomcat-users.xml, give roles to users who really need them and even disable usernames/roles you do not use/need.

One can even crypt tomcat-users.xml passwords using the following upstream script:

/usr/share/tomcatn/bin/digest.sh -a SHA NEW_PASSWORD

This will output something like:

NEW_PASSWORD:b7bbb48a5b7749f1f908eb3c0c021200c72738ce

Paste the hashed part in place of the clear password in tomcat-users.xml and add the following to server.xml:

Note that this may not be relevant because only root and/or tomcat is supposed to have read/write access to that file. If an intruder manages to gain root access, they would not need such passwords to mess with your applications/data anyway. Be sure to keep restricted read and write access to that file, and always know what you are deploying!

First, check for any syntax error. If everything is fine and is correctly running, run as root to check the logs for any exception thrown (see #Logging). If you read anything like , this is due to some other service listening on the same port. For instance, it is possible that Apache HTTP Server and Tomcat are listening on the same port (if for example you have Apache running on port 8080 with Nginx serving it as a proxy on port 80). If this is the case, edit the file and change the Connector port to something else under :

/etc/tomcat''n''/server.xml

<?xml version='1.0' encoding='utf-8'?>
...
...
<!-- Change port from 8080 to something else, like 8090 -->
<Service name="Catalina">
    <Connector executor="tomcatThreadPool"
                 port="8090" protocol="HTTP/1.1"
                 connectionTimeout="20000"
                 redirectPort="8443" />
...
...
</Service>

Finally, restart and services.

If you have no solution and you are in a VM, it can help to delete and create it again (cf. Solution: FUTEX_WAIT hangs Java on Linux / Ubuntu in vmware or virtual box):

# rm /dev/random 
# mknod -m 644 /dev/random c 1 9

Or another solution to keep it even after a reboot is to modify (for example) to point to /