Benoît Sibaud a écrit 10261 commentaires

Les images destinées à LinuxFr.org sont stockées sur LinuxFr.org au premier accès réussi. Le stockage d'origine peut bien disparaître ensuite. Par contre si le stockage d'origine se met à mentir (servir une autre image valide à la place de l'image initiale) là c'est une autre histoire. Voir le paragraphe « 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. (…) » de https://linuxfr.org/news/img-le-cache-d-images-sur-linuxfr-org#toc-les-probl%C3%A9matiques-restantes

Si ça peut produire des malwares efficaces, ça peut aussi produire du code utile, non ?

• l'attaque est plus facile que la défense (d'un côté réussir toujours, de l'autre réussir une fois), moins exigeant (l'attaquant peut avoir des choses très imparfaites, trop gourmandes, dévastatrices, etc. Mais qui marchent souvent à la fin). Néanmoins l'attaque se "professionnalise/s'industrialise" chez les gros méchants, donc monte en gamme.
• ça dépend de la définition de "utile" retenue ici : faire du code jetable de prototype, oui. Faire du code que tu ne saurais de tout façon pas faire, oui. Faire du code passable, oui. Faire du code de grande qualité, maintenable ou très complexe, ça reste à démontrer. Ce n'est pas manichéen IA bonne/nulle, ça dépend, et justement parce que ça dépend, c'est l'humain qui supervise qui soit a tout lâché parce que non-compétent sur le sujet, soit qui guide/vérifie le processus.

(Et c'est indépendant des autres aspects négatifs évoqués nocivité en termes de gaspillage de ressources, utilisation abusive de travailleurs sous-payés, dépendance émotionnelle et autres)

Bien vu.

https://www.geeksforgeeks.org/python/range-vs-xrange-in-python/

The variable storing the range created by range() takes more memory as compared to the variable storing the range using xrange(). The basic reason for this is the return type of range() is list and xrange() is xrange() object.

    The size allotted using range() is : 
    80064
    The size allotted using xrange() is : 
    40

Donc basiquement c'est juste le range() le souci, même pas la fermeture des descripteurs ou la gestion des exceptions. Et c'est qui était moche mais indolore est devenu un gouffre de ressources lors de l'extension massive de la taille de la boucle.

Que quatre sur ma capture car la prod était alors stoppée et qu'il s'agit uniquement de mon test sur une copie de la dépêche G'Mic qui contient 4 blocs avec coloration. Pendant l'incident, potentiellement bien plus suivant le nombre de blocs édités (sachant que les processus ne finissent pas vraiment avant des heures, ils s'empilent jusqu'à ce que la Mort par OOM ne survienne)

Au passage, c'est un peu le code ultime qui sature ton CPU, qui sature ta RAM et qui tue tes I/O avec l'extérieur… dommage qu'il ne fasse rien d'utile.

Visiblement en python 2, sur ce code, VIRT et RSS se suivent (0.032t ça fait 32g ; comme on avait 2 fois 300M ou 3G dans mes tests)

Cf https://linuxfr.org/news/incident-du-26-aout-2025-ayant-touche-les-serveurs-de-production-et-de-developpement

comprendre la surconsommation mémoire ? (les boucles actives expliquent la consommation processeur, mais pour la mémoire ?)

Prenons ce court bout de code :

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

Avec la valeur X=10000000, il s'exécute en 6s avec python2 .

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
   2609 alpha     20   0  342120 325216   4088 R 100.0  0.1    (snip) python2

real  0m6.304s

Avec la valeur X=100000000, il s'exécute en 66s toujours avec python2. Et la mémoire s'affole.

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
   2610 alpha     20   0 3206084 3.041g   4108 R 100.0  1.2    (snip) python2

real  1m5.876s

Même machine, même code, juste en exécutant avec python3. Beaucoup plus raisonnable en mémoire. Par contre la boucle active occupe toujours le processeur forcément.

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
   2611 alpha     20   0   28732  10032   5424 R 100.0  0.0    (snip) python3

real    1m0.274s

Du coup il y a une fuite quelque part avec Python2, pas directement liée au code lui-même.

Imagine si les humains étaient des bactéries à quelques générations près.

Imagine si les Européens étaient des Africains à quelques générations près.

le dev ruby n'étant pas ma spécialité, en regardant les gems ruby les plus téléchargées pour la coloration syntaxique on trouve bien le composant actuel, quelques autres sans modification récentes et rouge qui semble très actif niveau développement.

Qui est le composant actuellement utilisé donc, une Gem ruby qui lance du Python. https://rubygems.org/gems/pygments.rb

Corrigé, merci (dans le contexte \20 donne 2, \\20 donne \20)

C'est précisément ce que dit la dépêche.

La version suivante du composant la remplace d’ailleurs par un ajout de l'option :close_others, qui précisément « modifie l’héritage [des descripteurs de fichiers du processus parent] en fermant les non-standards (numéros 3 et plus grands) ».

Caurigé, merci.

Corrigé, merci. Probable conséquence de l'incident d'hier (cf dépêche en attente de publication)

Ajouté, merci.

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

Visiblement il y a eu un hoquet dans l'alimentation électrique du serveur :

Thu Jun 26 2025 04:16:14    The system board PS1 PG Fail voltage is within range.   
Thu Jun 26 2025 04:16:09    The system board PS1 PG Fail voltage is outside of range.   
Thu Jun 26 2025 04:15:55    Power supply 1 fan is operating normally.   
Thu Jun 26 2025 04:15:55    Fan failure detected on power supply 1.

(je pensais qu'on avait vérifié ces logs à l'époque, mais apparemment non, en tout cas je viens de retomber dessus en traquant un autre incident…)

Ils sont dans le plan du bas de page évidemment, mais aussi réglables dans les préférences du compte, avec un réglage par défaut d'affichage sur la page d'accueil. On en parle aussi dans Proposer un contenu ou dans l'aide. Et ils ont donc leur partie dédiée

Sur une Ubuntu 24.04 par exemple, juste une petite sélection de quelques logiciels un peu connu :

$ apt rdepends perl|grep -vE "lib.*-perl"|grep Dépend
(...)
  Dépend: chromium
  Dépend: ocsinventory-server (>= 5.14)
(...)
  Dépend: mariadb-server (>= 5.6)
(...)
  Dépend: git
(...)
  Dépend: vmware-manager (>= 5.10.0)
(...)
  Dépend: xen-tools
(...)
  Dépend: sympa (>= 5.8)
(...)
  Dépend: nix-bin
(...)
  Dépend: mimefilter
(...)
  Dépend: debmirror
(...)
  Dépend: spamassassin
(...)

At the same time, because we are part of a European legal entity, F-Droid is obligated to comply with applicable European laws such as the General Data Protection Regulation (GDPR) and assess whether other European legislation like the Digital Services Act (DSA) and the Digital Markets Act (DMA) are applicable in our case.

RGPD: « Il s'applique aux entreprises établies en dehors de l'Union européenne qui traitent les données relatives aux activités des organisations de l'UE. Les sociétés non européennes sont également soumises au règlement dès qu'elles ciblent les résidents de l'UE par le profilage ou proposent des biens et services à des résidents européens. »

DMA : « Le règlement s'applique aux services de plateforme essentiels fournis ou proposés par des contrôleurs d’accès à des entreprises utilisatrices établies dans l’Union ou à des utilisateurs finaux établis ou situés dans l’Union, quel que soit le lieu d’établissement ou de résidence des contrôleurs d’accès et quel que soit le droit par ailleurs applicable à la fourniture des services »

Donc c'est en fait que le service est utilisé par des résidents européens, donc F-Droid est concerné RGPD/DSA/DMA. Et, par ailleurs, F-Droid est basé en Europe, alors il est concerné par toute la législation locale.

Faut aussi penser à NIS2, au Cyber Resilience Act, etc.

Cf https://linuxfr.org/users/cg/liens/the-register-the-year-of-the-european-union-linux-desktop-may-finally-arrive
https://linuxfr.org/users/abriotde/liens/abandon-microsoft
https://linuxfr.org/users/anubis/liens/ministere-du-numerique-danois-sur-la-voie-de-l-independance-a-microsoft

Ne pas faire la montée de version à chaque version donne plus de boulot ensuite (vu qu'il faut gérer une montée de plusieurs versions). Et petit à petit on commence à avoir des soucis de « vieux logiciels » (entre les postes clients à jour et les serveurs en retard par exemple).
Les mises à jour de sécurité sortent d'abord pour la version stable en cours, donc c'est un peu mieux niveau sécurité d'être en stable.
L'idéal pourrait être de tout réinstaller à chaque fois avec la dernière version (ça dépend si on sait automatiser ou bien gérer le transfert des données de l'ancienne à la nouvelle), mais sinon les mises à jour se font très bien.

J'ai fait les montées de version depuis Debian 12 bookworm vers 13 Trixie pour LinuxFr.org sur 3 serveurs, 1 VM et 2 conteneurs LXC par exemple : les releases notes sont très détaillées, les changements annoncés, ça se fait bien. Parce que la quantité de machines est raisonnable. Si je devais gérer des dizaines/centaines/milliers de machines, je ne passerai pas par les mises à jour, j'automatiserais le déploiement d'installations neuves.

Mais ça mériterait d'être précisé dans le site au endroit concerné, je vais laisser l'entrée ouverte pour l'instant du coup.

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

Historique (sur des années) : on avait un conteneur LXC daté (que l'on peine à moderniser) avec IP publique sur un hôte daté. On a migré ce conteneur sur un hôte à jour, il s'est retrouvé en IP privée derrière un frontal, puis on a commencé à déplacer des services (SQL, redis, epub, etc.) vers un autre conteneur LXC à jour (avec l'espoir de réduire l'ancien à zéro à terme). Ce qui a donné : un frontal qui doit parler à un conteneur, et un conteneur qui doit parler à un autre conteneur. Avant l'incident, les communications passaient par les adresses IP, attribués dynamiquement par dnsmasq-dhcp.

Situation courante post mesure corrective : dnsmasq-dhcp est configuré pour servir toujours les mêmes IP pour les adresses MAC des conteneurs, et les conteneurs se connaissent par leurs noms. Le frontal continue à utiliser les IP car il est hors de la résolution de noms LXC. Deux petits écueils :

• pour que la résolution fonctionne, il faut que le conteneur ait démarré, donc il faut gérer l'ordre de démarrage des conteneurs (ce qui redonnera 8 min d'interruption le 17 août après un redémarrage pour découvrir cela et corriger).
• étant parti d'un conteneur à IP publique, on se retrouve avec un conteneur nommé par exemple "alpha" associé à une IP publique alpha.linuxfr.org et donc sur l'hôte on a alpha qui a une IP publique et une IP privée. Si ce conteneur était refait de zéro il aurait un nom différent voire aléatoire et ce micro-problème n'existerait pas.

Non parce qu'on a des pénibles indonésiens qui nous spamment chaque jour pour leur casino donc ça nous arrangerait pour LinuxFr.org… (bon spammer étant un tantinet pas très respectueux des règles, pas sûr que ça aide une interdiction officielle)