In cPanel & WHM version 76, we implemented a new version of Apache Tomcat® for users that run EasyApache 4. This iteration represents a complete overhaul of our implementation and provides substantial differences from the EasyApache 3 version. The EasyApache 4 implementation of Tomcat configures a private instance for each user. This utilization increases security and allows the user to manage their Tomcat services, but increases memory use on the server.

A Glimpse into the Process

We sat down with Adam Wien, the Product Owner of the team responsible for developing Tomcat. His demo of the new Tomcat at the 2018 cPanel Conference was well received, so we wanted to share the highlights of that demo with our readers.

When this project began, one of the biggest pushes was to create a parity of EasyApache3 (EA3) for EasyApache4 (EA4) to give administrators what they were accustomed to using. This was one of the last things our development team had to do before EA3 reached End of Life.

The easiest path forward was to make Tomcat work in EA4 the same way it did in EA3, meaning a single shared daemon amongst multiple users. This approach became a problem that we needed to overcome as users traditionally had to run the daemon as root, so any of the Java apps running on the server were also running as root. Worth pointing out is that there were some advantages of running it this way, such as a smaller memory footprint, and again, what users were used to experiencing.

In version 76, we wanted to reintroduce Tomcat to the user base. As the new version was still considered experimental, we felt that this allowed us to take some risks. The user base of Tomcat was small, but very vocal, which gave us an advantage of an audience that provided feedback and the ability to iterate changes quickly. At that time, we reached out to a large partner that was using Tomcat, and we discovered they didn’t use our implementation the way we intended; they used a mixture of the old Tomcat processes and the new way we were going to do it. We sat down with the partner and spent some time deciding the best path forward, and decided that was giving users the tools they needed to make the correct decisions while still protecting them security wise.

With that, we decided to start running Tomcat as a user daemon. Running it as a user gave us more security because it wasn’t running Java applications as root. There were some disadvantages: a larger memory footprint. Our initial testing showed every user that had Tomcat enabled was using an extra 128-256 MB of RAM. This wasn’t ideal, but Tomcat users understand that Java is a resource hog. Willing to make that tradeoff, we decided to push forward.

So how did we get there?

In the pursuit of a new Tomcat, we’ve implemented a couple of new features. First, Ubic, a toolkit for describing daemons in pure Perl, is an init system for user-level daemons. Second, we’ve implemented a feature we are calling Port Authority, which is configuration management for ports so that individual user’s Tomcat instances don’t trample on top of each other and are easier to configure overall.

Also included as part of Port Authority are IP tables outbound rules to increase protection from Man in the Middle Attacks.

So what happens when a user enables Tomcat now?

We now have a single installation of Tomcat that copies the binaries and configurations it needs into the users home directory. Tomcat then uses Ubic to manage starting and stopping that daemon. We see this being advantageous for modern web applications, and those not supported by mod_passenger.

Once Tomcat is up and running, there are some changes to the way users handle deployment: the web root is not public_html, and it must be deployed manually. So you will have to use whatever proxying technique you prefer. mod_proxy/mod_proxy_ajp via command line is the most popular. We want to remind our users that this is an MVP, but also a basis for where we can go forward.

So what’s next?

This all depends on customer adoption and customer requests. We are looking into auto-deployment of mod_proxy ajp via the Application Manager or just deploying mod_proxy_ajp automatically. We now have the framework where we could implement Tomcat 7, 8, or 9 on the same system without much effort. We are eager to hear how our users are interacting with Tomcat.

To discuss Tomcat in EasyApache4 more in-depth, or to weigh in with your own opinion, join the conversation on Slack, Discord, or the Official cPanel subreddit.