Cédrix
1 line
30 KiB
JSON
1 line
30 KiB
JSON
[{"uuid":"3f750a3a-fad0-4089-98e5-79c8b4287ea2","slug":"esp8266ex-restore-commandes-at","title":"Réinitialisation d'un ESP-01 : restauration du firmware AT","category":"Électronique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2020-12-13 14:35","created_at":"2020-12-13 14:35:26","updated_at":"2026-05-13 18:15:11","tags":[],"plain":"Introduction\r\n\r\nL'ESP-01 est un petit module Wi-Fi très répandu, construit autour du microcontrôleur ESP8266EX fabriqué par Espressif. À sa sortie d'usine, il est livré avec un firmware (le programme interne du circuit) qui permet de le piloter à l'aide de commandes textuelles simples appelées commandes AT. Ce firmware peut être effacé ou corrompu, par exemple après avoir téléversé un programme Arduino ou MicroPython sur le module. Ce document explique comment remettre l'ESP-01 dans son état d'origine afin de retrouver l'usage des commandes AT.\r\n\r\nQuelques notions préalables\r\n\r\nAvant de commencer, il est utile de clarifier quelques termes.\r\n\r\nUn firmware est le logiciel embarqué dans un composant électronique. Contrairement à un programme installé sur un ordinateur, il s'écrit directement dans la mémoire flash du microcontrôleur et s'exécute au démarrage du circuit.\r\n\r\nUn fichier binaire (extension ) est le résultat de la compilation d'un code source écrit dans un langage évolué, généralement le C. Une fois compilé, le fichier ne contient plus que des instructions destinées au processeur, illisibles directement par un humain. Il n'est pas nécessaire de les modifier : ils se téléversent tels quels dans le microcontrôleur.\r\n\r\nLa mémoire flash de l'ESP8266EX est divisée en zones. Chaque binaire doit être écrit à une adresse mémoire précise, sans quoi le module ne saura pas où trouver le code à exécuter au démarrage. Sur l'ESP-01, la mémoire est généralement organisée en 512k + 512k, ce qui signifie que la flash totale de 8 Mbit (1 Mo) est partagée en deux zones de 512 ko : l'une pour le programme actif, l'autre réservée aux mises à jour à distance (OTA).\r\n\r\nÉtape 1 — Télécharger le firmware AT officiel\r\n\r\nLe firmware est mis à disposition par Espressif sur son site officiel :\r\n\r\nhttps://www.espressif.com/en/products/socs/esp8266ex/resources\r\n\r\n\r\n\r\nDans la section , choisir la version ou plus récente. L'archive ZIP téléchargée contient plusieurs binaires destinés à l'ESP8266EX.\r\n\r\nQuatre fichiers sont particulièrement importants :\r\nbootv1.7.bin — le chargeur de démarrage (bootloader), premier programme exécuté à la mise sous tension ;\r\nuser1.1024.new.2.bin — le programme AT proprement dit, qui interprète les commandes envoyées par la liaison série ;\r\nespinitdatadefaultv08.bin — les données d'initialisation (paramètres radio, calibration) ;\r\nblank.bin — un fichier rempli de zéros, utilisé pour réinitialiser certaines zones de la flash.\r\n\r\nUne copie de ces binaires pour la configuration ESP8266EX 512k+512k est disponible ici :\r\n\r\nhttps://gitlab.com/cedricAbonnel/esp/-/tree/master/esp01/esp8266exatbin\r\n\r\nÉtape 2 — Identifier le port série de l'ESP-01\r\n\r\nL'ESP-01 ne se connecte pas directement à un port USB : il faut passer par un adaptateur USB-série (souvent un module FTDI ou CH340). Une fois branché, l'ordinateur expose ce périphérique sous la forme d'un fichier dans .\r\n\r\nPour repérer ce fichier, exécuter dans un terminal :\r\n\r\n\r\n\r\nParmi les entrées affichées, celle qui nous intéresse est généralement /dev/ttyUSB0 (parfois si plusieurs adaptateurs sont branchés, ou selon le modèle).\r\n\r\nUne astuce utile : exécuter la commande une première fois sans l'adaptateur, puis une seconde fois après l'avoir branché. La nouvelle entrée qui apparaît est celle du module.\r\n\r\nÉtape 3 — Préparer le téléversement avec esptool.py\r\n\r\nesptool.py est l'outil officiel d'Espressif, écrit en Python, qui permet de communiquer avec la mémoire flash de l'ESP8266EX. S'il n'est pas déjà installé, on peut l'obtenir via :\r\n\r\n\r\n\r\nAvant le téléversement, l'ESP-01 doit être placé en mode programmation : la broche GPIO0 doit être reliée à la masse (GND) au moment de la mise sous tension. Sans cette manipulation, le module démarre normalement et refuse l'écriture en flash.\r\n\r\nÉtape 4 — Téléverser les binaires\r\n\r\nLa commande suivante écrit les quatre binaires aux bonnes adresses mémoire :\r\n\r\n\r\n\r\nDécortiquons les options :\r\nindique le port série identifié à l'étape précédente ;\r\nest la sous-commande d'écriture en mémoire flash ;\r\nprécise le mode d'accès à la flash (Quad I/O, le plus rapide, supporté par l'ESP-01).\r\n\r\nChaque valeur hexadécimale (, , etc.) qui précède un nom de fichier indique l'adresse mémoire à laquelle l'écriture doit commencer. La table de correspondance officielle pour une flash de 8 Mbit organisée en 512k+512k est la suivante :\r\n\r\n\r\n\r\nL'adresse correspond aux paramètres système, et à la zone RF système : les remplir de zéros () garantit un démarrage propre.\r\n\r\nSi tout se passe bien, esptool affiche la progression du téléversement et confirme la réussite de l'opération. C'est le moment d'apprécier le travail accompli :\r\n\r\n\r\n\r\nÉtape 5 — Vérifier le bon fonctionnement\r\n\r\nAprès le téléversement, retirer la connexion entre GPIO0 et la masse, puis redémarrer le module. Ouvrir une console série (par exemple avec , ou la console série de l'IDE Arduino) à la vitesse 115200 bauds :\r\n\r\n\r\n\r\nTaper la commande suivie d'un retour à la ligne. Le module doit répondre . La commande retourne la version du firmware installé, ce qui permet de confirmer la réussite de la réinitialisation.\r\n\r\n\r\n\r\nEn cas de problème\r\n\r\nQuelques pistes si la procédure échoue :\r\nAucune réponse d'esptool : vérifier que GPIO0 est bien reliée à GND au moment de l'alimentation, et que l'adaptateur USB-série fournit assez de courant (l'ESP-01 demande des pics jusqu'à 300 mA).\r\nRéponses illisibles dans la console série : la vitesse par défaut a pu changer selon la version du firmware. Essayer 9600, 74880 ou 115200 bauds.\r\nErreur de checksum ou de mode flash** : essayer à la place de , certains clones d'ESP-01 ne supportent pas le mode Quad I/O.\r\n\r\nConclusion\r\n\r\nCette procédure restaure un ESP-01 dans son état d'origine, prêt à recevoir des commandes AT depuis n'importe quel système capable de dialoguer en série : ordinateur, Arduino, Raspberry Pi, etc. Elle constitue également un bon exercice d'introduction aux notions de firmware, de mémoire flash et de programmation bas-niveau des microcontrôleurs."},{"uuid":"6f2639a5-58ed-4102-a6a2-0acbecf01de5","slug":"esp8266-commandes-at","title":"ESP8266 : prise en main des commandes AT","category":"Électronique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2020-12-13 08:51","created_at":"2020-12-13 08:51:55","updated_at":"2026-05-13 18:23:54","tags":[],"plain":"Présentation\r\n\r\nL'ESP8266 est un microcontrôleur Wi-Fi développé par Espressif. Lorsqu'il sort d'usine, ou lorsqu'il est flashé avec le firmware AT officiel d'Espressif, il accepte un jeu d'instructions textuelles appelées commandes AT (ou commandes Hayes, du nom du fabricant de modems qui les a popularisées dans les années 1980).\r\n\r\nLe module ESP-01, le plus répandu pour découvrir l'ESP8266, est généralement livré avec ce firmware AT préchargé. Il est donc utilisable immédiatement, sans programmation, simplement en lui envoyant des commandes texte sur sa liaison série.\r\nPrérequis matériel : un ESP-01 connecté à un PC via un adaptateur USB-série, et un terminal série (moniteur série de l'IDE Arduino, , , PuTTY…) configuré à 115200 bauds avec fin de ligne CR+LF.\r\nNote sur les versions : la syntaxe et les codes retour des commandes AT varient selon la version du firmware. Les exemples ci-dessous correspondent à un firmware AT v1.x typique sur ESP-01. Pour les firmwares plus récents (AT v2.x sur ESP32), certaines commandes prennent des paramètres supplémentaires.\r\n\r\nTravaux pratiques\r\n\r\nL'enchaînement ci-dessous permet de mettre l'ESP-01 sur un réseau Wi-Fi, puis de le transformer en serveur HTTP minimaliste. Chaque commande est envoyée depuis le terminal série ; les lignes préfixées par représentent la réponse du module.\r\n\r\n1. Vérifier le mode Wi-Fi courant\r\n\r\n\r\n\r\nLe module répond avec un chiffre indiquant son mode courant (voir glossaire plus bas).\r\n\r\n2. Passer en mode dual (client + point d'accès)\r\n\r\n\r\n\r\nLe mode 3 active simultanément le mode station (le module se connecte à un Wi-Fi existant) et le mode AP (le module expose son propre point d'accès). C'est le mode le plus polyvalent pour expérimenter.\r\n\r\n3. Se connecter à un réseau Wi-Fi\r\n\r\n\r\n\r\nTrois événements sont remontés successivement :\r\nWIFI CONNECTED : association réussie au point d'accès ;\r\nWIFI GOT IP : adresse IP obtenue via DHCP ;\r\nOK : la commande est terminée avec succès.\r\n\r\n4. Lister les adresses IP et MAC du module\r\n\r\n\r\n\r\nEn mode dual, le module possède deux interfaces réseau :\r\nAP (point d'accès) : adresse fixe par défaut, sur laquelle se connectent les clients du Wi-Fi exposé par l'ESP ;\r\nSTA (station/client) : adresse attribuée par le routeur du réseau auquel l'ESP s'est connecté.\r\n\r\n5. Activer les connexions multiples\r\n\r\n\r\n\r\nPar défaut, l'ESP n'accepte qu'une seule connexion TCP simultanée. Le mode multi-connexion est obligatoire pour faire fonctionner le module en serveur (étape suivante).\r\n\r\n6. Démarrer un serveur TCP sur le port 80\r\n\r\n\r\n\r\nLe module écoute désormais sur le port 80 de son adresse STA. Un simple navigateur pointé sur (l'adresse retournée par ) déclenche une connexion HTTP.\r\n\r\n7. Observer une requête entrante\r\n\r\nLorsqu'un client se connecte, l'ESP recopie sur la liaison série l'événement de connexion, puis la requête HTTP brute, et enfin la fermeture de la connexion :\r\n\r\n\r\n\r\nLecture :\r\n: un client vient de s'associer ; est l'identifiant de connexion (link ID), utile en mode multi-connexion ;\r\n: l'ESP a reçu 341 octets sur la connexion ; ces octets suivent immédiatement (ici, l'en-tête HTTP envoyé par Firefox) ;\r\n: le client a fermé la connexion (ou un timeout est intervenu).\r\n\r\nÀ ce stade, l'ESP ne répond rien au client : il faut explicitement envoyer une réponse avec (voir glossaire). Le navigateur affichera donc une page vide ou un message d'erreur.\r\n\r\nPour aller plus loin : répondre au client\r\n\r\nPour renvoyer une page HTML minimale au client :\r\n\r\n\r\n\r\nLe module affiche et attend exactement le nombre d'octets annoncé, puis envoie le tout sur la connexion . Il faut ensuite fermer la connexion avec :\r\n--\r\n\r\nGlossaire des commandes AT\r\n\r\nConventions\r\n\r\nTrois formes coexistent pour la plupart des commandes :\r\nForme | Syntaxe | Rôle |\r\n---|---|---|\r\nInterrogation | | Lire la valeur courante |\r\nTest | | Lister les valeurs autorisées |\r\nAffectation | | Modifier la valeur |\r\n\r\nLes chaînes de caractères (SSID, mot de passe…) sont toujours encadrées par des guillemets droits.\r\n\r\nCommandes Wi-Fi\r\n\r\n— Mode de fonctionnement Wi-Fi\r\n\r\n\r\n\r\nValeurs de :\r\nValeur | Mode | Description |\r\n---|---|---|\r\n1 | STA | Station/client : le module se connecte à un Wi-Fi existant |\r\n2 | AP | Point d'accès : le module expose son propre Wi-Fi |\r\n3 | STA+AP | Mode dual : les deux à la fois |\r\n\r\nExemple :\r\n\r\n\r\n\r\n— Lister les points d'accès visibles\r\n\r\n\r\n\r\nRetourne une ligne par réseau détecté, sous la forme :\r\nChamp | Signification |\r\n---|---|\r\n| Chiffrement : ouvert, WEP, WPA-PSK, WPA2-PSK, WPA/WPA2-PSK |\r\n| Nom du réseau |\r\n| Puissance du signal en dBm (plus la valeur est proche de 0, plus le signal est fort) |\r\n| Adresse MAC du point d'accès (BSSID) |\r\n| Canal Wi-Fi (1 à 13 en Europe sur 2,4 GHz) |\r\n\r\nExemple :\r\n\r\n\r\n\r\nPrérequis : doit inclure le mode station (1 ou 3).\r\n\r\n— Se connecter à un point d'accès\r\n\r\n\r\n\r\nCodes d'erreur retournés en cas d'échec via :\r\nCode | Signification |\r\n---|---|\r\n1 | Délai de connexion dépassé |\r\n2 | Mot de passe incorrect |\r\n3 | SSID introuvable |\r\n4 | Échec de connexion (autre) |\r\n\r\nExemple d'échec :\r\n\r\n\r\n\r\nExemple de réussite :\r\n\r\n\r\n\r\n— Se déconnecter du point d'accès\r\n\r\n\r\n\r\nÀ ne pas confondre avec une commande de sauvegarde : signifie Quit AP, c'est-à-dire déconnexion. Les paramètres de connexion (SSID, mot de passe) sont en revanche automatiquement mémorisés en flash par les commandes et dans les versions classiques du firmware AT — le module se reconnectera donc au démarrage suivant.\r\n\r\n— Adresses IP et MAC locales\r\n\r\n\r\n\r\nRenvoie les adresses IP et MAC du module pour chaque interface active :\r\n/ : interface point d'accès (toujours par défaut) ;\r\n/ : interface station (attribuée par le DHCP du réseau rejoint).\r\n\r\nEn mode , seule la partie STA est retournée ; en mode 2, seule la partie AP.\r\n\r\nCommandes TCP/IP\r\n\r\n— Activer les connexions multiples\r\n: connexion unique (mode par défaut) ;\r\n: jusqu'à 5 connexions simultanées, chacune identifiée par un link ID de 0 à 4.\r\n\r\nPrérequis pour passer en mode 1 : aucune connexion ne doit être active, et le module ne doit pas déjà être en mode serveur.\r\n\r\n— Démarrer un serveur TCP\r\n: pour démarrer, pour arrêter ;\r\n: port d'écoute, optionnel (par défaut 333).\r\n\r\nPrérequis : doit avoir été exécuté au préalable.\r\n\r\nAprès un arrêt (), un redémarrage du module est nécessaire () pour libérer complètement le port.\r\n\r\n— Envoyer des données sur une connexion\r\n\r\n\r\n\r\nLe module affiche un prompt et attend exactement octets, puis transmet le bloc au client. Indispensable pour répondre à une requête HTTP entrante.\r\n\r\n— Fermer une connexion\r\n\r\n\r\n\r\nCommandes générales utiles\r\nCommande | Rôle |\r\n---|---|\r\n| Test de présence du module (doit répondre ) |\r\n| Redémarrer le module |\r\n| Afficher la version du firmware AT |\r\n| Changer le débit série (non persistant) |\r\n/ | Désactiver / activer l'écho des commandes |\r\n--\r\n\r\nRécapitulatif : déclarer un serveur HTTP minimal\r\n\r\nSéquence complète depuis un ESP-01 vierge :\r\n\r\n\r\n\r\nÀ partir de cet instant, toute connexion entrante sur est remontée sur le port série sous forme d'événements , à charge pour le programme côté PC (ou pour un firmware personnalisé) de les analyser et de répondre via .\r\n\r\nLimites du firmware AT\r\n\r\nLe firmware AT est pratique pour découvrir et tester l'ESP8266, mais il montre vite ses limites :\r\nlatence importante (chaque commande passe par le port série) ;\r\npas de TLS correct dans les anciennes versions ;\r\ncomplexité pour gérer plusieurs clients simultanés ;\r\ndépendance à un hôte qui pilote l'ESP en permanence.\r\n\r\nPour des projets plus aboutis, il est préférable de flasher l'ESP avec un firmware personnalisé (Arduino, ESP-IDF, MicroPython, Tasmota, ESPHome…) qui exécute directement la logique applicative sur le microcontrôleur, sans intermédiaire série.\r\n```"},{"uuid":"7e0b56c6-8a43-41f3-982e-15bd51a74bdb","slug":"46-20201207-reparer-un-smartphone","title":"Réparer un smartphone. Zigbee vs Xbee. AT ESP-01","category":"Podcasts","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2020-12-07 22:14:39","created_at":"2020-12-07 22:14:39","updated_at":"2020-12-07 22:14:39","tags":[],"plain":"Voici le 46ème épisode : Réparer un smartphone. Zigbee vs Xbee. AT ESP-01\nCette page est amenée à évoluer. Réagissez à cet épisode dans la partie [Épisode disponible sur https://info.mindcast.fr/]\n--"},{"uuid":"1363f454-ca59-4264-a8f0-a2446d645ebc","slug":"installation-et-mise-en-service-d-une-borne-de-recharge-murale-goneo-7-4-kw","title":"Installation et mise en service d'une borne de recharge murale GONEO 7,4 kW","category":"","author":"cedric@abonnel.fr","cover":"cover.jpg","published":true,"published_at":"2026-05-13 11:04","created_at":"2026-05-13 11:23:38","updated_at":"2026-05-13 15:17:04","tags":{"logiciels":["Home Assistant"]},"plain":"Une borne de recharge murale GONEO a été récemment acquise (référence Amazon B0FP288GM7). Il s'agit d'une wallbox monophasée 7,4 kW (32 A, 230 V), équipée d'un connecteur Type 2, d'un lecteur RFID, et pilotable via Wi-Fi, Bluetooth. La gamme constructeur est documentée sur le site officiel GONEO Global et son catalogue EV Charger sur it.goneoglobal.com.\r\n\r\nCaractéristiques techniques\r\n\r\nD'après les fiches constructeur et revendeurs, le modèle présente les caractéristiques suivantes :\r\nPuissance : jusqu'à 7 kW en monophasé (annoncée 7,4 kW selon le réglage de courant)\r\nCourant réglable : 8 A à 32 A\r\nTension : 230 V monophasé\r\nConnecteur : Type 2 (IEC 62196-2)\r\nProtection : IP65, IK10, ignifuge UL94 V-0, plage -30 °C à +55 °C\r\nDétection de défaut intégrée : protection de fuite Type A 30 mA + DC 6 mA\r\nConnectivité : Wi-Fi, Bluetooth, compatible OCPP et Home Assistant\r\nApplication : Goneo EV Charger (Android / iOS)\r\n\r\nCâblage et raccordement\r\n\r\nLe câble d'alimentation a été tiré soi-même, en s'appuyant sur les règles de dimensionnement détaillées dans cet article. La section retenue est conforme aux préconisations constructeur : câble 3G6 mm² pour un courant maximum de 32 A, avec en amont un disjoncteur 40 A et un interrupteur différentiel type A 40 A.\r\n\r\nUn soin particulier a été apporté au serrage des borniers : un serrage insuffisant entraîne une résistance de contact accrue, source d'échauffement et de chute de tension sous charge — risque non négligeable compte tenu des intensités mises en jeu (jusqu'à 32 A en continu pendant plusieurs heures).\r\n\r\nVérifications avant mise sous tension\r\n\r\nUne fois le raccordement effectué, les mesures suivantes ont été réalisées au multimètre :\r\nPhase – Neutre : 230 V (tension nominale du réseau)\r\nPhase – Terre : 230 V (confirme la continuité de la phase et de la terre)\r\nNeutre – Terre : 0 V (idéalement quelques volts maximum ; une valeur significative trahirait un défaut de neutre ou de mise à la terre)\r\n\r\nÀ noter : la protection différentielle intégrée à la borne couvre la composante DC (6 mA), ce qui permet en théorie de se contenter d'un différentiel type A en amont — là où une borne sans détection DC interne exigerait un type B beaucoup plus onéreux. La vérification de la valeur de la prise de terre au telluromètre et le test du déclenchement du différentiel restent recommandés.\r\n\r\nMise en service\r\n\r\nLa mise en service s'effectue via le Wi-Fi de l'appareil et l'application propriétaire Goneo EV Charger. Points à anticiper :\r\nTélécharger l'application avant de commencer la procédure.\r\nCréer un compte utilisateur.\r\nS'assurer que le téléphone est connecté à un réseau Wi-Fi 2,4 GHz et que le Bluetooth est activé ; la borne doit être à portée du signal Wi-Fi.\r\nAssocier la borne au compte (un appui court sur le bouton règle l'alimentation, un double appui lance la configuration Wi-Fi).\r\n\r\nLa borne ayant été achetée d'occasion, elle n'avait pas été dissociée du compte du précédent propriétaire — situation fréquente sur ce type d'achat. Un message au SAV par mail (info@goneoglobal.com) a suffi : la réponse a été rapide et la dissociation effectuée sans difficulté. Réflexe à prendre lors d'un achat d'occasion : demander au vendeur de procéder à la dissociation avant l'expédition.\r\n\r\nUsage au quotidien\r\n\r\nDeux modes d'utilisation cohabitent :\r\nProfil horaire programmé via l'application : pratique pour caler les sessions sur les heures creuses.\r\nBadge RFID** fourni avec la borne : démarrer ou arrêter une session par simple présentation du badge, sans passer par l'application.\r\n--\r\n\r\nÀ noter sur le plan réglementaire : depuis 2017, l'installation d'une borne de recharge d'une puissance supérieure à 3,7 kW à domicile relève en principe d'un électricien qualifié IRVE. Le fait de procéder soi-même au tirage du câble et au raccordement reste possible techniquement, mais sort du cadre permettant de prétendre aux aides publiques (crédit d'impôt, prime ADVENIR) et peut avoir des conséquences en matière d'assurance."},{"uuid":"bea327e2-9d1c-4ff6-a5a5-26748c80018b","slug":"anatomie-d-un-script-d-auto-deploiement-bash-fetch-scripts-sh","title":"Script Bash d'auto-déploiement : `fetch_scripts.sh`","category":"informatique","author":"cedric@abonnel.fr","cover":"cover.svg","published":true,"published_at":"2026-05-04 07:04","created_at":"2026-05-12 10:55:39","updated_at":"2026-05-12 11:10:51","tags":[],"plain":"Comment un simple script Bash peut télécharger, mettre à jour et synchroniser une bibliothèque de scripts distants — et pourquoi il faut le lire avec un œil critique.\r\n\r\nfetchscripts.sh\r\n📝 Note — Cet article est une autocritique. Le script analysé ici est de ma propre fabrication, déployé sur mes propres machines. L'exercice consiste à le relire avec la distance d'un reviewer extérieur, pour identifier ce qui tient la route et ce qui mériterait d'être repris.\r\n\r\nLe contexte\r\n\r\nL'idée derrière ce script est élégante : centraliser une collection de scripts utilitaires dans un dépôt Git public (ici, une instance Forgejo auto-hébergée), puis fournir un unique point d'entrée que l'on télécharge sur n'importe quelle machine. Ce point d'entrée se met à jour tout seul, propose à l'opérateur de choisir quels sous-ensembles de scripts récupérer, et maintient une synchronisation locale du dépôt distant.\r\n\r\nC'est typiquement le genre d'outil qui se déploie en une ligne :\r\n\r\n\r\n\r\nDécortiquons ce qu'il fait, étape par étape, puis voyons où il faudrait taper.\r\n--\r\n\r\nÉtape 1 — L'auto-mise à jour\r\n\r\n\r\n\r\nCe qui se passe : le script télécharge sa propre version distante dans , la compare octet-à-octet avec lui-même (), et si elle diffère, il s'écrase, se rend exécutable, et se relance via (qui remplace le processus courant — pas d'empilement de shells).\r\n\r\nPourquoi c'est malin : ça garantit qu'à chaque exécution, l'opérateur travaille avec la version canonique du dépôt. Pas besoin de mécanisme de versioning, pas de vérification de hash, pas de paquet à publier.\r\n\r\nPourquoi c'est risqué : on y reviendra dans la critique, mais en résumé — l'auto-mise à jour silencieuse depuis une URL en HTTPS sans signature est une porte d'entrée pour la chaîne d'approvisionnement.\r\n--\r\n\r\nÉtape 2 — Récupération du catalogue de dossiers\r\n\r\n\r\n\r\nLe dépôt distant contient un fichier qui liste les catégories de scripts disponibles (par exemple : , , , …). Ce fichier est la source de vérité : ajouter une catégorie côté serveur la rend immédiatement disponible côté client.\r\n\r\n (alias ) lit le fichier ligne à ligne dans un tableau Bash. Plus propre qu'une boucle .\r\n\r\nUn dossier est marqué comme obligatoire — il sera toujours téléchargé, sans demander à l'utilisateur.\r\n--\r\n\r\nÉtape 3 — Mémoire de la sélection précédente\r\n\r\n\r\n\r\nÀ chaque exécution, le script relit la sélection de la fois précédente. C'est ce qui permet à l'interface graphique (étape suivante) de pré-cocher les bons dossiers : on n'a pas à refaire son choix à chaque mise à jour.\r\n--\r\n\r\nÉtape 4 — L'interface \r\n\r\n\r\n\r\n est l'outil de dialogue ncurses standard sur Debian/Ubuntu — il affiche cette boîte bleue familière avec des cases à cocher, navigable au clavier. Idéal en SSH.\r\n\r\nLa gymnastique est un classique : écrit son interface sur stdout et sa réponse sur stderr. Il faut donc échanger les deux pour capturer la sélection dans tout en laissant l'interface s'afficher.\r\n\r\nL'expression est une astuce courante pour tester l'appartenance à un tableau Bash — on entoure d'espaces pour éviter les correspondances partielles ( qui matcherait ).\r\n--\r\n\r\nÉtape 5 — Synchronisation : ajouts et suppressions\r\n\r\n\r\n\r\nLogique de diff : tout ce qui était sélectionné avant et ne l'est plus est supprimé du disque. Ça maintient le répertoire local propre — pas de scripts orphelins qui traînent.\r\n\r\n renvoie la sélection sous forme de chaîne entre guillemets (), d'où le pour les retirer avant de constituer le tableau.\r\n--\r\n\r\nÉtape 6 — Téléchargement des fichiers de chaque dossier\r\n\r\n\r\n\r\nMême logique récursive d'un niveau plus bas : chaque dossier contient son propre listant ses fichiers. On télécharge ceux qui y figurent, on supprime ceux qui n'y figurent plus, et on rend tout exécutable.\r\n\r\nC'est une forme de artisanal, basé sur des manifestes plats. Ça fonctionne sans avoir à installer sur la machine cible — seuls et sont requis.\r\n--\r\n\r\nCritique : ce qui marche, ce qui inquiète\r\n\r\nLes bons côtés\r\n\r\nLa logique d'idempotence est solide. Le script peut tourner cent fois de suite, il convergera toujours vers le même état : les dossiers sélectionnés contiendront exactement les fichiers du manifeste, ni plus, ni moins. C'est le bon réflexe DevOps.\r\n\r\nL'auto-bootstrap est ergonomique. Une seule URL à retenir, tout le reste se télécharge tout seul. Pour une bibliothèque personnelle de scripts d'admin, c'est imbattable en simplicité.\r\n\r\nPas de dépendances exotiques. , , : tout est disponible nativement sur Debian. Le script tourne aussi bien sur un conteneur LXC fraîchement provisionné que sur une machine établie.\r\n\r\nLe manifeste séparé ( et ) découple la liste des fichiers de leur contenu. C'est plus simple qu'un parsing HTML de l'index Git, et ça reste sous contrôle éditorial.\r\n\r\nLes angles morts\r\n\r\n1. Aucune vérification d'intégrité\r\n\r\nC'est le point critique. Le script télécharge du code exécutable en HTTPS, sans vérifier :\r\nni signature GPG,\r\nni hash SHA256,\r\nni même que le serveur a bien répondu correctement.\r\n\r\n en mode silencieux n'échoue pas visiblement : si la requête renvoie une page d'erreur 404 ou une page de connexion captive Wi-Fi en HTML, elle sera écrite dans le fichier de destination. La vérification suivante () considérera ce HTML comme « différent », fera le , et au prochain le shell essaiera d'exécuter du HTML. Au mieux ça crashe, au pire ça exécute des balises interprétables.\r\n\r\nPire encore pour l'auto-update : si quelqu'un compromet l'instance Forgejo (ou interpose un proxy malveillant capable de servir un certificat valide pour ), le prochain télécharge et exécute du code arbitraire avec les privilèges de l'utilisateur courant — souvent root pour ce genre d'outils d'admin.\r\n\r\nCorrectif minimal : publier un fichier signé GPG dans le dépôt, le télécharger, vérifier sa signature avec une clé connue localement, puis valider chaque fichier téléchargé contre ce manifeste.\r\n\r\n2. sans gestion d'erreur\r\n\r\n\r\n\r\nSi échoue (réseau coupé, DNS HS, certificat expiré), sera soit vide soit absent. retournera « différent », et le script écrasera la version locale par un fichier vide. À la prochaine exécution, plus rien ne fonctionne.\r\n\r\nCorrectif : vérifier le code de retour de , vérifier que le fichier téléchargé n'est pas vide, et vérifier qu'il commence bien par avant d'écraser quoi que ce soit.\r\n\r\n\r\n\r\n3. Le perd les modifications de l'environnement\r\n\r\nSi le script a été lancé par (donc sans le bit exécutable, sans shebang utilisé), vaut . Après , on un fichier qui pourrait ne pas être dans le . En pratique ça marche parce qu'on est dans le bon répertoire, mais c'est fragile — un quelque part dans le script suffirait à le casser.\r\n\r\n4. Injection via les noms de fichiers du manifeste\r\n\r\n\r\n\r\nLe contenu de est utilisé directement dans une URL et dans un chemin de fichier local. Si quelqu'un peut écrire dans ce fichier manifeste (ce qui revient à pouvoir pousser sur le dépôt Forgejo), il peut y mettre des chemins comme et écrire en dehors du répertoire prévu.\r\n\r\n neutralise partiellement la chose côté nom local, mais l'URL côté distant accepte n'importe quoi. C'est moins critique que la première faille, mais ça mérite un filtre regex ( uniquement).\r\n\r\n5. et la sélection vide\r\n\r\nSi l'utilisateur ne coche rien et valide, est vide. Le script continue avec seulement , ce qui est probablement le comportement attendu. Mais si n'est pas installé (rare mais possible, par exemple sur Alpine ou un Debian minimal sans ), le script échoue avec une erreur peu explicite. Un test préalable éviterait la déconvenue.\r\n\r\n6. Pas de log, pas de mode dry-run\r\n\r\nPour un outil qui supprime des fichiers (), l'absence d'option qui afficherait ce qui serait fait sans rien toucher est gênante. Une frappe distraite sur la checklist, et un dossier entier disparaît sans warning.\r\n\r\n7. Le verrou manquant\r\n\r\nRien n'empêche deux instances de de tourner en parallèle (par exemple via et un opérateur en interactif). Un sur un fichier de lock éviterait des courses sur les opérations de download/delete.\r\n--\r\n\r\nVerdict\r\n\r\nC'est un script utile, lisible, et bien construit pour un usage personnel sur des machines de confiance. La logique de synchronisation est saine, l'ergonomie est appréciable, l'auto-bootstrap est élégant.\r\n\r\nMais dès qu'on franchit la frontière du « j'utilise ça sur mes propres machines avec mon propre dépôt », les manques se font sentir : pas de vérification d'intégrité, pas de gestion d'erreur réseau, pas d'option de récupération. Dans un contexte d'équipe ou de production, ces points sont bloquants.\r\n\r\nPistes d'évolution prioritaires\r\n\r\n1. Signature ou checksum : publier un signé GPG, le vérifier avant tout ou exécution.\r\n2. en tête de script pour faire échouer proprement à la première erreur.\r\n3. Vérifier : code de retour, fichier non vide, shebang présent.\r\n4. Backup avant écrasement : conserver la version précédente () pour pouvoir revenir en arrière.\r\n5. Option pour visualiser sans appliquer.\r\n6. Filtre regex sur les noms de fichiers du manifeste pour éviter les traversées de chemin.\r\n7. Lock file** via pour éviter les exécutions concurrentes.\r\n\r\nAvec ces ajouts, on passe d'un script « pratique » à un outil de déploiement digne de ce nom — sans rien perdre de sa simplicité initiale."}] |