Linuxfr.org

Dans l’histoire de l’espace, les épisodes qui ont le plus marqué les esprits sont, probablement, ceux des marches sur la Lune qui ont été le fait des missions Apollo. Dans cette deuxième dépêche à l’occasion de la journée Ada Lovelace de 2024, on retrouvera donc un portrait de quatre femmes qui ont codé ou calculé les missions Apollo, Judith Love Cohen (1933 – 2016), Margaret Hamilton, JoAnn H. Morgan et Frances (Poppy) Northcutt mais aussi une histoire de celles, plus anonymes, qui ont tissé les mémoires des modules Apollo.

Ces biographies sont précédées d’un genre d’état des lieux de l’informatique en URSS et aux USA et suivies d’une sitographie pour prolonger un peu plus l’exploration.

• lien nᵒ 1 : La dépêche précédente sur la conquête féminine de l'espace
• lien nᵒ 2 : Le lien surprenant entre la mission Apollo 13 et Jack Black
• lien nᵒ 3 : Judith Love Cohen and the Female Engineers of Tomorrow
• lien nᵒ 4 : Margaret Hamilton, la femme qui a fait atterrir l’Homme sur la Lune
• lien nᵒ 5 : Margaret Hamilton
• lien nᵒ 6 : The Rocket Women of Apollo: JoAnn Morgan, Instrumentation Controller, NASA
• lien nᵒ 7 : JoAnn H. Morgan
• lien nᵒ 8 : Frances Northcutt, la femme qui a contribué à envoyer l'Homme sur la Lune
• lien nᵒ 9 : Poppy Northcutt: The only woman in the Apollo control room
• lien nᵒ 10 : Le rôle clé des femmes dans l’histoire des mémoires informatiques
• lien nᵒ 11 : Core memory weavers and Navajo women made the Apollo missions possible

Sommaire

• Préambule
• Les ordinateurs de la conquête de l’espace URSS et USA
  • Les ordinateurs soviétiques
  • Les ordinateurs des missions Apollo
• Judith Love Cohen – Wikipédia (1933 – 2016) l’accouchement du programme de guidage Apollo
  • Margaret Hamilton (née en 1936) la jeune femme à côté de la pile de livre de sa hauteur
• JoAnn H. Morgan (née en 1940) la seule femme présente dans la salle de tir lors du lancement d’Apollo 11
• Frances Northcutt dite « Poppy » (née en 1943) l’autre seule femme présente dans les salles de tir des missions Apollo 8 et 13
• Les tisserandes
• Pour compléter
  • Les ordinateurs soviétiques
  • Missions Apollo
  • L’exploration spatiale et les astronautes
  • Sur la journée Ada Lovelace et la place des femmes dans les carrières scientifiques et techniques
• Excuse et paragraphes de la fin

Préambule

Pourquoi n’est-il essentiellement question que des informaticiennes de la NASA ou ayant travaillé pour la NASA ? Cela revient à poser la question de l’informatique côté Union soviétique. Plusieurs facteurs peuvent expliquer la méconnaissance que l’on a des personnes qui, côté soviétique, ont travaillé sur les programmes relatifs à la conquête de l’espace, à commencer par l’histoire qui est, disons compliquée surtout par rapport à celle des USA.

Ensuite, c’était un secteur stratégique : envoyer des satellites pose les mêmes questions balistiques que l’envoi d’un missile intercontinental. L’existence du fondateur du programme spatial soviétique, Sergueï Korolev, qui subissait des peines d’emprisonnement pour raisons politiques (dont quatre mois de goulag) et qui avait été admis dans l’équipe de l’ingénieur aéronautique Andreï Tupolev lui-même prisonnier politique à l’époque, a été tenue secrète jusque bien après sa mort. On peut penser qu’il en va de même pour les autres personnes ayant participé aux programmes de conquête spatiale.

Concernant l’informatique proprement dite, trois noms apparaissent. Sergueï Lebedev (1902 - 1974) est considéré comme le père de l’informatique soviétique. Lebedev semble être un nom assez courant, ainsi, on trouve un cosmonaute russe du nom de Valentin Lebedev. L’Ukrainienne Ekaterina Yushchenko (en) (1919 - 2001) que le site ukrainien (en) sur l’histoire de l’informatique en Ukraine appelle « l’Ada Lovelace ukrainienne ». Yushenko a posé les bases de la programmation théorique en Ukraine (et en URSS avant) et écrit le langage de haut niveau Address. Andreï Erchov (en) (1931 – 1988), fondateur de l’École sibérienne de science informatique dont le livre, Programmation pour le BESM, a marqué un certain Donald Knuth.

Les ordinateurs de la conquête de l’espace URSS et USA Les ordinateurs soviétiques

Le premier ordinateur soviétique date de 1950, construit sous la direction de Sergeï Lebedev, dans un contexte où le traitement électronique de l’information, considéré par Staline (1878 – 1953) et son entourage comme « fausse science au service de l’impérialisme »1 n’est pas encouragé par le pouvoir. Il s’agit du MESM (МЭСМ, Малая электронная счетно-решающая машина, petit calculateur électronique, qui était plutôt assez gros en volume), développé par une vingtaine de personnes. La plupart des ordinateurs soviétiques en découleront.

Le BESM sur lequel Andréï Erchov a écrit son livre de programmation a été produit à partir de 1953. Il se déclinera en deux séries les : BESM–1 (1950) à BESM–6 (1966) et les M -20 et ses descendants. Ces derniers, dont le premier, fabriqué à Moscou, est sorti en 1956 seront les ordinateurs des premiers âges de la conquête spatiale. Le dernier de la série, le M-220 était, quant à lui, fabriqué à Kazan. Ils ont, par la suite, probablement été remplacés par le MINSK dans les années 1960.

Quant aux langages de programmation, Yves Logé, en 1987, dans l’article Les ordinateurs soviétiques : Histoire obligée de trois décennies de la Revue d’études comparatives Est-Ouest relevait ceci :

• 1953 – librairie de sous-programmes pour STRELA et BESM,
• 1955 – langage de compilation (PP2 – PP – BESM),
• 1957 – assembleurs (PAPA, SSP),
• 1962 – compilateur Algol 60 (TA 1),
• 1962 – moniteur de traitement par lots (AUTOOPERATOR),
• 1966 – premier système d’exploitation (MINSK 22, BESM 6),
• 1967 – langage de programmation (EPSILON, ALMO).

Le FORTRAN et l’ALGOL, bien qu’ayant été introduits dans les ordinateurs soviétiques dans les années 1960, ne commenceront à être vraiment utilisés qu’à partir des années 1970, époque à laquelle l’URSS abandonnera la production de ses propres ordinateurs.

Les ordinateurs des missions Apollo

L’informatisation de la NASA a commencé avec des machines IBM, la série IBM 700/7000 commercialisée dans les années 1950 à 1960 ; c’était la première version des ordinateurs à transistors. Les langages de programmation les plus courants à l’époque était le Cobol et le FORTRAN pour lequel des personnes comme Frances Allen avaient été recrutées afin de former des chercheurs, parfois réticents, au langage.

En 1964, IBM sort la série System/360 qui pouvait travailler en réseau et dont le système d’exploitation, multitâches, était OS/360. Il était doté d’une RAM, insuffisante, d’un mégaoctet qui a poussé les ingénieurs à adopter un code abrégé. Et, évidemment, il se programmait encore à l’époque avec du papier.

L’invention qui a permis d’équiper informatiquement les modules des missions Apollo est celle des circuits intégrés, inventés par Jack Kilby en 1958. Ils équiperont les ordinateurs à partir de 1963, la NASA étant dans les premiers utilisateurs pour les ordinateurs de guidage d’Apollo. Par la suite, les circuits intégrés permettront de fabriquer les « mini-ordinateurs » (qui restent toujours assez encombrants) et les micro-ordinateurs. Les premiers micro-ordinateurs, à l’allure de ceux que nous avons actuellement avec : l’ordinateur, un écran, un dispositif de saisie, puis, plus tard, un dispositif de pointage sortiront en 1973, après les missions Apollo.

Judith Love Cohen – Wikipédia (1933 – 2016) l’accouchement du programme de guidage Apollo

Judith Love Cohen est ingénieure aérospatiale, après sa retraite, elle deviendra écrivaine et fondera une entreprise multimédia Cascade Pass.

En 1952, celle qui aidait ses camarades de classe à faire leurs devoirs de mathématiques, est embauchée par la North American Aviation. Elle obtient, en 1957 un Bachelor of Art (licence) en sciences, puis, en 1962, un master en sciences à l’Université de Californie. En 1957, après son BA, elle est embauchée par le « Space Technology Laboratories (laboratoire des technologies spatiales) qui deviendra TRW. Elle y travaillera jusqu’à sa retraite en 1990, souvent seule femme ingénieure de l’équipe dans laquelle elle se trouvait.

Son travail : les ordinateurs de guidage. Elle a fait partie de l’équipe qui a conçu le « Tracking and Data Relay Satellites (TDRS) », le système suivi et de relais des données des satellites de la NASA. Ce système qui permet notamment de rester en contact avec la Station spatiale internationale.

Elle s’occupera aussi du télescope Hubble. Elle avait été chargée de concevoir le système terrestre des opérations scientifiques. Elle dira dans une vidéo (en) réalisée par Cascade Pass qu’elle avait travaillé avec les astronomes, car c’étaient eux qui allaient utiliser le télescope. Le système avait trois fonctions principales :

• planification des observations,
• contrôle en temps réel du réglage de la mise au point et du changement des filtres,
• récupération des données pour générer des photos, partie que Cohen considérait comme la plus intéressante et la plus difficile à réaliser.

Mais, le point culminant de sa carrière a été le programme Apollo, notamment le système de guidage de la mission Apollo 13 qui devait être la troisième à se poser sur la Lune, l’ordinateur AGS (Abort Guidance System, système de guidage d’abandon pour le module destiné à rester sur la Lune). Cette mission commence mal : les astronautes prévus à l’origine changent presque à la dernière minute, quand la fusée décolle le 11 avril 1970, le moteur central du deuxième étage s’éteint trop tôt. Ce sera compensé, sans incidence sur la trajectoire. Le 13 avril, l’un des astronautes, Jack Swigert, lance le fameux :

Houston, we’ve had a problem.

Le module de service d’Apollo 13 est hors d’usage, l’équipe change de module de service en urgence et embarque dans le module lunaire (LM) prévu pour deux personnes alors qu’ils sont trois. L’AGS servira en tant qu’ordinateur de bord et contrôlera tous les équipements vitaux, mais il n’aurait pas pu revenir sur l’orbite terrestre si Cohen n’avait pas bataillé avec la NASA pour que la fonction de retour y soit incluse.

Son fils, l’ingénieur en informatique Neil Siegel (en) racontera, ce qui a été vérifié, qu’elle avait conçu l’AGS pendant qu’elle était enceinte de son demi-frère, l’acteur Jack Black. Le 28 août 1969, au moment de partir pour l’hôpital pour accoucher, elle prend aussi le code d’un problème sur lequel elle travaillait. Elle appellera son patron plus tard pour lui signaler qu’elle l’avait résolu, et aussi, en passant, que le bébé était né. Le problème en question concernait l’AGS.

Margaret Hamilton (née en 1936) la jeune femme à côté de la pile de livre de sa hauteur

La photo probablement la plus connue de Margaret Hamilton est celle où on la voit poser à côté d’une pile de gros documents reliés : le code du logiciel de navigation de la mission Apollo 11.

Margaret Hamilton intègre le MIT (Massachusetts Institute of Technology) en 1960 pour développer des logiciels informatiques. En 1961, la NASA confie au MIT la mission de réaliser un ordinateur embarqué de navigation et de pilotage avec un cahier des charges assez léger et permettant au MIT une grande créativité. Ce sera l’AGC (Apollo Guidance Computer) qui sera le premier à utiliser des circuits intégrés. Lourd, 32 kilos, il préfigure néanmoins les ordinateurs portables puisque tous les éléments, ordinateur, mémoire, écran et dispositif de saisie étaient réunis dans un seul boitier.

Mais avant de travailler sur l’AGC, Hamilton intègre, en 1961, le laboratoire Lincoln pour travailler sur le projet militaire ultra-secret SAGE qui devait produire en temps réel une image de l’espace aérien états-unien. Elle racontera ensuite avoir fait l’objet d’un bizutage (une coutume apparemment) : on lui avait demandé de travailler sur un programme piégé commenté en grec et en latin. Elle était la première à avoir réussi à le faire fonctionner. Et c’est ainsi qu’en 1963 elle est invitée à rejoindre le laboratoire Draper du MIT qui était en charge du développement des logiciels embarqués d’Apollo.

Elle évoquera aussi la fois où, emmenant de temps en temps sa fille au laboratoire, un jour, cette dernière, jouant à l’astronaute, fait planter le système : elle avait sélectionné le programme d’atterrissage alors qu’elle était « en vol » (un appui sur une mauvaise touche). Ce que voyant Hamilton alerte la direction pour que l’on modifie le programme, réponse « ils sont expérimentés, ça n’arrivera pas ». Sauf qu’évidemment, c’est arrivé au pendant la mission Apollo 8. On peut imaginer qu’Hamilton et son équipe étaient préparées à cette éventualité : les données de navigation seront renvoyées et la trajectoire corrigée. Elle codera aussi un système de priorité des tâches afin d’éviter que l’AGC ne sature et qu’il fasse le travail correctement. L’AGC pouvait ainsi interrompre des tâches pour faire passer celles qui étaient les plus prioritaires et c’est ce qui a permis à Apollo 11 d’atterrir correctement sur la Lune.

Hamilton quittera le MIT en 1974 pour co-fonder une entreprise de développement de logiciels, Higher Order Software (HOS) qu’elle dirigera jusqu’en 1984. HOS se spécialisait notamment sur les logiciels de détection des erreurs. Ensuite, en 1986, elle créera Hamilton Technologies et concevra le langage de programmation USL (Universal Systems Language).

Elle reçoit en 2016 la médaille présidentielle de la liberté des mains de Barack Obama. Margaret Hamilton est considérée comme une pionnière de l’ingénierie logicielle et comme une des personnes qui ont contribué à la populariser.

JoAnn H. Morgan (née en 1940) la seule femme présente dans la salle de tir lors du lancement d’Apollo 11

Sur une photo de la salle de tir d’Apollo 11, le 16 juillet 1969, elle apparaît comme la seule femme derrière une console. Les femmes que l’on voit sur le côté sont entrées après le lancement.

Étant enfant, elle préférait lire Jules Verne à jouer à la poupée2 et jouer avec la boîte de chimie que son père lui avait offert. Son père, justement, travaillait pour le programme de développement des fusées américaines. JoAnn H. Morgan va passer son adolescence à Titusville en Floride, à quelques kilomètres de la base de lancement de Cap Canaveral. Elle y regardera les lancements des fusées. Ce qui la décidera dans son orientation professionnelle. Elle commence, à dix-sept ans, par un stage à l’Army Ballistic Missile Agency (ABMA, Agence des missiles balistiques de l'armée de terre). Elle continuera à travailler à Cap Canaveral pendant l’été. En 1963, elle obtient un Bachelor of Arts (licence) en mathématiques. Elle commence à travailler pour la NASA au Centre spatial Kennedy (KSC) en tant qu’ingénieure. Elle sera la seule, ça n’a pas été facile : entre le fait que son supérieur hiérarchique trouve nécessaire de préciser qu’elle est ingénieure et pas là pour faire le café pour ses collègues (en) ou l’absence de toilettes pour femmes.

En 1969, elle est promue et devient « Chief Instrumentation Controller, KSC Technical Support » (Contrôleur en chef de l’instrumentation, support technique du centre), ce qui lui donne un poste dans la salle de contrôle de la mission Apollo 11. L’équipe de Morgan sera celle qui supervisera le lancement de la mission ce qui lui demandera de rester dans la salle de contrôle encore après le lancement pour pouvoir vérifier les équipements et faire un rapport sur les dommages consécutifs au lancement afin de préparer le suivant, sa tâche, dans le cadre de la mission, s’arrête au moment de l’atterrissage lunaire. Elle considère que c’est ce qui a lancé sa carrière.

Après Apollo 11, elle bénéficiera d’une bourse Sloan pour poursuivre des études et elle obtiendra une maîtrise en sciences de gestion en 1977 et retournera à la NASA en 1979 où elle est promue chef de la division des services informatique du KSC, première femme à occuper ce poste en particulier et un poste de direction à la NASA. Une tâche ardue dans une période de transition technologique : la NASA changeait son système informatique et commençait à remplacer les vieux ordinateurs géants par des PC. Elle deviendra ensuite directrice adjointe des véhicules de lancement (deputy of Expendable Launch Vehicles, director of Payload Projects Management) puis directrice de la sécurité de la mission ( director of Safety and Mission Assurance). Elle aura été l’une des deux dernières personnes à avoir vérifié le lancement de la navette spatiale.

Elle prend sa retraite en 2003 après avoir passé toute sa carrière à la NASA.

Morgan continue à militer pour que plus de femmes puissent suivre des carrières scientifiques et techniques.

Frances Northcutt dite « Poppy » (née en 1943) l’autre seule femme présente dans les salles de tir des missions Apollo 8 et 13

Frances « Poppy » Northcutt a planifié les trajectoires des vols des missions Apollo dans les années 1960 et 1970.

Elle commence sa carrière dans l’aérospatiale comme Judith Love Cohen en étant embauchée en 1965 par TRW. Elle sera d’abord une des calculatrices humaines. Problème : pour pouvoir bénéficier d’une promotion, elle devait faire des heures supplémentaires si nécessaire, ce qui était interdit aux femmes états-uniennes de l’époque. Elle tient le pari d’en faire mais non rémunérées. Cela fonctionne, elle obtient une promotion et intègre l’équipe technique (personnel effectuant des travaux ingénierie), mieux payée. Ce qui pose un autre problème, celui de l’écart de rémunération entre les hommes et les femmes.

Le travail de l’équipe technique consistait à écrire le programme. D’autres assuraient la tâche de le rentrer dans l’ordinateur, ce qui n’allait pas sans quelques bugs au passage, qui pouvaient avoir des conséquences fatales. L’équipe de Northcutt était chargée du calcul de la trajectoire de retour d’Apollo 8. C’était une mission mémorable pour Northcutt à plus d’un titre. D’abord, c’était la première fois qu’un véhicule spatial habité allait être mis en orbite autour de la Lune. C’était aussi ce qui aura permis de déterminer l’équipement et le matériel nécessaire pour les missions suivantes, notamment la quantité de carburant nécessaire. Enfin, c’était la première fois que les calculs de Northcutt et de son équipe étaient utilisés, et cela allait servir aussi aux missions suivantes. Ainsi, après Apollo 8, il n’y aura pas eu de modifications des programmes, sauf en cas de problème. Pour Apollo 13, avec d’autres ingénieurs, elle aura pour mission de calculer le retour de la capsule Apollo après l’explosion du réservoir d’oxygène qui oblige l’équipage à rentrer sur Terre dans le module lunaire.

Elle suivra ensuite des études de droit à l’Université de Houston pour devenir avocate. Elle en sortira diplômée en 1981 et travaillera pour le procureur du comté de Harris à Houston, sera stagiaire auprès d’un juge fédéral en Alabama avant de se tourner vers le privé et défendre des causes sur les droits de femmes, elle qui a longtemps travaillé avec un salaire inférieur à celui de ses collègues pour le même travail.

Elle expliquera au site astronomy (en) :

J’ai eu beaucoup de chance. La plupart des femmes n’avaient pas quelqu’un qui se battait aussi durement pour elles.

Elle ajoutera :

C’est le problème auquel sont confrontées les femmes en particulier, lorsqu’elles sont embauchées pour un salaire inférieur à ce qu’elles valent. Si vous ne partez pas sur un pied d’égalité, vous ne pourrez jamais vous rattraper.

Northcutt continue à militer pour les droits des femmes, mis à mal aux États-Unis lors de la présidence de Trump.

Les tisserandes

Les tisserandes, dont beaucoup étaient navajos ou noires, les « Little Old Ladies » ont tressé les mémoires à tores de ferrite des missions Apollo. Elles avaient littéralement la vie des astronautes entre leurs mains.

Les RAM des ordinateurs des années 1950 à 1975 étaient le plus souvent des mémoires à tores de ferrite. D’après la notice de celles présentées au musée du Conservatoire National des Arts et Métiers (CNAM) à Paris dans la photo ci-dessous :

elles sont encore utilisées lors de certaines missions spatiales car elles ne sont pas endommagées par les rayons cosmiques.

Mémoires à tores de ferrite du Gamma 60 d’une capacité de 512 octets, début des années 1960, musée du CNAM, Paris.

La fabrication de ces mémoires ne pouvait pas être mécanisée, elles étaient donc tissées à la main. Et, à l’époque des missions Apollo les seules personnes qui avaient l’habilité et la précision digitale nécessaires pour le faire étaient des femmes, surnommées les LOL et supervisées par les « rope mothers » (mères des cordes), généralement des hommes, et dont la cheffe était Margaret Hamilton. Ce travail extrêmement critique, était contrôlé par trois ou quatre personnes avant d’être validé. Il réclamait non seulement des ressources manuelles mais aussi des capacités intellectuelles certaines pour être accompli correctement.

Quand, en 1975, un rapport de la NASA sur les missions Apollo s’extasiait, à juste titre, sur les systèmes informatiques développés en mis en œuvre, il négligeait complètement cet aspect essentiel. Les journalistes de cette époque, présentaient la fabrication des mémoires comme un travail ne nécessitant aucune réflexion ni aucune compétence…

Pour compléter Les ordinateurs soviétiques

• Sergeï A ; Lebedev, père de l’ordinateur soviétique, Pierre Vandeginste, La Recherche, mensuel N°375, mai 2004, pour accéder à l’article, il faut « l’acheter » en visionnant une publicité, le bouton qui permet cela ne se voit pas dans un Firefox avec un bloqueur de publicité, mais ça fonctionne bien avec Konqueror
• Les ordinateurs soviétiques : histoire obligée de trois décennies, Yves Logé, Revue d’études comparatives Est-Ouest Année 1987 18-4 pp. 53-75
• Il y a 50 ans : back in the USSR, Pierre Mounier-Kuhn, blog binaire, 24 janvier 2020
• Première génération d’ordinateurs (1936-1956), tout le site est en fait une histoire des calculatrices et des ordinateurs, Fabrice Auclert, 18 juillet 2019.

Missions Apollo

• Apollo 11 : un bond de géant technologique avec les ordinateurs de la mission,
• Il y a 50 ans, Apollo 13 : revivez en images la catastrophe transformée en succès
• Il y a 50 ans : l’ordinateur qui emmena l’Homme sur la lune, 26 juillet 2019
• Dépôt du code source d’Apollo 11 (en)
• Si vous voulez vous amuser à refaire l’ordinateur embarqué d’Apollo 11, vous pouvez vous procurer le matériel pour un euro (oui ça a coûté beaucoup plus cher au départ)
• Photos des missions (en).

L’exploration spatiale et les astronautes

• La conquête spatiale pas pour les femmes russes, Victoria Loguinova-Yakovleva, lapresse.ca, 14 juin 2013
• Les femmes dans l’espace : une conquête inégale, Maxime Tellier, Radiofrance, 18 octobre 2009
• Liste de femmes astronautes
• Svetlana Savitskaïa, première femme à avoir effectué une sortie extra-véhiculaire
• Corps européen des astronautes.

Sur la journée Ada Lovelace et la place des femmes dans les carrières scientifiques et techniques

• ‘I wrote my first piece of code at seven’: women share highs and lows in computer science for Ada Lovelace Day (en), 10 octobre 2023, témoignages de six femmes informaticiennes, Nature, 10 octobre 2023
• De l’école à l’entreprise, les femmes toujours découragées de faire carrière dans les métiers scientifiques et techniques, Charlotte Bozonnet, Le Monde, 2 octobre 2024.

Excuse et paragraphes de la fin

Cette dépêche paraît assez tardivement après la précédente pour des raisons assez indépendantes de ma volonté et incluant un piratage d’un de mes sites.

Ceci étant, un grand merci une fois de plus à vmagnin pour ses suggestions, notamment pour cette citation tirée d’une de ses lectures, Forces de la nature de François Lacombe, Anna Reser et Leila McNeil chez Belin :

Dans l’histoire des sciences et des vols spatiaux, on constate que cette distinction nette établie entre les tâches techniques et non techniques a été l’une des façons de marginaliser systématiquement les femmes.

Ce qui se vérifie amplement notamment avec les tisserandes des mémoires.

Comme de bien entendu, entre les recherches, l’écriture et les commentaires de la dépêche précédente, il appert qu’il y a un sujet connexe, celui de l’astronomie et de l’évolution du métier d’astronome et d’astrophysicienne qui mériterait d’être traité. Ce qui sera fait, d’ici la fin de l’année. Et, si vous cherchez un sujet de mémoire ou thèse, à mon avis le thème des langages informatiques : naissance, diversité, histoire, pourquoi un langage très populaire finit par être abandonné, etc. pourrait être passionnant (si ça n’a pas déjà été fait). Peut-être qu’un jour je vous infligerai un texte sur l’histoire de l’informatique soviétique (ou peut-être pas).

1. Citation reprise de l’article d’Yves Logé dans « Les ordinateurs soviétiques : histoire obligée de trois décennies » Revue d’études comparatives Est-Ouest Année 1987 18-4 pp. 53-75 qui cite D. Brand, L’Union Soviétique, France, Sirey, 1984, p. 230. ↩

2. L’autrice de cette dépêche aussi à qui ce comportement paraît tout à fait normal. ↩

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

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  (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 :


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 

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 .

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.

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

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.

• [Le Monde.fr] Lina Khan, la femme qui fait trembler les Gafam (€)
• [La République] Vie privée, logiciels libres: ce journaliste veut sensibiliser à un usage plus éthique de l'informatique
• [Next] L'Open Source Initiative accuse Meta de polluer la définition de l'IA open source
• [ZDNET] Wordpress: l'écosystème open source s'enfonce dans le conflit

• lien nᵒ 1 : April
• lien nᵒ 2 : Revue de presse de l'April
• lien nᵒ 3 : Revue de presse de la semaine précédente
• lien nᵒ 4 :

Calendrier Web, regroupant des événements liés au Libre (logiciel, salon, atelier, install party, conférence), annoncés par leurs organisateurs. Voici un récapitulatif de la semaine à venir. Le détail de chacun de ces 27 événements (France: 24, internet: 2, Suisse: 1) est en seconde partie de dépêche.

• lien nᵒ 1 : April
• lien nᵒ 2 : Agenda du Libre
• lien nᵒ 3 : Carte des événements
• lien nᵒ 4 : Proposer un événement
• lien nᵒ 5 : Annuaire des organisations
• lien nᵒ 6 : Agenda de la semaine précédente
• lien nᵒ 7 : Agenda du Libre Québec

Sommaire

• • [FR Vandœuvre-lès-Nancy] Infographie – Sérigraphie – Du lundi 21 octobre 2024 à 14h00 au vendredi 25 octobre 2024 à 17h00.
  • [internet] Mapathon en ligne 2024-2025 – Le lundi 21 octobre 2024 de 18h00 à 20h00.
  • [FR Montpellier] Permanence | GNU/Linux et Logiciels Libres – Le mardi 22 octobre 2024 de 15h00 à 17h00.
  • [internet] Émission «Libre à vous!» – Le mardi 22 octobre 2024 de 15h30 à 17h00.
  • [FR Angoulême] Apéro Numérique – Le mardi 22 octobre 2024 de 18h00 à 20h00.
  • [FR Le Mans] Permanence du mercredi – Le mercredi 23 octobre 2024 de 12h30 à 17h00.
  • [FR Le Blanc] Atelier “Libre” – Le mercredi 23 octobre 2024 de 14h00 à 17h00.
  • [FR Beauvais] Sensibilisation et partage autour du Libre – Le mercredi 23 octobre 2024 de 18h00 à 20h00.
  • [FR Vandœuvre-lès-Nancy] Réunion OpenStreetMap – Le mercredi 23 octobre 2024 de 18h00 à 20h00.
  • [FR Cysoing] Mercredis Linux – Le mercredi 23 octobre 2024 de 19h30 à 23h30.
  • [FR Bordeaux] Rencontre autour de l’Espéranto – Le jeudi 24 octobre 2024 de 18h00 à 19h30.
  • [FR Lyon] Recherche des bonnes pratiques de packaging – Le jeudi 24 octobre 2024 de 19h00 à 21h00.
  • [CA-QC] Rencontre du CA de FACiL – Le jeudi 24 octobre 2024 de 19h00 à 21h00.
  • [FR Quimperlé] Point info GNU/Linux – Le vendredi 25 octobre 2024 de 13h30 à 17h30.
  • [FR Annecy] Réunion hebdomadaire AGU3L Logiciels Libres – Le vendredi 25 octobre 2024 de 20h00 à 23h59.
  • [FR Fourmies] Donnez une seconde vie à vos ordinateurs – Le samedi 26 octobre 2024 de 09h15 à 09h15.
  • [FR Beauvais] Utiliser et enrichir la carte collaborative OpenStreetMap – Le samedi 26 octobre 2024 de 09h30 à 12h00.
  • [FR Bégard] Permanence infothema (Groupe 1) – Le samedi 26 octobre 2024 de 10h00 à 12h00.
  • [FR Ivry sur Seine] Cours de l’École du Logiciel Libre – Le samedi 26 octobre 2024 de 10h30 à 18h30.
  • [FR Montpellier] Prépa de l’ÉRABLE – Week-end de travail et de convivialité – Du samedi 26 octobre 2024 à 11h00 au lundi 28 octobre 2024 à 17h00.
  • [CH Genève] Café Linux – Le samedi 26 octobre 2024 de 13h00 à 14h00.
  • [FR Marseille] Install Party GNU/Linux – Le samedi 26 octobre 2024 de 14h00 à 19h00.
  • [FR Saint Cyr l’École] Permanences logiciels libres – pc et smartphones – Le samedi 26 octobre 2024 de 14h00 à 17h00.
  • [FR Brasparts] Install-party et distribution d’ordis reconditionnés Linux. – Le samedi 26 octobre 2024 de 14h00 à 18h00.
  • [FR Ramonville Saint-Agne] Atelier Paheko – Le samedi 26 octobre 2024 de 14h00 à 18h00.
  • [FR Juvisy-sur-Orge] Permanence GNU/Linux – Le samedi 26 octobre 2024 de 14h30 à 17h00.
  • [FR Nantes] Permanence Linux-Nantes – Le samedi 26 octobre 2024 de 15h00 à 18h00.
  • [FR Quimper] Permanence Linux Quimper – Le samedi 26 octobre 2024 de 16h00 à 18h00.

[FR Vandœuvre-lès-Nancy] Infographie – Sérigraphie – Du lundi 21 octobre 2024 à 14h00 au vendredi 25 octobre 2024 à 17h00.

Les participants donneront une image qui témoigne de leur propre regard sur le quartier Vand'Est où ils vivent au quotidien.

Loin des clichés du quartier rêvé ou d’une vision futuriste, il est attendu que le livre et le tee-shirt imprimés qui recueilleront ces images soient un témoignage de ceux qui y habitent.

Les après-midi ; public adolescents ; gratuit sur inscription obligatoire: 03 57 80 58 35

Organisé par la FCCL et Yves Coppens
Animé par Philippe Morlot, association L’Antre.

• Espace Yves Coppens, 54 allée de Marken, Vandœuvre-lès-Nancy, Grand Est, France
• https://fccl-vandœuvre.fr
• infographie, gimp, création, logiciels-libres, stage, fccl

[internet] Mapathon en ligne 2024-2025 – Le lundi 21 octobre 2024 de 18h00 à 20h00.

Vous voulez vous engager pour une cause, rencontrer de nouvelles personnes et découvrir la cartographie participative et humanitaire? CartONG vous invite à participer à un ou plusieurs mapathons en ligne!