After Lucee restart all Lucee Web Contexts use Server Admin password

dev support
1

We are testing our Lucee 6 with multi-context server setup and found an odd issue which we can’t figure out or find anyone else having the same issue.

  • We created a new site (e.g. mysite.com) on the server and everything appears fine, a new WEB-INF added and we can access the web admin using the set default password for that site (web admin dashboard shows correct path to sites directory).
  • We restart the Lucee service and all starts fine, no errors etc
  • We can access the Server Admin and all looks correct
  • We go to mysite.com/lucee/admin/web.cfm and try the default password which was working pre-restart but it fails
  • We use the /lucee/admin/server.cfm password on the web admin for mysite.com and it works and allows us in for the mysite.com web context (not the default one: /var/www/html).

It is if the web contexts forget their password settings and just fall back to the server password. If we set the default password again, it changes it for all instances and we can login, however it changes it for all contexts, even those not on the default password as well, it is a full reset of all web admin passwords (apart from the server one of course). If we restart Lucee again, it goes back and reverts all instances to the server admin password.

We downgraded to the latest version 5 and everything works perfectly and no issues after many restarts, removing and re-adding sites/contexts. All is well.

Has anyone seen or experienced this using Lucee 6? We spent a number of hours going around the houses on this one! Any help is always appreciated!

OS: AlmaLinux 8
Java Version: 21.0.5
Tomcat Version: Apache Tomcat/9.0.98 (mod_cfml)
Lucee Version: 6 (all versions)

2

Sounds like Lucee 6 may think it’s in the new “Single” admin mode, even though it’s not. The behavior described sounds like that might be the underlying cause.

3

It certainly does seem like it - we are going to try doing an upgrade and set again to multi-mode and see what happens.

4

Completed an upgrade from v5 to v6 and if you have an instance which uses the default password, after Lucee restart, the web admin password is again set to the server admin password instead of keeping the default password.

Instances with a changed password from the default work fine.

5

After doing a complete new install of Lucee (switched to multi context) on a clean Linux node with mod_cfml (Apache/Tomcat) we continue to see once the service is rebooted all created web contexts passwords become the same as the server admin.

Can anyone running Lucee + Linux confirm if they have this issue?

6

You are only using one mod_cfml connector for your whole server, then yes, that is the correctly working.

7

Thanks for your insight - so this is a change to Lucee 6 and its implementation as Lucee 5 works perfectly as expected. Also, as per previous messages in this thread, we can downgrade from 6 to 5 and it works.

So I am not 100% sure your statement is correct here if this was the case for Lucee 5 in your view.

8

@Jonathon_Lucas

If you want to post your exact configuration for tomcat and apache that would be more useful than trying to guess your problem.

My “Fill in the blank” guess is you created bunch of websites on Apache which are connected via mod_cfml.

If you want to run each site as its own instance “config”

Create a virtual host for each one in Apache
Create a mod_cfml_siteXXX.conf for each virtual host
in /opt/lucee/tomcat/conf/server.xml
create a virtual host with mod_cfml values for each virtual host
restart tomcat
restart apache

9

I have installed DirectAdmin control panel as a test CP, so using their Apache configuration which is pretty standard Apache.

I installed Lucee with mod_cfml:
1: Apache Control Script Location: /usr/sbin/apachectl
2: Apache Modules Directory: /etc/httpd/modules/
3: Apache Configuration File: /etc/httpd/conf/httpd.conf
4: Apache Logs Directory /var/log/httpd/

Everything works perfectly fine when we create a new site, we use the define default password in Lucee, we can configure the context for the new site without issues, we then restart Lucee and the instance password goes.

It is like the multi-context setting isn’t working and stays with a single web context setup.

10

Your config is working exactly as it was designed and how you have it configured.

So lets go in reverse…

Your website runs on lucee, which runs on tomcat.

https://tomcat.apache.org/tomcat-9.0-doc/virtual-hosting-howto.html

Go configure that so its a 1-to-1 apache-vhost to tomcat-vhost

Next, understand that MOD_CFML is a really fancy form of mod_proxy, which you can use instead of mod_cfml, save for mod_cfml does some of the heavy lifting for you

Read this so you have a base understanding of what apache is doing with your request
https://httpd.apache.org/docs/2.4/mod/mod_proxy.html

After the above, read the tomcat documentation on what mod_cfml does
https://viviotech.github.io/mod_cfml/docs-valve.html

11

Yeah, I completely understand that, but:

Lucee 5 allows for multi-context with and a routing through to Apache without issues as we want it to work. Lucee 6 doesn’t, so I just want to understand that in Lucee 6 somehow the tomcat → Apache routing works differently but with the same mod_cfml version installed.

12

The change log is here:
https://download.lucee.org/changelog/?version=6.2

13

Thanks for the link.

We are going to look at getting a consultant in on this one as we need to define if this is a bug or a feature and/or how we can get it working similar to how Lucee 5 treats web contexts.

14

Lucee 6 still supports multi mode, it is, however, being removed in 7

I usually run in single mode, but here is my local install running with 6.2.1.77-RC switched into multi-mode

I have Lucee docs running here on a different context/site

image
image898×266 14.7 KB

Back to debugging, the password for the web context is stored in the /WEB-INF/lucee/CFconfig.json file, can you take a copy of that file, do a restart to reproduce the problem and then compare the running version against the copy?

This is all working for my locally as expected, let’s see if we can reproduce your problem.

mine looks like this

{
  "version": "5.0",
  "salt": "5095E9E4-3D0E-44DA-A4C9B168A34C1A91",
  "hspw": "db77625624f0ae690a0692f5c08d5c76c06700......"
}
15

While I am all for you paying anyone for commerce and consulting, though I would rather have you donate to Lucee.

Ill make this as simple as I can.

This is your current setup
request —> apache httpd —> mod_cfml —> tomcat —> lucee —> site

With multi-context it is still

request → apache httpd (vhost 1 or many) → mod_cfml (single request for every site) —> tomcat -(all instances are one instance) —> lucee (applies context logic) —> site

In Version 5.x the Context logic is applied per request – This is slow, its why it “works on 5” but not on 6.x → the Request gets “routed” through lucee internals to find the right “location” for your site and render result.

What happens is
Your site(s) after the first request have a WEB-INF file generated, this is where your configuration data for that web instance sits. –

IN 5.x Lucee iooks for the WEB-INF then allows that logic to happen, what ever that logic is per web-inf

In configuration instance
apache httpd (many vhosts) → single instance mod_cfml config —> tomcat —> lucee 5 —> PROXY BACK —> file system of vhost /WEB-INF/ (siteconfig)

In 6, the correct way to set this up, and will result in improved performance and security is as described in my previous post

apache httpd --Vhost configs —> tomcat —Tomcat Vhosts -->Lucee

<VirtualHost *:80>
ServerName vhost1.example.com
DocumentRoot /path/to/vhost1/document/root

# mod_cfml configuration for vhost1
ModCFMLHandlers "before"
ModCFMLSharedSecret "vhost1_shared_secret"
ModCFMLConfigFile "/path/to/vhost1/config/file"

# Other Apache configurations specific to vhost1

<VirtualHost *:80>
ServerName vhost2.foo.it
DocumentRoot /path/to/vhost2/document/root

# mod_cfml configuration for vhost2
ModCFMLHandlers "before"
ModCFMLSharedSecret "vhost2_shared_secret"
ModCFMLConfigFile "/path/to/vhost2/config/file"

# Other Apache configurations specific to vhost2

in your httpd.conf you would add unless you specifically are throwing everyting in the httpd.conf
Include /path/to/vhost1.conf
Include /path/to/vhost2.conf

In Tomcat you will add the following to server.xml

<Host name="vhost2.example.com" appBase="webapps">
    <Context path="" docBase="/path/to/vhost2/document/root" />
</Host>

After you make the config changes, restart Apache and lucee services

This will configure now allow lucee to look for WEB-INF directory inside the document root of each vhost

16

That makes sense now as the difference between 5 and 6 - as we use hosting Control Panels we are limited with how the hosts are setup and need to automate this as much as possible which of course v5 did perfectly for our needs.

Will need to think how we can get around this, likely using some hooks to either update the server.xml or another option.

17

as you are using linux

you can use sed for injecting files and merging files

sed ‘100r file2’ file1 > tempfile && mv tempfile file1

sed will read to the line stated of file file, in this case, line 100
sed will then put the contents of file 2 into file 1, starting at line 100 into a “tempfile”
after the temp file contains all the data, it moves the newly combined data into file1.

You could for example use coldfusion to generate the vhost conf and xml append for tomcat.
you could use a bash script and cfexecute to trigger the merge and restart the service.

18

We can create hooks for when a new domain/site is created and adjust the server.xml file, we just need to make sure that can also delete nicely and not become a mess.

We have done similar things in the past, but haven’t needed to for Lucee.

Version 7 of Lucee will certainly cause some issues and might be a show stopper for our needs depending on the implementation of it and how we can work with it.

19

This should all still be working with 6 as it did with 5

Lucee changed the underlying format for config and introduced single mode. If it’s not working it a bug.

As for single mode in 7, aside from the single namespace for applications, what are the showstoppers for you?

20

That contradicts @Terry_Whitney though, so would be good to have it all aligned, we will do some more tests :smiley:

In regards to version 7, we need each website to have its own context to manage, if that is going away then we would need to either build a lot of integrations with Lucee to be able to re-create such a UI for end users (website owners) to use.