Partage on Zwindler's Reflection

Ta visio Open Source comme un pro avec Jitsi

Tue, 17 Mar 2020 07:55:00 +0000

Jitsi Meet au secours de la France qui télétravaille

COVID-19 oblige, j’ai un peu modifié l’ordonnancement de mes articles pour reparler d’un sujet que j’avais traité il y a 3-4 ans : la visioconf avec Jitsi Meet. Pourquoi ce sujet ? D’abord parce que pas plus tard qu’il y a 5 jours, NextInpact (mon journal préféré) a relayé les mésaventures de Framasoft suite à l’épidémie.

En effet, Framasoft (que vous connaissez forcément) propose de longue date des outils/services en ligne gratuit. Le souci, c’est que le but est ici d’éduquer les gens et leur montrer qu’on peut autohéberger de nombreux services habituellement payants chez de gros éditeurs (ou gratuits en échange de vos données personnelles).

Mais, pris par la panique de devoir passer tout un tas de gens à l’arrache sur un mode massivement télétravail, beaucoup de gens se sont tournées vers des solutions toutes prêtes, surchargeant au moins de manière temporaire les serveurs de Framasoft.

Mais vous l’avez bien compris, le but, c’est d’apprendre à faire soit-même, comme le fait Framasoft, avec Jitsi Meet :).

Notes additionnelles

Si jamais vous cherchez des solutions toutes faites, sachez que de nombreuses entreprises de la tech mettent à disposition ce genre de solutions de manière temporairement gratuite pour soulager les équipes IT et “faire leur part” pour lutter contre la propagation du virus. Les derniers en date sont OVH qui propose un service de téléconférence gratuit jusqu’à 24h et 50 participants, mais j’ai aussi entendu parlé de discord pour de la visio à 50 et d’autres services qui font sauter leurs limites habituelles dans le contexte Coronavirus.

Parallèlement à cet article sur Jitsi, sachez que NextCloud propose une alternative libre (NextCloud Talk) dans la dernière version. Je ne l’ai pas encore testée, mais la communauté NextCloud FR est très active je suis sûr qu’ils ont du faire des tutos (Genma ?).

Et Jitsi dans tout ça ?

C’est quoi exactement Jitsi ?

Multi-platform open-source video conferencing

Share your desktop, presentations, and more

Invite users to a conference via a simple, custom URL

Edit documents together using Etherpad

Pick fun meeting URLs for every meeting

Trade messages and emojis while you video conference, with > integrated chat.

C’est donc une plateforme relativement complète de visio, a priori plutôt scalable (possibilité de faire des confs à plus de 100), qui permet de partager son écran et de chatter.

Le gros avantage c’est que c’est dans un navigateur et que c’est très simple d’utilisation. On ouvre la page web, on rentre un nom de salle dans une barre de texte, et voilà.

Installation

Avant de commencer, je me suis posé la question du sizing. Nécessairement ça va dépendre fortement de la charge que vous attendez, mais sachez qu’au minimum il vous faudra une machine avec 1 vCPU et 1Go de RAM. Le double serait le mieux, car Jitsi se compose de plusieurs applications Java (c’est donc un peu gourmand même sans charge).

https://jitsi.github.io/handbook/docs/devops-guide/

En soit, l’installation de Jitsi est assez triviale, en particulier sur une Debian ou une Ubuntu récente.

Instruction d’installation disponibles sur https://jitsi.org/downloads/ubuntu-debian-installations-instructions/

Ici, voilà les commandes que j’ai tapé pour installer Jitsi sur une Ubuntu 18.04 vierge :

sudo apt upgrade
sudo apt install gnupg2
wget -qO - https://download.jitsi.org/jitsi-key.gpg.key | sudo apt-key add -
sudo sh -c "echo 'deb https://download.jitsi.org stable/' > /etc/apt/sources.list.d/jitsi-stable.list"
sudo apt update
sudo apt install jitsi-meet

Lors de l’installation, le terminal nous promptera pour le nom d’hôte public sur lequel le service sera disponible et si on souhaite générer un certificat ou en fournir un soit même.

Cependant, comme souvent avec les sites qui disent “regardez c’est trop simple d’installer notre soft, c’est juste apt install monsoftgenial, en vrai il manque des bouts ;)

Firewall

A moins d’avoir une machine chez un cloud provider pas trop regardant et sur laquelle vous installez le soft sans se poser de question, vous allez probablement avoir mis (ou vouloir mettre) du filtrage de port devant vos serveurs. Comme vous vous en doutez, il va falloir ouvrir des ports pour que ça fonctionne correctement. On trouve l’info des ports utilisés par Jitsi dans la documentation d’installation (un peu plus complète) disponible sur Github. Grosso modo, si tous les composants de jitsi sont installés sur la même machine, vous avez les ports suivants à ouvrir sur Internet (ou en LAN si vous ne souhaitez utiliser Jitsi que sur votre réseau Interne) :

443/TCP pour le serveur web de la page d’accueil
4443/TCP (jitsi-meet videostream)
10000 => 20000 en TCP et en UDP

La dernière plage de 10000 port est très probablement bien trop grande dans une grande majorité des cas et peut normalement être configurée dans Jitsi (mais je n’ai pas les commandes exactes).

Jitsi dans un réseau NATé

Je n’allais pas commander une nouvelle machine juste pour mes tests Jitsi. J’ai donc installé une VM sur mes hyperviseurs persos, dans lequel le réseau virtuel est NATé.

Et manque de bol, dans ce cas là, il faut ajouter deux lignes dans un fichier de configuration (deux lignes que j’ai mis du temps à trouver mais qui sont là aussi, dans la doc… Passons).

~~Dans la machine sur laquelle vous avez installé Jitsi, ouvrez le fichier suivant et ajoutez y les deux lignes qui suivent (en remplaçant bien entendu les parties entre crochets par les vraies IPs).~~

[Edit]La configuration a maintenant changé, vous n’avez plus besoin de renseigner les IPs publiques/privées. Il suffit de supprimer les lignes avec les IPs et de mettre les deux autres à la place (ce qui a l’immense avantage de permettre les IPs dynamiques).

vi /etc/jitsi/videobridge/sip-communicator.properties
#org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=[IP_MACHINE_LAN]
#org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS=[IP_PUBLIQUE_SERVICE]
org.ice4j.ice.harvest.DISABLE_AWS_HARVESTER=true
org.ice4j.ice.harvest.STUN_MAPPING_HARVESTER_ADDRESSES=meet-jit-si-turnrelay.jitsi.net:443

Premier test

Maintenant qu’on a configuré le firewall et la configuration spécifique pour le NAT, on essaye de faire sa première conf et … voilà ce que ça donne :

Comme vous pouvez le voir sur ce superbe cliché, j’ai connecté 3 devices, dont un smartphone, depuis mon wifi vers mon serveur chez Hetzner. J’ai testé avec Chrome et Firefox, les deux fonctionnent mais il arrive que Jitsi conseille plutôt d’utiliser Chrome. Historiquement, c’était bien mieux supporté, en tout cas. Pour le smartphone, il existe une application sur l’Android Store et sur F-Droid qui m’a paru assez complète.

Partage d’écran

C’était une des déceptions que j’avais eu il y a 3 ans lorsque j’avais essayé l’outil. On teste et on se dit : “Cool, la vidéo fonctionne… Mais qu’en est-il ?” Et là c’est (c’était) le drame. A l’époque, j’avais surtout fais le tuto pour cette partie, car il était nécessaire de compiler soit même une extension pour chaque navigateur (et je n’avais réussi à faire fonctionner que celle de Chrome (cf mon précédent article). Heureusement, aujourd’hui, ça fonctionne out of the box ! Avec quelques limitations tout de même. Si sur Chrome, j’ai pu partager n’importe quelle de mes fenêtres ouvertes, je n’ai réussi à partager que mon navigateur avec Firefox. Je ne sais pas si c’est un souci de mon côté ou une limitation de l’outil.

Quelques features sympa

Dans les fonctionnalités “nice to have”, il existe comme dans un autre outil propriétaire qui en fait massivement la pub à la télé, la possibilité de flouter le fond pour qu’on ne voit pas le bazar que c’est chez vous par exemple. Ça marche assez bien mais ça consomme énormément de CPU (surtout si vous avez un portable avec un CPU un peu faiblard) et ça rajoute quand même un peu de latence.

On peut espérer que cette fonctionnalité encore en bêta finira par s’améliorer.

Ma tête n’est pas floutée, c’est l’essentiel…

Le chat fonctionne bien mais la gestion des emoji se limite à une 15aine de signe. Quand on est habitué à Slack et aux émoji personnalisés, c’est vraiment pauvre…

Il existe bien entendu une fonction pour demander la parole (et ainsi éviter que ça soit le bazar quand on est nombreux), ainsi que des fonctions pour se mute ou couper sa caméra.

On peut également choisir sa qualité vidéo et voir la bande passante sur le poste local.

Mais quelques manques

Je n’ai pas eu le temps de jouer extensivement avec l’outil, mais il me semble qu’une partie de mes remarques d’il y a 3 ans sont cependant toujours d’actualité.

L’outil se veut simple : pas d’inscription nécessaire et réunion simple à créer. Le corollaire est que l’outil est parfois simpliste. Pas d’interface d’administration pour vérifier (voire limiter) les consommations de bande passante au niveau global sur le serveur, qui est connecté et quand, etc.

De même, n’importe qui, de base peut créer une conférence. Si on est un peu parano on peut s’imaginer plein de choses… (A noter, on peut protéger l’accès à une conférence par un mot de passe une fois qu’on l’a créée).

Bref, quelques points encore à améliorer pour avoir une solution 100% équivalente aux acteurs payants. Ces mêmes points qu’il y a 3 ans et qui avaient des solutions de contournement mais non triviales (notamment Openfire). Donc à voir si c’est toujours le cas aujourd’hui.

Mais en attendant que je me penche là dessus, enjoy :)

Sources et bonus

Partage de VMDK entre plusieurs VMs

Wed, 07 Jan 2015 16:05:17 +0000

Si vous déjà voulu faire un POC de cluster Linux sur des machines virtuelles VMware, vous vous êtes déjà demandé comment vous alliez faire pour partager entre deux serveurs un espace de stockage commun à ces deux machines.

Une façon de faire consiste à rajouter une couche d’abstraction du stockage au dessus de l’OS (via GlusterFS ou DRBD par exemple), mais dans le cas d’un POC pour valider un cluster connecté au SAN, ce n’est pas forcément la première solution qui vient à l’esprit. Personnellement, la plupart des clusters que je construis sont encore dans un schéma plus simple à base de LUNs iSCSI ou FC partagés sur un SAN en actif/actif ou actif/passif.

Cependant, pour simuler ce fonctionnement sur vos VMs, il va falloir bidouiller un peu.

En effet, pour éviter toute erreur malencontreuse (et même désastreuse), VMware interdit par défaut le démarrage de toute machine virtuelle qui aurait un disque en cours d’utilisation par une autre machine virtuelle. Aïe…

Voici un petit mode opératoire pour s’en sortir ;-)

Dans ce mode opératoire, les disques qu’on souhaite partager entre les deux serveurs sont des disques LVM en miroir, hébergés sur les baies de disques qui sont accessibles depuis les deux serveurs ESXi.

Cet exemple permet de valider la fiabilité de la méthode dans le cadre d’un cluster Linux virtuel de type RedHat Cluster Suite. Le principe reste tout de même valide pour une utilisation en dehors de RedHat Cluster Suite, certaines opérations ne seront juste pas nécessaires (qui peut le plus peut le moins).

Prérequis

Pour les besoins de la documentation, deux machines virtuelles test_partage_vmdk_1 et test_partage_vmdk_2 ont été créés. Elles disposent des caractéristiques techniques suivantes :

test_partage_vmdk_1
- hébergée sur ESXi1
- RedHat Entreprise Linux 5.8
- 2 vCPU, 1 Go de RAM
- 50 Go de disque interne sur un espace partagé
- IP 192.168.111.1/24 sur un réseau virtuel
test_partage_vmdk_2
- hébergée sur ESXi2
- RedHat Entreprise Linux 5.8
- 2 vCPU, 1 Go de RAM
- 50 Go de disque interne sur un espace partagé
- IP 192.168.111.2/24 sur un réseau virtuel

Création des disques virtuels

Les machines test_partage_vmdk_1 et test_partage_vmdk_2 doivent être éteintes avant de réaliser les modifications.

Ouvrir les paramètres de la machine virtuelle test_partage_vmdk_1, et ajouter un nouveau périphérique (Disque dur).

Le provisionnement du disque doit impérativement être « statique immédiatement mis à zéro ». De plus, il doit aussi être hébergé sur un datastore commun aux deux machines physiques ESXi.

Créer le disque et l’affecter à un Nœud périphérique virtuel qui n’est pas encore utilisé.

Ici, le disque interne est stocké sur l’adresse SCSI (0:0). Par défaut VMware propose de créer le disque à la suite en SCSI (**0:**1).

Il faut impérativement dérouler la liste pour affecter le disque à l’adresse SCSI (**1:**0) qui représente un nouveau contrôleur SCSI.

De plus, pour permettre l’usage des snapshots sur la partie disque dur interne, les disques doivent être créés en Mode Indépendant/Persistant. Dans le cas contraire, les snapshots seront impossibles sur la machine virtuelle.

Une fois le disque créé, un nouveau contrôleur SCSI est également créé. Avant de valider la création du disque et du contrôleur SCSI, il faut modifier le paramètre de Partage de bus de SCSI en mode « Physique ».

[4]Le second disque dur devra être créé de la même manière, et affecté au même contrôleur SCSI (on prendra l’adresse 1:1).

Remettre test_partage_vmdk_1 sous tension.

Ajout des disques virtuels sur la deuxième machine virtuelle

Ouvrir les paramètres de la machine virtuelle test_partage_vmdk_2, ajouter un nouveau périphérique (Disque dur) puis sélectionner « Utiliser un disque virtuel déjà configuré ».

Sélectionner le premier disque créé précédemment.

De la même manière que précédemment, on doit créer un disque dur virtuel sur un nouveau contrôleur SCSI et en mode Indépendant-Persistant.

Modifier le nouveau contrôleur SCSI comme précédemment :

Ajouter enfin le second disque de la même manière à l’adresse SCSI (1:1).

Valider et mettre la machine virtuelle sous tension. Si elle boot correctement c’est que le partage fonctionne.

Créer le miroir LVM partagé

Sur les deux serveurs, exécuter les commandes suivantes :

chkconfig acpid off #seulement pour RHCS
service acpid stop #seulement pour RHCS
vi /etc/lvm/lvm.conf
     filter = [ "a/.*/" ]
   #filter = [ "a|/dev/cciss/.*|", "a|/dev/mpath.*|", "r|.*|" ] #utiliser cette ligne en cas d’utilisation de multipath et de disques locaux présentés en tant que /dev/cciss. A adapter au contexte
[…]
volume_list = [ "vg01" , "@[TAG]" ]

Dans le cas de RedHat Cluster Suite, remplacer [TAG] par le nom de la machine tel qu’il est définit dans le fichier /etc/cluster/cluster.conf.

En dehors du cas d’un traitement automatisé par cluster, n’importe quel tag convient du moment qu’il est unique à la machine. Dans le cas présent, les tags choisis sont respectivement tag_vm1 et tag_vm2.

Quelques précisions :

filter permet de traiter les cas où on doit ignorer certains disques. C’est typiquement nécessaire lorsque l’on utilise LVM avec multipath ou powerpath, car l’OS voit plusieurs « disques » sda ,sdb, … pour un même disque mpath (1 sdX pour chaque chemin vers mpathY).
volume_list indique à LVM que seul le vg01 (interne) et les VG explicitement taggués avec le nom de la machine qui peuvent être utilisés. Cela permet de s’assurer qu’il n’y a qu’une seule machine qui peut activer le VG du moment qu’on n’ajoute jamais plus d’un tag au VG.

Même si les modifications du fichier lvm.conf sont prises en compte immédiatement, RedHat Cluster Suite impose une recompilation de l’initrd. Dans le cas d’un cluster RHCS, il faut donc lancer la commande suivante :

mkinitrd -f /boot/initrd-$(uname -r).img $(uname -r)

Sur un seul nœud (le premier) :

pvcreate /dev/sdb
pvcreate /dev/sdc
vgcreate -c n vg_mirror /dev/sdb /dev/sdc

Tagger le VG pour pouvoir travailler dessus sur ce nœud.

vgchange --addtag tag_vm1 -ay vg_mirror
lvcreate -n lv_mirror -m1 -l 5116 /dev/vg_mirror
Logical volume "lv_mirror" created

Le journal des écritures doit lui aussi être en miroir

lvconvert --mirrorlog mirrored /dev/vg_mirror/lv_mirror
Logical volume lv_mirror converted.

Il est enfin possible de formater le disque, et de le monter sur le test_partage_vmdk_1

mkfs.ext3 /dev/vg_mirror/lv_mirror
mount /dev/vg_mirror/lv_mirror /mnt

Tester la bascule

Scanner les VGs pour vérifier que le nouveau VG est bien disponible sur le test_partage_vmdk_2

vgscan
vgs

Même s’il le VG est visible, il n’est pas possible de le monter car il n’a pas le bon tag (tel que spécifié dans le lvm.conf). Cela permet de vérifier que l’on ne pourra pas écrire sur les disques sur les deux nœuds en même temps.

Not activating vg_mirror/lv_mirror since it does not pass activation filter.
0 logical volume(s) in volume group “vg_mirror” now active

On peut démonter le FS, désactiver le vg et enlever le tag sur le serveur test_partage_vmdk_1 et vérifier qu’on peut bien le monter et écrire dessus sur le test_partage_vmdk_2.

Ce comportement est automatique sous RedHat Cluster Suite, qui gère lui même les tags lors de la bascule d’un VG/LV.

Sur test_partage_vmdk_1

umount /mnt
vgchange --deltag tag_vm1 -an vg_mirror

Sur test_partage_vmdk_2

vgchange --addtag tag_vm1 -ay vg_mirror
mount /dev/vg_mirror/lv_mirror /mnt

Have fun