Jitsi Meet est un formidable outil de visioconférence qui tient la dragée haute aux ténors du secteur comme Zoom, LiveStorm, Whereby et consors. Le niveau de fonctionnalités est très élevé, avec le chat et le partage d’écran par exemple. Mais surtout, utiliser votre propre infrastructure avec votre propre serveur vous permet d’éviter les périodes de surcharge des infrastructures mutualisées précédemment citées. Enfin, ce système vous permet de gérer une vingtaine de personnes simultanément connectées à un même meeting gratuitement, et avec un serveur relativement modeste.
Voici comment installer Jitsi Meet sur votre propre serveur.
L’originalité de cet article consiste en la configuration multi-domaines pour une seule et unique installation.
Prérequis
Il vous faut un serveur Linux, ici une VM sous Debian 10 vierge, équipé de 2 vCPU et 4 Go de RAM.
Un domaine ou sous-domaine dédié de type visio.mon-domaine.fr sera utilisé.
Installation de Jitsi Meet
Pour ma part j’ai suivi les instructions de la page de Scaleway.com pour installer Jitsi sur une VM Debian 10. Très simple et très rapide.
Vérification que le domaine utilisé pour Jitsi Meet pointe vers 127.0.0.1 dans le fichier /etc/hosts.
1 2 |
127.0.0.1 localhost 127.0.1.1 visio.mon-domaine.fr |
Mise à jour, le cas échéant (apt est un système des distributions basées sur Debian).
1 2 3 |
# apt update # apt upgrade # apt dist-upgrade |
Installation de dépendances.
1 |
# apt-get install gnupg2 |
Ajout du dépôt Jitsi et de sa clé GPG.
1 2 |
# 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 - |
Installation de Jitsi Meet. Le serveur nginx sera installé si aucun serveur web n’est présent sur le serveur.
1 |
# apt install -y jitsi-meet |
Lors de l’installation j’ai précisé de créer un certificat SSL Let’s Encrypt ultérieurement comme ceci :
1 |
# /usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh |
Et ce n’est pas plus compliqué que cela. Merci Jitsi.
État des lieux
- La configuration du système se trouve dans /etc/jitsi
- Le fichier de configuration de l’interface web est /etc/jitsi/meet/visio.mon-domaine.fr-config.js
- L’application web en tant que telle est dans /usr/share/jitsi-meet
- La configuration du serveur web est dans /etc/nginx/sites-ensabled/visio.mon-domaine.fr.conf
Je remarque une charge CPU de 0.30 et une occupation mémoire de 600 Mo avec 4 personnes connectées et un partage d’écran en cours. La bande passante consommée est de 300 Ko/s down et 150 Ko/s up pour une qualité de service parfaite.
Utilisation
Sur un ordinateur équipé de Firefox ou de Chrome, vous pouvez vous rendre sur https://visio.mon-domaine.fr. Il parait que Chrome est mieux conseillé que Firefox pour cette application mais je ne m’en suis pas rendu compte.
Les utilisateurs de smartphones ou de tablettes peuvent également utiliser ce lien pour rejoindre le salon, mais il leur sera demandé d’installer l’application native Jitsi Meet.
Pour l’utilisation de l’application vous pouvez vous référer à l’article de makina-corpus.com ou 01net.com.
Configuration de Jitsi Meet en multi-domaines
Si vous souhaitez utiliser Jitsi Meet sur un sous-domaines principal comme visio.mon-domaine.fr et aussi sur un domaine secondaire visio.mon-domaine2.fr vous pouvez configurer une VM et une installation par domaine, bien entendu. Les accros à Docker peuvent utiliser Docker.
Mais après quelques recherches et la consultation de la page suivante sur le forum du projet, j’ai découvert qu’il était possible d’exploiter une même installation sur plusieurs domaines. Cela m’a beaucoup plu car je n’aime pas la lourdeur inutile même avec une virtualisation KVM que j’aime beaucoup, ou Docker.
Dans /etc/nginx/sites-enabled/visio.mon-domaine.fr :
Remplacer la ligne commentée par la ligne du dessous pour que la même application web soit accessible depuis deux domaines :
1 2 |
# server_name visio.mon-domaine.fr; server_name visio.mon-domaine.fr visio.mon-domaine2.fr; |
De plus, l’application derrière Jitsi Meet essaye par défaut d’obtenir le domaine de référence depuis le domaine du serveur. Dans le cas multi-domaines cela entraine une confusion, et il faut donc hardcoder le nom de domaine principal dans la configuration du serveur web.
1 2 |
# proxy_set_header Host $http_host; proxy_set_header Host visio.mon-domaine.fr; |
J’ai aussi opéré le changement suivant sans juger de sa nécessité.
1 2 |
# ssi_types application/x-javascript application/javascript; ssi_types *; |
Enfin, assurez-vous que le chemin vers le certificat SSL pointe vers un certificat multi-domaines généré par exemple comme ceci :
1 |
# certbot certonly --standalone -d visio.mon-domaine.fr,visio.mon-domaine2.fr --pre-hook="service nginx stop" --post-hook="service nginx start" |
Pour en savoir plus sur certbot, voir mon article détaillé.
Dans /etc/jitsi/meet/visio.mon-domaine.fr-config.js :
Il faut utiliser une syntaxe plus permissive pour obtenir le domaine en vigueur depuis une variable d’environnement et non pas hardcodée. C’est en quelque sorte l’opération inverse de ce que nous venons de faire dans nginx.
Je ne sais pas quel est le dialecte en vigueur qui me permet d’ajouter des commentaires HTML dans du code JS mais c’est correct.
1 2 |
// bosh: '//visio.mon-domaine.fr/http-bind', bosh: '//<!--# echo var="http_host" -->/<!--# echo var="subdir" default="" -->http-bind', |
Un redémarrage du serveur ou des services Jitsi ne peut pas faire de mal.
1 2 3 |
# service nginx restart # service jicofo restart # service jitsi-videobridge2 restart |
Conclusion
Vous pouvez maintenant vous connecter à Jitsi Meet depuis https://visio.mon-domaine.fr/meeting-room ou encore https://visio.mon-domaine2.fr/meeting-room.
A noter qu’il n’y a pas d’isolation des meeting room entre les deux domaines. Donc si deux utilisateurs utilisent chacun le lien ci-dessus, ils se rencontreront.
Mais pour un cas de figure où des noms de meeting room différents sont choisis sur chacun des domaines, cette installation est très efficace.
Bonjour et merci pour votre post.
Lors de la configuration du fichier host, pour le coup, ça ne devrait pas être 127.0.0.1 localhost domain ?
De plus, une petite question pour vous, vous aurez peut être une solution. J’ai implémenté mon instance Jitsi sur un serveur Ubuntu. Je peux créer des meetings, tout est parfait. Comment éviter que des personnes utilisent mon instance à mon insu et me prennent des ressources ? Y aurait-il une intégration possible d’une authentification pour la création d’un meeting ?
Merci et belle journée,
Fabien
Ah désolé… Trouvé… https://github.com/jitsi/jicofo#secure-domain
Je ne me suis pas encore renseigné sur le sujet mais ceci est intéressant ! J’aurais naturellement envisagé quelque chose dans le serveur web à base de http_basic ou http_digest.
Du coup, j’ai pu intégrer une authentification via openldap lors de la création et du lancement d’un meeting : https://github.com/jitsi/jitsi-meet/wiki/LDAP-Authentication. Ceci garantie que ce sont les employés de mon entreprise qui utilisent le service en premier. Tout petit bémol, il faut ouvrir certains ports supplémentaires, mais rien de méchant.
bonjour
après 2 tentatives, j’ai bien installé jitsi sur une machine 32bits, debian10, 4Go de ram
en appelant le sous domaine, jtsi s’ouvre correctement mais j’obtiens une erreur :
Error occurred during initialization of VM Could not reserve enough space for 3145728KB object heap
il semblerait qu’une machine 32bits ne réserve que 1go
est-ce que quelqu’un a une solution de paramétrage de jitsi pour que ça puisse fonctionner?
merci
rb
Bonjour,
Tout d’abord, je pense qu’en 2020, la place du matériel x86 32 bits est à la recyclerie. N’importe quel micro PC type Raspberry Pi permettra des performances au moins équivalentes pour une fraction de la consommation d’électricité.
Si vous tendez vers l’informatique verte et la réutilisation plutôt que l’achat neuf, on trouve des PC d’occasion pour quelques dizaines d’euros. Exemple avec ce broker informatique.
Vous pouvez installer 4 Go dans la machine, mais environ 3 Go seront utilisables dans un ordinateur 32 bits. Pouvez-vous le confirmer avec la commande
free -m
?Ensuite, le message d’erreur est induit par la machine virtuelle Java et l’argument de mémoire allouable -Xmx3072m.
Apparemment vous pouvez ajouter
VIDEOBRIDGE_MAX_MEMORY=2048m
dans/etc/jitsi/videobridge/config
(source). Vous pouvez essayer une valeur inférieure, naturellement.Cordialement
bonjour et merci de la réponse
j’avais finalement trouvé la/les solutions VIDEOBRIDGE_MAX_MEMORY=1024m dans
/etc/jitsi/videobridge/config et /etc/prosody/conf.d
et tout roule correctement
NB effectivement, je suis dans le recyclage de mon ancien matériel …mais pas que! (Pi et autres objets connectés sont mes joujous de retraité)
Avant de voir en grand, des tests matériels et découverte des logiciels s’imposent à moi.
encore merci
cordialement
RB