====== Meet jitsi dans un container LXC ====== On suppose que LXC et certbot sont installés, et que l'on veut installer Meet Jitsi sur visio.futuretic.fr. Inspirations : * [[https://wiki.pielo.net/jitsi-meet-sur-lxc|Jitsi Meet sur LXC]] * [[https://jitsi.github.io/handbook/docs/devops-guide/devops-guide-quickstart|Installer Jitsi sur Debian (doc officielle)]] * [[https://debamax.com/fr/blog/2020/03/18/installing-jitsi-behind-a-reverse-proxy/|Installer Meet Jitsi derrière un proxy apache]] ===== Installation du container ===== On crée un container nommé **meet**, sous Debian Buster (10) : lxc-create -t download -n meet -- -d debian -r buster -a amd64 Pas d'ip fixe, config réseau par défaut pour le container. On démarre le container : lxc-start meet On peut voir les congainers ouverts avec la commande : lxc-ls -f On rentre dans le container avec la commande : lxc-attach meet ===== Création des certificats SSL letsencrypt ===== On utilise le virtual host par défaut d'apache écoutant le port 80 et pointant vers un dossier accessible par apache : **/var/www/html**. Il servira à amorcer la création des certificats. Executer cette commande pour générer les certificats : certbot certonly --webroot -w /var/www/html -d visio.futuretic.fr Maintenant que les certificats sont créés, la création des virtual hosts sur les ports 80 (http) et 443 (https) sera abordé plus bas. ===== Installation de meet jitsi ===== Entrer dans le container et installer Jitsi comme décrit dans la [[https://jitsi.github.io/handbook/docs/devops-guide/devops-guide-quickstart|doc officielle]]. ===== Configuration host hostname ===== Sur le host, ajouter dans **/etc/hosts** (changer l'IP du container par la votre) : 10.0.3.211 visio.futuretic.fr Dans le container, ajouter dans **/etc/hosts** : 127.0.1.1 visio visio.futuretic.fr 10.0.3.211 visio.futuretic.fr et dans le fichier **/etc/hostname** : visio.futuretic.fr ===== Création des vhost apache pour proxy le traffic vers le container ===== On crée d'abord le vhost du port 80 qui redirige vers le 443 : nano /etc/apache2/sites-available/visio.futuretic.fr.conf Avec dedans : ServerAdmin user@domaine.tld ServerName visio.futuretic.fr RewriteEngine on RewriteRule ^ https://visio.futuretic.fr%{REQUEST_URI} [END,QSA,R=permanent] Puis le vhost du port 443 : nano /etc/apache2/sites-available/visio.futuretic.fr-le-ssl.conf Avec dedans : ServerAdmin user@domaine.tld ServerName visio.futuretic.fr # Headers for security # Deja fourni par Jitsi # Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains; preload" Header set X-XSS-Protection "1; mode=block" Header set X-Frame-Options "sameorigin" Header set X-Content-Type-Options "nosniff" # SSL config SSLEngine on SSLProxyEngine On SSLProxyVerify none SSLProxyCheckPeerCN off SSLProxyCheckPeerName off SSLProxyCheckPeerExpire off # SSL certificates SSLCertificateFile /etc/letsencrypt/live/visio.futuretic.fr/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/visio.futuretic.fr/privkey.pem Include /etc/letsencrypt/options-ssl-apache.conf # Proxy base parameters ProxyPreserveHost On # Proxy pour certificat DocumentRoot /var/www/html ProxyPass /.well-known ! ProxyPass / https://visio.futuretic.fr/ ProxyPassReverse / https://visio.futuretic.fr/ #ProxyPass "/" "https://10.0.3.211/" #ProxyPassReverse "/" "https://10.0.3.211/" # Set WebSockets RewriteEngine on RewriteCond %{HTTP:Connection} Upgrade [NC] RewriteCond %{HTTP:Upgrade} websocket [NC] RewriteRule /(.*) wss://visio.futuretic.fr/$1 [P,L] RequestHeader set X-Forwarded-Proto “https” RequestHeader set X-Forwarded-Port “443” #SetEnv proxy-sendchunks 1 # Set rights Order deny,allow Allow from all # Logs ErrorLog /var/log/apache2/visio.futuretic.fr.error.log LogLevel error CustomLog /var/log/apache2/visio.futuretic.fr.access.log vhost_combined ===== Réglages Firewall et Réseau ===== ==== Dans le container ==== Installer UFW et autoriser les ports suivant : sudo ufw allow 22/tcp sudo ufw allow 80/tcp sudo ufw allow 443/tcp sudo ufw allow 3478/udp sudo ufw allow 5349/tcp sudo ufw allow 10000/udp sudo ufw enable Configurer le videobridge en modifiant le fichier **/etc/jitsi/videobridge/sip-communicator.properties** : org.ice4j.ice.harvest.DISABLE_AWS_HARVESTER=true # On ne configure pas de serveur STUN pour le moment #org.ice4j.ice.harvest.STUN_MAPPING_HARVESTER_ADDRESSES=meet-jit-si-turnrelay.jitsi.net:443 # Apparemment c'est bien de mettre cette instruction aussi : org.jitsi.impl.neomedia.transform.srtp.SRTPCryptoContext.checkReplay=false # Pour faire fonctionner dans un container LXC, on précise l'IP locale et publique org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=10.0.3.211 # Remplacer XXX.XXX.XXX.XXX par votre IP publique de l'hote, pas du container org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS=XXX.XXX.XXX.XXX org.jitsi.videobridge.ENABLE_STATISTICS=true org.jitsi.videobridge.STATISTICS_TRANSPORT=muc org.jitsi.videobridge.xmpp.user.shard.HOSTNAME=localhost Puis redémarrer videobridge : systemctl restart jitsi-videobridge2 [[https://community.jitsi.org/t/jitsi-users-getting-jitsi-meet-to-work-in-a-container-behind-double-nat/11446/5|Voir ce sujet si embrouilles]]. ==== Sur l'hote ==== Installer UFW et autoriser les ports suivant : sudo ufw allow 22/tcp sudo ufw allow 80/tcp sudo ufw allow 443/tcp sudo ufw allow 3478/udp sudo ufw allow 5349/tcp sudo ufw allow 10000/udp sudo ufw enable Vérifier le status du firewall : sudo ufw status verbose Il faut transférer certains de ces ports au container jitsi (pour 80 et 443, c'est apache sur l'hote qui fait le proxy vers le container). Dans le fichier **/etc/ufw/before.rules**, ajouter au début : *nat :PREROUTING ACCEPT [0:0] # jitsi specific rules -A PREROUTING -i enp8s0 -p udp --dport 10000 -j DNAT --to-destination 10.0.3.211:10000 -A PREROUTING -i enp8s0 -p udp --dport 3478 -j DNAT --to-destination 10.0.3.211:3478 -A PREROUTING -i enp8s0 -p tcp --dport 5349 -j DNAT --to-destination 10.0.3.211:5349 # General postrouting for LXC containers -A POSTROUTING -s 10.0.3.0/24 ! -d 10.0.3.0/24 -j MASQUERADE COMMIT 10.0.3.211 étant l'ip du container. Penser à remplacer l'interface réseau **enp8s0** par la votre. Redémarrer ufw avec sudo ufw disable && sudo ufw enable ou systemctl restart ufw.service ==== Trouble shooting ==== Redémarrer lxc-net service sur l'hote systemctl restart lxc-net.service Dans le container tail -f /var/log/jitsi/jicofo.log tail -f /var/log/jitsi/jvb.log ===== Configurations complémentaires ===== ==== Personnaliser l'interface ==== * Voir [[https://framacloud.org/fr/cultiver-son-jardin/jitsi-meet.html|le guide de Framasoft]] Notamment nano /usr/share/jitsi-meet/interface_config.js et une redirection pour le logo et interface dans le vhost nginx (copier les fichiers correspondants) location = /body.html { alias /var/www/jitsi-custom/body.html; } location = /interface_config.js { alias /var/www/jitsi-custom/interface_config.js; } location = /images/watermark.png { alias /var/www/jitsi-custom/images/logo-futuretic.png; } ==== Réglages serveur STUN ==== On va utiliser ici le serveur STUN proposé officiellement par Meet Jitsi : meet-jit-si-turnrelay.jitsi.net Dans le container, dans le fichier **/etc/jitsi/videobridge/sip-communicator.properties**, veiller à décommenter cette instruction : org.ice4j.ice.harvest.STUN_MAPPING_HARVESTER_ADDRESSES=meet-jit-si-turnrelay.jitsi.net:443 Puis dans le fichier **/etc/jitsi/meet/visio.futuretic.fr-config.js**, dans la section **p2p**, vous devez avoir (config enlevée pour container visio en debian 11) : p2p: { // Enables peer to peer mode. When enabled the system will try to // establish a direct connection when there are exactly 2 participants // in the room. If that succeeds the conference will stop sending data // through the JVB and use the peer to peer connection instead. When a // 3rd participant joins the conference will be moved back to the JVB // connection. enabled: true, // The STUN servers that will be used in the peer to peer connections stunServers: [ { urls: 'stun:meet-jit-si-turnrelay.jitsi.net:443' } ] Enfin, on redémarre le videobridge et jicofo : systemctl restart jitsi-videobridge2.service && systemctl restart jicofo.service Pour voir si le serveur STUN est utilisé, toujours dans le container, executer la commande : tcpdump host meet-jit-si-turnrelay.jitsi.net ==== Désactiver ipv6 ?! ==== nano /etc/sysctl.conf Ajouter la ligne suivante en fin de fichier net.ipv6.conf.all.disable_ipv6 = 1 Appliquer les changements sysctl -p ==== Permettre la diffusion en direct vers autre chose que youtube ==== * Possible de faire de la [[https://community.jitsi.org/t/stream-to-any-or-multiple-rtmp-destinations-record-simultaneously/51943|multi-diffusion via le vhost nginx]] * D'après la documentation, il est possible de [[https://docs.joinpeertube.org/use-create-upload-video?id=with-jitsi-meet|mettre l'adresse rtmp, d'un serveur Peertube par exemple, et la clef de stream directement]] à la place de la clef de youtube (pas réussi à faire marcher) * Apparemment [[https://github.com/jitsi/jitsi-meet/issues/2829|avec cette technique ça marche]] !!! {{::jitsistream.png|}} ==== Hébergement d'un colloque en ligne de plus de 200 personnes via Jitsi ==== Une [[https://indiehosters.net/blog/2021/10/12/retour-experience-visioconference-jitsi-owncast-ingenium.html|super doc proposée par Indiehosters]] sur la config à mettre en place avec l'utilisation complémentaire de [[https://owncast.online/|owncast]] ==== Documentations complémentaires ==== * [[https://wiki.hadoly.fr/documentation_technique:jitsi|Voir la doc d'un chaton]] avec un jitsi derrière un proxy {{tag> bj, serveur, futuretic, lxc, meet_jitsi, jitsi, streaming}}