Matrix synapse - Historique des versions

Ycharbi : Déplacement de la section sur la réinitialisation du mot de passe d'un utilisateur et ajout d'une section pour en désactiver un

2025-11-22T12:10:28Z

Déplacement de la section sur la réinitialisation du mot de passe d'un utilisateur et ajout d'une section pour en désactiver un

@@ Ligne 2 : / Ligne 2 : @@
 {{chantier}}
 [https://github.com/matrix-org/synapse/ Synapse] est une implémentation serveur libre (licence ''Apache 2.0'') du protocole [https://fr.wikipedia.org/wiki/Matrix_(protocole) Matrix] écrit en ''Python''. Le projet, initié en 2014, est maintenu par la fondation [https://matrix.org Matrix.org] et passe en version stable (''1.0.0'') en 2019. Il est disponible dans les dépôts ''Bullseye-Backports'' et ''Testing'' de ''Debian''.
@@ Ligne 53 : / Ligne 55 : @@
 ===Création d'un utilisateur===
   synapse_register_new_matrix_user http://127.0.0.1:8008 -c /etc/matrix-synapse/homeserver.yaml
 ===Source de la section===
@@ Ligne 358 : / Ligne 385 : @@
 Un outil permettant de determiner les caractéristiques du serveur est disponible à l'adresse https://federationtester.matrix.org/. Il peut s'avérer d'une aide précisieuse (surtout le rapport ''Json'').

Ycharbi : Ajout de la section "Réinitialisation de mot de passe"

2024-03-24T11:17:19Z

Ajout de la section "Réinitialisation de mot de passe"

← Version précédente		Version du 24 mars 2024 à 13:17
Ligne 358 :		Ligne 358 :

	Un outil permettant de determiner les caractéristiques du serveur est disponible à l'adresse https://federationtester.matrix.org/. Il peut s'avérer d'une aide précisieuse (surtout le rapport ''Json'').		Un outil permettant de determiner les caractéristiques du serveur est disponible à l'adresse https://federationtester.matrix.org/. Il peut s'avérer d'une aide précisieuse (surtout le rapport ''Json'').

			=Réinitialisation de mot de passe=
			Aussi étrange que cela puisse parraitre, il n'existe pas de fonction pour réinitialiser le mot de passe d'un utilisateur (incroyable) ! Les développeurs de cette solution doivent ignorer que ces derniers perdent régulièrement leur mot de passe et qu'il s'agit donc d'une fonctionnalité indispensable en production.
			Heureusement, la structure de l'authentification étant très simple, il est triviale de réaliser cette opération [https://paritoshbh.me/blog/reset-user-password-synapse-matrix-homeserver soit-même] dans la base de données après génération d'un mot de passe haché .

			# Génération du mot de passe haché
			su - matrix-synapse -s /bin/sh -c 'python3 /usr/libexec/matrix-synapse/hash_password -c /etc/matrix-synapse/homeserver.yaml'
			# connexion à la base de donnée de Synapse
			su - matrix-synapse -s /bin/sh -c 'sqlite3 /etc/matrix-synapse/homeserver.db'

			Après avoir identifié l'utilisateur dont le mot de passe doit être réinitialisé ("michel" pour l'exemple), utiliser le hachi généré pour remplacer l'ancien
			<syntaxhighlight lang="sql">
			SELECT * FROM users;
			UPDATE users SET password_hash='$2b$12$OkrnSR1hOCj0xjb7mDnvf.OXVQ0P/EU8u4lUpMuU5YepvHXpv3sxm' WHERE name='@michel:synapse.exemple.fr';
			</syntaxhighlight>

			Le changement est instantané.

Ycharbi : Correction d'une faute dans un titre

2023-02-24T19:07:36Z

Correction d'une faute dans un titre

← Version précédente		Version du 24 février 2023 à 21:07
Ligne 268 :		Ligne 268 :
	systemctl restart apache2.service		systemctl restart apache2.service

	=Source==		==Source==
	* https://github.com/vector-im/element-web/tree/develop/docs		* https://github.com/vector-im/element-web/tree/develop/docs

Ycharbi : Page créée avec « Category:Service_communication {{chantier}} [https://github.com/matrix-org/synapse/ Synapse] est une implémentation serveur libre (licence ''Apache 2.0'') du protocole [https://fr.wikipedia.org/wiki/Matrix_(protocole) Matrix] écrit en ''Python''. Le projet, initié en 2014, est maintenu par la fondation [https://matrix.org Matrix.org] et passe en version stable (''1.0.0'') en 2019. Il est disponible dans les dépôts ''Bullseye-Backports'' et ''Testing'' de '... »

2023-01-30T19:16:54Z

Page créée avec « Category:Service_communication {{chantier}} [https://github.com/matrix-org/synapse/ Synapse] est une implémentation serveur libre (licence ''Apache 2.0'') du protocole [https://fr.wikipedia.org/wiki/Matrix_(protocole) Matrix] écrit en ''Python''. Le projet, initié en 2014, est maintenu par la fondation [https://matrix.org Matrix.org] et passe en version stable (''1.0.0'') en 2019. Il est disponible dans les dépôts ''Bullseye-Backports'' et ''Testing'' de '... »

Nouvelle page

[[Category:Service_communication]]

{{chantier}}

[https://github.com/matrix-org/synapse/ Synapse] est une implémentation serveur libre (licence ''Apache 2.0'') du protocole [https://fr.wikipedia.org/wiki/Matrix_(protocole) Matrix] écrit en ''Python''. Le projet, initié en 2014, est maintenu par la fondation [https://matrix.org Matrix.org] et passe en version stable (''1.0.0'') en 2019. Il est disponible dans les dépôts ''Bullseye-Backports'' et ''Testing'' de ''Debian''.

Il permet la communication électronique textuelle, orale et vidéo entre plusieurs interlocuteurs au travers de réseaux ''IP''. Il propose en outre la possibilité d'envoyer des fichiers et de partager les écrans des correspondants. Une attention toute particulière est porté sur la sécurité des échanges avec un système de chiffrement de bout en bout obligatoire, tant entre clients (pair à pair) que lors de transactions avec le serveur (client/serveur).

Il est nécessaire de permettre la communication vers les ports suivants :
* Fédération ''Synapse'' : 8448 ''TCP''
* ''TURN'' : 3478 ''TCP/UDP''

=Service Synapse=
==Installation==
Ajout des dépôts ''Backports'' pour ''Debian 11''

<syntaxhighlight lang="bash">
echo "deb http://ftp2.fr.debian.org/debian bullseye-backports main" >> /etc/apt/sources.list
apt update
apt install --no-install-recommends -t bullseye-backports matrix-synapse
</syntaxhighlight>

La réponse aux questions n'a pas d'importance car les fichiers de configuration seront re-générés plus loin.

==Configuration==
Le domaine utilisé pour l'exemple est le suivant
export DNS_SYNAPSE=synapse.exemple.fr

Génération des fichiers configuration et de la clé de signature

<syntaxhighlight lang="bash">
synapse_generate_config --server-name ${DNS_SYNAPSE} --config-dir /etc/matrix-synapse --data-dir /etc/matrix-synapse/ --report-stats no --generate-secrets -o /etc/matrix-synapse/homeserver.yaml
synapse_generate_log_config -o /etc/matrix-synapse/${DNS_SYNAPSE}.log.config
synapse_generate_signing_key -o /etc/matrix-synapse/${DNS_SYNAPSE}.signing.key

echo 'report_stats: false' > /etc/matrix-synapse/conf.d/report_stats.yaml
echo "server_name: \"${DNS_SYNAPSE}\"" > /etc/matrix-synapse/conf.d/server_name.yaml
</syntaxhighlight>

Écouter les requêtes clientes sur toutes les adresses ''IP'' du serveur
sed -i "s/bind_addresses: \[.*\]/bind_addresses: ['0.0.0.0']/g" /etc/matrix-synapse/homeserver.yaml

Redémarrer le service
systemctl restart matrix-synapse.service

Vous devriez voir un port 8008 ''TCP'' en écoute avec un <syntaxhighlight lang="bash" inline>ss -ltn</syntaxhighlight>. Celui-ci permet aux outils d'administrations d'utiliser les ''API'' de ''Synapse'' pour interagir avec lui.

==Gestion des utilisateurs==
Actuellement, seule la création d'un utilisateur est possible avec les outils fournis. Leur suppression ou modification (ou même leur listage) n'est pas supporté (oui c'est aberrant). Ce sujet est traité dans ce [https://github.com/matrix-org/synapse/issues/1707 ticket].

La syntaxe d'un utilisateurs dans les différents clients ''Matrix'' est <syntaxhighlight lang="bash" inline>@michel:synapse.exemple.fr</syntaxhighlight>. Ceci est utile pour en ajouter comme contact depuis un logiciel client (pourquoi faire simple ?).

===Création d'un utilisateur===
synapse_register_new_matrix_user http://127.0.0.1:8008 -c /etc/matrix-synapse/homeserver.yaml

===Source de la section===
* https://matrix-org.github.io/synapse/latest/setup/installation.html

=Service TURN=
Dans la mesure où le vrai monde est peuplé de ''NAT'' à profusion et qu'aucun protocole de communication en temps réel ne sais gérer cette situation correctement (la raison m'échappe toujours...), il est indispensable d'employer un service mitigeant cette contrainte. Ceci est le rôle des protocoles [https://en.wikipedia.org/wiki/Traversal_Using_Relays_around_NAT TURN]/[https://en.wikipedia.org/wiki/STUN STUN] implémenté dans le logiciel [https://github.com/coturn/coturn Coturn].

==Installation==
Le paquet est disponible dans les dépôts ''Sable''
apt install --no-install-recommends coturn

==Configuration==
Les informations spécifiques à l'instance de cette documentations seront les suivantes

<syntaxhighlight lang="bash">
export DNS_COTURN=turn.exemple.fr
export SECRET_COTURN=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 64 | head -n 1)
export IP_EXTERNE=$(wget -qO - ifconfig.co)
export IP_INTERNE=192.168.0.100
</syntaxhighlight>

Le fichier de configuration du service se composera comme suit

<syntaxhighlight lang="bash">
cat << _EOF_ > /etc/turnserver.conf
use-auth-secret
static-auth-secret=${SECRET_COTURN}
realm=${DNS_COTURN}

# Le trafic VoIP est entièrement UDP. Il n'y a aucune raison de laisser les utilisateurs se connecter à des points d'extrémité TCP arbitraires via le relais
no-tcp-relay

# Ne laissez pas le relais essayer de se connecter à des plages d'adresses IP privées au sein de votre réseau (s'il y en a)
# Étant donné que le serveur tournant est probablement derrière votre pare-feu, n'oubliez pas d'inclure également toutes les adresses IP publiques privilégiées
denied-peer-ip=10.0.0.0-10.255.255.255
denied-peer-ip=192.168.0.0-192.168.255.255
denied-peer-ip=172.16.0.0-172.31.255.255

# À recommandé, blocage de pairs locaux supplémentaires, afin de limiter l'accès externe aux services internes
# https://www.rtcsec.com/article/slack-webrtc-turn-compromise-and-bug-bounty/#how-to-fix-an-open-turn-relay-to-address-this-vulnerability
no-multicast-peers
denied-peer-ip=0.0.0.0-0.255.255.255
denied-peer-ip=100.64.0.0-100.127.255.255
denied-peer-ip=127.0.0.0-127.255.255.255
denied-peer-ip=169.254.0.0-169.254.255.255
denied-peer-ip=192.0.0.0-192.0.0.255
denied-peer-ip=192.0.2.0-192.0.2.255
denied-peer-ip=192.88.99.0-192.88.99.255
denied-peer-ip=198.18.0.0-198.19.255.255
denied-peer-ip=198.51.100.0-198.51.100.255
denied-peer-ip=203.0.113.0-203.0.113.255
denied-peer-ip=240.0.0.0-255.255.255.255

# Cas particulier : le serveur TURN lui-même pour que les flux client->TURN->TURN->client fonctionnent
# Il doit s'agir de l'une des adresses IP d'écoute du serveur TURN
allowed-peer-ip=${IP_INTERNE}

# Examinez si vous souhaitez limiter le quota de flux relayés par utilisateur (ou total) pour éviter les risques de DoS
user-quota=12 # 4 flux par appel vidéo, donc 12 flux = 3 appels relayés simultanés par utilisateur
total-quota=1200

# Certificats TLS, y compris les certificats intermédiaires
# Pour les certificats Let's Encrypt, utilisez 'fullchain.pem' ici
cert=/srv/tls/corturn.pem

# Fichier TLS de clé privée
pkey=/srv/tls/corturn.key

# Assurez-vous que les lignes de configuration qui désactivent TLS/DTLS sont commentées ou supprimées.
#no-tls
#no-dtls

external-ip=${IP_EXTERNE}
listening-ip=${IP_INTERNE}
_EOF_
</syntaxhighlight>

===Support du TLS===
Créer le répertoire d'accueil des éléments de chiffrement
mkdir /srv/tls

Ces éléments peuvent être issus d'une autorité de certification publique comme [[Letsencrypt|Letsencrypt]] (mettre la clé et le certificat '''chaînés''') ou privée, via [[Openssl|OpenSSL]] par exemple.

<syntaxhighlight lang="bash">
chown -R root:root /srv/tls
chmod 500 /srv/tls
chmod 400 /srv/tls/*
</syntaxhighlight>

Redémarrer le service
systemctl restart coturn.service

Le service écoute sur le port 3478 ''TCP/UDP''.

Il est à présent possible de configurer ''Synapse'' afin qu'il informe les clients d'utiliser notre service ''TURN'' lors de l'établissement des communications pair à pair entre eux.

<syntaxhighlight lang="bash">
cat << _EOF_ >> /etc/matrix-synapse/homeserver.yaml

turn_uris: [ "turn:${DNS_COTURN}?transport=udp", "turn:${DNS_COTURN}?transport=tcp" ]
turn_shared_secret: "${SECRET_COTURN}"
turn_user_lifetime: 86400000
turn_allow_guests: True
_EOF_
</syntaxhighlight>

systemctl restart matrix-synapse.service

==Enregistrement DNS==
Cette section est totalement facultative et n'apporte rien. Il existe peut-être une configuration de ''Synapse'' permettant de trouver automatiquement le serveur ''TURN'' via ''DNS''...

Enregistrements ''DNS SRV'' (à ajouter dans la configuration de votre zone)

<syntaxhighlight lang="bash">
_stun._udp 10800 IN SRV 0 5 3478 exemple.fr.
_turn._udp 10800 IN SRV 0 5 3478 exemple.fr.
</syntaxhighlight>

Il est possible de requêter le serveur de noms sur ces champs précis via les commandes suivantes

<syntaxhighlight lang="bash">
dig +short _stun._udp._tcp 10800 IN SRV 0 5 3478 exemple.fr.
dig +short _turn._udp._tcp 10800 IN SRV 0 5 3478 exemple.fr.
</syntaxhighlight>

==Test de fonctionnement==
Voici une [https://nextcloud-talk.readthedocs.io/en/latest/TURN/#6-testing-the-turn-server méthode] permettant de tester le fonctionnement du service en ligne de commande. Elle peut aider à deceler des problèmes simplement.
turnutils_uclient -p 3478 -W <CLÉ_SERVEUR_TURN> -v -y turn.exemple.fr

==Source de la section==
* https://matrix-org.github.io/synapse/latest/setup/turn/coturn.html

=Client WEB Element=
[https://github.com/vector-im/element-web Element] est un client WEB pour ''Matrix''. Anciennement connu sous le nom de ''Riot'', il existe aussi sous forme d'application ''IOS'' et ''Android''.

==Installation==
N'étant pas dans les dépôts ''Debian'', nous utiliserons la version ''Git''

<syntaxhighlight lang="bash">
apt install --no-install-recommends apache2

wget https://github.com/vector-im/element-web/releases/download/v1.10.14/element-v1.10.14.tar.gz -P /tmp

tar xf /tmp/element-v1.10.14.tar.gz -C /var/www/
ln -s /var/www/element-v1.10.14/ /var/www/element
chown -R www-data: /var/www/element*
</syntaxhighlight>

==Configuration==
L'hôte virtuel d{{'}}''Apache'' doit pointer vers le programme

<syntaxhighlight lang="bash">
cat << '_EOF_' > /etc/apache2/sites-available/element.conf
<VirtualHost *:80>
ServerAdmin webmaster@localhost
DocumentRoot /var/www/element
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
_EOF_
</syntaxhighlight>

Désactivation de l'hôte virtuel par défaut et activation du nouveau
<syntaxhighlight lang="bash">
a2dissite 000-default.conf
a2ensite element.conf
</syntaxhighlight>

Le domaine utilisé sera le suivant
export DNS_ELEMENT=element.exemple.fr

La configuration de notre instance sera celle-ci

<syntaxhighlight lang="bash">
cat << _EOF_ > /var/www/element/config.json
{
"default_server_config": {
"m.homeserver": {
"base_url": "https://${DNS_SYNAPSE}",
"server_name": "${DNS_SYNAPSE}"
},
"m.identity_server": {
"base_url": "https://vector.im"
}
},
"disable_custom_urls": false,
"disable_guests": false,
"disable_login_language_selector": false,
"disable_3pid_login": false,
"brand": "Element",
"bug_report_endpoint_url": "https://element.io/bugreports/submit",
"uisi_autorageshake_app": "element-auto-uisi",
"default_country_code": "FR",
"show_labs_settings": false,
"features": { },
"default_federate": false,
"default_theme": "light",
"enable_presence_by_hs_url": {
"https://matrix.org": false,
"https://matrix-client.matrix.org": false
},
"setting_defaults": {
"breadcrumbs": true
},
"features": {
"feature_you_want_to_turn_on": true,
"feature_you_want_to_keep_off": false
}
}
_EOF_
</syntaxhighlight>

Redémarrer ''Apache''
systemctl restart apache2.service

=Source==
* https://github.com/vector-im/element-web/tree/develop/docs

=Fédération=
Un des atouts de cette solution est la décentralisation. En effet, il est possible d'interconnecter plusieurs serveurs afin de permettre la communication d'utilisateurs enregistrés sur des instances différentes. Ces interconnexions doivent êtres explicitement spécifiées dans la configuration de ''Synapse''.

Le domaine du serveur distant sera le suivant
export DNS_SRV_DISTANT_SYNAPSE=synapse.toto.fr

Ajout de celui-ci dans la configuration de ''Synapse'' (ceci doit être fait des deux côtés)

<syntaxhighlight lang="bash">
sed -i "s/^trusted_key_servers:/trusted_key_servers:\n - server_name: \"${DNS_SRV_DISTANT_SYNAPSE}\"/g" /etc/matrix-synapse/homeserver.yaml
sed -i "s/^#federation_domain_whitelist:/federation_domain_whitelist:\n - ${DNS_SRV_DISTANT_SYNAPSE}/g" /etc/matrix-synapse/homeserver.yaml
</syntaxhighlight>

systemctl restart matrix-synapse.service

=Cas d'une connexion mandaté=
Dans la mesure où il est courant qu'un serveur ne soit jamais relié directement à Internet (comprendre par la qu'il ne dispose pas d'IP publique), le cas d'un [[:Category:Reverse_proxy|mandataire inverse]] officiant entre les clients du ''WAN'' et le serveur ''Element'' du ''LAN'' est le plus probable. Ce point complique la transparence des échanges entre les machines et doit être géré au niveau de cet intermédiaire. Deux services ont étés testés en production avec succès. Leur configuration est donnée ci-après.

==Traefik==
Ajout d'un point d'entrer dans Traefik pour le port 8448

<syntaxhighlight lang="bash">
cat << _EOF_ >> /etc/traefik/config/vhosts/matrix.toml
[http]
[http.routers]
[http.routers.synapse]
entryPoints = ["websecure"]
rule = "Host(\`${DNS_SYNAPSE}\`)"
service = "synapse"
[http.routers.synapse.tls]
certResolver = "myresolver"

[http.routers.element]
entryPoints = ["websecure"]
rule = "Host(\`${DNS_ELEMENT}\`)"
service = "element"
[http.routers.element.tls]
certResolver = "myresolver"

[http.routers.synapsefed]
entryPoints = ["synapsefed"]
rule = "Host(\`${DNS_SYNAPSE}\`)"
service = "synapse"
[http.routers.synapsefed.tls]
certResolver = "myresolver"

[http.services]
[http.services.synapse.loadBalancer]
[[http.services.synapse.loadBalancer.servers]]
url = "http://${IP_INTERNE}:8008"
[http.services.element.loadBalancer]
[[http.services.element.loadBalancer.servers]]
url = "http://${IP_INTERNE}:80"
_EOF_
</syntaxhighlight>

==HAProxy==
<syntaxhighlight lang="bash">
cat << _EOF_ >> /etc/haproxy/haproxy.cfg
frontend matrix-federation
bind *:8448,[::]:8448 ssl crt /etc/haproxy/tls/ alpn h2,http/1.1
http-request set-header X-Forwarded-Proto https if { ssl_fc }
http-request set-header X-Forwarded-Proto http if !{ ssl_fc }
http-request set-header X-Forwarded-For %[src]
default_backend synapse

frontend https
http-response add-header X-Frame-Options SAMEORIGIN

bind :443 ssl crt /etc/haproxy/tls/ alpn h2,http/1.1

acl host_synapse hdr(host) -i synapse.exemple.fr

use_backend synapse if host_synapse

<backend synapse
option forwardfor except 127.0.0.1
option http-server-close
server synapse 192.168.170.178:8008 check maxconn 32
_EOF_
</syntaxhighlight>

=Débogage=
La configuration de ''Synapse'' est quelque peu imbuvable et les problèmes, difficiles à corriger. Il est possible de s'appuyer sur les journaux du service afin de cibler l'origine des disfonctionnements.
tail -f /var/log/matrix-synapse/homeserver.log

Un outil permettant de determiner les caractéristiques du serveur est disponible à l'adresse https://federationtester.matrix.org/. Il peut s'avérer d'une aide précisieuse (surtout le rapport ''Json'').

Matrix synapse - Historique des versions

Ycharbi : Déplacement de la section sur la réinitialisation du mot de passe d'un utilisateur et ajout d'une section pour en désactiver un

Ycharbi : Ajout de la section "Réinitialisation de mot de passe"

Ycharbi : Correction d'une faute dans un titre

Ycharbi : Déplacement de la section sur la réinitialisation du mot de passe d'un utilisateur et ajout d'une section pour en désactiver un

Ycharbi : Ajout de la section "Réinitialisation de mot de passe"

Ycharbi : Correction d'une faute dans un titre