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.

Docker et les journaux

Nous sommes en 2019 et l'on raffole de Docker. En particulier chez TeDomum, nous l'employons pour rationaliser nos travaux de déploiement et de configuration, pour faciliter le partage. Par exemple, l'ensemble de nos services, y compris les services d'infrastructure (sauvegardes, journalisation, statistiques, etc.) est déployé sous forme d'images Docker disponibles à tous et de projets Compose accessibles publiquement, ce qui assure que créer un hébergeur identique est l'affaire de quelques heures, et qu'on bénéficie de facto des mises à jour.

Les écoles varient, mais l'un des patterns usuels de gestion des journaux sous Docker consiste à employer exclusivement la sortie d'erreur et la sortie standard, puis confier à Docker le routage des messages. Cette approche est critiquable par beaucoup d'aspects, surtout son manque de souplesse, mais compense en simplicité et fait presque aujourd'hui l'unanimité. Elle a cela aussi d'avantageux que les choses fonctionnent bien, sans trop de complexité initiale, par exemple pour afficher les journaux du service app d'un projet Compose :

docker-compose logs --tail=100 app

Centraliser les journaux

Lorsqu'on commence à gérer des dizaines de projets Compose sur plusieurs serveurs, même plus généralement quand on multiplie les équipements et les services, il est de bon goût de centraliser rapidement les journaux. Cela permet non seulement de faciliter la détection de défaut avec des jeux d'alertes, mais c'est aussi bénéfique pour la gestion de la vie privée et des libertés : un point unique où les journaux peuvent être systématiquement nettoyés de leurs adresses IP, logins, autres informations personnelles ; un point unique où la rétention peut être limitée conformément à la jurisprudence européenne.

Plusieurs outils et standards pour ça : – syslog, historique mais très robuste, supporte chiffrement et signature des messages ; – Elastic, en appelant directement les endpoints d'un ElasticSearch pour y injecter des objets formattés JSON ; – Splunk, propriétaire et assimilable à une API HTTP ; – GELF, transporté en TCP, UDP ou HTTP, formalisé par Graylog et spécialisé pour le transport de journaux.

Historiquement, TeDomum utilisait Graylog pour la gestion de ses journaux, et nous avions donc favorisé GELF pour les transporter directement depuis le démon Docker. La configuration est simple (extrait de notre daemon.json de configuration Docker :

{
    "log-driver": "gelf",
    "log-opts": {"gelf-address":"udp://logs.server.hostname:12201"}
}

C'est une architecture simplissime, qu'on recommande vivement à quiconque gère une petite infrastructure à base de Docker. Attention toutefois à ce que les communications soient bien protégées (réseau privé) entre les hôtes et le serveur de journaux, de sorte que les traces ne soient pas interceptées.

Ses principaux défauts :

• la consommation de stockage (qu'on se le dise, un index Graylog doublé de son ElasticSearch pour la recheche, cela consomme plus de 5 fois le volume des journaux ingérés ; TeDomum le payait de 50Go assignés au journaux pour une semaine de rétention environ) ;
• la consommation en RAM (de même, pour un moteur applicatif sur OpenJDK accompagné d'un ElasticSearch, compter au minimum 3Go) ;
• on ne collecte que Docker en l'état.

Fluentd pour plus de souplesse

S'agissant de collecter les journaux système, nous employons actuellement journald sur tous nos hôtes car déployé nativement sous notre distribution, Debian Buster.

Malheureusement, journald n'implémente pas de transmission de journaux au format GELF, un agent intermédiaire est donc nécessaire. Les principales technologies sont à ce titre :

• rsyslog, originalement orienté syslog mais aujourd'hui très généraliste pour router des messages, sa configuration est malheureusement complexe ;
• Logstash, très accessible et composant essentiel de ELK, gourmand en ressources toutefois ;
• Fluentd et son petit frère FluentBit bien plus légers et toujours accessibles.

Par principe conservateur, nous avons opté pour Fluentd en attendant un support plus large de la communauté de FluentBit. Déjà franchement léger (compter quelques dizaines de Mo, au pire 200Mo pour une instance), l'agent est capable de traiter de nombreux types d'entrée et de les router vers la même variété de destinations (ElasticSearch, Mongo, fichiers plats, tout y passe, et les modules existent pour étendre). En prime, Docker supporte officiellement le format d'entrée natif, et il existe un module natif pour journald, impeccable !

Nous avons donc imaginé une infrastructure simple, reposant sur Fluentd déployé localement sur chaque hôte ; il peut même y effectuer des pré-nettoyages et pré-traitements. Chaque Fluentd rappatrie ses journaux collectés de Docker et de journald vers un serveur central assurant le processing et le stockage.

Loki, petit nouveau très complet

TeDomum emploie déjà Prometheus pour collecter l'ensemble de ses métriques. Même notre robot de supervision Anna publie des métriques Prometheus sur la supervision des services (combien de temps met un message pour être délivré de chez nous à tel ou tel fournisseur de mails, etc.) Nous consultons ces métriques collectées via Grafana, leader libre de la visualisation de métriques. Grafana est très complet et nous sert dans de nombreux cas d'investigation ; il était auparavant employé aux côtés de Graylog pour la consultation.

Il y a quelques mois, Grafana annonçait la sortie de Loki, une solution de centralisation de journaux façon Prometheus : légère, reposant sur des principes simples mais performants, et surtout complètement intégrée à Grafana. Il faut l'avouer : pouvoir afficher côte à côte les statistiques d'accès à un service et les journaux de ce service, difficile de refuser.

Nous avons donc expérimenté avec Loki, et avons abouti à une configuration plutôt simple mais solide. Nous pouvons aujourd'hui en une seule requête : {"app": "mastodon"} ou {"service": "db"} cibler les statistiques et les journaux d'un type de service, d'une application entière et les affichers sur une même fenêtre.

Nous avons donc orienté notre configuration Fluentd pour employer Loki en moteur de stockage, ce qui s'avère plutôt aisé avec un plugin développé officiellement par Grafana.

Un déploiement sans encombre

Après une phase de laboratoire, quelques jours d'expérimentation sur une fraction de notre production, la décision était prise jeudi 9 de profiter d'un redémarrage – mise à jour oblige – pour basculer le premier de nos serveurs entièrement sous Fluentd et Loki côté journalisation.

Pour l'occasion, nous avons déployé Fluentd dans un conteneur local, qui écoute sur un socket unix :

<source>
  @type unix
  @id in_docker
  @label docker

  path /var/log/fluentd.socket
</source>

Et Docker qui pointe ses journaux vers le socket :

{
    "log-driver": "fluentd",
    "log-opts": {
        "fluentd-address": "unix:///var/log/fluentd.socket",
        "fluentd-async-connect": "true",
        "fluentd-retry-wait": "30s"
    }
}

Le choix de la connexion asynchrone est nécessaire, puisque Fluentd étant lui-même conteneurisé, Docker ne parvient à lancer aucun conteneur tant que le service n'est pas disponible sur le socket.

Après un premier déploiement réussi, la même configuration est appliquée partout. Rapidement l'ensemble des journaux remonte vers Loki : un bonheur.

Et les ennuis commencent...

C'est jeudi soir que les premiers ennuis se font sentir. Le symptôme est simple, plus aucun service n'est accessible sur l'un de nos serveurs : joke. Naturellement on fait le lien avec le nouveau déploiement, mais comme plusieurs mises à jour ont également été appliquées, rien n'est évident.

Un diagnostic rapide montre que les services eux-mêmes ne sont pas en défaut, mais que le frontal traefik ne répond plus aux requêtes (il n'accepte même plus de connexion TCP). Qu'à cela ne tienne, avant d'investiguer, on le redémarre pour rétablir le service :

docker-compose restart traefik                                                                                         
Restarting front_traefik_1 ...                                                                                                                                                                                                                                                                   
ERROR: for front_traefik_1  UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=70)                                
ERROR: An HTTP request took too long to complete. Retry with --verbose to obtain debug information.                                               
If you encounter this issue regularly because of slow network conditions, consider setting COMPOSE_HTTP_TIMEOUT to a higher value (current value: 60). 

Le stress grimpe un petit peu, et pour rétablir les choses assurément, on redémarre le démon Docker et l'ensemble des services. Tout rentre dans l'ordre, un « glitch » passager tente-t-on de se rassurer. Le diagnostic matériel ne donne par ailleurs aucune information, rien non plus dans les journaux système ou noyau.

Un « glitch » passager

S'il y a une chose acquise depuis qu'on administre un hébergeur, c'est qu'un « glitch » passager n'existe pas. On s'en rassure, mais il y a toujours une cause derrière chaque défaut, et souvent elle revient à la charge.

Vendredi, ce n'est pas un mais trois plantages du même serveur, joke, auxquels nous avons fait face. Très difficile à vivre pour un hébergeur habitué à quelques défauts mais rarement de panne générale. Aussi, en fin d'après midi, pas enclins à passer la nuit à surveiller les compteurs, on décide de rappatrier sur une autre machine nos services les plus délicats.

En parallèle, on investigue rapidement. Le défaut semble lié à un gros volume de journaux comme en témoigne les statistiques (en octets par seconde reçus par Loki). On distingue parfaitement les horaires des trois dénis de service :

Ces statistiques sont effectivement corrélées avec l'émission réseau par le conteneur Fluentd sur joke :

Malheureusement, il ne semble pas qu'un seul de ces journaux reçus apparaisse dans Loki ; on ne sait donc pas qui les génère ni pourquoi ils empêchent Fluentd ou traefik de fonctionner. Les statistiques CPU laissent tout de même entendre que PeerTube est particulièrement actif au moins sur l'un des défauts :

On décide de conserver PeerTube sur joke pour ne pas risquer d'impacter les autres hôtes et on projette d'investiguer pendant le week-end.

Vers un début de solution

A notre surprise samedi, c'est l'hôte où l'on a justement migré les services qui fait défaut. Une fois, puis deux. On s'apprête à conclure que c'est l'un des services migrés qui déclenche le bug lorsque joke tombe à nouveau : nos certitudes s'effondrent.

Toutes nos hypothèses à l'eau, on profite du défaut de joke sans service critique pour investiguer plus tranquillement. D'abord, on confirme le volume de journaux importants à chaque plantage ; ils n'apparaissent toujours pas dans Loki pour une raison qu'on ignore – un défaut de parsing suppose-t-on – aussi on active une copie locale dans un fichier.

<match **>
  @type copy

  <store>
    @type loki
    ...
  </store>
  <store>
    @type file
    path /logs/fluentd.log
  </store>
</match>

Egalement, en tentant d'isoler le défaut de Docker on constate que seul le conteneur traefik est impacté. Le reste fonctionne impeccablement, et aucun autre timeout n'est constaté. Dernier pas en avant (et pas des moindres) dans notre réflexion, redémarrer le conteneur Fluentd résoud le problème.

Non seulement cela nous offre une solution meilleur marché que redémarrer l'ensemble des services si le défaut se reproduit, mais cela confirme une chose : le lien clair avec Fluentd. Notre hypothèse à ce stade : quelque chose déclenche le traitement d'un gros volume de journaux dans Fluentd ; puis soit la forme soit le seul volume de ces journaux rend Fluend inopérant, y compris sur son socket (ce qui est normalement impossible grâce au mécanismes internes de buffer de Fluentd) ; Docker, ne pouvant écrire sur le socket de logs, refuse de traiter la sortie standard et la sortie d'erreur des conteneurs ; traefik est bloquant dans son écriture de journaux et se retrouve donc inopérant.

On laisse l'infrastructure en l'état en espérérant que les traces générées par un plantage prochain offriront quelques éclairages.

Le déni de service auto-infligé

Les traces n'ont pas tardé à tomber ce dimanche, nous n'avons pu les analyser que ce matin.

-rw-r--r--   1 root  root    244M May 12 13:01 fluent.log.20190512_0.log
-rw-r--r--   1 root  root    244M May 12 21:19 fluent.log.20190512_1.log
-rw-r--r--   1 root  root    244M May 12 22:17 fluent.log.20190512_2.log
-rw-r--r--   1 root  root    244M May 12 22:17 fluent.log.20190512_3.log
-rw-r--r--   1 root  root    244M May 12 22:17 fluent.log.20190512_4.log
-rw-r--r--   1 root  root    244M May 12 22:17 fluent.log.20190512_5.log
-rw-r--r--   1 root  root    244M May 12 22:18 fluent.log.20190512_6.log
-rw-r--r--   1 root  root    244M May 12 22:18 fluent.log.20190512_7.log
-rw-r--r--   1 root  root    244M May 12 22:18 fluent.log.20190512_8.log
-rw-r--r--   1 root  root    244M May 12 22:18 fluent.log.20190512_9.log
-rw-r--r--   1 root  root    212M May 13 02:46 fluent.log.20190512_10.log
-rw-r--r--   1 root  root    244M May 13 09:36 fluent.log.20190513_0.log
-rw-r--r--   1 root  root    244M May 13 09:36 fluent.log.20190513_1.log
-rw-r--r--   1 root  root    244M May 13 09:36 fluent.log.20190513_2.log
-rw-r--r--   1 root  root    244M May 13 09:37 fluent.log.20190513_3.log
-rw-r--r--   1 root  root    244M May 13 09:37 fluent.log.20190513_4.log
-rw-r--r--   1 root  root    244M May 13 09:37 fluent.log.20190513_5.log
-rw-r--r--   1 root  root    244M May 13 09:37 fluent.log.20190513_6.log
-rw-r--r--   1 root  root    244M May 13 09:37 fluent.log.20190513_7.log
-rw-r--r--   1 root  root    244M May 13 09:37 fluent.log.20190513_8.log

À 22h18 dimanche, puis à 9h37 ce matin, les horaires des derniers sursauts du serveur correspondent parfaitement à une flanquée de journaux écrits par Fluentd, comme nous l'attendions ! Pour ne pas tomber dans le défaut de parsing on les analyse avec des moyens simples : grep, awk et sort font l'affaire.

D'abord on confirme que PeerTube est à l'origine du plantage dans chacun des cas. Clin d'œil à l'ami virtualab qui a dû faire la publicité de son blog tout récemment, et quelques visiteurs parcourent ses pages où une vidéo PeerTube est intégrée, le client PeerTube générant beaucoup de requêtes pour charger la vidéo par morceaux. Il n'empêche que ces quelques 1000 requêtes par seconde consomment un petit peu de CPU sur les frontaux et PeerTube lui-même, mais ne devraient certainement pas inquiéter Fluentd, par ailleurs habitué à traiter des millions de lignes de journaux par seconde.

On se concentre donc sur les traces de Fluentd lui-même et la réponse n'est pas bien loin :

2019-05-12T20:17:13+00:00       dad34f22107c    {"container_id":"xxx","container_name":"/agents_fluentd_1","source":"stdout","log":"2019-05-12 20:17:13 +0000 [info]: #0 sending 5714975 bytes","app":"agents","service":"fluentd","tag":"agents.fluentd","instance":"joke"}
2019-05-12T20:17:14+00:00       dad34f22107c    {"container_name":"/agents_fluentd_1","source":"stdout","log":"2019-05-12 20:17:14 +0000 [warn]: #0 failed to POST http://logs.hostname:3100/api/prom/push (500 Internal Server Error rpc error: code = ResourceExhausted desc = grpc: received message larger than max (5186961 vs. 4194304)","container_id":"xxx","app":"agents","service":"fluentd","tag":"agents.fluentd","instance":"joke"}

Suivi d'une description précise des messages qui n'ont pas pu être émis :

2019-05-12T20:17:14+00:00       xxx    {"log":"2019-05-12 20:17:14 +0000 [warn]: #0 {\"streams\":[{\"labels\":\"{app=\\\"video\\\",service=\\\"peertube\\\",tag=\\\"video.peertube\\\",instance=\\\"joke\\\"}\",\"entries\":[{\"ts\":\"2019-05-12T20:17:03.644103Z\",\"line\":\"container_id=\\\"xxx\\\" container_name=\\\"/video_peertube_1\\\" source=\\\"stdout\\\" log=\\\"[video.tedomum.net:443] 2019-05-12 20:17:03.643 \\u001B[32minfo\\u001B[39m: 2a01:: - - [12/May/2019:20:17:03 +0000] \\\"GET /static/webseed/01cd2292-e4e3-4b61-bb74-a4fbdb704f32-360.mp4 HTTP/1.1\\\" 206 16384 \\\"https://video.tedomum.net/videos/embed/01cd2292-e4e3-4b61-bb74-a4fbdb704f32\\\" \\\"Other\\\"\\\"\"},{\"ts\":\"2019-05-12T20:17:03.784652Z\",\"line\":\"container_name=\\\"/video_peertube_1\\\" source=\\\"stdout\\\" log=\\\"\\\" container_id=\\\"xxx\\\"\"},{\"ts\":\"2019-05-12T20:17:03.786381Z\",\"line\":\"log=\\\"[video.tedomum.net:443] 2019-05-12 20:17:03.644 \\u001B[32minfo\\u001B[39m: 2a01:: - - [12/May/2019:20:17:03 +0000] \\\"GET /static/webseed/01cd2292-e4e3-4b61-bb74-a4fbdb704f32-360.mp4 HTTP/1.1\\\" 206 16384 \\\"https://video.tedomum.net/videos/embed/01cd2292-e4e3-4b61-bb74-a4fbdb704f32\\\" \\\"Other\\\"\\\" container_id=\\\"xxx\\\" container_name=\\\"/video_peertube_1\\\" source=\\\"stdout\\\"\"},{\"ts\":\"2019-05-12T20:17:03.786593Z\",\"line\":\"container_id=\\\"xxx\\\" container_name=\\\"/video_peertube_1\\\" source=\\\"stdout\\\" log=\\\"\\\"\"},{\"ts\":\"2019-05-12T20:17:03.786793Z\",\[... suivi de 5Mo de logs non émis]

Fluentd, non content de n'avoir pu émettre un bloc de 5Mo de journaux (qui correspondent à 10s de trafic intense sur PeerTube) comme cette taille dépasse le maximum accepté par Loki, journalise cette erreur en incluant le contenu... des journaux qui n'ont pas été émis. Vous connaissez la suite : Fluentd lui-même est journalisé par Docker, ces quelques 5Mo, gonflés par une batterie d'anti-slash d'échappement, sont rapidement réinjectés dans la boucle, et le tout dépasse à nouveau 5Mo en générant une erreur du même accabit. Effet Larsen.

Comme tout se déroule localement, les choses vont vite. Très vite. Après quelques millisecondes, les journaux internes de Fluentd ressemblent plutôt à :

log":"\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\[... quelques Mo d'anti-slashs]

Au bout d'une seconde environ, Fluentd ne peut plus conserver ces journaux dans ses buffers et s'effondre en bon guerrier.

On trouve rapidement une solution et l'on patch, en limitant la taille des blocs envoyés à Loki d'une part pour ne plus générer cette erreur, mais également en configurant Fluentd pour ne passer par... Fluentd :

• https://forge.tedomum.net/tedomum/documentation/commit/90fff8e5dcd327c1abb46f0610d246e157468b0f
• https://forge.tedomum.net/tedomum/documentation/commit/5ca77708250441d254ad66960db9efe06b473a44

On avait pourtant testé !

Et c'est vrai. Certes pas pendant des mois, mais une petite semaine a vu les journaux de production de pas mal de conteneurs, dont traefik, pointer vers un Fluentd de test afin d'évaluer le bon fonctionnement. Comment se fait-il donc que le défaut n'ait pas été identifié avant un déploiement global ?

C'est que les conditions de tests ont consisté à rediriger spécifiquement chaque conteneur testé vers Fluentd, et jamais Fluentd lui-même. Egalement, les quelques heures de tests en production sur le premier serveur déployé n'ont pas été suffisantes pour déclencher le bug qui dépend grandement du trafic entrant (il est rare en temps normal de générer plus de 1Mo ou 2Mo de journaux toutes les 10 secondes).

Une bonne leçon pour ne pas oublier de tester et de qualifier en conditions au plus près de la production. Avec le recul, ce fut l'un des bugs les moins évidents à investiguer depuis qu'on administre TeDomum.

Pour protéger les données, la vie privée, et les libertés de nos utilisateurs, nous croyons en une solution par l'hébergement distribué – acentré – où ni les risques ni les pouvoirs ne sont concentrés. Aussi, TeDomum est le fruit de travaux sur ce thème débutés bien avant la déclaration de l'association. Les prémisses remontent à 2005 ; Google était surtout un moteur de recherche, Facebook n'était que l'embryon du géant que nous connaissons, l'iPhone n'existait pas et Apple était presque un acteur de niche. Pourtant déjà les vieux avaient flairé la réalité à venir. Derrière l'Internet tel qu'il avait débuté, Multimania, iFrance et quelques publicitaires élaboraient des modèles commerciaux basés sur la centralisation et l'enfermement : devenir principal hébergeur de sites Web – la principale source de contenu à l'époque – c'était s'assurer une visibilité en tant que régie, donc un revenu.

2005, c'était aussi les premiers pas de la LCEN. Le souvenir du procès Altern encore chaud, le législateur venait de déresponsabiliser largement les hébergeurs. Cela profitait évidemment aux quelques gros en devenir, mais aussi aux fournisseurs modestes proposant de publier un site Web pour pas grand chose et sans restriction à ceux qui ne disposait pas de la connexion nécessaire pour le faire chez soi. Dans le texte, un chapitre complet consacré aux prestataires techniques définit précisément le rôle et les responsabilités des intermédiaires sur l'Internet ; l'article 6 s'attaque à la position des hébergeurs de contenu, qui ne sont donc pas auteurs ou publicateurs du contenu qu'ils diffusent pourtant techniquement :

(2) Les personnes physiques ou morales qui assurent, même à titre gratuit, pour mise à disposition du public par des services de communication au public en ligne, le stockage de signaux, d'écrits, d'images, de sons ou de messages de toute nature fournis par des destinataires de ces services ne peuvent pas voir leur responsabilité civile engagée du fait des activités ou des informations stockées à la demande d'un destinataire de ces services si elles n'avaient pas effectivement connaissance de leur caractère illicite ou de faits et circonstances faisant apparaître ce caractère ou si, dès le moment où elles en ont eu cette connaissance, elles ont agi promptement pour retirer ces données ou en rendre l'accès impossible.

La voie était ouverte ; les textes, certes un peu flous mais appuyés par une jurisprudence, permettaient une plus grande latitude dans le rôle d'hébergeur. Cette latitude était balancée par l'obligation de rétention des données de connexion afin que l'auteur d'un contenu puisse être identifié et poursuivi en cas d'infraction. En particulier, les petits hébergeurs n'avaient plus à craindre de devoir contrôler tout le contenu de leurs utilisateurs : la responsabilité ne leur incombait pas tant qu'ils n'étaient pas mis au courant. Une route toute tracée vers un Internet bien acentré, le succès d'intiatives comme le RHIEN, le tout dans la neutralité et le respect des libertés individuelles, non ? Non.

Les faits sont simples : dans les années 2000, tous les passionnés et la moitié des intéressés se retroussaient les manches pour assembler une page Web, les plus aguerris administraient des services en tous genre, et l'ensemble n'était pas systématiquement hébergé chez Amen. Dans les années 2010, tous les Internautes se font guider pour créer une page Facebook et les entrepeneurs un site Wix, des services privés (et privateurs) disposent d'un monopole sur les technologies pourtant intrinsèquement ouvertes. Ce monopole s'inscrit dans la simple continuité du modèle économique d'enfermement avancé par feu-Multimania : il est nécessaire de concentrer l'audience chez quelques acteurs pour la rentabiliser en tant que régie – et nouveau marché obligeant, pour collecter et revendre un maximum de données personnelles.

Le régime plus souple a profité aux plus gros, également nourris par la nouvelle ère du commerce de la surveillance. Et c'est soudain en Europe, alors que le RGPD peine justement à responsabiliser les internautes et les fournisseurs à la protection des données personnelles, que fleurit le débat sur la « directive copyright », portant largement sur les mesures de protection du droit d'auteur sur Internet. L'objet n'est pas ici d'en commenter trop en détails le contenu, car bonne nouvelle : pour une fois, le texte est digeste, loin des 200 considérants du RGPD, le tout tien en moins de 50 pages et est disponible sur le site de l'union (la version consolidée n'est pas encore mise en forme à notre connaissance, nous mettrons le lien à jour au besoin, en attendant l'amendement 271 est disponible en PDF). Il n'est pas non plus question d'aborder la pertinence du sujet de la directive ou des moyens déployés, la Quadrature a par exemple développé le très bon argument de la soumission au marché de la surveillance de masse. Plutôt très égoïstement, nous abordons la principale nouveauté pour un acteur comme TeDomum, le fameux article 13 : contrairement à la déresponsabilisation apportée par la LCEN, l'hébergeur devient responsable sous certaines conditions et se voit attribuer une obligation de moyens pour lutter contre les infractions au droit d'auteur.

Principal moyen rendu obligatoire par le texte maintenant validé : la coopération avec les titulaires des droits pour tout ce qui concerne la mise à disposition de contenu au public. Suggérée également, la mise en place de dispositifs automatiques et systématiques pour forcer l'application des conventions que nous aurions établies en coopérant avec les titulaires. Autrement dit : petit hébergeur, nous devrions engager des moyens administratifs pour décider en accord avec les ayants droits d'une posture et d'un régime quant à la publication d'œuvres sur notre plateforme. Avant même de réflechir à mettre en place techniquement les dispositions convenues, l'idée même que nous soyons reçus pour échanger d'égal à égal avec les ayants droits est surréaliste – même en dépêchant les représentants d'un collectif de petits hébergeurs –, l'application de la directive est donc irréalisable à notre échelle.

Seulement les dernières versions du texte ont complexifié les règles, et un paquet d'analyses publiées (par exemple par Arte, ou des YouTubers) sont rassurantes quant à l'avenir des plateformes de diffusion de contenu. Il faut modérer. Ce qui a changé d'abord (pour rappel la version originale du texte, l'article 13 étant renuméroté en 17) :

• le paragraphe 4. est découpé en trois obligations, celle d'obligation de moyens pour obtenir une autorisation des ayants droits (a priori, de tous les ayants droits), celle d'obligation de moyens pour empêcher les infractions à l'autorisation – ou en l'absence les infractions au droit d'auteur en général –, et une obligation de résultats en cas d'infraction pour oter le contenu du site ;
• le paragraphe 5. indique que les obligations de moyens et résultats doivent être appréciées en fonction du type, de la taille et de l'audience, ainsi que des moyens de la plateforme ;
• le paragraphe 6. crée une exception pour les entités de moins de 3 ans, moins de 10M€ de chiffre d'affaire, et une contre-expception pour le sites cumulant plus de de 5M visiteurs par an ;
• le paragraphe 7 rappelle et confirme que les exceptions au droit d'auteur continuent de courir, en particulier concernant la citation et la caricature.

Il va sans discuter qu'une partie des précisions apportées est rassurante. Celle qui a essuyé la sueur de la plupart des critiques : le maintien de l'exception pour caricature ou critique, qui sauve le modèle des principales plateformes où bloggeurs et chroniqueurs postent leurs productions. Sauvés pour autant ? pas encore. Les précisions protègent :

• les principales plateformes qui appliquent déjà des filtres automatiques et disposent d'une armée d'avocats, mais ne peuvent se permettre de perdre l'auditoire des chroniqueurs vidéos qui commentent sur – insérer au choix sorties cinéma, séries, livres, jeux, etc. ;
• les startups qui chercheraient à les concurrencer mais ne seraient pas immédiatement rentables ou populaires ;
• les plateformes touchant à l'éduction et l'enseignement, bien que pas explicitement inquiétées.

Ce qui nous tire a priori de l'embaras tient plutôt dans les modifications de l'article 2 portant définitions pour le texte et dans l'ajout du considérant 62.

(62) Certains services de la société de l’information sont, dans le cadre de leur utilisation normale, conçus pour donner au public l’accès aux contenus ou autres objets protégés par le droit d’auteur que leurs utilisateurs téléversés. La définition de fournisseur de services de partage de contenus en ligne prévue par la présente directive ne devrait cibler que les services en ligne qui jouent un rôle important sur le marché des contenus en ligne en étant en concurrence pour les mêmes publics avec d’autres services de contenus en ligne, comme les services de diffusion audio et vidéo en flux continu. Les services couverts par la présente directive sont les services dont l’objectif principal ou l’un des objectifs principaux est de stocker et de permettre aux utilisateurs de téléverser et de partager une quantité importante de contenus protégés par le droit d'auteur en vue d’en tirer un profit, directement ou indirectement, en organisant et en promouvant ces contenus afin d’attirer un public plus large, y compris en les classant et en faisant une promotion ciblée parmi ceux-ci. Ces services ne devraient pas inclure les services qui ont un objectif principal autre que celui de permettre aux utilisateurs de téléverseret de partager une grande quantité de contenus protégés par le droit d’auteur en vue de tirer profit de cette activité.

[...]

Article 2 – 5. « fournisseur de services de partage de contenus en ligne », le fournisseur d’un service de la société de l’information dont l’objectif principal ou l’un des objectifs principaux est de stocker et de donner au public l’accès à une quantité importante d’œuvres protégées par le droit d’auteur ou d’autres objets protégés qui ont été téléversés par ses utilisateurs, qu’il organise et promeut à des fins lucratives.

S'il semble à première lecture que nous ne cochions pas la case de la fin lucrative, une partie de nos services répond sans conteste au reste de la définition. La subtilité est illustrée dans la Directive par les encyclopédies en ligne ou les plateformes de partage de code, mais rien ne fait référence aux outils de l'expression libre que nous contribuons à mettre en place, tels que Mastodon, PeerTube ou Pixelfed ; c'est probablement que le cas des hébergeurs de notre taille n'était pas à l'esprit du groupe de travail qui a rédigé l'amendement. Vu la délicate question de la modération sur le Fédiverse, la position des lobbies et d'une partie de la classe politique française sur le droit d'auteur, nous craignons évidemment que la nuance soit effacée dans la traduction en droit national et que malgré l'exception pour Wikipedia et autres encyclopédies, les petits hébergeurs deviennent vulnérables légalement, annulant les dispositions protectrices de 2004.

L'idée était séduisante que d'attaquer légalement les monopoles de la diffusion de contenu sur Internet. Après tout, c'est à cela que tient aujourd'hui notre liberté d'expression. Mais en les attaquant pour de mauvaises raisons (satisfaire financièrement les quelques bénéficiaires du droit d'auteur, et non protéger les créateurs ou la liberté d'expression – tirer profit des monopoles plutôt que de limiter leur pouvoir) et avec de mauvais outils (en contraignant tout le monde – y compris la concurrence – plutôt qu'en favorisant des alternatives), le résultat nous effraie en tant que petit hébergeur. Enfin, même si elle nous concerne peu, la Directive crée de la complexité. Le démêlement du corpus légal qui entoure l'activité d'hébergement, où le régime général de responsabilité limité de 2004 cède progressivement la place à des régimes spécifiques – sur le droit d'auteur ici, la lutte anti-terroriste là- rend l'aventure plus difficile et plus risquée pour les acteurs de la décentralisation.

Plus délicat encore, si la directive copyright traite exclusivement du droit d'auteur, la question de la responsabilité quant à la mise à disposition du public de contenus illicites en général promet un débat d'autant plus guidé par l'émotion que seront abordés les cas de l'incitation à la haine, de l'apologie du terrorisme, ou de la pédo-pornographie. Mais restons positifs, car indépendamment de l'hypothétique législation que nous ne pourrions de toute façon pas appliquer, chaque nouvel utilisateur de nos services et chaque nouvel hébergeur que nous inspirons ou aidons est un progrès concret vers plus de sécurité, de libertés, et un meilleur respect de la vie privée.