"Quick-installation" of jitsi-meet user experience

Hello everybody,
thank you very much for providing us with this software. Certainly you have realized raising interest in recent weeks; indeed, need for “virus-proof” communication lead me too to try out jitsi-meet.

By that, I am no expert in videobridging etc, although there is some experience with Linux server maintenance. So I tried the quick-install route of both stable and nightlies versions on a Debian GNU/Linux 9 (stretch) server, set up as LAMP server with Fully Qualified Domain Name (FQDN) and established TLS certificate.

Here is my first eight-hour-experience:

  • The software retrieving process worked well along the Debian/apt-get path: Adding the repositories and subsequent installation on the target system. The basic setup of Jitsi is integrated into this through script(s) automatically. An option of using existing certificates is present and seems to work. In my case an Apache-Webserver is used as web-interface for Jitsi-meet

  • Jitsi-meet consists of a software bundle installed in /usr/share/. A new Apache “virtual host” is configured with a DocumentRoot pointing to /usr/share/jitsi-meet.

  • In order to use an existing FQDN TLS certificate, the virtual host has to serve this FQDN-server name; in my case, this conflicts with other server applications.

  • I did not get jitsi-meet working from a web-server directory linked to /usr/share/jitsi-meet. There is a forum-thread around this idea but the solutions suggested therein did not work for me. The problem is that the custom install seems to rely on a relative directory path names. Suggestions to resolve this imply advanced use of the Apache “Location-” and “Alias-” Directives which unfortuntely went beyond my skills

  • Present firewall setting needed adjustments

  • Set up as main FDQN-website I got jitsi-meet eventually running. The software prompts through a web browser client as expected. By default there seems to be no access limitation, so everybody can connect.

  • Using both Google Chrome and Mozilla Firefox on two independent computers as test clients, I was not able to establish a shared conference room; different clients logged into identical conference were in video & audio contact with the server only without realizing each other.

  • The established conference “selfsessions” could not be protected by password

So, after all, I wasn’t able to get the desired solution on the basis of the “quick-install”. It were very helpful if a user guide could be provided.

Again, thanks for your efforts…
Best, Oll1

Just a self-update.

The problem regarding the missing conference capability has been solved meanwhile:
The logfile /var/log/jitsi/jicofo.log indicated

Jicofo 2020-04-08 13:11:15.236 SEVERE: [16] util.UtilActivator.uncaughtException().122 An uncaught exception occurred in thread=Thread[pool-5-thread-1,5,main] and message was: unable to create new native thread

With this and hints by Toberl and Fensterkreuz here the attention was directed to the systemd details in the quick installation guide. Following te advice to adjust the parameters

DefaultLimitNOFILE=65000, DefaultLimitNPROC=65000, DefaultTasksMax=65000

in /etc/systemd/system.conf and subsequent systemctl daemon-reload, service jitsi-videobridge2 restart helped to fix the problem. So eventually, the system is serving. :slightly_smiling_face:

What is the available RAM on the machine for the processes?

$ cat /proc/meminfo
MemTotal: 4194304 kB