How does Lucee web admin work?

dev support
1

Hi,

I’ve been using Lucee for a couple years now, but I still don’t really know anything about how the admin interface routing works… specifically, the routing for Web Contexts.

This server shows 2 contexts…one is, I assume, for the main Lucee Server Admin, and the other is for my site. But the thing is, that link doesn’t work. It’s pointing at a host called “mediacast”, which is not the hostname of this machine, and doesn’t resolve to anything. I can fix it by replacing the host name with “localhost” in the address bar after I click it, but I’m wondering where that value is set, and how to change it.

SCR-20230120-txj-2
SCR-20230120-txj-21056×305 6.75 KB

Also, the scheduler does not seem to be working (which is why I wanted to access the web admin page in the first place)…I’m wondering if it might be related to the incorrect host name in the URL. I’m pretty sure that the Web Context Admin link used to work at some point, as well as the scheduler. But now it seems all of our installed sites are having these issues. Our sysadmin knows nothing about Lucee, and he may have changed something in the system config that broke all our sites…but I don’t know enough to know where to look.

Thanks!
-Partap

OS: Windows Server 2019 (10.0) 64bit
Java Version: 11.0.7 (AdoptOpenJDK) 64bit
Tomcat Version: Apache Tomcat/9.0.35
Lucee Version: Lucee 5.3.7.47

2

Interesting…Here are some questions.

  1. Doesn’t that name “mediacast” say anything to you? Is it just a name that appeared in the admin from nowhere? Didn’t you set it up somewhere? I’m pretty sure that name is/was registered in a host file somewhere.

  2. have you a fronted webserver installed or something like a proxy that redirects to that Lucee instance from somewhere?

  3. This “mediacast”’ entry is created by Tomcat (if that is the servlet engine you are using) on startup and it may come from:
    A. adding & configuring it manually via the server.xml & Catalina config etc, or
    B. it’s being added/created by mod_cfml automatically.

  4. Were are the files of your running application located? Are they at C:/lucee/tomcat/webapps/ROOT or are they at C:/web/public?

  5. How are you accessing the lucee admin? A tunnel? Or do you log into by RDP?

3

Thanks for the quick reply!

Yes it does. It’s actually our product name…It appears all over the master image, but it’s not the hostname.

On this particular server, the etc/hosts file contains:

x.y.x.w mediacast.notarealdomain.org

…which is weird…maybe left over from testing at some point? x.y.z.w, in this case, is the actual internal ip of the machine, but we shouldn’t actually be referring to that name anywhere. It’s got a real fqdn in DNS.

So that would work as a hostname, anyhow… but that’s not what the admin interface is trying to use.

have you a fronted webserver installed or something like a proxy that redirects to that Lucee instance from somewhere?

Yes, we’re using IIS as a front end, with the boncode connector

I checked server.xml and everything in the tomcat conf folder, so it doesn’t seem to be set manually there.

The application lives in c:/web/public… I guess the other one is just the default site? Server admin pages? I’m still confused about how a web context is defined.

Through a series of rdps and a vpn… It literally hurts to access. :stuck_out_tongue:

So, yeah…“mediacast” is not a surprising name to see, but I still don’t know why Lucee thinks that it is the hostname for the site.

I know the link at the bottom of the page used to work, because I found the screenshots that I made for documenting how to set up scheduled tasks when we first started using them a couple years ago.

So… I just logged into the server admin page at the site where the old screenshot was taken to double check.
The web context link used to have the full fqdn in the url, but now just says: “mediacast:80”

So something happened in the meantime to this and some of our other sites. Maybe something when the sysadmin configured ssl?

There are a lot of layers involved that I’m not very familiar with: Windows, IIS, Boncode, Tomcat, mod_cfml…
Maybe some key in the registry got updated and it’s overriding the automatic fqdn value or something like that? For that matter, how would lucee or tomcat ever know the fqdn without it being configured somewhere? Our application needs to have it configured and saved in the db…

How bout this? If I wanted to explicitly set a value for the hostname in that link, how could I do that?

4

Considering that:

  • you didn’t find anything in the server.xml about “mediacast”
  • a context exists named “mediacast” pointing to C:/web/public (because you are seeing it with the Lucee admin) and
  • that your working files serving the applications content is also located at C:/web/public…

tells that this particular context was built with mod_cfml. Mod_cfml task is to createa a Tomcat web context auto"magically" for you. I say magically, because it populates the server.xml configuration virtually(in memory), keeping the server.xml file untouched and you won’t even know that it happened.

Here is what mod_cfml does in a simplified, but more detailed manner:

  1. As soon as you add a new site configuration to your IIS/Apache2 and the first cfml request comes in, it redirects it to Tomcat.
  2. mod_cfml intercepts it (it receives it via boncode connector) and
  3. verifies if the web context for that hostname has an available configuration in Tomcat
  4. Because the site has just been created in your IIS/Apache webserver, but still not in Tomcat, it will retrieve detailed information about that new site, like hostname and also the physical webroot defined in your fronted webserver
  5. Then mod_cfml adds a new configuration for that to your /tomcat/config/Catalina/{hostname}/ROOT.xml for Tomcat and holds the settings (that you would have entered to your server.xml) in memory.

Then everything just works.

Because you have a working “mediacast” host configured in tomcat, that machine have received a hostname named “mediacast”. And that were from the IIS/Apache machine.

I’m pretty sure that if you open a cmd terminal session on the machine that serves your IIS fronted webserver, and you do tracert mediacast, it will resolve to the tomcats IP address.

Additional information: On your fronted webserver you might even not have a website defined with the name “mediacast” but your FQDN served with IIS, but then you have an host header rewrite setup somewhere, changing the IIS host header name to “mediacast”, very probably in your BonCodeAJP13.settings with the directive “server=mediacast” or some sort of host header rewrite in IIS.

5

Hm…
@andreas So you’re saying you think that the mediacast hostname is coming from IIS via boncode and mod_cfml? But “mediacast” doesn’t resolve to anything on the server (which is the problem)

In general, all urls defined on the machine refer to http://localhost or http://127.0.0.1
If mod_cfml is seeing host: mediacast, it would seemingly need to have been set manually in the headers, since the hostname itself would not route to this server.

Oh $#!%…that must be it!!! …just remembered, there are client kiosk machines onsite that do contact the server intermittently using hostname mediacast (set in their local etc/hosts). This is something we need to change, since it means no ssl, among other things, but it’s the legacy config.

So…the theory is that, when the server starts up, if the first request it gets is from a kiosk client (likely, since they poll the server every couple minutes), mod_cfml sees that and sets the tomcat server name to mediacast.

OK, so if that’s the case, I just need to explicitly set the hostname to the fqdn in Server.xml…or in IIS, I guess?
Now…where do I set that, while also making sure that it continues to work with hostname “localhost”?

6

Generally speaking, why are you convinced you need to change anything? The URL in the admin is really just Lucee’s best guess at what the public URL is to your site. The host is just whatever was in the HTTP request when Lucee created the context, but I don’t believe it’s used for anything really. So long as your sites are working, just ignore whatever nonsense Lucee has on that admin page and move along.

You mentioned the scheduler in your first post. Can you show what URL your scheduled tasks are hitting? So long as they are configured to hit the correct public URL, then they should work fine.

7

Yeah, the problem I’m actually chasing is that the scheduler doesn’t seem to be running. I ran into this issue because I was unable to load up the web context admin page to check the scheduled tasks, but once I did, I found that the tasks appeared to be configured properly, and not paused.

So I added a new test task that just hits a dummy url at http://localhost/test.cfm (all it does is output a message in the log so I can see that it was run) once per minute.

It is not being hit, so I thought it might be related to the admin url issue…but now it seems it might be something else. Should I make a new topic post?

8

I would forget the admin URL bit for a moment and focus on the scheduler. Firstly, the URL configured in the tasks needs to be a URL that when hit from the server itself resolves correctly to the right site. Hitting localhost is probably NOT what you want since you’d be just hitting the Tomcat default web root, not the root defined in IIS and handled by Boncode, etc.

So, if you RDP into the server, open up a Chrome browser, what URL do you need to hit there in order to load the correct page you want to hit as part of the scheduled task? Because that’s the URL that Lucee needs to be using.

9

btw, I added this to the bottom of the server.xml file, under
<!-- ADD NEW HOSTS HERE -->:

     <Host name="[server_fqdn]" appBase="webapps">
          <Context path="" docBase="c:\web\public" />
          <Alias>localhost</Alias>
     </Host>

But after restarting tomcat, the context link still shows “mediacast:80”…

10

http://localhost is the url that should work (and does work in the browser). It is handled by IIS… For the default tomcat root, I would need to hit http://localhost:8808

Also, our scheduled task urls are currently being handled by windows Task Scheduler, using curl http://localhost …these work, but we’re trying to ditch windows task scheduler

11

OK, looks like I screwed up…
I forgot to open up the new test url to anonymous access. It was failing because it’s not coming from a logged-in session, but now it’s working.

However, the original scheduled task is still not running…or at least not successfully. Shouldn’t I get something in the WEB-INF/lucee/logs/scheduler.log if it fails? All I see in there are some pretty old Java exceptions.

12

…and now the original scheduled task is working again…

Is there a way to log these verbosely? e.g. so I could check the scheduler log and see if a task executed, and what the http status was?

1 Like
13

@partap great that you are making progress :smiley:

Just like @bdw429s said, I wouldn’t change anything. I was a little confused about your question “how does Lucee web admin work”, when in fact you just wanted to access a particular web context. What I’d do in your case is very simple, I do it quite the same when I need to access the web admin with tunnels, works very similar:

  1. RPD to the server running Lucee (should be the same you access the Lucee Server Admin)
  2. On that machine edit the host file and add:
mediacast 127.0.0.1
  1. open a terminal session on that machine with CMD and ipconfig /flushdns
  2. Then you should be able to access the web context on http://mediacast:8888/lucee/admin/web.cfm from that machine
  3. After finishing your work, change the host file back to what it was.
14

“mediacast:80” will continue to show up, since this context is generated by mod_cfml comming from IIS (or another machine) accessing it. I would really leave everything as it was. For accessing your web admin in mediacast, do it like I told you above.

We had a similar approach a while back. Some scheduled tasks in our system need System permission. No way you can/should move these to cfml, because Tomcat executes with low level priviliged local service, and you would not want to run Tomcat as local “System”. The windows taks that could run with low privileges and ran in a “global” manner for all websites, we moved as cfschedules to one single web context that acts as the global web context.

I usually check these through the usual access log files for that web context, since these are normal http request that execute a specific cfm/cfc template by calling its URL. These show access time and http status in details. For a more verbose logging, I’d create a custom logging feature from within your scheduler templates. You could even build a monitoring system around that, e.g. adding a the last execution time of a template into a database. The monitoring system could retrieve that information and fire an email notification after a certain amount without an execution.

15

That’s the workaround I’d been using…thanks.
Weird that you can’t set the name manually though… e.g., like virtual server names in Apache or nginx…

1 Like
16
  1. This is an OS constraint, not a Lucee / Tomcat constraint.
  2. Even on UNIX / LINUX devices, it is best practice to keep the HOST FILE updated with the vhosts running on the device.
17

So I finally got some actual data…I have a scheduled task set up to hit an update url every minute.

The endpoint processes and updates a queue, creating and deleting some xml files according to a schedule defined in our system (allcall schedule, to differentiate from lucee task schedule).

This morning the allcall schedule wasn’t working, and then it suddenly started back up again.

Checked the logs, I saw that the update url was being hit once per minute, as expected, until last night at 02:00:01…then nothing.
…then, this morning at 9:56:48, I got another hit, and another one at 9:57:01, and every minute since then on the :01s

The lucee task schedule looks like this

image
image786×632 8.49 KB

Any ideas about what could be happening?

Edit:
Just noticed that the server has another scheduled task that restarts iis and tomcat every morning at 5am (sysadmin paranoia)…so that happened right in the middle of the blank interval. I would think that if the scheduler got “stuck” that restarting lucee would kick it back into gear…

18

Partap, what logs are you checking? You’ve mentioned previously that you have your task code log when it’s run, and Andreas had proposed looking in the web server access log.

I’ll note that those focus on “whether the request ran”, not on “whether lucee even attempted to call the task”. And you said you saw no errors in the lucee scheduler log,

I have a couple of other ideas for you.

1: First, do you by any chance run FusionReactor, or would you be open to using its free 14 day trial? It offers a transactions>history page (with a drop down at the top offering httpclient) which would shows any calls out of lucee (or ACF), and under the cover a scheduled task call is just an automated equivalent to a cfhttp.

2: Indeed, yet another proof point for you (without need of fr) would be to setup a cf page that DID do a cfhttp to the url that your task is calling. Yes, I do realize that page sometimes runs for your then sometimes not. (I’m proposing above you make sure lucee is even TRYING to call it.) But now I’m adding that when you feel from your other logs that it’s “NOT being called”, you could at that time also check if the cfhttp call to it somehow ALSO stops working.

If so, now we’d see it’s perhaps NOT about the scheduled task mechanism after all: it may have been TRYING but just not REACHING the url for the task. And in that case, do a cfdump of the cfhttp scope (on that page doing the cfhttp) to see if it reflects whatever is amiss. It could be any of MANY problems.

3: Finally, if you “simply need this to work” and “can’t spend more days and weeks going back and forth here”, I’ll note that we could get together remotely to look at all this. We might even solve it in as little as 15 minutes, my minimum billable increment. I could also help you install/use FusionReactor. You can find more on my rates, approach, satisfaction guarantee, online calendar, and more at Charlie Arehart's Server Troubleshooting Consulting Services.

I know some may think it crass for me to propose that paid help here. I’ve offered a lot above for you to try on your own (and written in a way to help others who may find this thread in the future), as I try usually to do. Again, I just know sometimes people have to/are willing to move on from free help to paid, when it makes more economic sense for them. They just may not know who might even be available. Or Lucee also offers paid support and consulting options, as well.

1 Like
19

Thanks for the ideas!

I’d actually already set up another test page on our QA server using the same 1-minute schedule, so next time it happens I should be able to see if it’s only the one url that seems to be getting skipped.

We actually do have a dev license for FR…I haven’t used it in a long time and kinda forgot about it, but I will set it up on that server and see if the logs catch anything. Also, I like your idea about calling an indirect page that can log any cfhttp errors from the client side to the allcall page.

Oh, the logs I mentioned before are from the app…it logs every incoming request at OnRequestStart and OnRequestEnd…these were not showing up for around 8 hours yesterday morning.

The good/bad thing about this is that it only seems to happen rarely…good because it usually works, and bad because I have no way to trigger the problem. Right now, the only times I know that it’s happened were yesterday on our QA server, and two weeks ago on a client’s server. It may be happening more often, but these are the only times I know for sure. Also, both times were early Friday mornings, so it’s possible that has something to do with it, too…after all, it’s processing a schedule…only problem with that theory is that the same page has worked for years running curl from Windows Task Scheduler .

I appreciate your offer to look at it…but if it comes down to it, we’ll probably just fall back to using Windows Scheduler…Switching to Lucee’s scheduler was just supposed to make things easier for us :wink: …one less external dependency

20

Looking forward to hearing what you may find.