Why different types of Triggers within openLuup & ALTUI

[akbooer]

AFAIK there’s been no change at all in the file loader code. AltUI seems to work for me, but I don’t use a local CDN.

Did you do anything other then just update openLuup?

Edit: I just tried getting a non-existent file and see this log:

2021-08-23 07:43:12.984   openLuup.server:: GET /foo HTTP/1.1 tcp{client}: 0x55adcd32ec28
2021-08-23 07:43:12.984   openLuup.servlet:: file not found:foo

So I don’t think that the missing ‘/‘ is of significance.

[Buxton]

No. The update started it. Is it possible to see the actual call through debug. Because obviously the files reported as not there, are there. So something is wrong or different in the call.

[akbooer]

Can you just check by reverting to an older version? The master branch is just a couple of revisions behind, or v21.4.26 would do.

[akbooer]

Alternatively, try to see if the server can actually read one of the files by requesting it manually. For example:

http://openLuupIP:3480/localcdn/joint.css

[Buxton]

@akbooer said in Altui file not found errors:

localcdn/joint.css

Yes, that http command returns the file.

[Buxton]

@akbooer and the standard plugin altui js files load from the cmh-ludl folder. It's the localcdn folder js that is not loading. Odd that the server is saying the request completed, but the servlet says that the file is not found.

2021-08-23 10:55:28.520   openLuup.server:: request completed (202128 bytes, 13 chunks, 10 ms) tcp{client}: 0x55c768bab068
2021-08-23 10:55:28.520   openLuup.server:: GET /J_ALTUI_multibox.js HTTP/1.1 tcp{client}: 0x55c7693511b8
2021-08-23 10:55:28.522   openLuup.server:: request completed (40237 bytes, 3 chunks, 1 ms) tcp{client}: 0x55c7693511b8
2021-08-23 10:55:28.524   openLuup.server:: GET /J_ALTUI_iphone.js HTTP/1.1 tcp{client}: 0x55c7688d4168
2021-08-23 10:55:28.526   openLuup.server:: request completed (22770 bytes, 2 chunks, 1 ms) tcp{client}: 0x55c7688d4168
2021-08-23 10:55:28.526   openLuup.server:: GET /J_ALTUI_uimgr.js HTTP/1.1 tcp{client}: 0x55c7693240b8
2021-08-23 10:55:28.571   openLuup.server:: request completed (717146 bytes, 45 chunks, 44 ms) tcp{client}: 0x55c7693240b8
2021-08-23 10:55:28.571   openLuup.server:: GET /etc/cmh-ludl/localcdn/altui/joint.min.js HTTP/1.1 tcp{client}: 0x55c7690878c8
2021-08-23 10:55:28.572   openLuup.servlet:: file not found:etc/cmh-ludl/localcdn/joint.min.js
2021-08-23 10:55:28.572   openLuup.server:: request completed (155 bytes, 0 chunks, 0 ms) tcp{client}: 0x55c7690878c8

[Buxton]

I was able to get altui back up by deleting the contents of the localcdn state variable and the bootstrap variable (this action will then pull files from the internet). So it may be that the altui installation was corrupted when I installed the dev version of openLuup. I tried re-installing altui, but it didn't improve things and in the process I further managed to erase all my cached ui settings. Anyway, I'd still like to see why the file not found message is in the logs, when the files are actually there.

[akbooer]

Is there an AltUI parameter which defines the location of the local CDN?

I really have no explanation… you’re sure that nothing else changed?

[Buxton]

@akbooer Yes, these two variables control location:

[akbooer]

Remind me how to create a local CDN so that I can try myself…

[Buxton]

@akbooer You would copy the folder localcdn and its subfolders from the github repo Altui to a similar folder structure on your openLuup cmh-ludl installation. Then place the full path in the LocalCDN variable via the altui device. For the LocalBootstrap, I believe it's just the bootstrap.min.js file name:

[akbooer]

@Buxton

At last, I've had a chance to try this.

It all appears to work as expected. I can be sure that it's using the localcdn/ by renaming one of the files in there and seeing an 'file not found' error message.

To clear, I have the localcdn in cmh-ludl/ (ie. the openLuup home folder) and my AltUI LocalCDN variable is set to localcdn/altui/

[Buxton]

Yes, that is the same as my setup (I also tried storing the files in the altui sub folder with no change). My installation worked fine for more than a year. It broke on the openLuup update, leading me to believe there was some sort of local file corruption.

However, I also believe there must be a difference between the path that is being used by the openLuup routine to grab a file, and the path that is displayed in the log, as the log display path pointed to the folder where the localcdn files are stored (as seen in the the first post's screen shot of the directory structure.)

[akbooer]

Do you know what version you were running previously? Have you tried reverting. I still can’t see anything that could cause this. I will enhance the error message to specify the exact path.

[akbooer]

OK, I've checked the code. The openLuup server's root folder is cmh-ludl. All paths are relative to this, hence any leading '/' is removed from the given path. In common with other web servers, you cannot access an arbitrary path on the system, which is why it also disallows '..' in a pathname. There are also a limited number of path aliases built into the system, mostly to do with CGI handling, and nothing to do with localcdn.

The filtered pathname is already displayed in the error messages. Nothing has changed in this area of code for quite a while. I still cannot see how the latest update could have changed anything. It all seems to be working as it should.

[akbooer]

Just noticed in your very first post that the given path is

etc/cmh-ludl/localcdn/

Whereas you should have just this:

localcdn/

Did you inadvertently change this after the update??

[Buxton]

@akbooer said in Altui file not found errors:

All paths are relative

That's probably the reason this happened. I had the full path in the variable. Though, the full path did work for more than a year.....

However, that still leaves the issue of why the path as seen in the log is different from the actual path being used in the routine that looks for the files...... For diagnostic reasons alone, the two paths should be an exact match.

[Buxton]

@buxton The relative path works.

Can you make the "file not found" error a red highlit error like the other system errors. This would flag in the log any odd files that are not within the relative path scope, as the relative paths are not explicitly known to the end user....

[akbooer]

@buxton said in Altui file not found errors:

the full path did work for more than a year...

I have no explanation for how that could be.

@buxton said in Altui file not found errors:

that still leaves the issue of why the path as seen in the log is different from the actual path being used

I don’t understand this. It isn’t. It’s the actual path used by the open routine (which is relative to the base folder.)

@buxton said:

Can you make the "file not found" error a red highlit error like the other system errors.

Yes, I’d planned to do that, but it happens rather often in a benign way, for example, the browser often tries to get favicon.ico, but if you haven’t got one, it keeps trying…

The console HTTP has a list of all file requests and their latest status.

[Buxton]

@akbooer My apologies for not being clear. I'll try to explain what I mean with the following screen shots. The folder holding the localcdn files is "/etc/cmh-ludl/localcdn/"

A sample error message in openLuup is:

file not found:etc/cmh-ludl/localcdn/joint.css

The two paths are identical. Because the two paths are expressed as the same, the impression that one gets from the log is that the actual files in the folder are somehow not accessible to the calling program.

Because files are retrieved from a relative position to the base folder, the actual path that is being called is probably: /etc/cmh-ludl/etc/cmh-ludl/localcdn/joint.css. If I saw the below path in the error log, I would immediately understand why the files were not being found:

file not found:etc/cmh-ludl/etc/cmh-ludl/localcdn/joint.css

Knowing now that the underlying problem was relative paths, the issue is not really a concern for me. And I completely understand the need for relative paths given the chaotic working folder structure on a vera device--and the need to account for this structure in a more rational manner in openLuup. However, others may encounter similar file not found error messages, and be completely flummoxed as to why files that are obviously showing as being in a proper folder, are then not found by the calling function.

Displaying the full path in the log would give an immediate understanding of why the error is occurring. As for why the original path worked for so long, my guess is that the lua routine walked the path in various ways, and found the files. Why it broke is a mystery, perhaps a more restrictive linux update -- I usually do an OS update when I update openLuup.