L’article explique comment résoudre les problèmes de confiance des certificats HTTPS générés par Symfony CLI sous WSL2 lorsque ces certificats sont utilisés depuis un navigateur Windows. L’idée principale est que WSL2 et Windows gèrent séparément leurs magasins de certificats racines, ce qui empêche Windows de faire confiance aux certificats locaux créés dans WSL2. L’auteur détaille d’abord l’installation du certificat racine local via Symfony CLI dans WSL2, puis la méthode pour exporter ce certificat depuis WSL2 et l’importer dans le magasin de confiance de Windows. Cette solution permet d’éviter les avertissements de sécurité dans les navigateurs Windows tout en maintenant un environnement de développement sécurisé.

L’article aborde les trois problèmes courants rencontrés lors de la configuration d’un environnement de développement Symfony 7 avec Docker et WSL2 sous Windows. L’auteur partage des solutions pratiques pour éviter ces écueils, notamment un conflit de port avec PostgreSQL (résolu en mappant le port 5433 sur l’hôte au lieu de 5432) et des soucis de permissions avec le groupe Docker sous WSL2 (corrigés via newgrp docker ou un redémarrage de WSL2). Il évoque aussi l’absence de démarrage automatique du démon Docker au lancement de WSL2, suggérant d’activer systemd ou de lancer manuellement le service. L’auteur justifie enfin son choix d’Apache plutôt que Nginx pour des raisons de simplicité dans un contexte de développement.

L’auteur explique comment il a modernisé un projet legacy reposant sur Alice, Nelmio, Hautelook et Faker pour le rendre plus maintenable avec Doctrine. Après avoir réduit la dépendance à Faker et converti les fixtures Alice de YAML à PHP, il a évité un piège courant : migrer Alice vers Foundry sans résoudre les problèmes sous-jacents, ce qui aurait prolongé la dette technique. En créant une commande personnalisée pour charger toutes les fixtures en une seule fois, il a simplifié le processus et supprimé plusieurs dépendances, dont doctrine/doctrine-fixtures-bundle. Cette approche a permis une migration rapide et une meilleure maintenabilité, illustrant l’importance de privilégier des solutions simples et intuitives plutôt que des refontes coûteuses et peu efficaces.

L’auteur relate un problème rencontré dans son lab où le redémarrage de systemd-networkd provoquait la perte du lien entre Incus et une interface réseau, car l’index de cette dernière changeait. Une solution a été trouvée en utilisant l’option KeepMaster de systemd, qui maintient l’index de l’interface lors des rechargements ou redémarrages, évitant ainsi la rupture avec Incus.

Le billet mentionne également une commande alternative (ip link set vxlan5 parent br5) pour rattacher explicitement une interface à une parente, bien que cette méthode ne soit pas documentée de manière évidente dans les ressources systemd. L’auteur souligne l’efficacité de KeepMaster pour résoudre son problème récurrent, lié à la gestion des interfaces VXLAN dans son infrastructure.

Ce retour d’expérience s’inscrit dans une série de notes techniques autour de l’administration système et du DevOps, avec une approche pragmatique pour contourner des dysfonctionnements courants dans des environnements Linux modernes.

Symfony 8.1 modernise les commandes console en intégrant les value resolvers Doctrine, comme #[MapEntity], déjà disponibles pour les contrôleurs depuis Symfony 6.2. Cette évolution permet de simplifier la résolution des entités directement dans la signature de la méthode __invoke() d’une commande, réduisant ainsi le code boilerplate. Par exemple, la commande app:user:2fa-setup peut désormais injecter une entité User via #[MapEntity], éliminant les méthodes manuelles de recherche comme findUser().

L’article illustre cette amélioration avec un cas concret : avant Symfony 8.1, il fallait gérer manuellement la récupération de l’utilisateur via EntityManager, tandis qu’après, l’entité est résolue automatiquement grâce à #[MapEntity], qui mappe l’argument console à une propriété de l’entité. Cette approche standardise le comportement entre les commandes console et les contrôleurs HTTP, tout en réduisant la complexité du code.

Enfin, l’auteur souligne que cette modernisation, bien que mineure, révèle des commandes obsolètes encore présentes dans le codebase, rappelant l’importance de maintenir un code propre. Il note aussi un prérequis non documenté : #[MapEntity] nécessite une contrainte d’unicité sur la propriété mappée pour fonctionner correctement.

Scott H Young explique que pour lire de meilleurs livres, il faut d'abord lire davantage, car la quantité améliore la qualité. En accumulant des connaissances sur un sujet, on renforce sa capacité à comprendre des ouvrages plus complexes, comme illustré par son exemple avec The Fragility of Goodness de Martha Nussbaum, dont la lecture exige une familiarité préalable avec des concepts philosophiques. Ainsi, lire plus permet de mieux saisir des textes exigeants, même si la compréhension initiale reste partielle.

Cependant, cette approche comporte un risque : la dépendance au chemin parcouru. Plus on se spécialise dans un domaine, plus on devient compétent pour en lire les ouvrages, mais moins on perçoit les perspectives alternatives. Young en fait l'expérience avec ses propres livres, où ses recherches initiales sur le transfert d'apprentissage l'ont conduit à approfondir des théories spécifiques, limitant progressivement sa vision globale.

En résumé, Young recommande de diversifier ses lectures pour éviter de s'enfermer dans une seule perspective, tout en soulignant que la lecture intensive reste la clé pour progresser dans la compréhension des livres exigeants.

Bon à savoir - cette erreur est probablement due à la présence de modules kvm

L’article explique comment mutualiser la configuration de quatre CRUDs (Post, Page, Category, Series) dans EasyAdmin grâce à un trait PHP, évitant ainsi la duplication de code. Les entités partagent une structure commune (statut, slug, planification, SEO, Schema.org) mais nécessitent des adaptations mineures, gérées par des branches conditionnelles basées sur leur FQCN. Le code est structuré en onglets (tabs) et ensembles de champs (fieldsets) pour améliorer la lisibilité, tandis que des helpers de visibilité (comme onlyOnForms ou hideOnIndex) permettent d’ajuster l’affichage selon le contexte.

L’auteur détaille l’utilisation de FormField::addTab et FormField::addFieldset pour organiser les champs de manière claire, puis extrait les sections récurrentes dans un trait (ContentFieldsTrait). Une branche conditionnelle gère les champs spécifiques à certaines entités (par exemple, la catégorie pour un Post), tandis que des types de champs comme AssociationField ou ChoiceField avec des enum natifs simplifient les relations et les sélections. L’objectif est de maintenir un code DRY (Don’t Repeat Yourself) tout en restant flexible.

Enfin, l’article mentionne les limites du trait et propose d’extraire certaines logiques en services si la complexité augmente. Il s’inscrit dans une série de six billets sur EasyAdmin, après des épisodes consacrés à l’installation, à la construction d’un menu ou à la sécurisation d’un admin. La méthode vise à éviter la divergence des configurations tout en gardant un code maintenable et lisible.

La faille IDOR (Insecure Direct Object Reference) est une vulnérabilité de sécurité classée parmi les plus courantes par l'OWASP, où une application expose des identifiants directs (comme un numéro de commande ou un ID utilisateur) dans des URLs, formulaires ou APIs, sans vérifier les droits d'accès. Un attaquant peut ainsi modifier manuellement ces identifiants pour accéder aux données d'autres utilisateurs, comme illustré par l'exemple d'une URL ?id=1042 où remplacer 1042 par 1041 donne accès à une facture étrangère.

Cette faille est fréquente car elle est simple à implémenter et souvent négligée lors du développement, notamment avec des identifiants numériques prévisibles (auto-incrémentés). Elle ne se limite pas aux URLs mais peut aussi toucher les paramètres POST, les APIs ou les cookies, rendant le risque encore plus diffus. L'article souligne que même des développeurs expérimentés peuvent omettre de vérifier les permissions côté serveur, exposant ainsi des données sensibles.

Ce billet explique comment l'auteur utilise FrankenPHP en développement, mettant en avant son mode worker qui maintient une instance PHP active pour éviter les recharges coûteuses à chaque requête. Trois mécanismes de hot reload sont combinés : --watch pour les fichiers statiques, tailwind:build --watch pour les styles, et le worker lui-même, permettant un rechargement instantané du navigateur sans configuration complexe. L'article souligne aussi l'intégration d'un certificat HTTPS auto-signé, accessible via https://localhost:8443 sans modification du fichier hosts.

L'auteur détaille l'architecture de FrankenPHP, un binaire Go combinant le serveur Caddy et PHP-FPM, simplifiant l'infrastructure en un seul processus au lieu de Nginx + PHP-FPM. Le mode worker évite le redémarrage complet de l'application à chaque requête, améliorant les performances en développement comme en production. Le même fichier de configuration est utilisé pour les deux environnements, avec des variables d'environnement ajustant les comportements selon le contexte Docker.

FrankenPHP simplifie l’infrastructure PHP en remplaçant Nginx et PHP-FPM par un seul binaire, combinant serveur HTTP (Caddy) et exécution PHP. L’auteur partage son expérience en production depuis octobre 2025, où quatre sous-domaines sont servis depuis un unique processus, réduisant la complexité DevOps tout en maintenant Symfony. Le mode worker permet de charger l’application une seule fois au démarrage, améliorant les performances, mais impose une vigilance accrue sur les variables statiques ou états persistants, autrefois effacés à chaque requête sous PHP-FPM.

L’optimisation repose aussi sur opcache preload, qui précharge les classes Symfony en mémoire avant l’exécution du worker, accélérant ainsi le démarrage. La configuration se résume à quelques lignes, et l’absence de reverse proxy externe ou de pools FPM par site simplifie la maintenance. Cependant, cette approche déplace plutôt qu’elle n’élimine la complexité, notamment en matière de gestion des états applicatifs.

L’article détaille les gains concrets (un seul binaire, une seule configuration) tout en soulignant les pièges potentiels, comme les fuites de mémoire ou les variables globales persistantes, autrefois neutralisées par le redémarrage fréquent des workers PHP-FPM.

L’article présente deux nouvelles fonctions CSS, sibling-index() et sibling-count(), issues du module CSS Values and Units Level 5, permettant de simplifier la création d’effets de cascade décalée (staggered animations) sans recourir à des boucles Sass ou à du JavaScript. Ces fonctions exploitent des données déjà connues du navigateur, comme la position d’un élément parmi ses frères ou le nombre total de ses frères, pour appliquer des animations dynamiques en une seule ligne de CSS, sans limite de taille de liste.

L’auteur explique que les méthodes traditionnelles (comme les sélecteurs :nth-child() ou les manipulations JavaScript) sont lourdes et peu maintenables, surtout pour des listes dynamiques. À l’inverse, sibling-index() et sibling-count() offrent une solution élégante et performante, fonctionnant aussi bien pour 5 éléments que pour 5 000, sans générer de code superflu ni dépendre de variables injectées dynamiquement.

Ces fonctions, déjà approuvées par le CSS Working Group, résolvent un problème récurrent en CSS en donnant accès à des informations structurelles du DOM directement dans les styles, ouvrant la voie à des mises en page plus dynamiques et maintenables.

L’auteur partage ses expériences récentes avec des "bizarreries" rencontrées lors de la migration vers Ubuntu 26. Il évoque des dysfonctionnements après la mise à jour, notamment la réinstallation forcée de Firefox en version Snap malgré ses préférences pour le .deb, des problèmes avec KeepassXC et Rygel, ainsi que des incompatibilités liées au passage à sudo-rs, qui ont perturbé ses scripts Ansible.

Il aborde ensuite les difficultés liées aux webcams modernes, en particulier celles utilisant le protocole Mipi, qu’il a tenté de configurer sans succès pendant des mois. Après des essais infructueux avec DroidCam, il découvre scrcpy, un outil sous Linux qui lui permet enfin d’utiliser sa webcam et d’accéder à des fonctionnalités avancées de son smartphone depuis son ordinateur, comme la gestion de Signal ou la lecture de musique.

Enfin, il évoque les défis liés à Wayland et aux claviers alternatifs, critiquant notamment l’absence de fonctionnalités comme l’autotype dans KeepassXC sous Wayland. Il s’intéresse aux outils comme kanata et ydotool pour simuler ou afficher des couches de clavier, tout en regrettant l’absence d’un affichage visuel en temps réel pour faciliter l’apprentissage des nouvelles dispositions.

L’article illustre les conséquences des interruptions fréquentes en entreprise, comme les visites horaires d’un manager surnommées « le bocal des geeks », qui empêchent la concentration profonde. Selon des recherches, une interruption coûte en moyenne 23 minutes de regain de concentration, et dans une équipe de 10 personnes, cela représente jusqu’à 63 journées de travail cognitif perdues par mois. L’auteur souligne que le problème ne relève pas d’un manque de discipline individuelle, mais d’une mauvaise organisation, où le management par le contrôle prime sur l’efficacité réelle.

Le concept de Deep Work, popularisé par Cal Newport, est présenté comme une solution : il s’agit de réaliser des tâches exigeantes sans interruption, créatrices de valeur, plutôt que de se contenter d’une pseudo-productivité (réponses rapides, agitation visible). L’exemple d’Éric montre comment une méthode de suivi intrusive, bien que bien intentionnée, peut nuire à la productivité globale en empêchant les employés d’atteindre un état de travail optimal.

L’auteur propose une alternative simple : remplacer les interruptions par un canal d’information partagé, réduisant ainsi les perturbations tout en maintenant une communication efficace. L’enjeu est de repenser l’organisation du travail pour privilégier la qualité et la profondeur des tâches plutôt que leur apparence.

Cette faille critique dans Kubernetes, révélée en janvier 2026, exploite la permission RBAC nodes/proxy GET pour exécuter du code à distance dans n’importe quel Pod du cluster, sans laisser de trace dans les logs d’audit. Cette vulnérabilité repose sur un contournement des vérifications d’autorisation : le Kubelet, via une connexion WebSocket, autorise l’exécution de commandes (/exec) en validant uniquement un GET initial, sans exiger le verbe CREATE normalement requis. L’absence de logs d’audit côté Kubelet aggrave le risque, permettant des attaques discrètes, notamment sur des composants système comme etcd ou kube-apiserver.

L’article souligne que des ServiceAccounts aux noms évocateurs, comme rook-ceph-system, combinés à des permissions étendues (accès en lecture aux Secrets), constituent des cibles privilégiées pour une élévation de privilèges. Une analyse des Roles et ClusterRoles est recommandée, avec des outils comme le script de détection du chercheur Graham Helton. Parmi les composants vulnérables figurent des outils courants comme l’OpenTelemetry Collector, dont les ServiceAccounts associés pourraient être exploités pour compromettre l’ensemble du cluster.

Pour atténuer ce risque, l’auteur propose plusieurs correctifs et mesures préventives, comme l’activation de la feature gate KEP-2862 pour un contrôle granulaire des autorisations Kubelet, l’utilisation de CiliumNetworkPolicy pour bloquer l’accès au port 10250, ou encore l’application de politiques Kyverno pour interdire la création de Roles incluant nodes/proxy. La surveillance des audit logs et la mise à jour des composants (comme Rook-Ceph) sont également essentielles, bien que Kubernetes ait classé cette faille comme un "comportement intentionnel" non corrigé en l’état.

Cet article explique comment configurer un réseau interne pour des machines virtuelles (VM) sous Proxmox dans un homelab monoserveur. L'auteur détaille une solution adaptée aux petits budgets, sans équipement réseau intermédiaire comme des switchs gérant les VLAN. La configuration repose sur un routeur virtuel (conteneur LXC) et des VLAN dédiés directement gérés par Proxmox, simplifiant ainsi l'infrastructure.

La configuration réseau repose sur un schéma en étoile où le serveur Proxmox centralise les VLAN 121 (192.168.121.0/24) et 221 (192.168.221.0/24), connectés au LAN principal (192.168.21.0/24). Le routeur virtuel, intégré au serveur, gère les routes statiques pour permettre l'accès aux sous-réseaux depuis le réseau local ou externe via la box/FAI.

L'approche proposée est idéale pour un usage domestique et pédagogique, mais n'est pas conçue pour des environnements professionnels exigeants. L'auteur partage sa configuration complète, incluant les adresses IP et la topologie, pour faciliter la reproduction par d'autres utilisateurs.

L'auteur décrit la refonte de son infrastructure DNS pour éliminer les points de défaillance uniques (SPOF) et améliorer la résilience. Son ancien setup, basé sur un seul conteneur LXC combinant AdGuard Home et NPM, souffrait d'un manque de redondance et d'une résolution inefficace des noms de domaine locaux, générant du trafic inutile via le NAT (hairpin). La nouvelle architecture sépare les rôles en quatre composants : Technitium DNS Server pour la gestion des zones DNS locales et la haute disponibilité, AdGuard Home pour le filtrage avancé des requêtes, NextDNS comme résolveur chiffré en amont, et NPM pour la gestion des proxy inverses.

Technitium assure la synchronisation automatique entre deux instances, permettant une continuité de service immédiate en cas de panne d'un nœud Proxmox. AdGuard Home, déployé dans un conteneur dédié, applique des règles de filtrage personnalisées par client ou groupe, tandis que NextDNS prend le relais pour les requêtes publiques et offre une protection renforcée hors réseau. NPM, isolé dans son propre conteneur, gère les redirections des noms de domaine locaux et publics sans conflit.

Cette refonte élimine les inefficacités du hairpin NAT et garantit un filtrage cohérent, que ce soit en local ou à distance, tout en assurant une haute disponibilité grâce à la redondance des composants.

L’article explique comment éviter les pertes ou corruptions de données lors des déploiements en utilisant des graceful shutdowns avec Symfony Messenger. L’idée principale est que les processus de consommation de messages doivent terminer le traitement en cours avant de s’arrêter, évitant ainsi des incohérences (comme des transactions bancaires incomplètes ou des fichiers orphelins). Symfony Messenger gère automatiquement les signaux de terminaison (SIGTERM, SIGINT) et propose des options comme des limites de temps ou de mémoire pour contrôler l’arrêt propre des consommateurs.

L’auteur détaille l’implémentation de base via la commande messenger:consume, avec des exemples de code et des flags comme --limit ou --time-limit pour limiter le nombre de messages ou la durée d’exécution. Il souligne aussi l’importance des limites mémoire (--memory-limit) pour éviter les fuites de mémoire, tout en permettant au processus de finir sa tâche avant de s’éteindre. Le système est conçu pour être robuste, même lors de redémarrages ou de déploiements, grâce à une gestion native des signaux par Symfony.

L’article explique comment sortir les outils de qualité de code PHP du vendor/ d’un projet Symfony en utilisant l’image Docker jakzal/phpqa, afin d’éviter les conflits de dépendances, les composer update plus lents et les divergences entre environnement local et CI. L’auteur remplace les dépendances require-dev classiques (PHPStan, Rector, PHP-CS-Fixer, Deptrac, etc.) par des exécutions one-shot dans un conteneur Docker contenant les binaires .phar, avec un tag d’image figé pour garantir la reproductibilité et un cache partagé /tmp pour accélérer fortement les analyses. Le workflow repose sur un Makefile séparant des contrôles rapides avant commit et des vérifications plus lourdes avant release, avec des cibles atomiques réutilisables individuellement. Certains cas restent toutefois hors du périmètre de jakzal/phpqa, notamment lint:container de Symfony, composer audit et Biome pour JS/TS. L’article souligne aussi les limites des outils non maintenus embarquant une ancienne version de nikic/php-parser, comme PHPMetrics ou PDepend, devenus incompatibles avec certaines nouveautés de PHP 8.4/8.5.

L’auteur explique comment son passage d’un Raspberry Pi 3 à un mini PC x86 plus puissant l’amène à envisager la conteneurisation de son serveur domestique afin d’héberger ses propres services liés à la lecture de mangas, BD et ebooks sur tablette. Il décrit l’intérêt d’outils comme Docker pour isoler et déployer facilement différentes applications auto-hébergées, notamment dans un contexte où les usages personnels évoluent et nécessitent davantage de souplesse et de ressources matérielles. Le billet met aussi en avant les avantages pratiques d’une machine disposant de davantage de RAM et d’une architecture x86-64, ouvrant la porte à des solutions d’hébergement plus modernes et modulaires. Il donne quelques conseils, notamment sur l'utilisation de Traefik