Incident du 26 juin 2025 ayant touché les serveurs de production et de développement

Posté par  (site web personnel) . Édité par Florent Zara, palm123 et bobble bubble. Modéré par Florent Zara. Licence CC By‑SA.
Étiquettes :
33
27
juin
2025
LinuxFr.org

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

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

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

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

Changement d'adresses IP

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

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

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

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

Incident :

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

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

Nature du redémarrage

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

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

Mesures préventives et correctives

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

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

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

  • # C'est sans doute lié à l'orage

    Posté par  (site web personnel) . Évalué à 7 (+6/-0).

    Je ne l'ai pas entendu sur les médias, mais il y a bien une coupure électrique sur une partie sud de Paris depuis la nuit du 25 au 26. J'en sais quelque chose… notre salle serveur n'étant pas redondée faute de budget (mais ça n’empêche pas le dictateur d'appeler les chercheurs états-uniens réprimés à venir chez nous, de prétendre qu'on va devenir des meneurs dans l'IA, etc.), c'est le branle-bas de combat depuis cette fameuse nuit pour transférer des VMs à la main vers les machines d'un autre site. Bon là le courant vient d'être rétabli et les grosses têtes commencent à se détendre… mais il reste à échelonner le démarrage des équipements et machines bien sûr, il y en a encore pour deux/trois heures. J'ai demandé un archivage de la page contenant de vagues informations

    • [^] # Re: C'est sans doute lié à l'orage

      Posté par  (site web personnel, Mastodon) . Évalué à 4 (+4/-3). Dernière modification le 27 juin 2025 à 12:56.

      Je dois dire que ceci laisse rêveuse :

      De même, les bureaux étant globalement inaccessibles, les personnels sont invités à se rapprocher de leurs chefs de service pour organiser leur journée de travail.

      Les gens ne peuvent même plus aller bosser parce qu'ils ne peuvent plus entrer dans leur bureau. Cela dit, si leur boulot se fait essentiellement avec un ordinateur, de toute façon, iels ne peuvent pas travailler.

      Une direction intelligente leur filerait une journée de relâche payée hors congés et récupération, naturellement.

      « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

      • [^] # Re: C'est sans doute lié à l'orage

        Posté par  . Évalué à 4 (+4/-2).

        Une direction intelligente leur filerait une journée de relâche payée hors congés et récupération, naturellement.

        Et inventerait ainsi le chômage technique. Brillant.

      • [^] # Re: C'est sans doute lié à l'orage

        Posté par  (site web personnel) . Évalué à 1 (+0/-0).

        Une direction intelligente leur filerait une journée de relâche payée hors congés et récupération, naturellement.

        C'est ce qui s'est certainement passé dans 99% des cas t'inquiète. On est vraiment pas à plaindre sur ce sujet (faut bien compenser les nombreux autres dysfonctionnements). Ils mettent ça pour se protéger car il y en a un paquet qui pourrait en profiter abusivement, car nous avons tout de même 25 autres sites et certaines choses pouvaient tout de même être faites sans informatique.

    • [^] # Pas sûr… Re: C'est sans doute lié à l'orage

      Posté par  (site web personnel, Mastodon) . Évalué à 5 (+2/-0). Dernière modification le 27 juin 2025 à 15:14.

      Ça doit être les burgers

  • # ip hardcodées dans la config en 2025?

    Posté par  (Mastodon) . Évalué à 4 (+2/-1).

    Je ne comprends pas pourquoi vous utilisez des containers mais hardcodez des ip dans une config. Le but d'utiliser des containers, c'est entre autre de pouvoir bénéficier de l'auto découvertes de services. Votre reverse proxy a juste à pointer vers les hostname des containers sur le DNS du réseau interne de docker/podman/kubernetes/nomad/.

  • # plan d'adressage IPv4 only (RFC1918)... en 2025 ?

    Posté par  . Évalué à 4 (+5/-1).

    Loin de moi l'idée de critiquer avec des idées toutes faites et ce n'est pas pendant le "coup de feu" qu'il faut lancer des sujets qui pourraient rapidement devnenir "trollesque".

    Aussi ce qui suit est juste pour alimenter la réflexion pour d’éventuelles futures évolutions.

    "En 2025 on monte encore des archi en IPv4 only" ?

    Les archi "cloudesques" contemporaines à base de pods/conteneurs sont majoritairement orientées services (ou micro-services) applicatifs web (API REST) ? En général, sur ce type d'archi on dispose d'un frontal (parfois dénommé ingress-controler/load-balancer/reverse-proxy) qui relaie (et contrôle au passage) sur les services applicatifs en arrière plan. L'interface(s) externe(s) de ce frontal est "l'unique" interface qui serait dual-stack :une (ou des) IPv6 GUA(aka publique(s) et une ou(des) interfaces IPv4 publiques.

    En 2025, l'arrière plan devrait être IPv6 only. L'ensemble des pods/conteneurs de services ainsi que l'interface(s) interne(s) de l'ingress-controler devraient être "confinées" dans un domaine de diffusion (VLAN) dédié. Avec uniquement des adresses LLA "fe80::xxxx:xxxx:xxxx:xxxx/64" (confinées donc non routables, ne permettant que les com entre voisins directs). Une interface IPv6 dispose d'autant d'adresses que nécessaires. Il y a toujours une LLA par défaut à l'activation de l'interface, mais l'admin peut en ajouter à sa convenance, y compris une LLA avec un IID (Interface ID) stable, opaque (ne révèle pas d'info sensible matérielle de l'interface). La stabilité de ces adresses les rendent aptes à ếtre gérées par le système de nommage et/ou l'IPAM. Elles sont destinées au flux applicatifs entrant. Non routables ces addresses nécessitent d'être suffixées par l'interface qui la porte par le séparateur '%' suivi de l'interface ("fe80::xxxx:xxxx:xxxx:xxxx%ethn" par exemple). Pour les appels systèmes sous forme d'URI il faut l'encadrer par des '[' ']' (https://[fe80::xxxx:xxxx:xxxx%ethn]:4443 par exemple).

    L'avantage du plan d'adressage LLA est d'être indépendant de l'infrastructure, il devrait donc pouvoir être "relocalisé" facilement en cas de besoin. Si le VLAN en arrière plan doit être étendu mutli-site, in maillage VXLAN chiffré devrait pouvoir faire l'affaire.

    Alternativement, il est également possible de gérer "classiquement" le réseau en arrière plan avec un plan d'adressage IPv6 privatif bâti sur un préfixe ULA (/48).

    Pour ceux que cela intéresse : info détaillées sur les séquences 1 et 4 du MOOC "Objectif IPv6" sur France Université Numérique (ressources en CC-BY-SA). La session 10 s'achève la semaine prochaine, la session 11 devrait débuter à l'automne.

    • [^] # Re: plan d'adressage IPv4 only (RFC1918)... en 2025 ?

      Posté par  . Évalué à 4 (+3/-1).

      "En 2025 on monte encore des archi en IPv4 only" ?

      Cette archi n'a pas était monté en 2025

      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

      • [^] # Re: plan d'adressage IPv4 only (RFC1918)... en 2025 ?

        Posté par  . Évalué à 1 (+3/-2).

        Le protocole IPv6 est un protocole du millénaire/siècle dernier (RFC2460 de 1998, auquel s'est substitué le RFC8200 de 2017). Cela fait bientôt 25 ans que "je "prêche dans le désert" en enseignant IP en "v6 only" sous le regard narquois de collègues qui me prennent au mieux pour un illuminé ; si ce n'est un "psycho rigide". Depuis les années 2010 je conclus le cours en indiquant/espérant que tout nouveau segment réseau (VLAN) devrait être en v6 (aller, soyons indulgent à minima dual stack v6/v4).

        Dès le début des années 2000. Les bonnes pratiques recommandaient aux développeurs d'application des développer uniquement en AF-INET6 en intégrant la totalité de l'espace d'adressage V4 dans l'espace d'adressage v6 derrière le préfixe ::ffff:0:0/96 "IPv4-mapped IPv6 address" du RFC3493 (adresse de la forme ::ffff:a.b.c.d). De cette manière la couche applicative ne manipule que des adresses v6 (gestion dynamique des adresses, règles de sécurisation (filtrage) et d'autorisation dans un seul format).

        Je n'ai jamais compris pourquoi les dev de Google, aux alentours de 2014 pour kubernetes, ont codé en dur dans l'applicatif la gestion dynamique de l'adressage et sa sécurisation sur le préfixe privatif RFC1918 10.0.0.0/8 et le localhost 127.0.0.1. Résultat la gestion réseau dans les clusters k8s est d'une complexité "de dingue". Et il a fallu attendre pratiquement 7 années (k8S 1.23 (~2021) et supérieurs) pour ajuster le code de l'usine à gaz réseau IPv4 et commencer à avoir des clusters qui "marchouillent" en IPv6. Alors qu'en AF-INET6 et l'intégration "mapped IPv4 IPv6 address", kube aurait fonctionné correctement en dual stack dès la version 1.0. K8S aurait pu jouer le rôle de "killer application", attendue/espérée depuis 1998 qui aurait accéléré l'adoption (à l'instar du web de Tim Berner Lee et du protocole HTTP qui en quelques années, à partir de 1994, a imposé TCP/IP et relégué aux oubliettes les protocoles dominants de l'époque : OSI, X25, Netware, Netbios,… Alors qu'à l'époque TCP/IP n'était qu'un protocole universitaire snobbé par l'OSI et l'UIT-T). Quant à l'autre dominant du cloud, à savoir, Docker il a fallu patienter jusqu'à la v27 pour qu'IPv6 soit "facilité" ("Docker supporte IPv6 depuis la version 1.5, avec une configuration simplifiée à partir de Docker Engine v27 où l'activation d'IPv6 est désormais automatique sans nécessiter de modifications du daemon, et Docker Desktop 4.42 offre une prise en charge native d'IPv6". Si j'en crois le résumé IA de Qwuant : à vérifier!).

        Cette archi n'a pas était monté en 2025

        Effectivement et comme je viens de l'indiquer dans le monde des pods/conteneurs, pour les adminsys, jusqu'à il y a peu IPv6 restait une "quête".

        J'entame ma 64ieme année et à l'automne ma dernière rentrée, avec la satisfaction de constater que le France se maintient sur l' "IPv6 world podium", et qu'on arrive "enfin" à un point de bascule quant au traffic global en IPv6 natif. A ce sujet, vous trouverez des info détaillées sur l'avancement du déploiement en France sur le baromètre IPv6 annuel de l'ARCEP.

        Mais avec le conservatisme des plateformes majeures du cloud je doute de voir IPv4 devenir, sous peu, une "langue morte".

        • [^] # Re: plan d'adressage IPv4 only (RFC1918)... en 2025 ?

          Posté par  . Évalué à 3 (+2/-1).

          Bon

          Venir expliquer la vie à des bénévoles qui font comme ils peuvent avec les moyens qu’ils ont (financièrement, mais aussi en temps et en matériel). Tout ça pour décrire :

          • quelque chose qui n’aurait rien résolu (que ce soit une IPv4 ou v6 ne change rien, c’est le fais d’avoir une configuration statique à côté d’un composant dynamique avec DHCP qui a posé problème)
          • quelque chose de complètement hors sol avec des composants que tu liste parce que tu les aimes bien sans tenir compte de ce qui est pertinent ici. Composant qui eux-mème n’était pas en mesure de faire ce que tu propose de faire au moment où l’archi a était montée (mais ils auraient pu corrigé le problème qui est apparu ça oui avec l’ajout d’une grande complexité…)

          Bref c’est pour ça que tu es down voté. J’ai rien contre k8s/docker, j’ai milité pour le passage à IPv6 dans ma précédente entreprise où ça s’arrachait les cheveux à cause de sparadrap ajouté sur de l’IPv4. Mais là ton discours n’a rien de pertinent.

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

          • [^] # Re: plan d'adressage IPv4 only (RFC1918)... en 2025 ?

            Posté par  . Évalué à 1 (+1/-0).

            Je respecte l'engagement des bénévoles, et tout particulièrement en période de galère.

            Lecteur passif depuis plus de deux décennies (mais pas 27ans), linuxfr est une des mes principales sources de veille sur le numérique libre. J'ai hésité à répondre au post de de > Psychofox. Finalement je me suis dit pourquoi pas échanger, après tout un forum est fait pour partager les points de vue.

            Maladresse ? Pas le bon fil de discussion ? Pas le bon moment ("too soon") ? Pas le bon format ? Pas pertinent ? Ok je peux l'entendre. Je n'ai peut être pas tous les codes sociaux pour cette assemblée.

            J'espère que les efforts seront rapidement couronnés de succès et que vous retrouverez une infra opérationnelle et l'exploitation à votre main qui vous convient.

            Je retourne dans le confort de l'anonymat du lectorat passif et silencieux. Bonne et longue continuation. Mon intérêt pour le site demeure intacte.

            A l'avenir, je sais que je n'hésiterai pas… à m'abstenir.

            Salut!

            • [^] # Re: plan d'adressage IPv4 only (RFC1918)... en 2025 ?

              Posté par  . Évalué à -3 (+0/-5).

              Pas le bon fil de discussion ? Pas le bon moment ("too soon") ? Pas le bon format ? Pas pertinent ?

              L'utilisation de tes gros sabots pour expliquer ce qui doit être fait plutôt que de chercher à comprendre la situation. Ça n'a rien de spécifique linuxfr comme problème.

              A l'avenir, je sais que je n'hésiterai pas… à m'abstenir.

              C'est une tentative de te victimiser ? Tu ne te crois pas en mesure d'avoir une communication plus apaisée ? Je suis moi même rempli de défauts et je tente de m'améliorer plutôt que de fuir la difficulté

              https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

            • [^] # Re: plan d'adressage IPv4 only (RFC1918)... en 2025 ?

              Posté par  (site web personnel) . Évalué à 5 (+2/-0).

              Je suis le plus actif sur l'admin sys. du site, j'ai mis en place la configuration qui a foiré dans le cadre de l'incident, j'étais dans ceux qui sont intervenus pour réparer et j'ai écrit la dépêche présente. Et, sur le fond, je prends les critiques sur IPv6, je ne dirais pas que c'est agréable, mais bon c'est assez logique somme toute que ça soit attendu. Reste à le faire (*). Contribuer aux tests pourrait aider un peu. Tout ça pour dire que ce n'est pas l'équipe du site qui rembarre gentiment vos commentaires, mais des lecteurs qui nous aiment bien.

              (*) j'ai dû avoir ma première formation IPv6 il y a 20 ans, et il y encore compétition pour savoir si j'en verrais en premier en production pour le boulot ou pour l'associatif…

            • [^] # Re: plan d'adressage IPv4 only (RFC1918)... en 2025 ?

              Posté par  (site web personnel) . Évalué à 3 (+3/-1).

              A l'avenir, je sais que je n'hésiterai pas… à m'abstenir.

              De nombreux intervenants ont quitté le navire à cause de l'ambiance… perso je suis le site un peu de loin et envoie quelques contributions militantes par ci par là, en sachant très bien que je vais me faire rembarrer presque à chaque fois(y compris en étant considéré comme trop libriste et anti Gafamycu, un comble ! je me fais moins démolir dans des endroits non-censées être pro-libre)…

              • [^] # Re: plan d'adressage IPv4 only (RFC1918)... en 2025 ?

                Posté par  . Évalué à 4 (+2/-0).

                en étant considéré comme trop libriste et anti Gafamycu

                Je ne crois pas que tu te fasses rembarrer parce que "trop libriste" non. Bon je n'ai parcouru rapidement que les 2 premières pages de tes commentaires, mais même là je crois que tu n'es moinssé que lorsque tu écris des trucs comme Windaube, Micro$oft, et autres trucs non argumentés mais qui font surtout… gamin. On peut encenser Linux et le libre sans jouer au r3belle H4x0r. Ça par exemple ça ne défend pas le libre, ça attaque gratuitement (un logiciel libre) et sans argument. Le logiciel te paraît inutile, à moi aussi puisque je n'ai pas de machine sous Windows, mais ça n'est pas tellement "bonne ambiance" (vu que tu te plains de l'ambiance) de venir juste pour lâcher « m$ ferait mieux de corriger la bouse que certains considèrent comme un OS. »

    • [^] # Re: plan d'adressage IPv4 only (RFC1918)... en 2025 ?

      Posté par  . Évalué à 3 (+1/-0).

      Merci pour l'exposé.

      L'avantage du plan d'adressage LLA est d'être indépendant de l'infrastructure, il devrait donc pouvoir être "relocalisé" facilement en cas de besoin. Si le VLAN en arrière plan doit être étendu mutli-site, in maillage VXLAN chiffré devrait pouvoir faire l'affaire.

      Avec des IPs RFC1918 et un VLAN aussi, c'est généralement portable. Ce qui a mis le bazar ici c'est le DHCP.

      Les archi "cloudesques" […] pods/conteneurs […] orientées services (ou micro-services) […] frontal […] ingress-controler/load-balancer/reverse-proxy) qui relaie […]

      C'est une complexité inutile pour un site comme Linuxfr :).

      Par contre, pour te rejoindre, mais sur le côté IP publique, l'argument de ne pas proposer d'IPv6 parce que la fonction de vote regarde les IPs pour éviter la triche, bof en 2025 non ?.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.