Missing https://.../libs/lib-jitsi-meet.min.js?v=4289

Hi all,
About 1 1/2 month ago I installed jitsi on one of my servers. It worked like a charm. I’ve been away for about a month, and now, when trying to connect to the jitsi service I’m rewarded with a screen telling me

Missing https://…/libs/lib-jitsi-meet.min.js?v=4289

The file libs/lib-jitsi-meet.min.js exists and is readable, jitsi logs in /var/log/litsi do not receive new lines when connecting to the jitsi service, and searching for messages like the ‘Missing …’ message doesn’t help. The computer as well as the jitsi services were rebooted/restarted, but that also didn’t solve the problem.

If anybody has an idea about how to solve this problem, then I’d love to hear it. Thanks in advance for your help.

Is the TLS certificate still valid?

Did you try to restart the Nginx server or the server completely?

Hi emrah,
thx for your reply. I’m using apache2, not nginx, but restarting apache2, and the jitsi services didn’t solve the problem (using
systemctl restart apache2.service jicofo.service jitsi-videobridge2.service). The computer was rebooted a few days ago, and no further changes to the system were made thereafter, so that apparently didn’t solve the problem either.
Wrt the TLS certificate: the computer’s certificate is valid, but maybe you’re right: ‘service prosody status’ reports

portmanager: Error binding encrypted port for https: No certificate present in SSL/TLS configuration for https port 5281

If that might be the cause of the problem, do you maybe have a suggestion about how/where to configure jitsi so that the computer’s certificate is used? Alternatively I could use the install-letsencrypt-cert.sh script, but I’d rather not use two certificates if one’s sufficient.

no this is utterly irrelevant, nothing in Jitsi is using the encrypted connection to prosody. All encryption is done at the web server level that is proxying to prosody. The message can be disabled by uncommenting the line https_ports = { }; in the prosody config file.

Hi gpatel-fr,
Thx for your clarification. In the meantime I checked jitsi’s configuration wrt the used server certificate, and that appears to be
OK. It’s the standard server’s keypair that’s being used, and that certificate is valid, having an expiry date of Feb 18 2021.

Could you test the following command on the client side

curl --head 'https://your-domain/libs/lib-jitsi-meet.min.js?v=4289'

Hm… That’s interesting. When I did that I got

HTTP/1.1 404 Not Found
Date: Mon, 24 Aug 2020 09:05:11 GMT
Server: Apache/2.4.46 (Debian)
Content-Type: text/html; charset=iso-8859-1

which suggests that a link to the libs subdirectory isn’t available from the web server’s root directory. After (re?)defining that link I get

Date: Mon, 24 Aug 2020 09:08:34 GMT
Server: Apache/2.4.46 (Debian)
Last-Modified: Wed, 15 Jul 2020 15:27:29 GMT
ETag: “a99a6-5aa7c8fd01a40”
Accept-Ranges: bytes
Content-Length: 694694
Vary: Accept-Encoding
Content-Type: application/javascript

The result of this is that the original ‘Missing https:…’ message
doesn’t show up anymore, but instead an empty white page is shown, instead of the standard jitsi opening page. Any idea what I might have missed?

Do you have a disk space issue?

df -h

No, that’s not the problem. There’s still 22 GB available on the disk where jitsi’s installed:
/dev/sdb1 30G 6.9G 22G 25% /media/sdb1

That disk contains the usr/ files, and from the root directory
(/dev/sda1 26G 15G 10G 59% /) there’s a link
usr -> /media/sdb1/usr

I also just opened the files ssitest.html and ssitest.shtml and both
show the current time, which is what they’re supposed to do.

This can related in the load balancer if exists or a routing problem.

Did you check with clients from the different locations? This can be related in the client side too

your story suggests that you had a working jitsi server 6 weeks ago, you stopped it, and without anything changed, your restart it and it does not work.
Yet you have latest jitsi stable (the v=4289), while this version was released only on 20 July, that is, less than 5 weeks ago.
Are you sure that nothing was changed in your server between 6 weeks ago and now ?

Hi emrah, hi gpatel-fr,
I don’t think load balancer or routing problem is the issue here. All (other) access to the server works as usual, and there’s no load balancer active.
Considering that the ssitest.html scripts did work, and I initially got a blank screen, I noticed that chromium (normally I’m using firefox) also complained about a missing all.css file. After making that file available from apache’s standard css location I get a grey screen, something that many others also have experienced. About jitsi’s version: after returning I did a standard Debian software upgrade, which will have upgraded jitsi to its latest stable version. Thereafter the computer was rebooted not causing any problems.
Today I tried to open my local jitsi facilities with the effect described in this thread. I think the most likely cause of the problem (considering the missing libs/ and css/ directories) is that somewhere, somehow some links got lost. But it’s hard to figure out what it actually might be. I’ll do some additional checks; if I find something I’ll yell. And of course, if you have any further suggestions, please let me know. In any case: thanks a heap for helping me, so far :slight_smile:

Latest developments:
This morning I completely removed the jitsi files from my system. I also made sure the system was fully updated, and then, using the info in https://jitsi.github.io/handbook/docs/devops-guide/devops-guide-quickstart started to reinstall jitsi from scratch. As my computer isn’t dedicated to jitsi, but provides other services as well jitsi must be accessible from a subdirectory.
Apparently many things have changed since the latest stable version, as several files cannot be found according to apache’s logs. E.g., /config.cf, /interface_config.js, /logging_config.js. I fixed those missing links by providing Location specifications in apache’s config file, and then encountered errors I also saw yesterday: apache complaining about missing files like /base.html and /title.html , and when opening the jitsi-meet location I received a grey screen with a message about missing files, specifically mentioning. https://…/libs/lib-jitsi-meet.min.js?v=4289.
At that point I decided to ‘throw in the towel’. I give up: too many changes for which I cannot find proper documentation, and solving those problems would simply require too much time. E.g., none of those changes is documented in the provided changelog.Debian.gz file. It’s frustrating, but maybe/hopefullly at some point proper documentation will become available about how to configure jitsi when using it from a subdirectory. In the meantime I’ll have to fall back on the jit.si site itself. So be it.
Emrah and gpatel-fr: thanks again for you help and advice. Your help was much appreciated.

1 Like

to be candid I never grasped that it was the problem. If you look at the public instances list, you will see that almost all are built with the subdomain model (meet.mydomain.com). It is really so much easier.

I’m sure you’re right. But I can’t use a subdomain, and previously the subdirectory approach worked perfectly well.