Cédrix
1 line
30 KiB
JSON
1 line
30 KiB
JSON
[{"uuid":"976fd7f0-e53d-44e2-a879-58194765f3cf","slug":"activer-les-mises-a-jour-automatiques-sur-debian-pour-une-gestion-simplifiee-des-correctifs-de-securite","title":"Activer les mises à jour automatiques sur Debian pour une gestion simplifiée des correctifs de sécurité","category":"linux","author":"cedric@abonnel.fr","cover":"cover.svg","published":true,"published_at":"2026-01-06 20:45","created_at":"2026-01-06 20:45:52","updated_at":"2026-05-14 07:54:59","tags":{"logiciels":["Debian"]},"plain":"Dans un environnement de serveur ou de poste de travail, maintenir un système à jour avec les derniers correctifs de sécurité est crucial pour limiter l'exposition aux vulnérabilités. Debian fournit pour cela le paquet , qui automatise l'application des correctifs sans intervention manuelle. Cet article décrit comment l'installer, le configurer pour ne traiter que les mises à jour de sécurité, vérifier qu'il est bien actif, et tester son fonctionnement. La progression va du chemin minimal (sections 1 à 3) vers les réglages avancés utiles en production (sections 4 et suivantes). Étapes pour activer les mises à jour automatiques 1. Installer les paquets nécessaires On installe (qui applique les mises à jour) et, optionnellement mais recommandé, (qui résume les changements appliqués et peut les envoyer par e-mail) : À noter : sur Debian 12 (Bookworm) et versions ultérieures, n'est plus installé par défaut, même avec un environnement de bureau. À l'installation, pose quelques questions débconf (mode de remise : , , ; adresse mail destinataire ; fréquence). La valeur par défaut () convient pour un poste de travail ; sur un serveur, choisir et indiquer l'adresse de l'administrateur, après s'être assuré qu'un MTA local (postfix, msmtp…) est en place. Pour reconfigurer ultérieurement : 2. Activer le scheduling : La configuration d' se fait via deux fichiers dans :\n: quand déclencher la mise à jour (activation du scheduling)\n: quoi mettre à jour (origines, blacklist, redémarrage, mail…) Le premier peut être généré automatiquement avec : Une unique question débconf apparaît — « Automatically download and install stable updates? » — répondez Oui. Cela crée avec le contenu suivant : Sans ce fichier, est installé mais ne s'exécute jamais automatiquement. 3. Vérifier les origines dans Éditez le fichier : Sur Debian, les origines autorisées sont définies dans le bloc . Par défaut, seules les mises à jour de sécurité sont actives. Vérifiez la présence des lignes suivantes, non commentées : (La seconde ligne couvre l'ancien format d'étiquetage des dépôts de sécurité ; il est prudent de conserver les deux.) Optionnel : pour appliquer aussi les mises à jour fonctionnelles (corrections de bugs non critiques), décommentez la ligne correspondant aux updates : À utiliser avec discernement sur un serveur de production : ces mises à jour ne sont pas urgentes du point de vue sécurité et peuvent introduire des changements de comportement. À ce stade, la configuration minimale est terminée : les mises à jour de sécurité Debian seront appliquées automatiquement. Les sections suivantes couvrent les réglages utiles pour un usage en production. 4. Tester la configuration Lancez une simulation pour vérifier ce qui serait installé sans rien modifier : (Le binaire s'appelle bien au singulier ; le pluriel fonctionne aussi grâce à un lien symbolique.) La sortie est verbeuse. Les lignes à repérer sont :\n: doit lister les origines configurées en section 3 (au moins ).\n: les paquets exclus (voir section 6).\nou : ce qui serait installé.\n: message normal si aucune mise à jour de sécurité n'est en attente. Si une origine attendue n'apparaît pas dans Allowed origins, la ligne correspondante dans est probablement encore commentée. 5. Planification (timers systemd) L'exécution est pilotée par deux timers systemd fournis par le paquet : (téléchargement) et (installation). Par défaut, l'installation se déclenche tous les jours autour de 6h avec un délai aléatoire d'une heure. Pour vérifier l'état des timers : Pour modifier l'heure d'installation, créez un override : Et placez-y : Puis rechargez : 6. Réglages utiles en production Toujours dans , quelques options méritent d'être activées : Si vous désactivez le redémarrage automatique (recommandé en production), il faut un mécanisme pour savoir quand un reboot devient nécessaire — sinon les mises à jour de noyau s'accumulent silencieusement et la machine reste vulnérable jusqu'au prochain redémarrage manuel. Trois pistes complémentaires :\nLe fichier est créé automatiquement par les paquets qui exigent un reboot. Un simple dans un script de monitoring ou un motd suffit à le signaler à la connexion.\nInstaller () : il identifie les services à redémarrer après la mise à jour d'une bibliothèque (libc, openssl…), ce qui évite souvent un reboot complet. La commande liste les actions à entreprendre.\nLe mail envoyé par mentionne explicitement les paquets installés ; un redémarrage de noyau y est visible. 7. Cas des dépôts tiers Le bloc par défaut ne couvre que les dépôts Debian officiels. Les paquets installés depuis des dépôts tiers (Docker, PostgreSQL upstream, Nodesource, dépôts maison…) ne seront pas mis à jour automatiquement, alors même qu'ils concentrent souvent les CVE critiques sur un serveur. Pour les inclure, il faut ajouter leur pattern à . Par exemple pour Docker : Pour identifier l'origine et l'archive d'un dépôt : Repérez les champs (origin) et (archive/suite) dans la sortie ; ce sont eux qui doivent correspondre à votre pattern. Activer un dépôt tiers en mise à jour automatique demande de la confiance dans la stabilité de ce dépôt — testez d'abord en . 8. Vérifier les logs Les actions effectuées sont journalisées dans : Le premier trace l'activité d' lui-même (origines, paquets pris en compte, succès/échec) ; le second contient la sortie complète de pour chaque paquet installé.\n-- En activant correctement configuré, les correctifs de sécurité Debian sont appliqués rapidement et sans intervention manuelle. Sur un serveur de production, il reste essentiel de blacklister les paquets critiques pour votre stack, de configurer une notification par mail, de surveiller si le redémarrage automatique est désactivé, et de penser explicitement à inclure vos dépôts tiers dans . Les mises à jour majeures (changement de version Debian) restent toujours à faire à la main."},{"uuid":"68a07aea-8f12-4b6a-802a-03af83a09ad8","slug":"adaptateur-usb-vers-esp-01-activer-le-mode-programmation","title":"Adaptateur USB vers ESP-01 : activer le mode programmation","category":"Électronique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2020-12-13 07:44","created_at":"2020-12-13 07:44:45","updated_at":"2026-05-13 18:21:06","tags":[],"plain":"Présentation\r\n\r\nL'adaptateur USB vers ESP-01 avec puce CH340 permet de connecter facilement un module ESP-01 (basé sur le microcontrôleur ESP8266) au port USB d'un ordinateur. Il intègre également un régulateur de tension 3,3 V, indispensable pour alimenter correctement l'ESP-01.\r\n\r\nCet adaptateur sert à deux usages principaux :\r\ndialoguer avec l'ESP-01 via des commandes AT (commandes Hayes) afin de récupérer des informations ou de piloter le module ;\r\ntéléverser un firmware personnalisé sur l'ESP8266, par exemple depuis l'IDE Arduino.\r\nLien d'achat : adaptateur USB vers ESP-01 avec puce CH340\r\n\r\nLe problème : passer en mode programmation\r\n\r\nPar défaut, l'ESP-01 démarre en mode UART (communication série), qui convient pour échanger des commandes AT mais ne permet pas de flasher un nouveau firmware. Pour téléverser un programme, il faut basculer le module en mode FLASH (également appelé mode programmation).\r\n\r\nCette bascule n'est pas logicielle : elle se fait électriquement, en forçant la broche GPIO0 à la masse (GND) au moment du démarrage du module.\r\n\r\nDe nombreux adaptateurs USB vers ESP-01 d'entrée de gamme ne prévoient pas de bouton ou de switch pour cette opération. Sans modification, toute tentative de téléversement échoue avec une erreur de ce type dans l'IDE Arduino :\r\n\r\n\r\n\r\n\r\n\r\nLe message clé est : n'a pas réussi à mettre le module en mode flash et abandonne après plusieurs tentatives.\r\n\r\nLa solution : modifier l'adaptateur\r\n\r\nPour rendre l'adaptateur compatible avec le mode programmation, il suffit d'ajouter un moyen de relier GPIO0 à GND à la demande. Rappel du brochage de l'ESP-01 :\r\n\r\n\r\n\r\nMatériel nécessaire\r\nun fer à souder et de l'étain ;\r\ndeux fils fins ;\r\nune barrette de deux broches au pas de 2,54 mm ;\r\nun jumper ;\r\néventuellement un pistolet à colle pour rigidifier l'ensemble.\r\n\r\nProcédure\r\n\r\n1. Souder un premier fil sur la broche GPIO0 (côté adaptateur).\r\n2. Souder un second fil sur une broche GND (côté adaptateur).\r\n3. Relier l'autre extrémité de chaque fil à une broche de la barrette, de manière à pouvoir court-circuiter GPIO0 et GND en plaçant simplement un jumper.\r\n4. Fixer la barrette avec une goutte de colle chaude pour éviter que les fils ne tirent sur les soudures.\r\n\r\n\r\n\r\nUtilisation\r\nPour téléverser un programme : placer le jumper (GPIO0 relié à GND), insérer l'adaptateur dans le port USB, puis lancer le téléversement depuis l'IDE Arduino.\r\nPour utiliser le module normalement (commandes AT ou exécution du firmware) : retirer le jumper, puis débrancher et rebrancher l'adaptateur pour redémarrer l'ESP-01 dans son mode standard.\r\n\r\n\r\n\r\nÀ retenir\r\n\r\nLe téléversement d'un nouveau firmware écrase le code précédemment chargé, y compris le firmware AT d'origine. Pour retrouver les commandes AT après avoir flashé un programme personnalisé, il faudra reflasher un firmware AT officiel d'Espressif.\r\n```"},{"uuid":"3e7ef528-6bd0-4fd1-83cb-a0d03ba35949","slug":"npm-le-ver-dans-le-fruit-comprendre-la-faille-systemique-et-repenser-les-pratiques-devops","title":"NPM, le ver dans le fruit : comprendre la faille systémique et repenser les pratiques DevOps","category":"informatique","author":"cedric@abonnel.fr","cover":"cover.svg","published":true,"published_at":"2026-05-12 13:08","created_at":"2026-05-12 13:08:44","updated_at":"2026-05-12 13:12:42","tags":[],"plain":"À propos de l'article du MagIT « NPM : une nouvelle campagne malveillante souligne une vulnérabilité systémique ».\r\n\r\nNPM expliqué simplement\r\n\r\nQuand on développe une application web moderne en JavaScript ou TypeScript, on ne réécrit jamais tout depuis zéro. On assemble des briques logicielles déjà écrites par d'autres : un module pour parser des dates, un autre pour valider des emails, un troisième pour discuter avec une base de données. Ces briques s'appellent des paquets, et la place de marché centrale qui les distribue s'appelle npm (Node Package Manager).\r\n\r\nConcrètement, dans un projet, on déclare la liste des paquets nécessaires dans un fichier . On lance la commande , et l'outil télécharge automatiquement les paquets demandés… ainsi que tous les paquets dont ces paquets ont eux-mêmes besoin. Un projet « simple » se retrouve souvent à dépendre de plusieurs centaines, voire plusieurs milliers, de paquets en cascade. C'est ce qu'on appelle l'arbre des dépendances.\r\n\r\nLe registre npm héberge aujourd'hui plus de 2,5 millions de paquets. C'est à la fois sa force — un écosystème colossal, une productivité décuplée — et sa faiblesse : la confiance accordée à chaque maillon de la chaîne est implicite, et chaque maillon devient une porte d'entrée potentielle.\r\n\r\nLa faille : ce qui s'est passé\r\n\r\nL'épisode décrit par LeMagIT n'est pas un bug logiciel classique. C'est ce qu'on appelle une attaque sur la chaîne d'approvisionnement logicielle (supply chain attack) : au lieu d'attaquer directement la cible finale, l'attaquant compromet un fournisseur en amont, et laisse la mise à jour légitime faire son travail de propagation.\r\n\r\nLe scénario reconstitué se déroule en plusieurs temps.\r\n\r\n1. Compromission d'un paquet de confiance. Les attaquants sont parvenus à pousser du code malveillant dans des paquets npm largement utilisés, notamment via le détournement du pipeline d'intégration continue de projets connus comme et l'écosystème Checkmarx. L'astuce n'est pas de publier un faux paquet : c'est de modifier un vrai paquet en exploitant les GitHub Actions — les robots qui construisent et publient automatiquement les nouvelles versions.\r\n\r\n2. Vol de secrets à l'installation. Une fois installé sur la machine d'un développeur ou dans un environnement de build, le code malveillant scanne l'environnement à la recherche de variables sensibles : , , , . Tout ce qui traîne dans les variables d'environnement, les fichiers , les configurations cloud.\r\n\r\n3. Auto-propagation. C'est là que l'attaque devient virale. Avec les jetons npm volés, le maliciel se reconnecte au registre npm, récupère la liste des paquets publiés par la victime, et publie automatiquement des versions piégées de ces paquets. Chaque développeur compromis devient un super-propagateur. Socket a identifié une quarantaine de paquets infectés en cascade lors d'une seule vague.\r\n\r\n4. Persistance. Sur les postes touchés, le malware installe un script pour survivre aux redémarrages, et, si nécessaire, exfiltre les données volées dans un dépôt GitHub public créé pour l'occasion.\r\n\r\nLe résultat : un binaire signé, publié sous un nom officiel, à jour, qui passe tous les contrôles de surface — et qui contamine simultanément le poste du développeur et les serveurs de production.\r\n\r\nPourquoi c'est « systémique »\r\n\r\nLe terme employé par LeMagIT est juste. Ce n'est pas un bug isolé, c'est une propriété structurelle de l'écosystème.\r\n\r\nLa confiance est transitive. On fait confiance à , qui fait confiance à , qui fait confiance à , etc. Compromettre un nœud profond et populaire suffit à toucher des millions de projets.\r\n\r\nLa publication est ouverte. N'importe qui peut publier un paquet. Les contrôles existent (provenance, 2FA pour les mainteneurs populaires) mais restent surtout a posteriori.\r\n\r\nLes scripts d'installation s'exécutent automatiquement. Un paquet npm peut déclarer un qui lance du code arbitraire au moment de . C'est pratique, mais c'est aussi un cheval de Troie idéal.\r\n\r\nLes jetons d'API sont partout. Le poste du développeur, les runners CI/CD, les serveurs : tous manipulent des secrets en clair dans des variables d'environnement. Un malware qui s'exécute dans le build n'a même pas besoin d'escalader ses privilèges.\r\n\r\nLes versions sont mutables sur fenêtre courte. Un paquet peut être republié dans les 72 heures suivant sa publication, et un peut retirer une version d'un jour à l'autre.\r\n\r\nAucun de ces points n'est un défaut technique réparable par un patch. Ce sont des choix d'architecture, vieux de plus de dix ans, qui ont accompagné l'explosion de l'écosystème.\r\n\r\nY a-t-il des alternatives ?\r\n\r\nLa question est légitime, mais la réponse honnête est : pas vraiment, et pour de bonnes raisons.\r\n\r\nLes gestionnaires de paquets alternatifs\r\n\r\n, et sont des gestionnaires différents, mais ils tirent leurs paquets du même registre npm. Migrer de à ne change rien à la surface d'attaque : ce sont les mêmes paquets, le même registre, les mêmes mainteneurs.\r\n\r\nCela dit, certains apportent des garde-fous utiles :\r\na introduit l'option , qui refuse d'installer un paquet publié il y a moins de N jours. Une vague d'attaque dure typiquement quelques heures avant détection : attendre 72 heures avant d'installer une nouvelle version élimine la fenêtre dangereuse.\r\nimpose un consentement explicite pour les scripts , là où npm les exécute par défaut.\r\net proposent des lockfiles stricts () qui garantissent que ce qui est installé en CI correspond exactement à ce qui a été testé.\r\n\r\nLes registres alternatifs\r\n\r\nJSR (JavaScript Registry), lancé par les créateurs de Deno, est le seul vrai nouveau registre crédible. Il a été conçu en tirant les leçons des problèmes de npm : TypeScript natif, modules ECMAScript par défaut, pas de scripts d'install, scoring qualité automatique, compatible avec tous les runtimes (Node, Deno, Bun). Mais JSR est complémentaire, pas un remplaçant : il héberge des milliers de paquets, pas des millions. Pour la majorité des dépendances, on continuera de passer par npm.\r\n\r\nLes registres privés — Verdaccio, GitHub Packages, JFrog Artifactory, Sonatype Nexus — ne remplacent pas npm non plus. Ils servent de proxy filtrant : on continue de récupérer les paquets publics, mais à travers un cache d'entreprise où l'on peut bloquer une version, exiger une signature, refuser un mainteneur, ou interdire les paquets publiés depuis moins de X jours. C'est probablement le meilleur compromis disponible aujourd'hui pour une organisation.\r\n\r\nLe verdict\r\n\r\nAbandonner npm en 2026 reviendrait à abandonner JavaScript. La valeur de l'écosystème (2,5 millions de paquets) est trop importante pour qu'on en sorte. Le problème ne se résoudra pas par un changement d'outil ; il se résoudra par un changement de pratiques.\r\n\r\nChanger les pratiques : ce qui doit devenir réflexe\r\n\r\nL'enseignement de cette campagne, et des précédentes (Shai-Hulud, TeamPCP, l'attaque Trivy/KICS), tient en une phrase : la confiance par défaut est morte. Il faut traiter chaque dépendance comme du code hostile par défaut, et le pipeline CI/CD comme une zone de production.\r\n\r\nAu niveau du poste de développement\r\nActiver l'option (ou équivalent) pour différer l'installation des paquets fraîchement publiés.\r\nDésactiver les scripts par défaut, et n'autoriser que ceux explicitement validés.\r\nNe jamais stocker de jetons en clair dans ou les variables d'environnement persistantes. Préférer un gestionnaire de secrets (1Password CLI, , ).\r\nUtiliser des comptes npm séparés pour la publication, avec 2FA matérielle obligatoire.\r\n\r\nAu niveau du dépôt\r\nVerrouiller systématiquement les dépendances (, , ) et installer en mode strict (, ).\r\nMettre en place un audit automatique des dépendances à chaque PR (Socket, Snyk, GitHub Dependabot, ).\r\nPublier ses propres paquets avec provenance npm (signature liée au pipeline GitHub Actions), pour que les consommateurs puissent vérifier l'origine.\r\nTenir à jour un SBOM (Software Bill of Materials) pour savoir exactement ce qui tourne en production.\r\n\r\nAu niveau du CI/CD\r\n\r\nC'est probablement le chantier le plus important.\r\nCloisonner les jetons. Un jeton de publication npm ne doit jamais coexister avec un jeton AWS dans la même étape de pipeline. Un secret par étape, durée de vie minimale, scope minimal.\r\nPréférer les jetons à courte durée de vie (OIDC entre GitHub Actions et le cloud) plutôt que des clés statiques.\r\nAuditer les GitHub Actions tierces. Une action est l'équivalent d'un . Épingler par hash SHA (), pas par tag mutable.\r\nRestreindre les permissions du au strict minimum ( par défaut, ponctuel et justifié).\r\nSurveiller le comportement réseau des runners : un build qui contacte un domaine inconnu doit lever une alerte.\r\n\r\nAu niveau de l'organisation\r\nMettre en place un registre proxy (Verdaccio, Nexus, Artifactory) avec liste blanche/noire de paquets, et l'imposer comme unique source pour tous les projets.\r\nDéfinir une politique de dependency governance : qui peut introduire une nouvelle dépendance, sous quelles conditions, avec quel niveau d'audit.\r\nPrévoir un playbook de révocation : que faire dans l'heure qui suit la détection d'un paquet compromis (rotation de tous les jetons npm/GitHub/cloud, audit des artefacts publiés, communication).\r\n\r\nEn résumé\r\n\r\nNPM n'est pas cassé, il est tel qu'il a été conçu : ouvert, automatique, transitif. Ce qui a changé, c'est la valeur que les attaquants peuvent en extraire — secrets cloud, jetons CI/CD, accès aux pipelines — et la sophistication des campagnes, qui exploitent désormais l'auto-propagation pour atteindre une échelle virale.\r\n\r\nAucune alternative ne supprime le problème, parce que le problème n'est pas npm : c'est l'idée qu'on puisse exécuter en production du code écrit par des inconnus sans jamais le regarder. Le rôle du DevOps en 2026, c'est de bâtir l'infrastructure qui rend cette inspection systématique, économique et inévitable — registres proxy, lockfiles stricts, jetons éphémères, audits continus, isolation des étapes de build.\r\n\r\nOn ne fera pas confiance à moins de gens. On exigera juste que chaque maillon prouve, à chaque exécution, qu'il est bien celui qu'il prétend être."},{"uuid":"586c5ab7-e960-465b-b499-83e0209890fe","slug":"quand-alt-ne-repond-plus-anatomie-d-un-bug-clavier-sous-gnome-wayland","title":"Quand Alt ne répond plus : anatomie d'un bug clavier sous GNOME/Wayland","category":"informatique","author":"cedric@abonnel.fr","cover":"cover.png","published":true,"published_at":"2026-05-25 07:27","created_at":"2026-05-12 13:35:47","updated_at":"2026-05-12 13:40:34","tags":[],"plain":"Comment une option de clavier a priori anodine peut désactiver Alt+Tab, Alt+F4 et tous les raccourcis Alt — et comment diagnostiquer ce genre de problème de façon méthodique.\r\n\r\nLe symptôme\r\n\r\nUn beau matin, les raccourcis clavier ne répondent plus. Pas tous : seulement ceux qui utilisent la touche Alt gauche.\r\nne change plus de fenêtre\r\nne ferme plus l'application active\r\nDans un terminal, les raccourcis (édition de ligne readline, raccourcis dans une applicaiton, navigation tmux…) restent sans effet\r\nLa touche AltGr (Alt droite), elle, fonctionne toujours : on peut taper , , , les caractères normalement obtenus via Alt droite sur un clavier français azerty\r\n\r\nPremier réflexe naturel : « Le clavier est cassé ». Sauf que la touche physique répond bien — elle ne déclenche simplement plus ce qu'on attend d'elle.\r\n\r\nComprendre ce qui se passe (sans connaître Linux par cœur)\r\n\r\nPour saisir le bug, il faut comprendre un détail qu'on ignore généralement : une touche physique du clavier et la fonction qu'elle déclenche sont deux choses différentes.\r\n\r\nQuand on appuie sur la touche marquée « Alt » à gauche du clavier, le système reçoit d'abord un signal matériel — un code brut, sous Linux. Ce signal est ensuite traduit en une fonction logique par une couche logicielle appelée xkb (X Keyboard Extension). C'est xkb qui décide que signifie « modificateur Alt gauche » (le fameux ).\r\n\r\nMais xkb peut être configuré pour faire autre chose de ce même signal. Et c'est exactement ce qui s'était passé ici. Une option xkb nommée indiquait à la couche de traduction :\r\n« Quand tu reçois , ne génère pas . Génère à la place. »\r\n\r\n, c'est le nom technique de AltGr : la touche modificatrice qui permet d'accéder au « troisième niveau » d'une touche (le au-dessus du , le au-dessus du , etc.). En clair, l'option transformait Alt gauche en un deuxième AltGr.\r\n\r\nConséquence : du point de vue des applications, personne n'appuie jamais sur Alt. Le gestionnaire de fenêtres (mutter, dans GNOME) attend un événement qui ne vient jamais ; le terminal attend un préfixe Alt qui ne vient jamais non plus ; AltGr fonctionne toujours parce que c'est lui le « vrai » Level 3 Shift sur azerty, par défaut.\r\n\r\nC'est l'analogie d'un interrupteur dont on aurait inversé deux fils dans le mur : l'interrupteur marche, mais il commande une autre lampe.\r\n\r\nLa cause exacte\r\n\r\nSous GNOME, les options xkb sont stockées dans la base de configuration dconf, accessible via la commande . La clé concernée :\r\n\r\n\r\n\r\nSur le système concerné, la commande retournait :\r\n\r\n\r\n\r\nD'où venait cette option ? Plusieurs hypothèses plausibles :\r\nSélectionnée par erreur dans Paramètres → Clavier → Options de disposition lors d'une configuration ancienne\r\nImportée depuis une ancienne machine via la synchronisation du profil\r\nActivée par un script ou un outil de personnalisation (GNOME Tweaks, dconf-editor)\r\nHéritée d'une habitude QWERTY où certains préfèrent un second AltGr à gauche\r\n\r\nSur un clavier français azerty, cette option n'a aucun intérêt pratique : AltGr est déjà sur la touche Alt droite, là où l'index droit peut l'atteindre naturellement. Ajouter un second AltGr sur la touche Alt gauche revient à perdre Alt sans gagner quoi que ce soit.\r\n\r\nLe diagnostic, étape par étape\r\n\r\nVoici la séquence de commandes pour confirmer le problème — utile à mémoriser parce qu'elle s'applique à tout symptôme similaire sur GNOME/Wayland.\r\n\r\n1. Confirmer l'environnement de session. Les commandes qui suivent supposent GNOME sous Wayland ; sous X11 ou KDE, le diagnostic diffère.\r\n\r\n\r\n\r\n2. Inspecter les options xkb. C'est le test diagnostic principal pour ce genre de panne.\r\n\r\n\r\n\r\nSi la sortie n'est pas (liste vide) ou une option clairement intentionnelle, on tient probablement le coupable. Les options les plus susceptibles de casser des raccourcis :\r\n— transforme Alt gauche en AltGr (le cas présent)\r\n— échange Alt et Super (la touche Windows)\r\n— échange Caps Lock et Échap (anodin pour Alt, mais peut surprendre)\r\n, — transforment Caps Lock en Ctrl\r\n\r\n3. Vérifier que les raccourcis WM sont bien définis. Cela permet d'éliminer une mauvaise piste : si ne marchait pas parce que le raccourci avait été effacé, ce serait visible ici.\r\n\r\n\r\n\r\nLa sortie attendue est ou équivalent. Si y figure, le gestionnaire de fenêtres est correctement configuré — la panne est ailleurs.\r\n\r\n4. Vérifier les options d'accessibilité. Les touches rémanentes (StickyKeys), touches lentes (SlowKeys) ou touches rebonds (BounceKeys) peuvent provoquer des comportements clavier surprenants quand elles sont activées par erreur.\r\n\r\n\r\n\r\nToutes les trois doivent normalement renvoyer sauf besoin spécifique.\r\n\r\n5. Tester au niveau matériel si rien d'autre n'explique. Si toutes les vérifications logicielles sont propres, on vérifie que la touche envoie bien un signal au noyau :\r\n\r\n\r\n\r\nL'outil demande de choisir un périphérique (le clavier), puis affiche en direct chaque événement reçu. En appuyant sur Alt gauche, une ligne contenant doit apparaître. Si rien ne s'affiche, le problème est matériel ou dans le pilote — ce qui sort du cadre de cette fiche.\r\n\r\nLa correction\r\n\r\nUne seule commande suffit dans le cas présent :\r\n\r\n\r\n\r\nL'effet est immédiat : mutter recharge la configuration clavier à la volée, sans qu'on ait besoin de fermer sa session. Si pour une raison ou une autre l'effet ne se voit pas (vieux processus qui a mis en cache la configuration, terminal récalcitrant…), une déconnexion/reconnexion de la session GNOME suffit à tout réinitialiser.\r\n\r\nPour vérifier que la valeur est bien revenue à vide :\r\n\r\n\r\n\r\nEt si on voulait vraiment garder l'option ?\r\n\r\nPour information, la commande inverse est :\r\n\r\n\r\n\r\nÀ réserver aux cas où l'on tape énormément de caractères de troisième niveau de la main gauche et où on accepte de perdre Alt+Tab.\r\n\r\nLa méthode à retenir, au-delà de ce bug précis\r\n\r\nL'intérêt de cette fiche n'est pas tant la solution — une ligne de commande — que la logique de diagnostic. Quand une touche cesse de fonctionner sous Linux, on remonte la chaîne des responsabilités, du plus haut niveau au plus bas :\r\n\r\n1. Le gestionnaire de fenêtres a-t-il bien le raccourci ? ()\r\n2. Les options d'accessibilité ne brouillent-elles pas la frappe ? ()\r\n3. La couche xkb traduit-elle correctement la touche en modificateur ? ()\r\n4. Le noyau reçoit-il un signal matériel quand on appuie ? ()\r\n\r\nÀ chaque étage, une commande, une sortie attendue, et un verdict clair. La grande force de Linux dans ce genre de situation, c'est que chaque couche est inspectable séparément. Le réflexe à acquérir n'est pas « ça ne marche pas, je redémarre » mais « ça ne marche pas, je trouve quelle couche ment ».\r\n\r\nChecklist mémo\r\n\r\nModificateur (Alt / Super / Ctrl) qui ne répond plus sous GNOME/Wayland :\r\n\r\n1. — surveiller , , , \r\n2. — confirmer que le raccourci existe\r\n3. (puis , )\r\n4. → choisir le clavier → presser la touche → doit afficher le bon code (, , etc.)\r\n\r\nQuatre commandes, quatre couches, et 95 % des bugs clavier de session graphique sont localisés."},{"uuid":"ab4fd4aa-8ba8-4deb-89d2-b2c7019b2afe","slug":"de-activer-group","title":"Désactiver un groupe","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-02-10 22:48:32","created_at":"2023-02-10 22:48:32","updated_at":"2023-02-10 22:48:32","tags":[],"plain":"Mode graphique\nEn <u>mode graphique</u>, il faut accéder à Groups du menu Group management. Il suffit de cliquer sur le bouton vert Enabled pour désactiver le groupe. Un message vous informe du résultat de l'opération.\nLigne de commande\nEn <u>ligne de commande</u> je vous propose la méthode suivante en deux étapes. 1. Il faut connaître l'identifiant du groupe. Voir le chapitre . Dans l'exemple ci-dessous, le groupe jeux-actifs a pour identifiant le numéro 11. 2. On modifie la valeur dans la base de données gravity, la table group comme ceci : sudo sqlite3 /etc/pihole/gravity.db \"UPDATE 'group' SET enabled=0 WHERE id='11';\" \nPlanifier et automatiser\n1. Il faut créer un script qui va activer et désactiver les groupes. Ce script doit être appelé avec une option : 0 ou 1. Par exemple :\n pihole-group.sh 0 2. Ajouter des taches CRON pour activer les groupes\n \n sudo nano /etc/cron.d/pihole-group-enable en ajoutant ces instructions 3. Ajouter des taches CRON pour désactiver les groupes\n \n sudo nano /etc/cron.d/pihole-group-disable en ajoutant ces instructions"}] |