Lucee V5.3 with Tomcat 9 on Ubuntu/Debian using JAR-File

Rolf · October 24, 2019, 12:24pm

Hi,
I’m looking for an installation guide for a manual installation of Lucee V5.3.x on Ubuntu / Debian, Tomcat 9, Apache 2.x using the JAR file. Maybe someone knows a guide.

I have already installed the same configuration with Tomcat 8 very often and without any problems. With Tomcat 8 I downloaded the JAR file and saved it in the folder ‘/usr/share/tomcat8/lib/’, then I created a folder ‘/var/lib/tomcat8/lucee-server’ and added the necessary entries in the file ‘/etc/tomcat8/web.xml’. After a Tomcat restart, the Lucee files were automatically deployed in the folder ‘/var/lib/tomcat8/lucee-server’. This does not work anymore with Tomcat 9; the folder is empty after the restart.

Maybe somewhere is an existing installation guide, how to solve the problem.

Thankful for any advice.
Rolf

Jordan_Michaels · October 24, 2019, 6:29pm

Would you be willing to toss a sack of coins to the person that did this for you?

You could review the Lucee install that the Lucee Installer produces, since that basically automates what you’re wanting to do.

Alternatively, there is some really old documentation that I found that talks about how to do it, but due to it’s age, you will probably need to interpolate a little:

gist.github.com

https://gist.github.com/nifl/7344005

apache-tomcat-railo-multiweb.md

## Tomcat 
In the Tomcat folder create a `railo/` folder and copy in the contents of the unzipped Railo JARs ZIP file (or from the `WEB-INF/lib/` folder of the unzipped Railo WAR file). In the Tomcat `conf/` folder, edit `catalina.properties` and find the `common.loader` class path. We're going to add the Railo JARs to the common class path so that every web application can have Railo CFML pages. The new `common.loader` definition should look like this (all on one line, no spaces):
`common.loader=${catalina.home}/lib,${catalina.home}/lib/*.jar,${catalina.home}/railo,${catalina.home}/railo/*.jar`

_Note: embedding Railo directly in Tomcat like this means that you will end up with a generated `WEB-INF/` folder in each webroot, containing some Railo files (about 2MB)._ 

Unless you're going to use the default web applications that come with Tomcat, this is a good time to empty the Tomcat `webapps/` folder. You could create a `default/` folder in the Tomcat folder and move everything from `webapps/` to `default/` - this makes it easy to configure the applications again under a new hostname (I'll show this at the end). Next we must configure the Railo Servlet stuff. In the Tomcat `conf/` folder, edit `web.xml`. This is the master web application configuration for the Tomcat server and any web applications you create will inherit from it. At the end of the servlet section, just before the servlet-mapping section, add the following:
``` xml
<servlet>
  <servlet-name>RailoCFMLServlet</servlet-name>

This file has been truncated. show original

httpd-vhosts.conf

NameVirtualHost *:80

<Directory "Users/nifl/Projects/ACE/pony">
    Options Indexes FollowSymLinks MultiViews
    AllowOverride All
    Order allow,deny
    Allow from 127.0.0.1
</Directory>
<VirtualHost *:80>
    ServerName pony.dev

This file has been truncated. show original

httpd.conf

# Configuration and logfile names: If the filenames you specify for many
# of the server's control files begin with "/" (or "drive:/" for Win32), the
# server will use that explicit path.  If the filenames do *not* begin
# with "/", the value of ServerRoot is prepended -- so 'log/access_log'
# with ServerRoot set to '/www' will be interpreted by the
# server as '/www/log/access_log', where as '/log/access_log' will be
# interpreted as '/log/access_log'.
#
# ServerRoot: The top of the directory tree under which the server's
# configuration, error, and log files are kept.

This file has been truncated. show original

There are more than three files. show original

nickwhite · May 14, 2020, 8:06pm

Hi Rolf, did you ever get this working? I am trying the exact same thing, and also Lucee will not expand the .jar files to /var/lib/tomcat9/lucee-server. I’ve done this same thing dozens of times of Tomcat 8, but something has changed in 9. I’m hoping you figured it out! Jordan’s reply below wasn’t really helpful in this case. Thanks.

Markus_Wollny · August 25, 2020, 1:56pm

I am trying the very same thing and face the same outcome. Has anybody managed to have a manual install of the jar on Tomcat-9 to autodeploy? I am trying on Apache Tomcat/9.0.31 (Debian Buster), and as Rolf already said, I’ve done this successfully numerous times with Tomcat8. Am I missing something in the docs?

andreas · August 25, 2020, 4:16pm

Do you have any information about what exactly is going wrong? For example, is anything showing up in the Catalina logs?

Rolf · August 25, 2020, 4:37pm

Sorry nickwhite,
I didn‘t notice your question. Unfortunately I didn‘t find a solution for this . I decided to switch to the Lucee Installer, which is working fine. Although I deeply miss the package updates for Java and Tomcat.

Greets,
Rolf

Markus_Wollny · August 25, 2020, 4:37pm

No, unfortunately nothing at all. There’s just nothing helpful in Catalina.out, the server simply starts, but fails to deploy the contents from the jar. When I try to access the Lucee admin in a browser, Tomcat complains with java.io.FileNotFoundException: /var/lib/tomcat9/lucee-server/patches/… - and this indicates that the settings for the deployment paths are being ignored, as the files should be unpacked in /var/lib/lucee/configuration/server/. The settings in server.xml, web.xml and catalina.policy and /etc/defaults/tomcat are quite the same as in a previous setup I run with Tomcat8.

Markus_Wollny · August 25, 2020, 4:41pm

Thank you for your update. I’ll probably fire up a clean VM, use the installer and try to reverse-engineer the differences in configuration. I really, really don’t like the idea of bypassing package management for Tomcat and the JVM as well, so I really hope that there may be some way to success here. I took a look at the Docker image and checked the config files there, though even then I couldn’t exactly make out what the problem is here.

Rolf · August 25, 2020, 4:41pm

Hi Markus,
as far as I remember I had some „Felix“ messages in catalina.out.
Unfortunately the VM I used for my tests is deleted.

Cheers,
Rolf

Rolf · August 25, 2020, 4:47pm

I‘ve done this, too Obviously without success.
I hope you are more successful and so nice to post a solution here.
I‘m still highly interested, but I‘m on holiday right now …

andreas · August 26, 2020, 5:01am

What I can see in the post above is, that the folder lucee-server was created manually. What I’ve found is that Tomcat creates that directory by itself when deploying the jars.

When I have strange issues with Lucee I simply delete that “lucee-server” folder and it gets created on restart. I’ve seen that Tomcat behaves on Windows just the very same as on Ubuntu in a same manner. I’m no Linux/Ubuntu expert, but I’m actually doing some installing experiments with Ubuntu 20.04 lts at the moment, and this behaves just the same.

just as an reminder, I’m sure you did this already, but I’m asking it just in case you didn’t. Any chance that the user who is running tomcat hasn’t file write/access permissions to deploy that in that specific folder, or to access the copied Lucee.jars? May be there are some conflicting file permissions there?

Markus_Wollny · August 26, 2020, 6:59am

Solved it! First reaction to your response was “well of course I checked file and directory permissions, that’s not it”. /var/lucee/config/ and all the subdirectories do in fact belong to the tomcat-user, so that box was truely checked.

Then I took a step back and wondered what else could shoot down a daemon because of some permissions issue - and who would be so mean to do that covertly and not tell anybody about it in any damn log file?

First thing coming to mind was my old enemy systemd. My lazy ass had already taken some beating over adding kernel parameters to /etc/defaults/tomcat9, which had worked fine in previous Debian versions, but not with Buster (hence the name, I guess). After identifying the culprits by sheer trial and error I had to remove these lines and put them in /etc/sysctl.d/ and /etc/security/limits.d/ where they belonged. Fortunately systemd tells you exactly nothing why it doesn’t start a service, so guesswork can be quite an adventure for the day.

systemd sandboxing has more challenges, though - at least when leaving the predesigned paths. So one
systemctl edit --full tomcat9.service
later, I had added the paths to the Lucee jars and the working directories to ReadWritePaths, so the Security-block in my unit file now reads

# Security
User=tomcat
Group=tomcat
PrivateTmp=yes
AmbientCapabilities=CAP_NET_BIND_SERVICE
NoNewPrivileges=true
CacheDirectory=tomcat9
CacheDirectoryMode=750
ProtectSystem=strict
ReadWritePaths=/etc/tomcat9/Catalina/
ReadWritePaths=/var/lib/tomcat9/webapps/
ReadWritePaths=/var/log/tomcat9/
ReadWritePaths=/opt/lucee/
ReadWritePaths=/var/lucee/config/

One service tomcat9 start later I am greeted with a “No Password set yet!” on the Lucee admin page. What I glorious start to my day! I guess it’s downhill from here on, but I am quite happy for a few minutes now.

There may be more to this systemd config, though. I might have to fine tune some settings in the end, maybe ProtectSystem needs to be more lax. But at least now I know where to look. I am relieved that I didn’t use the installer, as that would have gotten me nowhere in the end - I would have tried to wrap the installed Lucee in a systemd unit and would have stumbled just as hard, I assume.

So thank you again for mentioning permissions. Even if file permissions are not the problem here, security in general definitely was.

andreas · August 26, 2020, 8:01am

Haaaaa!!! You made my day!!! I was about not to post that message, because it seemed too obvious to me. But then I just clicked the send button. To me that is exactly why we should always encourage others to say whatever solution they come up to. Have a great day!