varlog/_cache/similar/b0b0299b-835d-47f1-a377-f40198091548.json

[{"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."},{"uuid":"15c5486e-503e-4bdc-bd4b-97effa10899e","slug":"logout","title":"logout","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-02-20 07:56:43","created_at":"2023-02-20 07:56:43","updated_at":"2023-02-20 07:56:43","tags":[],"plain":"La commande  est une commande système qui permet de se déconnecter d'une session en cours sur un terminal ou une console. Lorsque vous exécutez la commande , le système met fin à votre session utilisateur en cours et ferme toutes les applications et processus en cours d'exécution associés à cette session. Vous serez alors retourné à l'écran de connexion ou de l'invite de commande, selon le système d'exploitation que vous utilisez. Notez que la commande  ne ferme pas la session du système d'exploitation lui-même. Si vous voulez arrêter complètement votre système, vous devriez utiliser la commande shutdown ou poweroff selon le système d'exploitation que vous utilisez."},{"uuid":"8f4754f5-be07-46bd-8e21-a3ac92cd4994","slug":"parametrer-raspbian","title":"Paramétrer Raspberry Pi OS","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-02-02 14:11:51","created_at":"2023-02-02 14:11:51","updated_at":"2023-02-02 14:11:51","tags":[],"plain":"J'ai déployé l'image de Raspbian sur la carte microSD :  Je démarre le Raspberry Pi sans écran ni clavier. Je vais procéder au paramétrage basique du Raspberry Pi. Configuration réseau\nRaspberry Pi OS utilise le service dhcpcd pour configurer toutes les interfaces réseau en TCP/IP. Ce service permet d'assigner pour chaque interface réseau une adresse IP, masque sous-réseau et passerelle, et la configuration de la résolution DNS.  Par défaut, Raspberry Pi OS essaie de configurer le réseau automatiquement par DHCP, et en cas d'échec il assigne une adresse IP privée dans la plage 169.254.0.0/16.  Il est possible de désactiver la configuration automatique pour l'une des interface réseau et de la signer de manière statique en modifiant le fichier . Par exemple :   Configurer les langues\nLors d'une première installation du paquet locales sous Raspbian, les fichiers de définition des paramètres régionaux ne sont pas générées proprement ou sont fixés sur une valeur incorrectes. Il suffit de reconfigurer le paquet pour que tout rentre dans l'ordre. Ce menu à pour but la création des définitions des paramètres régionaux dans le fichier  et positionner la variable LANG (et uniquement celle-ci). Il est également possible d’enchaîner les commandes suivantes : Voir l'article  Configurer la Timezone\nCréer un administrateur On ajoute tous les droits en lui affectant les groupes suivants :   sudo usermod -a -G adm,dialout,cdrom,sudo,audio,video,plugdev,games,users,input,netdev,gpio,i2c,spi cedric On s'identifie avec le compte , fraîchement créé. Une fois terminé, on peut redémarrer :\n  sudo shutdown -r Suppression du compte Pi\n  sudo deluser -remove-home pi Connexion par clé SSH\nSe connecter avec le compte utilisateur sur le Raspberry Pi :\n  ssh cedric@raspberrypi.acegrp.lan Créer le dossier  de l’utilisateur : \n  mkdir .ssh Retour sur votre poste de connexion / votre ordinateur. Lister les clés actuelles : Créer une nouvelle clé privée et publique. Si vous souhaiter utiliser clé existante, passez cette étape.\n  Copier la clé publique vers le Raspberry Pi Se connecter avec la clé SSH Configurer l’accès ssh à Pi\n1. Dans le fichier , option à activer : 2. Redémarrer le service ssh : Changer le hostname\nJe souhaite modifier le nom de l'ordinateur, fixé par défaut sur , par la valeur . 1. Il y a deux possibilités a/ Modifier le fichier  avec le nom souhaité b/ Exécuter la commande  [^note:  hmike sur Twitter <https:​twitter.com/​whiterabbit441/​status/​1226116907306078208> //] 2. Modifier le nom dans le fichier  3. Redémarrer Raspbian Liens\nUn assistant existe pour la configuration de Raspbian, il s'agit du programme . Suivant la version du Raspberry Pi, vous avez le choix dans les menus :\nLa version est Raspberry Pi 3+, accéder au paramétrage raspi-config pour RaspberryPi 3+.\nLa version est Raspberry Pi 3, accéder au \nLa version est Raspberry Pi 2, accéder au \nLa version est Raspberry Pi 1/1+, accéder au  À suivre"},{"uuid":"093711bf-4e60-4ea8-ba73-928d2d67776c","slug":"certificats-let-s-encrypt-a-6-jours-faut-il-sauter-le-pas","title":"Certificats Let's Encrypt à 6 jours : faut-il sauter le pas ?","category":"actualité","author":"cedric@abonnel.fr","cover":"cover.svg","published":true,"published_at":"2026-05-07 22:46","created_at":"2026-05-12 08:47:27","updated_at":"2026-05-12 08:59:58","tags":[],"plain":"Guide DevOps / WebOps pour comprendre les certificats à durée de vie courte () et décider si vous devez migrer.\r\n--\r\n\r\nTL;DR\r\n\r\nLet's Encrypt propose désormais au grand public des certificats valides 6 jours (profil ), en plus du classique 90 jours. Pour les certificats sur adresse IP, c'est même obligatoire. La question n'est pas \"est-ce que c'est bien ?\" — techniquement oui — mais \"est-ce que mon infra est prête ?\". Si votre renouvellement automatique fonctionne sans accroc depuis 6 mois, foncez. Sinon, fiabilisez d'abord, migrez ensuite.\r\n--\r\n\r\n1. De quoi on parle\r\n\r\nDepuis janvier 2026, Let's Encrypt émet en disponibilité générale deux nouveautés couplées : les certificats pour adresses IP, et les certificats à durée de vie de 6 jours via un nouveau profil ACME nommé . Certbot 4.0 a introduit le flag  pour les sélectionner, et Certbot 5.3 a ajouté  pour demander un cert sur IP.\r\n\r\nConcrètement, un certificat  a une validité de 6 jours au lieu de 90. Tout le reste — chaîne de confiance, algorithmes, format — est identique. Pour le navigateur, c'est un certificat Let's Encrypt standard.\r\n\r\nLes profils disponibles\r\nProfil | Durée | Usage |\r\n---|---|---|\r\n(défaut) | 90 jours | Tout le monde, par défaut |\r\n| 6 jours | Adopters précoces, certs sur IP (obligatoire) |\r\n| 90 jours | Variante optimisée serveur web (sans clientAuth) |\r\n--\r\n\r\n2. Pourquoi Let's Encrypt pousse vers le court\r\n\r\nQuatre raisons techniques, par ordre d'importance.\r\n\r\n2.1 La révocation TLS est cassée — autant l'éviter\r\n\r\nC'est le vrai sujet. Le mécanisme de révocation des certificats (CRL, OCSP) n'a jamais fonctionné correctement à grande échelle :\r\nOCSP soft-fail : si le serveur OCSP est injoignable, la plupart des navigateurs acceptent quand même le certificat. Un attaquant qui contrôle le réseau bloque l'OCSP et le cert révoqué passe.\r\nOCSP stapling mal configuré sur beaucoup de serveurs.\r\nCRLite, OneCRL : couvertures partielles, déploiement client incohérent.\r\nOCSP retiré : Let's Encrypt a arrêté OCSP en 2025, justement parce que ça ne servait quasiment à rien tout en posant des problèmes de vie privée.\r\n\r\nAvec un cert à 6 jours, la révocation devient cosmétique : on attend l'expiration. La fenêtre d'exploitation d'une clé compromise passe de plusieurs semaines (cert 90 jours, OCSP douteux) à quelques jours maximum.\r\n\r\n2.2 Réduire la fenêtre de compromission\r\n\r\nSi votre clé privée fuite (backup mal protégé, faille serveur, employé qui part avec une copie, vulnérabilité type Heartbleed), l'attaquant peut usurper votre site tant que le cert est valide. À 90 jours, c'est trois mois d'exposition dans le pire cas. À 6 jours, c'est une semaine.\r\n\r\nC'est encore plus critique pour les certs sur IP : une IP peut changer de propriétaire (cloud, VPS recyclé, réattribution FAI). Un cert long pour une IP qui ne vous appartient plus, c'est un risque que LE refuse de prendre — d'où l'obligation du profil court pour cet usage.\r\n\r\n2.3 Forcer une automatisation propre\r\n\r\nPersonne ne renouvelle un cert à la main tous les 6 jours. C'est mécaniquement infaisable. Le profil  est donc un filtre qualité : si votre renouvellement n'est pas blindé, vous le saurez vite.\r\n\r\nL'effet de bord positif : ça élimine les pannes classiques type \"le cert a expiré parce que le cron était cassé depuis trois mois et personne ne s'en est rendu compte\". À 6 jours, un cron cassé devient visible immédiatement.\r\n\r\n2.4 Agilité cryptographique\r\n\r\nSi une vulnérabilité majeure impose de déprécier un algorithme en urgence (RSA, transition post-quantique, faille découverte sur SHA-256), un parc avec des certs à 6 jours bascule en une semaine. Un parc 90 jours met trois mois. C'est la raison qui motive aussi le CA/Browser Forum à pousser globalement vers des durées plus courtes (45 jours d'ici 2029 dans la baseline).\r\n--\r\n\r\n3. Pourquoi vous pourriez ne pas migrer\r\n\r\nSoyons honnêtes : pour la plupart des infras web classiques, le 90 jours suffit largement. Le 6 jours a des coûts réels.\r\n\r\n3.1 Pression sur le rate limiting\r\n\r\nLet's Encrypt limite à 300 nouveaux certificats par compte par 3 heures et 5 duplicatas de cert par semaine. Avec des certs 90 jours, vous renouvelez 4 fois par an. Avec des 6 jours, c'est 60 fois par an et par cert. Si vous avez 50 services derrière 50 certs distincts, vous explosez votre budget de requêtes ACME.\r\n\r\nMitigation : regrouper les domaines dans des certs SAN (un seul cert pour , ,  plutôt que trois certs).\r\n\r\n3.2 Dépendance critique au CA et au réseau\r\n\r\nÀ 90 jours, si Let's Encrypt est down 48h, vous ne le remarquez même pas. À 6 jours, une panne de 48h sur LE et votre fenêtre de renouvellement (typiquement à 1/3 de la durée restante, soit 2 jours), et votre cert expire. Vos services tombent.\r\n\r\nConséquences concrètes :\r\nIl faut un monitoring sérieux de l'expiration des certs (Prometheus blackbox exporter, , etc.).\r\nIl faut un fallback : second client ACME, second account, ou cert de secours d'une autre CA.\r\nIl faut absolument que la résolution DNS et le port 80/443 sortants depuis votre serveur soient fiables.\r\n\r\n3.3 Charge sur les systèmes de déploiement\r\n\r\nChaque renouvellement déclenche : appel ACME, validation HTTP-01 ou DNS-01, écriture des fichiers, rechargement du serveur web (Nginx, Apache, HAProxy, etc.). À 60 fois par an au lieu de 4, ça multiplie par 15 le nombre de reloads.\r\n\r\nSur un serveur web basique, un  est gratuit. Sur des architectures plus complexes (load balancers stateful, terminations TLS distribuées, certs poussés vers un CDN, configs multi-nœuds avec Ansible/Salt), chaque renouvellement déclenche une cascade. À évaluer.\r\n\r\n3.4 Logs, audit, conformité\r\n\r\nCertains contextes réglementaires demandent une traçabilité des certificats (PCI-DSS, ISO 27001, HDS). Multiplier par 15 le volume d'événements de renouvellement à archiver et auditer, ça représente du stockage et du tooling à adapter.\r\n\r\n3.5 Le cas \"monitoring TLS externe\"\r\n\r\nSi vous avez des outils tiers (uptime monitors, scanners de conformité) qui vérifient l'expiration de vos certs, ils risquent de hurler en permanence : un cert qui montre toujours \"expire dans 6 jours\" déclenche les alertes \"cert expirant bientôt\" sur la plupart des outils mal configurés. Il faut soit ajuster les seuils, soit changer d'outil.\r\n--\r\n\r\n4. Décision : grille de lecture\r\nSituation | Recommandation |\r\n---|---|\r\nServeurs web classiques, renouvellement Certbot qui marche, < 20 certs | Restez en 90 jours. Le bénéfice marginal ne justifie pas le risque. |\r\nVous gérez des certs sur IP | Pas le choix :  est obligatoire. |\r\nArchitecture critique avec rotation de clés agressive (banque, santé, infra publique) | Migrez. Le 6 jours est aligné avec vos exigences de sécurité. |\r\nInfra dev/staging interne | Excellent terrain de test. Migrez d'abord ici pour valider votre pipeline. |\r\nVous avez déjà eu une expiration cert non détectée en prod | Ne migrez pas tout de suite. Fiabilisez d'abord le monitoring et le renouvellement, puis migrez. Sinon vous transformez un incident annuel en incident hebdomadaire. |\r\nVous publiez via reverse proxy unique (un seul cert SAN pour plusieurs services) | Bon candidat. Un seul renouvellement à fiabiliser. |\r\nVous avez un parc hétérogène (Apache + Nginx + HAProxy + Traefik...) avec hooks custom | Auditez chaque hook avant de migrer. C'est là que ça casse. |\r\n--\r\n\r\n5. Comment migrer concrètement (Certbot)\r\n\r\n5.1 Pré-requis\r\n\r\nAvant tout :\r\n\r\n1. Certbot 4.0+ pour , 5.3+ pour , 5.4+ pour  avec IP.\r\n2. Un renouvellement automatique opérationnel et vérifié (timer systemd ou cron actif, testé avec ).\r\n3. Un monitoring d'expiration des certs en place. Si vous n'en avez pas, installez-le avant de migrer.\r\n4. Un hook de reload du serveur web qui fonctionne ().\r\n\r\n5.2 Test sur le staging Let's Encrypt\r\n\r\n\r\n\r\nVérifier que le cert obtenu a bien une durée de 6 jours :\r\n\r\n\r\n\r\n5.3 Renouvellement plus fréquent\r\n\r\nPar défaut, Certbot renouvelle quand il reste 1/3 de la durée. Pour un cert 6 jours, ça veut dire renouveler à 2 jours restants. Ça laisse peu de marge en cas de panne. Vous pouvez forcer un renouvellement plus tôt :\r\n\r\n\r\n\r\nLe timer Certbot tourne deux fois par jour par défaut, ce qui est suffisant. Pas besoin de l'accélérer.\r\n\r\n5.4 Cas d'un certificat sur IP\r\n\r\n\r\n\r\nNote importante : Certbot ne sait pas encore installer automatiquement les certs IP dans Nginx ou Apache. Il faut éditer la config manuellement pour pointer vers  et , et configurer un  pour le reload.\r\n\r\n5.5 Plan de bascule recommandé\r\n\r\n1. Semaine 1-2 : un domaine non critique (un sous-domaine de test, un service interne) en . Surveillez les renouvellements.\r\n2. Semaine 3-4 : étendez à la moitié de votre dev/staging.\r\n3. Semaine 5-6 : migration progressive en prod, en commençant par les services les moins critiques.\r\n4. À tout moment : possibilité de retour arrière en supprimant  du fichier de config Certbot dans .\r\n--\r\n\r\n6. Pièges à éviter\r\nNe migrez pas tout en même temps. Si votre hook de reload a un bug, vous le découvrez sur un seul service, pas sur 50.\r\nNe désactivez pas le monitoring d'expiration sous prétexte que c'est automatisé. L'automatisation peut casser silencieusement. Un check externe qui hurle à J-2 reste indispensable.\r\nAttention aux secrets stockés dans des configs autres que Certbot. Si vous avez des certs poussés manuellement vers un CDN, un load balancer cloud ou un firewall TLS-inspectant, le passage à 6 jours impose d'automatiser cette propagation aussi.\r\nPas de cert IP pour un service exposé publiquement à long terme. Si l'IP change, le cert devient inutilisable instantanément. Préférez le DNS quand c'est possible.\r\nVérifiez votre client ACME. Tous les clients ACME ne supportent pas encore les profils. acme.sh, Caddy, lego, Traefik : checkez la version. Certbot 4.0 minimum.\r\n--\r\n\r\n7. Verdict\r\n\r\nLe profil  est techniquement supérieur au 90 jours sur le plan sécuritaire. Mais il déplace le coût : moins de risques liés aux clés compromises et à la révocation cassée, plus de risques liés à la chaîne de renouvellement.\r\n\r\nLa règle simple : si votre renouvellement automatique est fiable, migrez. Sinon, fiabilisez-le d'abord — la migration n'en sera que la conséquence naturelle.\r\n\r\nPour la majorité des infras web auto-hébergées (typiquement, un Proxmox + reverse proxy + une dizaine de services derrière), le 90 jours reste un excellent compromis. Le  devient pertinent quand :\r\nVous avez besoin de certs sur IP (obligatoire).\r\nVous exploitez des services à forte exigence de sécurité (clés très sensibles).\r\nVous voulez tester votre résilience opérationnelle (le 6 jours est un excellent test de fiabilité de votre stack).\r\n\r\nLe reste du temps, gardez le 90 jours, dormez tranquille, et ressortez ce document quand le CA/Browser Forum imposera 45 jours par défaut (vers 2027-2028).\r\n--\r\n\r\nSources\r\nLet's Encrypt — Six-Day and IP Address Certificates Available in Certbot (mars 2026)\r\nLet's Encrypt — 6-day and IP address certs in general availability (janvier 2026)\r\nDocumentation Certbot — Hooks\r\nCA/Browser Forum Baseline Requirements"},{"uuid":"357b1e51-4768-494e-a3ec-10c6e145d12e","slug":"2024-07-04-raspberry-pi-os-update","title":"Mise à Jour de Raspberry Pi OS (2024-07-04)","category":"Journal geek","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2024-07-05 17:17:47","created_at":"2024-07-05 17:17:47","updated_at":"2024-07-05 17:17:47","tags":[],"plain":"La Fondation Raspberry Pi a fait sensation aujourd'hui en dévoilant une nouvelle mise à jour de leur système d'exploitation phare, Raspberry Pi OS. Basé sur Debian, ce système est le cœur des ordinateurs monocarte Raspberry Pi, utilisés par des millions de passionnés et professionnels à travers le monde. La version 2024-07-04 apporte une foule d'améliorations et de nouvelles fonctionnalités qui raviront les utilisateurs. Des Améliorations de l'Interface Utilisateur\nParmi les nouveautés les plus marquantes, on trouve une mise à jour du panneau et du gestionnaire de fichiers PCManFM, désormais capable de gérer plus de deux bureaux. Cette flexibilité accrue permet aux utilisateurs de personnaliser leur environnement de travail de manière encore plus poussée. En parallèle, le panneau intègre désormais la possibilité de personnaliser le compositeur de fenêtres Wayland labwc, qui est maintenant installé par défaut comme alternative à Wayfire. Les utilisateurs peuvent sélectionner labwc comme compositeur Wayland par défaut via l'outil raspi-config, rendant la configuration de leur interface plus accessible. Nouvelles Fonctionnalités dans raspi-config\nL'outil de configuration raspi-config n'est pas en reste avec cette mise à jour. Il prend désormais en charge les options de configuration du clavier et la vitesse PCIe. De plus, l'assistant de démarrage piwiz a été amélioré pour permettre l'activation ou la désactivation de Raspberry Pi Connect, une nouvelle fonctionnalité de support à distance intégrée également à l'installateur de logiciels recommandés et aux utilitaires rc-gui. Support et Compatibilité Étendus\nRaspberry Pi OS 2024-07-04 intègre également des mises à jour pour raspberrypi-ui-mods, notamment la prise en charge des nouveaux écrans tactiles et le support de systemd-inhibit pour la gestion du bouton d'alimentation matériel sur le Raspberry Pi 5. Les modifications apportées à raspberrypi-sys-mods incluent une nouvelle règle udev pour permettre aux utilisateurs de modifier le rétroéclairage et d'augmenter la taille du fichier d'échange. Correctifs et Optimisations\nCette version apporte des correctifs significatifs, notamment pour le compositeur Wayfire Wayland qui a été patché pour éviter les crashs lors de l'ouverture de multiples fenêtres Xwayland et résoudre un bug d'écran tactile. Le gestionnaire de fichiers PCManFM a également été corrigé pour éviter les crashs pendant certaines opérations de glisser-déposer. Nouvelles Capacités pour les Développeurs et Utilisateurs Avancés\nL'installateur gui-pkinst propose maintenant un support de liste blanche pour restreindre l'installation à certains packages spécifiés. L'outil pishutdown utilise la commande pkill pour fermer le bureau, et le serveur VNC WayVNC améliore la gestion des écrans virtuels et le chiffrement. Téléchargement et Disponibilité\nRaspberry Pi OS 2024-07-04 est alimenté par le noyau Linux 6.6.31 LTS et est livré avec les dernières versions des navigateurs web Chromium (125.0.6422.133) et Mozilla Firefox (126.0). Cette mise à jour est disponible dès maintenant via l'utilitaire Raspberry Pi Imager et peut également être téléchargée sur le site officiel de la Fondation Raspberry Pi. Que vous soyez un utilisateur débutant ou un expert en Raspberry Pi, cette mise à jour promet d'améliorer votre expérience et d'ouvrir de nouvelles possibilités pour vos projets. Ne manquez pas de l'essayer dès aujourd'hui !"}]