URL: https://linuxfr.org/news/img-le-cache-d-images-sur-linuxfr-org Title: img, le cache d’images sur LinuxFr.org Authors: Benoît Sibaud BAud, Nils Ratusznik et Ysabeau 🧶 Date: 2024-10-20T13:53:38+02:00 License: CC By-SA Tags: linuxfr, image, docker, hurl, redis, nginx et docker-compose Score: 3 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](https://github.com/linuxfrorg/linuxfr.org/) en Ruby On Rails, et principalement 5 services autour : le [cache d’images _img_](https://github.com/linuxfrorg/img-LinuxFr.org), la [tribune](https://github.com/linuxfrorg/board-sse-linuxfr.org) _board_, le [convertisseur EPUB 3](https://github.com/linuxfrorg/epub-LinuxFr.org) _epub_, le [partageur sur les réseaux sociaux](https://github.com/linuxfrorg/share-LinuxFr.org) _share_ et le [convertisseur LaTeX vers SVG](https://github.com/linuxfrorg/svgtex) _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](https://linuxfr.org/users/oumph/journaux/linuxfr-org-seconde-quinzaine-de-septembre-2024#comment-1970929) d’un « _article technique sur le fonctionnement de ce cache, les choix techniques qui ont été faits, les erreurs commises donc à éviter…_ ». ---- ---- # 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](https://linuxfr.org/news/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_](https://developer.mozilla.org/fr/docs/Web/HTML/Element/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.")` ![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 : ![Logo LinuxFr.org](https://linuxfr.org/images/logos/linuxfr2_classic_back.png) Et côté code HTML : ```html 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 : ![April - Campagne d’adhésion](https://april.org/campagne-2024/relais/banniereCampagneApril.svg) Et côté code : > `April - Campagne d’adhésion` 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](https://github.com/linuxfrorg/linuxfr.org/blob/1d72a291d9486c0b3ced84d87e0f25476e792eda/app/models/image.rb) va vérifier que l’image est déclarée dans redis (créer l’entrée `img/` 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_](https://github.com/linuxfrorg/img-LinuxFr.org#how-it-works) 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/` or `GET /img//` pour les images, et `GET /avatars/` ou `GET /avatars//` 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/`) ; - l’adresse n’est pas dans le cache disque et la récupération a lieu (noté temporairement dans `img/update/`): 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_](https://developer.mozilla.org/fr/docs/Web/HTTP/Headers/Content-Type)), `checksum` avec un hachage SHA1 et `etag` avec la valeur ETag (entête [_ETag_](https://developer.mozilla.org/fr/docs/Web/HTTP/Headers/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](https://linuxfr.org/users/nono) 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_](https://hurl.dev/) 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](https://github.com/linuxfrorg/img-LinuxFr.org/blob/main/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_](https://developer.mozilla.org/fr/docs/Web/HTTP/Headers/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_](https://github.com/linuxfrorg/img-LinuxFr.org/blob/main/tests/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_](https://github.com/linuxfrorg/img-LinuxFr.org/blob/main/tests/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](https://github.com/linuxfrorg/img-LinuxFr.org/blob/main/tests/nginx.conf) é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_](https://github.com/linuxfrorg/img-LinuxFr.org/tree/main/tests/data-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](https://github.com/linuxfrorg/img-LinuxFr.org/blob/main/tests/img-tests.sh) : - 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](https://linuxfr.org/users/oumph/journaux/linuxfr-org-premiere-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/ img/updated/ img/err/ 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 par 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](https://linuxfr.org/users/jeanas/liens/l-internet-archive-victime-a-son-tour-d-une-attaque-31-millions-d-adresses-mail-ont-fuite) 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](https://linuxfr.org/users/oumph/journaux/linuxfr-org-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](https://linuxfr.org/suivi/separer-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/` vers les clés _redis_ `img/` et le cache disque des images par rapport aux requêtes `/avatars/` vers les clés `avatars/` 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](https://linuxfr.org/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](https://pypi.org/project/waybackpy/)). Enfin une troisième entrée de suivi suggère l'[hébergement des images des dépêches (et éventuellement des journaux)](https://linuxfr.org/suivi/heberger-les-images-des-news-et-eventuellement-journal), 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.