How To Install Apache Tomcat 7 On CentOS 6

— ny_wk

To install Apache Tomcat on CentOS, install a current JDK, download and extract the Tomcat distribution into /opt, create a dedicated unprivileged tomcat user, run Tomcat as a systemd service, configure the Manager users, and open port 8080 on the firewall. This walkthrough does exactly that, end to end, on a modern, supported Linux.

A quick word on versions before you begin

Older guides target Tomcat 7 on CentOS 6. Both are long past end of life and should not be used for anything you care about. Tomcat 7 reached end of life in March 2021, and CentOS 6 reached end of life in November 2020. The CentOS project itself pivoted to CentOS Stream, and CentOS 8 was discontinued at the end of 2021.

• Operating system: use a current, supported RHEL-family distribution — AlmaLinux 9, Rocky Linux 9, or RHEL 9. The steps below also work on CentOS Stream 9. The phrase “install Apache Tomcat on CentOS” still describes the workflow precisely, since these distributions are binary-compatible rebuilds of RHEL.
• Tomcat version: install a supported release — Tomcat 9, 10, or 11. Tomcat 9 implements the Java EE 8 / javax.* APIs, while Tomcat 10 and 11 moved to Jakarta EE with the jakarta.* namespace. If you are migrating an old app built for Tomcat 7, Tomcat 9 is usually the smoothest landing spot.
• Java: a current JDK such as OpenJDK 11 or OpenJDK 17. Tomcat 11 requires Java 17 as a minimum; Tomcat 9 and 10 run happily on Java 11 or 17.

The instructions that follow use Tomcat 9 with OpenJDK 17 on AlmaLinux/Rocky/RHEL 9. Substitute the exact Tomcat version number you download where you see it.

Prerequisites

• A running, updated server (AlmaLinux 9, Rocky Linux 9, RHEL 9, or CentOS Stream 9).
• root access, or a user with sudo privileges. Every command below is shown with sudo; drop it if you are already root.
• A working internet connection to download packages and the Tomcat archive.
• Basic familiarity with the terminal and a text editor (vi, vim, or nano).

Start by refreshing the package index so you pull current builds:

1. sudo dnf update -y

On these distributions the package manager is dnf (the modern successor to yum); the legacy yum command still works as an alias.

Step 1 — Install Java (OpenJDK)

Tomcat is a Java servlet container, so a Java Development Kit must be present before anything else. The cleanest approach on modern CentOS-family systems is the distribution's own OpenJDK package — no manual Oracle download, no .bin installer, and security updates arrive through dnf automatically.

1. Install OpenJDK 17 (the headless package is enough for a server with no GUI):
   sudo dnf install -y java-17-openjdk java-17-openjdk-devel
2. Confirm the install and note the version:
   java -version

You should see output reporting openjdk version "17.…". If you prefer Java 11, swap 17 for 11 in the package names. Because OpenJDK is managed by the system, you do not need to hand-edit symlinks like /usr/bin/java — the package's alternatives entries handle that for you. If multiple JDKs are installed and you need to choose the default, run sudo alternatives --config java.

Find your real JAVA_HOME. You will need the absolute path to the JDK for the service file. Resolve it reliably with:

1. readlink -f $(which java)

That prints something like /usr/lib/jvm/java-17-openjdk-17.0.x.x-x.el9.x86_64/bin/java. JAVA_HOME is that path minus the trailing /bin/java — for example /usr/lib/jvm/java-17-openjdk-17.0.x.x-x.el9.x86_64. Keep it handy.

Step 2 — Create a dedicated Tomcat user

Never run Tomcat as root. A web-facing Java process running as root is a serious security risk: any remote-code-execution flaw would hand an attacker the whole machine. The standard practice is a dedicated, unprivileged system account that owns the install and runs the service.

1. Create a system group:
   sudo groupadd --system tomcat
2. Create a no-login system user whose home is the install directory:
   sudo useradd -M -s /sbin/nologin -d /opt/tomcat -g tomcat tomcat

Here -M skips creating a separate home directory, -s /sbin/nologin blocks interactive logins, and -d /opt/tomcat points the account at where Tomcat will live. This account has no shell and no password, so it cannot be used to log in — exactly what you want.

Step 3 — Download and extract Apache Tomcat

Always download Tomcat from the official Apache distribution site and verify the version number against the live releases at tomcat.apache.org. Version numbers move, so check the current 9.0.x build rather than copying an old one blindly.

1. Move into a temporary location:
   cd /tmp
2. Download the binary tar.gz (replace the version with the current 9.0.x release):
   curl -O https://dlcdn.apache.org/tomcat/tomcat-9/v9.0.XX/bin/apache-tomcat-9.0.XX.tar.gz
3. Verify the download before trusting it. Grab the checksum and compare:
   curl -O https://dlcdn.apache.org/tomcat/tomcat-9/v9.0.XX/bin/apache-tomcat-9.0.XX.tar.gz.sha512
sha512sum -c apache-tomcat-9.0.XX.tar.gz.sha512
   It should print OK.
4. Create the install directory and extract straight into it, stripping the top folder:
   sudo mkdir -p /opt/tomcat
sudo tar -xzf apache-tomcat-9.0.XX.tar.gz -C /opt/tomcat --strip-components=1

Using /opt/tomcat as a stable, version-agnostic path is deliberate. When you upgrade later, you point the same path at a new extraction (or use a symlink), and your service file never has to change. The --strip-components=1 flag drops the apache-tomcat-9.0.XX wrapper directory so files land directly under /opt/tomcat.

Set correct ownership and permissions

The tomcat user must be able to read the installation and write to the directories Tomcat needs at runtime — logs, temp, work, conf, and webapps.

1. Give the group ownership of the tree:
   sudo chgrp -R tomcat /opt/tomcat
2. Make the conf directory group-readable and its contents executable as needed:
   sudo chmod -R g+r /opt/tomcat/conf
sudo chmod g+x /opt/tomcat/conf
3. Hand the runtime-writable directories to the tomcat user:
   sudo chown -R tomcat /opt/tomcat/webapps /opt/tomcat/work /opt/tomcat/temp /opt/tomcat/logs

Step 4 — Run Tomcat as a systemd service

Modern CentOS-family systems use systemd, not the old /etc/init.d SysV scripts. A systemd unit gives you clean start/stop/restart, automatic restart on failure, boot-time startup, and proper logging through journalctl. This replaces the hand-rolled service tomcat init script entirely.

Create the unit file at /etc/systemd/system/tomcat.service:

1. Open the file:
   sudo vi /etc/systemd/system/tomcat.service
2. Paste the following, replacing JAVA_HOME with the path you found in Step 1:

[Unit]
Description=Apache Tomcat 9 Servlet Container
After=network.target
 
[Service]
Type=forking
User=tomcat
Group=tomcat
Environment="JAVA_HOME=/usr/lib/jvm/java-17-openjdk"
Environment="CATALINA_HOME=/opt/tomcat"
Environment="CATALINA_BASE=/opt/tomcat"
Environment="CATALINA_PID=/opt/tomcat/temp/tomcat.pid"
Environment="CATALINA_OPTS=-Xms512M -Xmx1024M -server -XX:+UseG1GC"
ExecStart=/opt/tomcat/bin/startup.sh
ExecStop=/opt/tomcat/bin/shutdown.sh
Restart=on-failure
 
[Install]
WantedBy=multi-user.target

A few notes on what these directives do:

• Type=forking matches Tomcat's startup.sh, which launches the JVM and returns. The CATALINA_PID setting lets systemd track the real process.
• JAVA_HOME can usually point at the convenient symlink /usr/lib/jvm/java-17-openjdk; if that symlink does not exist on your system, use the full versioned path from Step 1.
• CATALINA_OPTS sets JVM heap sizing — adjust -Xmx to your server's RAM. This is where you tune memory, not inside catalina.sh.
• Restart=on-failure brings Tomcat back automatically if it crashes.

Now load, start, and enable the service:

1. Reload systemd so it sees the new unit:
   sudo systemctl daemon-reload
2. Start Tomcat:
   sudo systemctl start tomcat
3. Confirm it is running:
   sudo systemctl status tomcat
4. Enable it to launch at boot:
   sudo systemctl enable tomcat

The status output should show active (running). If it does not, jump to the pitfalls section below and check the logs with sudo journalctl -u tomcat and sudo cat /opt/tomcat/logs/catalina.out.

Step 5 — Configure Manager and Host Manager users

Tomcat ships two web admin apps — the Manager (deploy and manage apps) and the Host Manager (manage virtual hosts). They are locked down by default and ship with no usable accounts, so you must add roles and a user before you can log in.

Edit the users file:

1. Open tomcat-users.xml:
   sudo vi /opt/tomcat/conf/tomcat-users.xml
2. Inside the <tomcat-users> element, add roles and an account (choose a strong password):

<role rolename="manager-gui"/>
<role rolename="admin-gui"/>
<user username="admin" password="CHANGE_ME_STRONG" roles="manager-gui,admin-gui"/>

The manager-gui role grants the Manager web UI; admin-gui grants the Host Manager UI. (For scripted/CI deployments you would add manager-script instead, and authenticate via the text API.)

Allow remote access to the admin apps

By default the Manager and Host Manager are restricted to localhost only by a RemoteAddrValve in their context.xml files. If you are administering the server remotely, you must relax or remove that restriction — carefully.

1. Edit the Manager context:
   sudo vi /opt/tomcat/webapps/manager/META-INF/context.xml
2. Edit the Host Manager context:
   sudo vi /opt/tomcat/webapps/host-manager/META-INF/context.xml

In each file, find the commented <Valve> with allow="127\.\d+\.\d+\.\d+|::1|..." and either comment it out or extend the allow regex to include your admin workstation's IP. The safest approach for production is to leave the valve in place and add only your specific IP, rather than opening it to the world.

Restart Tomcat so the changes take effect:

1. sudo systemctl restart tomcat

Step 6 — Open the firewall for port 8080

Tomcat listens on port 8080 by default. On modern CentOS-family systems the firewall is firewalld, so you must add a rule before the port is reachable from other machines.

1. Open port 8080 permanently:
   sudo firewall-cmd --permanent --add-port=8080/tcp
2. Reload the firewall to apply:
   sudo firewall-cmd --reload
3. Confirm the rule is active:
   sudo firewall-cmd --list-ports

If your system uses SELinux in enforcing mode (the default), Tomcat on the standard port and directories generally works without extra policy. If you change Tomcat's port or install path, you may need to adjust SELinux labels or port types — check sudo ausearch -m avc -ts recent if something is mysteriously blocked.

Production note: exposing 8080 directly to the internet is rarely ideal. The common pattern is to put a reverse proxy (Apache httpd with mod_proxy, or Nginx) in front of Tomcat on ports 80/443, terminate TLS there, and proxy to Tomcat on localhost:8080 — keeping 8080 closed to the outside world.

Common pitfalls and how to avoid them

Most failed Tomcat installs trace back to a short list of recurring mistakes. The table below maps the symptom to the real cause and the fix.

Two more habits worth keeping: do not edit catalina.sh to set JAVA_HOME the way old guides did — put environment variables in the systemd unit (or in conf/setenv.sh) so upgrades don't wipe them. And treat security as part of the install, not an afterthought: run as the unprivileged user, use strong Manager passwords, keep the admin apps off the public internet, and remove the bundled examples, docs, and ROOT sample apps from webapps on a production box.

Step 7 — Verify the installation

With the service running and the firewall open, confirm Tomcat answers.

1. From the server itself, fetch the default page:
   curl http://localhost:8080
   You should get back HTML containing the Tomcat welcome page.
2. From any browser, visit:
   http://YOUR_SERVER_IP:8080

You should see the “Apache Tomcat” welcome page with the familiar “If you're seeing this, you've successfully installed Tomcat” message. Click Manager App and log in with the account you created to confirm the admin role works. Click Host Manager to confirm admin-gui. If both load, your installation is complete and correctly secured at the basic level.

To check it survives a reboot — the real test of the enable step — run sudo reboot, then after the server comes back, confirm with sudo systemctl status tomcat that it returned to active (running) on its own.

Key Takeaways

• Skip the EOL stack. Use a supported OS (AlmaLinux/Rocky/RHEL 9) and a supported Tomcat (9/10/11) with a current OpenJDK (11 or 17) — not Tomcat 7 on CentOS 6.
• Run Tomcat as a dedicated, no-login user, never as root, and give that user ownership of the runtime-writable directories.
• Manage it with systemd, not legacy init scripts — you get auto-restart, boot startup, and clean logs via journalctl.
• The Manager and Host Manager need explicit roles and a strong password in tomcat-users.xml, plus a relaxed RemoteAddrValve for remote admin.
• Open port 8080 in firewalld for testing, but front production with a TLS reverse proxy and keep 8080 off the public internet.

Frequently Asked Questions

Can I still install Tomcat 7 on CentOS 6?

Technically yes, but you should not. Both Tomcat 7 and CentOS 6 are end of life, receive no security patches, and expose you to known, unfixed vulnerabilities. Install Tomcat 9 or later on AlmaLinux, Rocky Linux, or RHEL 9 instead. If you are forced to host a legacy app, run it on Tomcat 9, which still uses the older javax.* servlet APIs that Tomcat-7-era apps expect.

Do I need Oracle's JDK, or is OpenJDK fine?

OpenJDK is fine and is the recommended choice. The distribution-provided java-17-openjdk (or java-11-openjdk) package is fully supported, gets automatic security updates through dnf, and avoids the manual .bin/RPM downloads and licensing considerations of Oracle's JDK. Tomcat does not care which compliant JDK it runs on.

Why does the Manager app return 403 even with the right password?

Two separate gates protect it. First, the user must hold the manager-gui role in tomcat-users.xml. Second, the RemoteAddrValve in webapps/manager/META-INF/context.xml restricts access to localhost by default — so a remote browser is rejected regardless of credentials. Add your IP to the valve's allow pattern (or comment the valve out for testing) and restart Tomcat.

How do I change the port from 8080?

Edit /opt/tomcat/conf/server.xml and change the port attribute on the HTTP <Connector> element (for example to 8081), then restart the service and update your firewall rule to match. If SELinux is enforcing and you pick a non-standard port, you may also need semanage port -a -t http_port_t -p tcp <port>.

Found this useful? Subscribe to @explorenystream on YouTube for more practical Linux and DevOps walkthroughs.