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 Stéphane Ascoët (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 Ysabeau 🧶 (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 :
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 Voltairine . Évalué à 4 (+4/-2).
Et inventerait ainsi le chômage technique. Brillant.
[^] # Re: C'est sans doute lié à l'orage
Posté par Stéphane Ascoët (site web personnel) . Évalué à 1 (+0/-0).
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 Florent Zara (site web personnel, Mastodon) . Évalué à 5 (+2/-0). Dernière modification le 27 juin 2025 à 15:14.
# ip hardcodées dans la config en 2025?
Posté par Psychofox (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/.
[^] # Re: ip hardcodées dans la config en 2025?
Posté par openbar . Évalué à 4 (+3/-0).
Peut être ils utilisent des containers lxc?
# plan d'adressage IPv4 only (RFC1918)... en 2025 ?
Posté par jlandru . É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 barmic 🦦 . Évalué à 4 (+3/-1).
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 jlandru . É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!).
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 barmic 🦦 . É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 :
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 jlandru . É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 barmic 🦦 . Évalué à -3 (+0/-5).
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.
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 Benoît Sibaud (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 Stéphane Ascoët (site web personnel) . Évalué à 3 (+3/-1).
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 Faya . Évalué à 4 (+2/-0).
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 Stéphane Ascoët (site web personnel) . Évalué à 1 (+0/-0).
Tiens, on peut parcourir les commentaires d'un utilisateur ? je n'ai jamais trouvé comment…
[^] # Re: plan d'adressage IPv4 only (RFC1918)... en 2025 ?
Posté par Faya . Évalué à 3 (+1/-0).
Tu cliques sur son nom, puis dans la colonne de gauche tu as
[^] # Re: plan d'adressage IPv4 only (RFC1918)... en 2025 ?
Posté par cg . Évalué à 3 (+1/-0).
Merci pour l'exposé.
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.
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 ?.
[^] # Re: plan d'adressage IPv4 only (RFC1918)... en 2025 ?
Posté par jlandru . Évalué à 3 (+3/-0).
[^] # Re: plan d'adressage IPv4 only (RFC1918)... en 2025 ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 4 (+1/-0).
Légende urbaine, ça n'a jamais été un argument sur ce sujet. Cf l'entrée dans le suivi.
Actuellement à ma connaissance seuls deux composants ont été testés en IPv6 (img et epub).
[^] # Re: plan d'adressage IPv4 only (RFC1918)... en 2025 ?
Posté par cg . Évalué à 2 (+0/-0).
Je viens de relire l'entrée du suivi, et c'est quand même le point le plus débattu, ce qui entretien la légende ! Mais je conçois que ce n'est pas la seule raison :).
Je me demandais s'il existe un schéma d'archi (ou un texte) qui présente les différentes composants du site ? Je ne connais pas trop RoR, mais ça me rend curieux :).
[^] # Re: plan d'adressage IPv4 only (RFC1918)... en 2025 ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 5 (+2/-0).
ça manque un schéma oui. Vite fait, derrière le nginx frontal :
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.