Matrix

Cette page porte sur l’installation, la configuration et la maintenance de notre instance Matrix. Pour vous renseigner sur nos usages de Matrix et son rôle dans notre communication interne, rendez-vous dans la catégorie Communication.

Fonctionnement🔗

Matrix est un protocole de messagerie instantanée qui comporte plusieurs caractéristiques fondamentales :

• décentralisé : les serveurs Matrix peuvent être hébergés par n’importe qui, le fonctionnement de la messagerie ne dépend pas d’une instance centrale ;
• fédéré : de la même manière que les emails, chaque utilisateur·ice peut s’inscrire sur n’importe quelle instance de serveur Matrix et communiquer avec des personnes inscrites sur d’autres instances de manière transparente ;
• chiffré : Matrix supporte nativement le chiffrement de bout-en-bout, et la plupart des serveurs Matrix chiffrent même les conversations privées par défaut ;
• libre et open-source : les spécifications de ce protocole sont publiques et le code source des clients et serveurs les plus utilisés est également ouvert.

L’entreprise derrière le développement du protocole Matrix maintient également des implémentations de serveurs Matrix (Synapse, Dendrite) ainsi qu’un client (Element) disponible sur toutes les plateformes (mobile, web, desktop), et il s’agit des implémentations client et serveur les plus utilisées.

Historique🔗

Quelques mois après sa création, La Contre-Voie a rapidement adopté Matrix pour sa communication interne, après une expérimentation rapide de XMPP relativement peu fructueuse.

À la base, Matrix a été utilisé comme moyen de s’organiser entre les membres de l’association présents à 42 Paris (l’école d’informatique dans laquelle La Contre-Voie est née), d’où l’usage de l’authentification unifiée avec l’intranet de 42 sur notre service. Pour l’instant, les personnes extérieures à 42 ne peuvent donc pas créer de compte. Toutefois, cela n’empêche pas des personnes extérieures de rejoindre nos canaux grâce à la fédération.

À terme, l’authentification unifiée avec 42 sera retirée (voir la section Évolutions envisagées.

Installation🔗

L’installation d’un serveur Matrix nécessite de nombreuses composantes :

• le serveur de messagerie, Synapse pour notre part ;
• le client de messagerie, nous proposons une instance web du client Element ;
• le serveur d’identité (Sydent) qui sert uniquement à la découverte de contacts, mais qui est obligatoire à installer pour éviter d’utiliser celui de l’instance principale matrix.org ;
• le serveur vocal : nous utilisons le serveur TURN/STUN Coturn et préparons une migration vers Element Call ;
• la base de données PostgreSQL, également utilisée par d’autres services.

Une documentation pour installer chacun de ces logiciels est consultable sur leurs sites web respectifs.

Synapse🔗

Nous utilisons l’image officielle matrixdotorg/synapse sans modification ; retrouvez nos fichiers de configuration du déploiement dans notre dépôt Core.

Un volume est monté depuis notre serveur NFS qui contient le fichier de configuration de Synapse et le dossier des contenus multimédia envoyés.

Element🔗

Notre image de Element est basée sur l’image officielle vectorim/element-web, modifiée pour faire fonctionner le serveur nginx intégré sans privilèges, modifier la page d’accueil et intégrer notre configuration du logiciel.

Sydent🔗

Nous utilisons l’image dotwee/matrix-sydent sans modification. Ses paramètres de déploiement sont consultables sur notre dépôt Core.

Serveur vocal🔗

Nous avons modifié l’image officielle coturn/coturn (variante alpine) pour y ajouter simplement son fichier de configuration, voir son dossier sur le dépôt Core.

Nous déconseillons toutefois l’usage de Coturn comme serveur vocal : ce service se fait spammer de requêtes (très nombreuses requêtes) et ne permet pas de journaliser les IPs qui effectuent ces requêtes, dans la perspective de les bannir avec fail2ban. De plus, nous avons remarqué un bug qui semble rendre Coturn indisponible après quelques jours d’uptime, et ce jusqu’au prochain redémarrage.

En bref : nous migrons peu à peu vers Element Call qui semble être une solution à utiliser de facto si l’on utilise déjà Element comme client Matrix, bien qu’il soit encore en cours de développement.

Reverse-proxy🔗

Nous appliquons une configuration particulière sur notre reverse-proxy pour ce service.

Nous utilisons deux domaines pour Matrix :

• element.42l.fr, qui est servi par Element ;
• matrix.42l.fr, le domaine dédié à notre serveur Matrix.

Il nous est tout d’abord nécessaire de servir les routes /.well-known/matrix/client et /.well-known/matrix/server sur le nom de domaine racine 42l.fr ; pour plus d’informations sur cette subtilité de configuration, consultez la page dédiée sur la documentation de Synapse.

Concernant le sous-domaine matrix.42l.fr, nous avons établi une politique de routes particulière :

• / redirige vers element.42l.fr ;
• /_matrix/identity est servie par serveur web de Sydent ;
• Toutes les autres routes sont servies par le serveur web de Synapse.

Tests🔗

Le statut de l’instance de Synapse peut être vérifié à l’aide de la route healthcheck : https://matrix.42l.fr/health. Le fonctionnement de la fédération peut être vérifié en utilisant le testeur fourni par Matrix.

En ce qui concerne Element, une simple requête pour récupérer n’importe quel fichier servi par le serveur web d’Element suffit à vérifier son état.

Pour Sydent, la route /_matrix/identity peut être sondée.

Il est plus complexe de tester le serveur vocal s’il s’agit de Coturn : un netcat sur les ports utilisés par Coturn peut constituer un test basique. Pour vérifier son fonctionnement, la meilleure façon reste de passer un appel.

Statistiques d’utilisation🔗

Voici quelques statistiques de l’utilisation de notre service Matrix, sous la forme de moyennes journalières mesurées pendant la 5e semaine (calendrier ISO) de chaque année listée.

Notez toutefois que notre service Matrix est (pour l’instant) un service privé, qui n’est accessible ni en libre accès, ni pour nos membres. Les personnes extérieures qui souhaitent rejoindre nos canaux s’inscrivent sur d’autres instances Matrix et nous rejoignent à travers la fédération.

Pour le serveur Matrix (Synapse) :

Attention : Matrix étant un service fédéré, de nombreuses requêtes peuvent provenir de serveurs distants plutôt que d’utilisateur·ices.

Voici les statistiques pour le client Matrix (Element), qui ne sert que des pages statiques et reste uniquement utilisé par les personnes qui préfèrent le client web au client desktop ou mobile :

L’usage du client web reste très marginal de notre côté.

En date de juillet 2023, notre instance compte 220 utilisateur·ices (hors fédération) dont a priori une vingtaine de personnes qui se connectent au moins une fois par mois. La base de données PostgreSQL de Synapse pèse 1 636 Mo. Cette mesure a été prise juste après l’exécution du script synapse-compress-state et l’utilisation de la commande VACUUM FULL sur toute la base de données : juste avant ces deux opérations, elle pesait 2 140 Mo.

Quant à l’usage disque − qui sert à conserver toutes les images et autre fichiers multimédia, locaux et distants − il totalise 3.8 Go (1.4 Go en contenu local et 2.4 Go en contenu distant), en sachant que l’historique des conversations locales sur notre instance est programmé pour s’effacer au bout de 6 mois.

Voici quelques statistiques supplémentaires concernant l’usage de RAM de chaque conteneur ainsi que la taille de leur image :

NB : Nous n’avons pas de statistiques à donner pour le serveur vocal Coturn, que nous sommes en train d’abandonner au profit de Element Call.

Synapse est l’un des services les plus gourmands en RAM de toute notre infrastructure : il consomme parfois plus de RAM que notre serveur mail ou que notre instance Collabora.

Précautions🔗

Fédération et grandes salles🔗

Par défaut, la fédération du serveur Matrix avec les autres serveurs est activée, ce qui peut engendrer de graves problèmes (saturation de la RAM immédiate) si un·e utilisateur·ice de votre instance rejoint une salle de discussion de grande taille (ex.: #matrix:matrix.org).

Ce problème peut être mitigé en bloquant la possibilité de rejoindre des salles trop grandes avec le paramètre limit_remote_rooms.

Espace disque🔗

La messagerie instantanée n’est pas seulement textuelle, des images ou d’autres pièces jointes peuvent être envoyées sur le service, ce qui peut considérablement alourdir le volume du serveur Matrix. Il existe plusieurs remèdes à cela :

• Définir une limite d’upload dans la configuration de Synapse avec le paramètre max_upload_size ;
• Paramétrer une politique de rétention pour supprimer les messages au bout d’un certain nombre de jours (ex.: un an) avec le paramètre retention.

Il faut aussi prendre en compte que les avatars et images distantes (des autres serveurs Matrix en fédération) devront être téléchargées par le serveur, ce qui peut engendrer une augmentation considérable de l’occupation du disque.

Entretien🔗

synapse-compress-state🔗

Synapse stocke les données relatives aux canaux de manière inefficiente, ce pourquoi les développeur·euses proposent un outil pour optimiser le stockage des données nommé synapse-compress-state, qu’il est suggéré d’exécuter régulièrement sur les instances les plus gourmandes en espace disque dans la base de données.

Il est possible d’utiliser ce script à travers une cron en l’exécutant régulièrement, ou bien de l’utiliser une fois de temps en temps.

Supervision de la consommation de RAM🔗

Selon le nombre de personnes qui utilisent le service, l’activité des canaux locaux et fédérés que les utilisateur·ices ont rejoint ou bien pour des raisons mystérieuses, il arrive que Synapse consomme graduellement une grande quantité de RAM. Il pourrait être nécessaire de surveiller activement l’usage de RAM de ce logiciel.

Mise à jour🔗

La mise à jour de ces quatre services peut se dérouler sans risque en téléchargeant la dernière image officielle, en reconstruisant l’image si nécessaire puis en redémarrant le conteneur, causant une interruption de service de moins d’une minute.

Deux points de vigilance importants doivent toutefois être adressés :

• Il peut arriver que des changements majeurs soient opérés sur Synapse et qu’une action particulière soit attendue des administrateur·ices d’instance. La lecture du changelog avant la mise à jour est généralement suffisante pour anticiper d’éventuels problèmes à ce niveau.
• Des changements de configuration peuvent arriver sur Element sans que cela ne soit clairement indiqué dans leur changelog, qui est plutôt difficile à lire. Il est sans doute pertinent de vérifier régulièrement si le fichier de configuration d’Element a été mis à jour. Généralement, les mises à jour de ce fichier restent rétrocompatibles.
• Sydent et Element Call étant deux projets peu matures, des changements majeurs peuvent arriver ; il vaut mieux consulter leur changelog avant toute mise à niveau.

Évolutions envisagées🔗

Migration vers Dendrite et changement de nom de domaine🔗

Il est envisagé de recréer complètement l’instance Matrix de zéro pour changer de nom de domaine (matrix.42l.fr -> matrix.lacontrevoie.fr). À cette occasion, l’authentification unifiée avec 42 sera également supprimée au profit de l’utilisation d’un futur SSO pour La Contre-Voie. Plusieurs contraintes empêchent cette migration pour le moment :

• Le support OIDC dans le protocole Matrix ;
• Le support OIDC dans Dendrite (vers lequel nous souhaiterions migrer) ;
• Le support du stockage S3 dans Dendrite ;
• Le développement du futur SSO de l’association (en cours en date de juillet 2023).

Installation de Element Call🔗

En date de juillet 2023, le remplacement de Coturn par Element Call est en cours sur notre instance. Ce logiciel étant encore en version alpha, nous ne l’utilisons pas encore pour nos réunions internes.

Se débarrasser du serveur d’identité🔗

S’il s’avère techniquement possible d’utiliser Synapse sans Sydent ni le serveur d’identité de l’instance principale, il pourrait être intéressant d’examiner comment se débarrasser de cette dépendance.