publish: De l'ejabberd à Matrix : pourquoi et comment migrer mon homelab de messagerie
This commit is contained in:
Cédrix
@@ -1,11 +0,0 @@
|
||||
{
|
||||
"title": "De l'ejabberd à Matrix : pourquoi et comment migrer mon homelab de messagerie",
|
||||
"slug": "de-l-ejabberd-a-matrix-pourquoi-et-comment-migrer-mon-homelab-de-messagerie",
|
||||
"_updated_at": "2026-05-16 08:17:33",
|
||||
"published": true,
|
||||
"published_at": "2026-07-16 08:16",
|
||||
"category": "Technologie",
|
||||
"tags": [],
|
||||
"seo_title": "",
|
||||
"seo_description": "De l'ejabberd à Matrix : pourquoi et comment migrer mon homelab de messagerie Mise à jour de l'article original « ejabberd - service de messagerie Jabber …"
|
||||
}
|
||||
@@ -1,122 +0,0 @@
|
||||
# De l'ejabberd à Matrix : pourquoi et comment migrer mon homelab de messagerie
|
||||
|
||||
*Mise à jour de l'article original « ejabberd - service de messagerie Jabber XMPP » publié en novembre 2021.*
|
||||
|
||||
## Ce que faisait l'article original
|
||||
|
||||
L'article publié en 2021 documentait l'installation d'un serveur de messagerie XMPP avec **ejabberd** sur Debian 10. L'objectif était de monter un service Jabber complet pour mon homelab, avec :
|
||||
|
||||
- Un serveur ejabberd installé via les paquets Debian, complété par une mise à jour vers la version 21.07 issue de ProcessOne
|
||||
- Une base **MariaDB** comme backend de stockage des comptes et messages
|
||||
- Un **certificat TLS Let's Encrypt** mutualisé avec un serveur Apache sur le même domaine
|
||||
- Une configuration **multi-hôtes virtuels** (`im.domain.tld`, `xmpp.domain2.tld`) avec authentification différenciée (interne pour l'un, SQL pour l'autre)
|
||||
- Un ensemble de modules de base (`mod_roster`, `mod_muc` pour les salons, `mod_ping`, etc.)
|
||||
- Le module **`mod_stun_disco`** pour annoncer aux clients XMPP des services STUN/TURN, en vue d'appels audio/vidéo
|
||||
|
||||
L'objectif sous-jacent était classique : disposer d'une **messagerie auto-hébergée, ouverte, fédérée**, indépendante des plateformes propriétaires. Sur le papier, XMPP cochait toutes les cases — protocole standardisé (RFC 6120), fédération native, écosystème de clients libres, chiffrement OMEMO disponible.
|
||||
|
||||
## Pourquoi cet article n'est plus le bon point de départ
|
||||
|
||||
Quatre ans plus tard, en relisant ce tutoriel avec un regard critique, plusieurs limites apparaissent — certaines dues à l'article lui-même, d'autres au contexte plus large.
|
||||
|
||||
### Les limites du tutoriel original
|
||||
|
||||
À la relecture, le tutoriel contenait plusieurs problèmes techniques : des erreurs de syntaxe YAML (listes mal formatées), des URLs cassées, un chemin de certificat tronqué, et un exemple MariaDB avec le mot de passe `password` en clair sans avertissement suffisamment appuyé. Plus important : la création du premier compte administrateur manquait, ainsi que la configuration du pare-feu et la création réelle d'un serveur TURN (le module `mod_stun_disco` se contente d'**annoncer** des services, il ne les fournit pas).
|
||||
|
||||
Ces points sont corrigibles, et ils l'ont été dans une réécriture intermédiaire. Mais le problème de fond n'est pas là.
|
||||
|
||||
### Le vrai problème : XMPP ne répondait pas à mon besoin réel
|
||||
|
||||
L'objectif initial était une « messagerie ». En pratique, ce que je voulais — et ce que veulent la plupart des gens qui montent un homelab de communication aujourd'hui — c'est :
|
||||
|
||||
1. Échanger des messages texte de manière fiable
|
||||
2. Passer des appels audio et vidéo de qualité
|
||||
3. Faire de la visio à plusieurs
|
||||
4. Avoir une expérience cohérente sur **tous mes appareils**, y compris iOS
|
||||
5. Idéalement, intégrer l'authentification à mon IdP existant (Keycloak sur `idp.a5l.fr`)
|
||||
|
||||
XMPP fait correctement le point 1 et partiellement le 2. Sur les autres points, l'écosystème montre ses limites :
|
||||
|
||||
- **iOS** : très peu de clients XMPP de qualité, push notifications difficiles à mettre en place sans gateway tierce
|
||||
- **Visio de groupe** : possible techniquement (Jingle + MUC), mais l'expérience est très en deçà de ce qu'on attend en 2026
|
||||
- **SSO OIDC** : seuls 2-3 clients XMPP supportent SASL OAUTHBEARER ; sur iOS, c'est quasi-inexistant. Pour un vrai SSO avec Keycloak, on est obligé de retomber sur du LDAP, ce qui n'est plus du SSO mais de la délégation d'annuaire avec ressaisie du mot de passe
|
||||
- **Multi-appareils** : l'historique synchronisé reste imparfait, OMEMO complique la donne
|
||||
|
||||
Ces frictions étaient déjà présentes en 2021, mais elles paraissaient acceptables. En 2026, des alternatives matures les ont supprimées.
|
||||
|
||||
### Le détour par Linphone / Flexisip
|
||||
|
||||
Une piste explorée a été de remplacer XMPP par du **SIP avec Flexisip et Linphone** (l'écosystème français de Belledonne Communications, basé à Grenoble). C'est techniquement excellent pour les appels audio/vidéo — c'est leur métier depuis vingt ans — et Linphone offre une expérience iOS très propre avec push natif. Mais SIP est faible sur la messagerie moderne (pas de threads, partage de fichiers basique, fédération inexistante en pratique) et l'écosystème de clients est quasi-monoculture autour de Linphone lui-même.
|
||||
|
||||
## La cible : Matrix avec Synapse, MAS et Element Call
|
||||
|
||||
Après analyse, **Matrix** est la pile qui répond le mieux à l'ensemble des besoins pour un homelab moderne.
|
||||
|
||||
### Pourquoi Matrix
|
||||
|
||||
- **Messagerie excellente** avec E2EE par défaut, historique synchronisé multi-appareils, threads, réactions, édition de messages
|
||||
- **Appels audio/vidéo de qualité** via **Element Call** (basé sur MatrixRTC + LiveKit), qui rivalise avec Zoom ou Meet
|
||||
- **Clients de qualité homogène sur toutes les plateformes** : Element Web, Element Desktop, Element X iOS et Android — avec push natif fonctionnel
|
||||
- **SSO OIDC natif et bien documenté** via **MAS (Matrix Authentication Service)**, qui s'intègre proprement à Keycloak
|
||||
- **Fédération mature** et écosystème grand public bien plus actif que XMPP en 2026
|
||||
- **Documentation et outillage self-hosting excellents**, notamment le playbook `matrix-docker-ansible-deploy` de spantaleev qui automatise tout
|
||||
|
||||
### Les contreparties à connaître
|
||||
|
||||
Honnêtement :
|
||||
|
||||
- **Synapse consomme plus de RAM qu'ejabberd** (compter 1-2 Go pour quelques utilisateurs)
|
||||
- La **base PostgreSQL grossit** avec l'historique fédéré, surtout si on rejoint de gros salons publics
|
||||
- La pile complète comporte **plus de briques** (Synapse + PostgreSQL + MAS + LiveKit SFU + lk-jwt-service + coturn) qu'un simple ejabberd
|
||||
- **Element X impose MAS** pour l'authentification — l'OIDC direct sur Synapse ne suffit plus
|
||||
|
||||
Ces contreparties sont gérables. Sur un homelab modeste (4-8 Go RAM, 50 Go SSD), la pile tourne sans difficulté.
|
||||
|
||||
## Architecture cible sur a5l.fr
|
||||
|
||||
```
|
||||
a5l.fr → délégation .well-known
|
||||
matrix.a5l.fr → Synapse (homeserver)
|
||||
auth.a5l.fr → MAS (délègue à Keycloak)
|
||||
chat.a5l.fr → Element Web
|
||||
mrtc.a5l.fr → MatrixRTC backend (LiveKit + lk-jwt-service)
|
||||
turn.a5l.fr → coturn (TURN dédié)
|
||||
idp.a5l.fr → Keycloak existant
|
||||
```
|
||||
|
||||
Le flux d'authentification devient :
|
||||
|
||||
```
|
||||
Client Matrix → MAS (auth.a5l.fr) → Keycloak (idp.a5l.fr)
|
||||
↓
|
||||
Synapse (matrix.a5l.fr)
|
||||
```
|
||||
|
||||
L'utilisateur s'authentifie une fois sur Keycloak — avec MFA, WebAuthn ou ce qui est configuré — et peut se connecter sur tous les clients Matrix de tous ses appareils sans ressaisir de mot de passe. C'est un vrai SSO, pas une délégation LDAP déguisée.
|
||||
|
||||
## Faut-il jeter l'article ejabberd à la poubelle ?
|
||||
|
||||
Non. Plusieurs raisons de le conserver, éventuellement dans une rubrique « archives » :
|
||||
|
||||
- **XMPP reste un protocole sérieux** pour des cas d'usage spécifiques : messagerie texte pure, intégration IoT (MQTT-XMPP), bots, communautés déjà établies sur ce protocole
|
||||
- Le tutoriel garde sa **valeur pédagogique** pour comprendre comment fonctionne un serveur de messagerie fédéré
|
||||
- Si un jour je voulais monter un service de messagerie pour une **association ou un usage pro** où la complexité Matrix n'est pas justifiée, ejabberd ou Prosody resteraient pertinents — Prosody en premier choix d'ailleurs, beaucoup plus léger qu'ejabberd pour les petits déploiements
|
||||
|
||||
Mais pour le besoin réel d'un homelab de communication en 2026 — messagerie + appels + visio + tous appareils + SSO — **Matrix est la bonne réponse**.
|
||||
|
||||
## Suite de la documentation
|
||||
|
||||
Les prochains articles documenteront le déploiement effectif :
|
||||
|
||||
1. Installation de Synapse et PostgreSQL avec Docker Compose
|
||||
2. Configuration de MAS et intégration Keycloak
|
||||
3. Déploiement d'Element Call (LiveKit SFU + lk-jwt-service)
|
||||
4. Configuration de coturn pour les NAT difficiles derrière FAI
|
||||
5. Sauvegarde et supervision
|
||||
6. Migration éventuelle des données ejabberd vers Matrix (via les bridges `mautrix-*`)
|
||||
|
||||
L'option simplifiée — **utiliser le playbook Ansible `matrix-docker-ansible-deploy`** — sera également documentée en parallèle, car elle réduit drastiquement le travail manuel tout en restant complètement self-hosted.
|
||||
|
||||
---
|
||||
|
||||
*Article rédigé en mai 2026. Liens utiles : [documentation Matrix](https://matrix.org/docs/), [Synapse](https://element-hq.github.io/synapse/), [matrix-authentication-service](https://element-hq.github.io/matrix-authentication-service/), [Element Call](https://github.com/element-hq/element-call), [matrix-docker-ansible-deploy](https://github.com/spantaleev/matrix-docker-ansible-deploy).*
|
||||
@@ -7,7 +7,7 @@
|
||||
"featured": false,
|
||||
"published_at": "2026-07-16 08:16",
|
||||
"created_at": "2026-05-16 08:16:29",
|
||||
"updated_at": "2026-05-16 08:16:46",
|
||||
"updated_at": "2026-05-16 08:17:35",
|
||||
"revisions": [],
|
||||
"cover": "",
|
||||
"files_meta": [],
|
||||
|
||||
Reference in New Issue
Block a user