---
title: Le package Jitsi-Meet : la fête du slip
date: 2019-05-23
author: raspbeguy
template: post
tags: Auto-hébergement,jitsy,Tutoriels,video,XMPP
---

Aujourd'hui j'ai du installer un serveur Jitsi Meet pour un client. Je ne l'aurais pas prévu mais ça a été la grosse galère pour des raisons tout à fait singulières.

Jistti Meet, pour ceux qui ne le connaissent pas, c'est une solution libre pour faire des discussion vidéo qui s'appuie entre autres sur les technologies XMPP et WebRTC. En gros ça a l'avantage de s'appuyer sur une techno de communication existante et ça ne demande pas d'installation de programmes autres qu'un navigateur un minimum récent. C'est compatible Firefox, Chrome, Edge, pour ne citer qu'eux.

Pour faciliter l'installation, Jitsi met à disposition des dépôts APT permettant d'installer sans galérer cet outil clef en main. En théorie seulement car en pratique il faut quelques étapes préliminaires afin que tous les rouages s'emboîtent correctement.

J'ai donc déployé une nouvelle VM sous Debian Stretch toute nue et j'ai installé les packets.

```
echo 'deb https://download.jitsi.org stable/' >> /etc/apt/sources.list.d/jitsi-stable.list
wget -qO - https://download.jitsi.org/jitsi-key.gpg.key | apt-key add -
apt update
apt install jitsi-meet
```

L'installeur pose ensuite quelques questions :

- La première porte sur le nom du service (comprendre ici le FQDN).
- La seconde vous demande si vous souhaitez utiliser votre propre certificat ou bien générer un certificat auto-signé. Moi je suis parti sur mon propre certificat, ce qui active les deux questions suivantes.
- Le chemin du fichier de clef.
- Le chemin du fichier de certificat.

Je me dis : cool, cela a l'air de s'être bien passé. Mais je me trompais.

J'ai refais l'installation plusieurs fois en variant plusieurs paramètres : certificat, chemin des fichiers, installation du reverse proxy avant... Dans certains cas j'avais droit à un handshake TLS foireux, dans d'autres cas des comportements bizarre comme l'impossibilité de rejoindre une room, et dans le reste des cas des erreur APT/DPKG.

Il se trouve que l'unique suite d'opération qui ait fonctionné pour moi est la suivante :

- Installer nginx (ou apache si vous aimez utiliser un tank pour casser un œuf). De cette façon, le paquet Jitsi va détecter la présence d'un proxy et va tout seul ajouter son vhost.
- Obtenir vos certificats (letsencrypt si vous le souhaitez) et faire en sorte que nginx écoute sur les ports 80 et 443) **avant l'installation de Jistsi**. Si ce n'est pas le cas, le processus java de Jitsi va s'approprier les ports 80 et 443 ce qui va créer une erreur au moment de recharger nginx avec la nouvelle configuration. C'est délicat comme position...
- Finalement, installer Jitsy.

J'ai écrit cet article pour économiser un peu de temps au prochains admin qui devront installer ça. Par ailleurs, il est possible que lorsque vous lancerez votre première room, un bug vous frappe: à chaque fois que quelqu'un d'autre rentre dans la room, l'occupant actuel est éjecté... Selon [la page du bug sur Github](https://github.com/jitsi/jitsi-meet/issues/2172), un reboot de la machine suffit et le bug ne se reproduit apparemment plus. Pour moi ce n'est pas satisfaisant d'appliquer des méthodes à la Windows, mais j'avoue que je n'ai pas eu le courage de chercher plus longtemps.
