Il y a exactement deux mois, un incident était survenu suite à un redémarrage brutal du serveur hébergeant les conteneurs de production et de développement ayant entraîné une attribution inattendue d’adresses IP. Et des réponses techniques 502 Bad Gateway pour notre lectorat.
Ce 26 août, vers 15:22, un message peu engageant est arrivé par pneumatique sur nos téléscripteurs (via Signal pour être précis) : « Tiens c’est bizarre j’ai perdu accès au site. Et au serveur oups. » L’après-midi et la soirée furent longues.
Le serveur répond au ping et permet les connexions TCP port 22, mais pas le SSH. Et les services web ne répondent plus. Souci matériel ? Noyau en vrac ? Attaque en cours ? Les spéculations vont bon train.
La connexion au serveur revient par intermittence, permettant à un moment d’exécuter quelques commandes, à d’autres d’attendre longuement pour l’affichage d’un caractère ou l’exécution de la commande tapée.
Le premier contact réétabli avec le serveur est assez clair (une forte charge) :
Connexion
$ uptime
15:06:59 up 2 days, 2:54, 1 user, load average: 50,00, 205,21, 260,83(dernier redémarrage le week-end précédent, mais surtout une charge système moyenne respectivement de 50, 205 et 261 sur les 1, 5 et 15 dernières minutes)
Initialement on suppose qu’il s’agit d’un trop grand nombre de requêtes ou de certaines requêtes tentant des injections de code sur le site (bref le trafic de fond plutôt habituel et permanent), et on ajoute des règles de filtrage péniblement et lentement pour bloquer les IP qui ressortent le plus dans nos logs.
Le site est alors inaccessible pendant plusieurs périodes. On arrête et relance ensuite plusieurs fois les services en pensant avoir ajouté suffisamment de filtrage, mais rapidement le serveur se retrouve englué. Les services sont alors arrêtés plus longuement le temps d’analyser les logs au calme. Au calme inclut notamment ne pas juste disposer d’une connexion ssh depuis un smartphone, mais plutôt d’un clavier et d’un grand écran par exemple, de l’accès à tous les secrets et toute la documentation aussi.
Finalement le trafic n’est pas énorme (en volume total) et si les requêtes hostiles sont bien présentes, rien ne semble inhabituel. Par contre les processus de coloration syntaxique partent en vrille, consommant chacun un processeur et aspirant allègrement la mémoire disponible. Avant d’être éliminés par le noyau Linux.
La console est remplie d’élimination de processus de ce type :
Mais si rien n’a changé niveau logiciel sur le conteneur LXC de production et si les requêtes ne sont pas inhabituelles, qu’est-ce qui peut bien écrouler le serveur et créer ces processus gourmands ?
Pendant les phases d’attente lorsque le serveur ne répondait plus vraiment, nous avons noté qu'une nouvelle entrée de suivi a été créée (merci BAud et merci RSS/Atom pour nous avoir permis de la voir alors que le serveur ne répondait déjà plus). Elle indique que la coloration syntaxique ne marche plus sur le site. Notamment l’exemple donné dans la documentation.
Pourtant le rendu fonctionne en testant en ligne de commande avec pygmentize.
Mais oui en testant l’exemple donné via le site, il est créé un processus Python2 pygment qui commence à se gaver de ressources.
Et en regardant les différents contenus et commentaires créés sur le site autour de l’incident, en filtrant sur ceux contenant des blocs avec de la coloration syntaxique, la dépêche (alors en préparation) sur G'MIC 3.6 apparaît. Et en testant cette dépêche, il est bien créé quatre processus Python2 pygment qui se gavent de ressources et ne semblent jamais vouloir se terminer. À rapprocher par exemple d’une page qui a été servie en 6785.9978s.
OK, le souci vient de requêtes tout à fait habituelles de coloration syntaxique, reste à comprendre pourquoi ces processus tournent mal.
Un petit strace pour suivre les appels système en cours sur un des processus infernaux relève une boucle assez violente :
(...)
close(623199355) = -1 EBADF (Bad file descriptor)
close(623199356) = -1 EBADF (Bad file descriptor)
close(623199357) = -1 EBADF (Bad file descriptor)
(...)
Il semble y avoir une immense itération sur des descripteurs de fichiers, en vue de les fermer, mais à l’aveugle, sans savoir s’ils existent réellement.
En regardant le code du composant utilisé (pygments), il semble n'y avoir qu'un seul appel à close() :
# close fd's inherited from the ruby parent
import resource
maxfd = resource.getrlimit(resource.RLIMIT_NOFILE)[1]
if maxfd == resource.RLIM_INFINITY:
maxfd = 65536
for fd in range(3, maxfd):
try:
os.close(fd)
except:
passDonc on itère sur tous les descripteurs entre 3 et le maximum déterminé…
>>> import resource
>>> print(resource.getrlimit(resource.RLIMIT_NOFILE)[1])
524288
>>> print(resource.RLIM_INFINITY)
-1Un demi-million de fois ici donc. L’objectif initial de la boucle est de fermer les descripteurs de fichiers provenant du processus Ruby père, issue du fork via Open3.popen3. 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) ».
Sur une Debian 12, la limite du nombre de fichiers par défaut, c’est 1 048 576. C’est déjà probablement bien plus que la valeur qui prévalait à l’époque où a été écrit la boucle Python (on avait des limitations à 4096 à une époque reculée). Mais il s’avère que durant le week-end l’hôte du conteneur de production a été migré en Debian 13. Sans modification du conteneur de production pensions-nous. Sans modification directe du conteneur de production. Mais quid d’une modification indirecte ? Par exemple si la limite par défaut des « Max open files » était passée à 1 073 741 816 sur l’hôte, soit 1024 fois plus que quelques jours auparavant. Et donc des boucles nettement plus longues voire sans fin, sans libération de mémoire.
On ne peut mettre à jour le composant pygments dans l’immédiat, mais on peut limiter les dégâts en abaissant la limite du nombre de descripteurs de fichiers à quelque chose de raisonnable (i.e. on va gaspiller raisonnablement des cycles CPU dans une boucle un peu inutile mais brève…). Une édition de /etc/security/limits.conf, un redémarrage du conteneur de production et on peut vérifier que cela va nettement mieux avec cette réparation de fortune.
Le conteneur LXC portant le service epub de production a assez mal pris la surcharge du serveur, et vers 20h08, systemd-networkd sifflera la fin de la récré avec un eth0: The interface entered the failed state frequently, refusing to reconfigure it automatically (quelque chose comme « ça n’arrête pas d’échouer, débrouillez-vous sans moi »). Le service epub est resté en carafe jusqu’au 27 août vers 13h31 (merci pour l’entrée de suivi).
Voir ce commentaire sur la dépêche de l’incident précédent expliquant la séparation du service epub et du conteneur principal de production (en bref : dette technique et migration en cours).
Le serveur était très occupé. Au point de n’avoir pas le temps de mettre à jour les graphiques de temps en temps.
Rétrospectivement les processeurs du serveur ont travaillé dur : 140 de charge sur le graphique (mais avec des pics jusque 260 d’après la commande uptime), contre moins de 5 en temps normal (un petit facteur de 28 à 52 ô_Ô)
Et l’utilisation de la mémoire montre aussi de brutaux changements de comportement : libération intempestive de mémoire (Free, en vert), utilisation mémoire plus importante que d’habitude (Used, en jaune), là où le comportement normal est d’avoir le maximum en cache (Cached, en orange) et des processus tellement peu consommateurs en RAM que cela n’apparaît normalement pas.
Dans les actions en cours ou à prévoir :
rrd des métriques concernant les interfaces réseauDe façon cocasse, ce nouvel incident et le temps passé à parcourir les différents logs ont permis de retrouver les infos de la carte d’administration distante et d’expliciter l’origine du redémarrage serveur intempestif. À quelque chose malheur est bon, si on peut dire. Ceci n’est pas une invitation pour un prochain incident.
Commentaires : voir le flux Atom ouvrir dans le navigateur
Vous voulez améliorer nettement votre Wi-Fi à la maison, sans sacrifier votre vie privée ? Bonne nouvelle : on peut aujourd’hui obtenir d’excellentes perfs avec des routeurs et systèmes mesh récents qui tournent officiellement sous OpenWrt. Je vous propose une sélection 2025 claire, triée par Routeur OpenWrt et Système Mesh OpenWrt, chacun en 3 niveaux de budget, avec un gros chapitre dédié OpenWrt & vie privée.
OpenWrt remplace le logiciel d’origine du routeur par un système ouvert et maintenu.
Concrètement :
Remarque simple : quand on parle “version stable” d’OpenWrt en 2025, on vise la branche 24.10.x. Installez la dernière révision disponible, point.
Pour savoir si vous avez besoin d’un Routeur (appareil seul) ou d’un système Mesh (Plusieurs Routeurs Interconnectés) voici de quoi vous aider à choisir très simplement. Une fois que vous savez vers quoi vous orienter, rendez-vous dans la section qui vous correspond.
J’ai déjà rédigé un article pour présenté les meilleurs solutions de WiFi Mesh Multiroom, et je vous invite à le consulter si vous rechercher des solutions natives grand publics. la sélection qui suit est focus sur les solutions compatibles OpenWrt, donc pour ceux qui recherchent une solution ou la transparence et le contrôle de sa vie privée est primordiale.
Entrée de gamme (Wi-Fi solide, fibre ≤ 1 Gb/s)Routeur simple et efficace pour un petit budget. Le Wi-Fi 6 tient bien la charge pour 10 à 20 appareils, avec une portée correcte en appartement. Les ports Gigabit suffisent pour une fibre à 1 Gb/s, et OpenWrt s’installe sans prise de tête. Idéal pour activer DNS chiffré, ad-blocking et un réseau invité sans ralentir la connexion.
GL.iNet GL-MT3000 “Beryl AX” (AX3000)
Format mini, perfs maxi pour sa taille. On apprécie le port 2,5 GbE et la facilité de configuration sous OpenWrt, y compris en mode voyage ou point d’accès d’appoint. Idéal pour une chambre, un bureau ou une résidence secondaire. Ça consomme peu, ça chauffe peu, et ça fait le job proprement.
Milieu de gamme (maison standard, fibre 1 Gb/s)Routeur discret qui passe partout, avec une radio Wi-Fi 6 très propre pour une maison standard. OpenWrt lui va bien : stabilité, bonnes vitesses et options utiles (réseau invité, contrôle parental basique). Si vous voulez un appareil qu’on installe et qu’on oublie, c’est typiquement celui-là. Excellent rapport simplicité/performances.
Haut de gamme (2,5 GbE, VPN rapide, maison > 150 m² en solo)ASUS TUF-AX6000 (AX6000, 2×2,5 GbE)
Un des meilleurs routeurs grand public récents compatibles OpenWrt. On a du 2,5 GbE pour le WAN et le LAN, un Wi-Fi 6 4×4 musclé et un CPU qui encaisse bien le VPN. Parfait pour un foyer très connecté ou pour lisser la latence avec du SQM. C’est puissant sans être compliqué à vivre au quotidien.
GL.iNet GL-MT6000 “Flint 2” (AX6000, 2×2,5 GbE)
Routeur costaud, taillé pour les foyers qui veulent du 2,5 GbE partout et un VPN rapide. Le Wi-Fi 6 4×4 couvre large et reste stable, même avec beaucoup d’appareils. OpenWrt est natif dans l’ADN du produit, donc les fonctions avancées s’activent facilement. Un excellent choix “performance/praticité”.
OpenWrt One / AP-24.XY (Wi-Fi 6, WAN 2,5 Gb/s, M.2)
Carte routeur pensée avec l’équipe OpenWrt pour être ouverte et durable. On y trouve du 2,5 GbE, du M.2 pour évoluer, et une base MediaTek moderne. Ce n’est pas le plus “plug-and-play” du lot, mais on contrôle tout et on apprend en chemin. Idéal si vous aimez comprendre votre réseau de A à Z.
| Modèle (année) | Wi-Fi | Ports RJ45 | Pour qui ? | Pourquoi lui |
|---|---|---|---|---|
| Cudy WR3000 (2023–2025) | AX3000 | 1×WAN 1G + 3×LAN 1G | Budget < 100 m² | Simple, stable, parfait pour DoH + Adblock |
| GL-MT3000 (2023) | AX3000 | 1×2,5G + 1×1G | Nomade / annexe | Compact, facile à configurer |
| ASUS RT-AX59U (2024) | AX4200 | 4×1G | Maison standard | Radio propre, bonne portée |
| ASUS TUF-AX6000 (2024) | AX6000 4×4 | WAN 2,5G + LAN 2,5G + 1G | Famille connectée | Débits élevés + faible latence |
| GL-MT6000 Flint 2 (2023) | AX6000 4×4 | 2×2,5G + 4×1G | Réseau 2,5 GbE | Très bon en VPN/WireGuard |
| OpenWrt One AP-24.XY (2024) | AX (2×2/3×3) | 2,5G + 1G | Passionnés | Ultra-ouvert, évolutif (M.2) |
BudgetCudy M3000 (AX3000, pack 2 ou 3)
Bon compromis prix/perfs pour 3 à 5 pièces. Le Wi-Fi 6 est efficace et OpenWrt offre les fonctions utiles (réseau invité, ad-blocking, DNS chiffré). Idéalement, reliez les deux boîtiers en backhaul Ethernet pour garder un Wi-Fi rapide sur tous les appareils. Vérifiez la révision matérielle compatible avant achat.
Milieu de gammeD-Link AQUILA PRO AI M30 (AX3000, pack 2 ou 3)
Un kit récent, discret, et facile à poser. Avec OpenWrt, on active rapidement les réglages de sécurité et le roaming, sans complexité. La couverture est homogène dans une maison de 120 à 180 m². En filaire ou en radio, le maillage reste stable pour le streaming, les visios et le jeu léger.
Haut de gammeLinksys Velop MX4200 (AX4200 tri-bande, pack 2 ou 3)
La valeur sûre pour les grandes surfaces sans câbles. La troisième bande sert de voie dédiée entre nœuds, donc le Wi-Fi reste fluide même en backhaul radio. OpenWrt est mature sur ce modèle, avec un roaming propre entre satellites. C’est le choix “sans surprise” pour une maison exigeante.
Astuce “Mesh DIY” : deux routeurs identiques (ex. 2× RT-AX59U ou 2× TUF-AX6000) reliés en Ethernet, avec 802.11r activé. Dans beaucoup de maisons, c’est plus stable et plus rapide qu’un mesh 100 % radio.
| Modèle (packs) | Wi-Fi | Backhaul recommandé | Pour qui ? | Pourquoi lui |
|---|---|---|---|---|
| Cudy M3000 | AX3000 | Ethernet | Maison 3–5 pièces | Prix doux, simple à déployer |
| D-Link M30 Aquila | AX3000 | Radio ou Ethernet | 120–180 m² | Installation facile, débit stable |
| Linksys Velop MX4200 | AX4200 tri-bande | Radio si pas de câble | Grandes maisons | Bon backhaul sans fil |
https-dns-proxy ou smartdns), choisissez un résolveur sérieux (Cloudflare, Quad9).adblock ou adblock-fast et chargez une liste légitime (par ex. oisd).Bonus performance : si votre box opérateur est obligatoire, mettez-la en mode bridge (ou DMZ vers le routeur OpenWrt), pour que le routeur OpenWrt gère vraiment le réseau.
Qu’est-ce que Wi-Fi 6, 6E, 7 ?
Je veux juste que ça marche, sans prise de tête. Je choisis quoi ?
Logement standard : ASUS RT-AX59U. Grand logement sans câble : Linksys Velop MX4200. Réseau domestique 2,5 GbE ou gros usage VPN : ASUS TUF-AX6000 ou GL-MT6000.
Et si j’ai déjà une box opérateur ?
Gardez la box pour l’accès Internet, mais confiez le Wi-Fi et le routage à l’appareil OpenWrt. Idéalement, mettez la box en bridge ou en DMZ vers le routeur OpenWrt.
Wi-Fi 7 : j’achète maintenant ?
Pas si vous voulez absolument OpenWrt “propre”. Préférez un bon Wi-Fi 6 maintenant. Vous ne perdrez pas grand-chose en usage réel, et vous gagnerez en stabilité.
Vérifiez la révision exacte du produit avant d’acheter (nom, version matérielle).
Cet article original intitulé Les Meilleurs Routeurs & Systèmes Mesh compatibles OpenWrt pour booster le Wi-Fi et protéger votre réseau personnel en 2025 a été publié la première sur SysKB.
Je me note ça sous le coude (pas pratique : faut 'ach'ment se contorsionner !) pour évaluer ma connexion internet.
J'apprécie que cela soit directement dans un navigateur. Par ailleurs, outre les informations usuelles : paquets ASC/DESC perdus/retardés, le ping et la gigue, j'aime bien que l'on puisse configurer le test, notamment avec des préconfigurations (stream, jeu, visio, …).
via https://korben.info/test-paquets-perdus-latence-connexion-internet.html
Quelques infos sur l'API Speculation uniquement supportée par Chrome pour l'instant. Elle ambitionne de "deviner" le chemin de navigation de l'utilisateur et de précharger autant que possible les ressources correspondantes.
Avec évidemment le risque de charger des ressources pour rien si la prédiction échoue.
J'avoue ne pas être certain de l'inérêt.
Au final si vous avez une bonne connexion, charger des ressources en arrière plan aura un impact négligeable mais l'intérêt de gagner 500ms lors de la navigation sera aussi limité puisque la connexion est performante.
Par contre si vous avez une connexion pourrie type 3G de la campagne, alors le peu de bande passante va s'étouffer entre pré-chargement de ressources inutiles et navigation de premier plan, dégradant alors l'expérience et augmentant la frustration.
Quelques infos sur l'API Speculation uniquement supportée par Chrome pour l'instant. Elle ambitionne de "deviner" le chemin de navigation de l'utilisateur et de précharger autant que possible les ressources correspondantes.
Avec évidemment le risque de charger des ressources pour rien si la prédiction échoue.
J'avoue ne pas être certain de l'inérêt.
Au final si vous avez une bonne connexion, charger des ressources en arrière plan aura un impact négligeable mais l'intérêt de gagner 500ms lors de la navigation sera aussi limité puisque la connexion est performante.
Par contre si vous avez une connexion pourrie type 3G de la campagne, alors le peu de bande passante va s'étouffer entre pré-chargement de ressources inutiles et navigation de premier plan, dégradant alors l'expérience et augmentant la frustration.
VELODACH - VÉLOGÎTES – OSPITABICI
Répertoire des hébergements pour les voyageurs qui prennent leur temps
Je me suis récemment acheté pour 15 et quelques euros un boîtier à brancher sur la TV (ou tout autre écran avec entrée HDMI) et qui permet d’y diffuser une vidéo depuis son smartphone. À la façon d’un chromecast, mais pour beaucoup moins cher, et sans la dépendance à un fournisseur externe, ou un autre réseau.
Par ailleurs j’avais le TripMate sous le coude depuis longtemps.
Prochainement je serai pendant un certain dans un environnement sans internet, mais avec une TV et l’envie de regarder des films.
Du coup j’ai préparé un setup qui fonctionne où je lis sur un disque-dur (DD) branché sur le TripMate (TM) un film téléchargé à l’avance et le diffuse sur la TV. Tout ceci sans-fil ! Le seul branchement est de DD au TM, et le boîtier à la TV.
Par ailleurs j’ai acheté un boîtier audio qui se branche sur une prise jack d’un côté, et en bluetooth (BT) de l’autre. Il fonctionne dans les deux sens (Tx/Rx) : mon cas-d’utilisation (UC) est de diffuser la TV sur une enceinte BT ; mais un autre UC est de diffuser sur son auto-radio de la musique depuis un smartphone par exemple.
Bref, je suis content de mon installation et je me suis amusé à modéliser cela avec plantuml ; cela donne le bousin en lien, et avec le code source suivant :
@startuml
database DisqueDur as DD
cloud Internet as Int
node TripMate as HT
node BoîtierTV as BTT
node BoîtierSon as BTS
node EnceinteBT as EBT
interface Bluetooth as BT
[DD] - USB: Vidéo+Audio
USB - [HT]
[HT] .. WiFi1
[HT] . [Wifi3]
Wifi3 . Int: Web\n(éventuellement)
WiFi1 .. [Smartphone]: Vidéo+Audio + Web
[Smartphone] .l.> WiFi2: Vidéo+Audio
WiFi2 .l. [BTT]
[BTT] --> HDMI: Vidéo+Audio
HDMI --> [Écran]
[Écran] -r-> Jack: Audio\n(éventuellement)
Jack -> [BTS]
[BTS] .u.> BT
BT -r-> EBT
@endumlQuelques liens externes (non-affiliés) :
La mairie de Paris a renouvelé le partenariat avec l’Afnic pour gérer le .paris.
QNAP annonce la sortie du QSW-1108-8T-R2, un switch réseau non manageable qui offre 8 ports Ethernet fonctionnant à 2,5 GbE.
The post QNAP lance un switch réseau avec 8 ports à 2,5 Gbps first appeared on Bhmag.A tester
