Lucee 6 - Single Mode

language proposals
1

As you know Lucee always comes with 2 Administrator, the web and server Administrator, this unnecessary complicate things, when you run Lucee with a single web context.

In Lucee 6 this “multi admin mode” is optional, you can decide if you wanna run Lucee with 1 or 2 Administrators with help of the setting “mode” in cfconfig.

All existing installations that get upgraded to Lucee 6, will be in “multi mode” and all new installation in “single mode”. With help of the newly supported “cfconfig” you can define the “mode” explicitly.

You can benefit from “single mode”, even you never use the Administrator itself, because startup time improves, you can define all setting in one configuration, including Scheduled tasks and logging and all resources are in a single place.

We do consider 3 possible modes

  • single - you always have only one Administrator independent of how many web context you have (the same way as ACF)
  • multi - you always have at least 2 Administrator independent of how many web context you have (the same way as Lucee 5)
  • auto - depending of how many web context you have, Lucee will be in single or multi mode

If we will do the “auto” mode is not sure yet, because it is possible to add a new web context add runtime and so far changing mode, needs a Lucee restart.

Also depending on the mode the Lucee Administrator will have a different color, so you see right away, which mode you are using.

Maybe something like this (admin colors mixed together )?

violet
violet912×646 82.4 KB

or this (more neutral color)?
grey
grey912×646 71.2 KB

All this is not curved in stone yet and i would like your suggestions on all of this?
Does it makes sense to have Lucee in “single” mode for new installations? or should it be “auto”?
How should the admin look like?
…

8 Likes
2

My thoughts are new installations would be single mode until a second context is added, and then it would naturally (and automatically) switch to multi-mode. If that’s ‘auto’, then I guess new installations should probably be in ‘auto’ mode. You didn’t really define how this will/could be switched between them, so hard to tell if single or auto is the right answer here.

Speaking of which… if you have a server in single mode, how difficult is it to switch to multi-mode?

What if you are in multi-mode but, for whatever reason, you want to go to single mode? Is there an interface to pick the context to keep or is going back to single mode even an option at that point? (Playing devils advocate… you know someone, somewhere will want to do this for some reason - faster startup time, perhaps)

UI colors really ought to have been left to the user as a setting imho, though the CSS is easy enough to change if one desires it so I suppose it doesn’t matter much what color scheme single mode has. I’m personally a fan of purple, but that’s just me. Other may detest the color lol

The faster startup time is a definite plus so kudos on that… we’re currently not using any single context Lucee servers, but we’re exploring containerization strategies which would make single mode quite a bit more useful, so the faster start-up time adds appeal to the strategy.

Whatever is chosen, I look forward to experiencing the new modes in Lucee 6 and appreciate all the work you and the team are putting into Lucee.

– Denny

3

There are good reason to run a server with multiple web context in single mode.
Take for example lucee.org, we have multiple web contexts with different sub domains (lucee.org, extension.lucee.org, download.lucee.org, …), but all this web contexts are using the same resources and have the same configuration. Multi mode really only is necessary, when you run multiple web contexts that are not directly related to each other.

The Lucee admin on the overview page will show the current mode and maybe allow to switch in the admin itself or at least explain how it is done. If you switch to “multi”, Lucee will create the necessary configuration for all context, when you switch from “multi” to “single”, it is not clear yet how we handle this.

  • delete the web context configurations
  • keep the web context configurations in place
  • backup and delete the web context configurations
  • merge all the configs to one
    If done in admin you could may pick one of the above
4

What’s cfconfig?

Given https://cfconfig.ortusbooks.com/ has been around for a long time, it’s going to be really confusing for support and googling, given cfconfig has been around for years.

2 Likes
6

When is Lucee 6 planned to be released? (other than “when it’s ready”.)

I’m new-ish to Lucee and am currently using ACF 2016 with IIS, but it becomes end-of-life within the next ~30 days. We want to migrate to Lucee, but would prefer a single context. I found this article from 2015 regarding “Serving multiple sites from a single web context in Lucee”, but don’t really like the proxy method as it seems more like a hack.

Regarding the “modes”, is it possible to have a primary single context AND have some sites (on the same server) have their own admin modes? (I’m just wondering if it’s an all-or-nothing global settings.)

Thanks.

7

I completely agree with this. Another name for this setting or variable will head off a lot of confusion.

8

This is a great idea!!! Yes, I think “single” mode as default is the best. Thanks for asking the community for input. Here is my opinion…

I’ve noticed that there is much confusion about server and web administrator out there. I was very confused about it myself when I switched from ACF. That’s the reason I did a quick intro in the Lucee installations videos I’ve added to Lucee’s documentation as a contribution (see the video section here). Before going to my opinion about the proposed modes, I’d like to say something about that first.

Problem 1: The server / web tab of the login form page creates confusion

Reason: If you are new to Lucee and you install Lucee for the first time, you want to take a quick tour through the administrators. As soon as you are on that login page, you’ll ALWAYS see that server/web access tab and very likely click them. See the image below:

Untitled

No matter if you are in web (blue) or in server (red) you’ll see the links as shown in the image above. If you have more than one web context running, that means that :

http://localhost has a server and a web admin link
http://mydomain.com has a server and a web admin link
http://myotherdomain.org has a server and a web admin link
http://mythirddomain.info has a server and a web admin link

That creates the wrong assumption that each web-context has also its own “Server Administrator” and its own “Web Administrator”. No chance to understand that “server administrator” is for the overall global setting of the running Lucee instance. In my opinion that should be very clear before you log into any administrator.

To add confusion to everything: At first sight the settings in each administrator seem to be identical. Server/Web-Admins have also same passwords by default. Another negative effect: Hosters who make “web administrators” available to customers will want to lockdown the server admin, causing 404 or 403 http status error codes for that links, having a bad effect/impact.

Proposed solution:

  • Remove the server-admin and web-admin access links tabs from that login form page. Users who administer web contexts frequently can save the URLs as browser favorites.
  • Add a title text to the login page using clear meaningful names:
    => For Server use “Global Server Administrator”, or “Server Administrator (Global Settings)”.
    See as an example the image below:
    loginServer

=> For Web use “Web Administrator (mydomain.com settings)” or “Website Administrator (mydomain.com settings)”.

Problem 2: Running additional admin modes “single” or “multi” may add more complexity for users to understand the modes.

Reason: the names “single”, “multi”, “auto” and the colors can make more confusion, because the names can be misinterpreted with servlets contexts or how servlet engine instances run.

Proposed solution:
Because the global server administrator will always be “on”, I’d make it much simpler by just setting it in the “Global Server Admin” front end, just like so:

Enable Web Context Administrators=“no” (that would be your “single” mode and would be the default)
Enable Web Context Administrators=“yes” (that would be the same as “multi”)
Enable Web Context Administrators=“auto” (that would be the same as “auto”)

This parameter could also be set as system.property or environment variable.

To make this more visual, I’ve created a quick sample image (with the values as a boolean here instead of yes|no|auto):

UntitledWebContexts
UntitledWebContexts879×535 65.4 KB

About cfconfig: I surely know about cfconfig of CommandBox. Don’t know about cfconfig in Lucee. If these are not related, another name should be used instead.

That’s all I can add for now. Again, thank you for asking!

9

nice suggestions!

I’d prefer myself to have the option of the admin only running on 8888, inaccessible to the internet, with a drop down to select which web context you want to administrate. That’s not so hard, it just requires the CFADMIN tag to accept a context parameter when type=“web”.

I think it’s also a good move to finally move by default all the WEB-INF’s outside the webroots in under a single folder. they don’t need to be under the web root, so they shouldn’t be.

It would also useful to have a built in config diff-er to compare settings between server and web, or between web contexts.

The problem with using a system.property or environment variable, is it requires a server restart to before Lucee picks them up

10

I think ACF hides the dev from a lot of this multi context stuff. Having a web server that then proxies to Lucee is in the way you describe either 1 to 1 (multi context) or as you describe using it so

foobar.com → proxies to myapp/foobar
anotherfoobar.com → proxies to myapp/anotherfoobar

Whether you are using NGINX, apache rewrite or IIS ARR its all very doable

This works really well. We don’t do it this way any more because we are all Dockerised and Kubernetes but I wouldn’t let the above stop you moving.

And you should be targeting 5.3.8 not waiting for Lucee 6 imho

best

Alex

11

Yeah!!! That is sooo important. Lucee should have a setting to bind/filter the server-admin and web-admin to the local IPs by default, just as @bdw429s commented in the last “Modern Or Die - Episode 87”(min 9:25): Lucees only native setting that I know of is the system property /environment variable “LUCEE_ADMIN_ENABLED=false” that sends a 404 status when accessing the administrators. But(!!!) this setting shuts down all administrators completetly. That means that with Lucee you must help yourself with other external options/utilities like firewall, URLRewrites/location directives in Tomcat/or fronted webserver or with Boncode settings.

12

webserver ip based restrictions don’t even work if you use a CDN like cloudflare (every request is a remote ip)

I also think the administrator should expose a (read-only) view of each application, i.e. application specific caches are currently invisible in the admin

As you can configure a lot of settings via Application.cfc, this becomes even more critical in single mode, as applications become the new web contexts

1 Like
13

As a long-time Adobe ColdFusion developer (since CF3), I’ve become accustomed to skipping a major version of ColdFusion and then waiting for 1st or 2nd patch before upgrading so that most show-stopping bugs can be addressed first.

I’m testing CF2016-to-Lucee migration, but need to identify the latest list of unsupported tags & functions (as well as undocumented hacks that we’ve added) and then audit our existing code bases.

Depending on how far out the 6 release date is, I think I’d prefer to wait to migrate to the major 6 release while testing for the current (and last) 5.x supported release.

1 Like