For the local future CHATONS (Chatons is a french word which means kitten), I am currently helping to host a new Jitsi-meet instance. This instance will be available at this address: https://conference.facil.services/ and this is a little post about how we did it and what problems we encountered.
First step - The manual installation
For the story, the first attempt for hosting the instance worked during several weeks. But, after a migration to our final server, we started to see a lot of problems with that instance (due to the migration or the installation of the back-up system or the monitoring tools). Anyway, even the logs were odds.
I arrived in this project at this precise moment. So, I decided to start to do my own virtual machine, in my local network (bridge mode) to replicate the final server config (a Debian Stretch, 1 Go RAM, 2 CPUs) and I followed the instructions from this page: https://github.com/jitsi/jitsi-meet/blob/master/doc/quick-install.md
The only big difference between my setup and the final server is that the VM is only available in my local network, so I used an auto-signed certificate instead of our Let’s Encrypt certificate. But we saw that the instance was functionnal and we did some conferences with multiple participants.
Because everything seemed to work, I did the same steps (with the auto-signed certificate) but on the final production server (in a clean state). Again, we did some tests and the instance was working great. So the next step is to setup the back-up system, monitoring tools and automate the installation of Jitsi and the certificate.
Second step - Automate all the things
Ansible is used ot automate the installation of our servers. And, to avoid to re-invent the wheel, we use existing ansible roles made by others. For Jitsi, I found this project: https://github.com/freedomofpress/ansible-role-jitsi-meet
Even if the role is not up-to-date (last commit is from 2017), a pull request exists to update the role and is only 2 months old! Let’s try with that patched role. So, I did this little playbook (jitsi.yml
)
- name: Configure jitsi-meet server.
hosts: [conference]
user: amarok
vars:
jitsi_meet_server_name: conference.facil.services
jitsi_meet_lang: fr
roles:
- role: thefinn93.letsencrypt
become: yes
letsencrypt_email: "webmaster@{{ jitsi_meet_server_name }}"
letsencrypt_cert_domains:
- "{{ jitsi_meet_server_name }}"
tags: letsencrypt
- role: freedomofpress.jitsi-meet
jitsi_meet_ssl_cert_path: "/etc/letsencrypt/live/{{ jitsi_meet_server_name }}/fullchain.pem"
jitsi_meet_ssl_key_path: "/etc/letsencrypt/live/{{ jitsi_meet_server_name }}/privkey.pem"
jitsi_meet_configure_nginx: true
become: yes
tags: jitsi
post_tasks:
# https://github.com/jitsi/jicofo/blob/master/README.md#certificates
- name: Copy root certificate from prosody
become: true
copy:
remote_src: yes
src: "/var/lib/prosody/{{ jitsi_meet_server_name }}.crt"
dest: "/usr/local/share/ca-certificates/"
- name: Copy auth certificate from prosody
become: true
copy:
remote_src: yes
src: "/var/lib/prosody/auth.{{ jitsi_meet_server_name }}.crt"
dest: "/usr/local/share/ca-certificates/"
- name: Run update-ca-certificates for Jicofo
become: true
command: update-ca-certificates
I press the BIG launch button, Ansible is starting and… FAIL. The certificate can’t be created. :sad:
Third step - Debugging the role
First problem, the challenge for the certificate is failing. It was a problem with the nginx
server which were listening only on IPv4, so it was failing for the IPv6 challenge.
Let’s retry. Re-click on the BIG launch button… certificate: OK ; installing Jitsi: OK ; reloading services: NOK. Shit, the website is not responding. Let’s see on the server. I don’t really understand why nginx
is not started, but let’s start it and see if it works. service nginx restart
, I can see that Jitsi is running. I create a new room, nice, the camera is working. Let’s try with somebody else… BOTH SIDES ARE CRASHING :sad:.
Maybe the problem is from the role. I purge all the server, and re-launch the role. Quick note, jitsi-meet-web-config
can’t be removed directly if nginx
is removed before Jitsi. To fix it, you have to remove the following lines from /var/lib/dpkg/info/jitsi-meet-web-config.postrm
if [ -x "/etc/init.d/nginx" ]; then
invoke-rc.d nginx reload
fi
So, the whole role is ok this time. I try to connect two computers and again - crash!
Let’s check the logs. Basically for this kind of issue, Jitsi have at least two interesting log files:
/var/log/jitsi/jicofo.log
which help me to find a littlessl
mis-configuration while I used the auto-signed certificate. This first file is telling me that it can’t find a bridge and indeed,service status jitsi-videobridge
is showing that the bridge is down, killed after a few seconds of life./var/log/jitsi/jvb.log
which are the video bridge’s logs. I can see the following line:Error: Could not find or load main class $JVB_EXTRA_JVM_PARAMS
which is actually a variable in/etc/jitsi/videobridge/config
. So, I remove the line from this file, restart the bridge, start a first device, now the second one. Nice, I can see both cameras! The instance is working now!
Let’s finish the work by installing the monitoring tools, the back-up system, and now, the instance is complete and production ready!
Conclusion
To conclude, if you want to host your own Jitsi instance:
- You can generate your own Let’s Encrypt certificate and follow the quick-install method from Jitsi. It will work great and you will be able to update your instance from time to time.
- I didn’t try in a dockerized environment, but i think this will also work. Some problems may exists, but Santiago is answering fast and already fixed his role!
- If you want to automate the whole process with Ansible, actually you can. The Freedom of Press role is working if you take the patched role.
Finally, if you see some problems with your instances, actually, the logs are complete and useful.