[{"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":"3b29ea92-6163-433f-9fe0-cfa037c56183","slug":"nat-forwarding","title":"Créer un réseau virtuel pour les machines virtuelles","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2021-02-21 20:51:46","created_at":"2021-02-21 20:51:46","updated_at":"2021-02-21 20:51:46","tags":[],"plain":"La carte virtuelle vibr0 doit être installée sur la machine pour faire le pont entre les machines virtuelles et le réseau hôte.\n-- La carte virtuelle est fournie par le programme virsh. vous pouvez vérifiez sa disponibilité avec la commande suivante : Résultat Si ce n'est pas le cas, voici quelques commandes pour vous en sortir.\n-- Résultat\n-- Récupération de la configuration XML et activation\n--\n--\nNouvelles vérifications : Résultat\n-- Exemple de résultat : Biblio\nhttps://wiki.libvirt.org/page/Networking"},{"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":"c5119921-464f-41ed-8433-b5aec8db3af7","slug":"cle-wifi-linux","title":"Wifi pour Linux en 2024","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2024-01-14 06:50:08","created_at":"2024-01-14 06:50:08","updated_at":"2024-01-14 06:50:08","tags":[],"plain":"Il y a des cartes Wifi qui sont mieux supportées par Linux, souvent dues à la compatibilité de leurs chipsets avec les drivers disponibles dans les distributions Linux. En général, les cartes Wifi n'ont pas de problèmes de compatibilité majeurs avec Linux, car la plupart utilisent des standards de communication bien établis. Cependant, certaines fonctionnalités spécifiques, des performances optimales ou la compatibilité de la carte Wifi peuvent dépendre du support du chipset par le noyau Linux. Les pilotes intégrés au noyau de Linux sont préférables aux pilotes externes au noyau pour la plupart des utilisateurs et des cas d'utilisation Ce qu'il faut chercher :\nCompatibilité avec le noyau Linux : Certains chipsets sont mieux pris en charge que d'autres. Les chipsets les plus courants comme ceux de SanDisk, Kingston, et Toshiba tendent à avoir un bon support.\nDocumentation du fabricant : Certains fabricants indiquent explicitement la compatibilité avec Linux ou fournissent des pilotes pour certaines distributions.\nPour les clés USB, normes USB : USB 2.0, USB 3.0, USB 3.1, etc. La prise en charge des différentes normes par votre système Linux peut influencer les performances.\nCommunauté Linux : Les forums et les sites dédiés à Linux sont de bonnes ressources pour trouver des avis sur la compatibilité des différents modèles de clés USB. Les informations ci-dessous peuvent nécessiter une familiarité avec le terminal et les commandes de base Linux. Quelques adresses :\nLes adaptateurs WiFi USB pris en charge par les pilotes Linux intégrés au noyau.\nBest USB WiFi Adapters for Linux (Review) in 2022 Quelques références\nBrosTrend AC3L Linux WiFi Adapter\nBrosTrend Linux USB Clé WiFi Adaptateurs, PC avec Ubuntu, Mint, Debian, Kali, Raspbian, Lubuntu, Xubuntu, Mate, Zorin, Raspberry Pi 2+, Windows11, 1200Mbps, Longue Portée 2 X 5dBi External Antennas La BrosTrend 1200Mbps USB WiFi Adapter est conçue pour offrir une connectivité réseau à haute vitesse et une meilleure portée grâce à ses deux antennes externes 5dBi. Voici quelques infos pour installer et configurer l'adaptateur sur un système Linux. Pour l'installation de la clé BrosTrend AC3L Linux WiFi Adapter sous Linux, les noyaux Linux (>= 6.2) incluent leurs propres pilotes, ce qui permet leur fonctionnement immédiat dans les distributions récentes.\nPour connaître la version de votre noyau, exécutez la commande . Les pilotes livrés avec le noyau ne sont pas encore aussi aboutis que ceux de BrosTrend, donc si vous rencontrez des problèmes, utilisez leur installateur pour les remplacer. Le processus d'installation nécessite une connexion Internet initiale :\n  sh -c 'wget linux.brostrend.com/install -O /tmp/install && sh /tmp/install' Pour toute assistance ou en cas de problème, la communauté Linux et le support de BrosTrend sont à votre disposition pour vous guider. Support et Documentation: Consultez la documentation de BrosTrend pour des problèmes spécifiques à l'adaptateur. https:linux.brostrend.com/ Antennes Externes: Assurez-vous que les antennes sont correctement connectées et orientées pour une meilleure réception. TP-Link TL-WN823N\nTP-Link Clé WiFi Puissante N300 Mbps, mini adaptateur USB wifi, dongle wifi, Bouton WPS, compatible avec Windows 11/10/8.1/8/7/XP, Mac OS X 10.9-10.13, Linux , Noir, TL-WN823N Le TP-Link TL-WN823N est un mini adaptateur USB WiFi offrant une vitesse allant jusqu'à 300 Mbps, idéal pour les jeux en ligne ou le streaming vidéo HD. Compatible avec une multitude de systèmes d'exploitation, son installation sous Linux peut varier en fonction de la distribution utilisée. Installer le TP-Link TL-WN823N sous Linux peut nécessiter un peu de travail en ligne de commande, mais une fois configuré, il offre une connexion stable et rapide. Assurez-vous de suivre les étapes spécifiques à votre distribution <https:static.tp-link.com/2018/201812/20181207/Installation%20Guide%20for%20Linux.pdf> ou . Consulter la communauté Linux pour obtenir de l'aide en cas de problème. Support et Documentation: La documentation officielle peut offrir des conseils supplémentaires spécifiques à votre modèle. https:www.tp-link.com/fr/support/download/tl-wn823n/ Bouton WPS: Si votre routeur a un bouton WPS, vous pouvez l'utiliser pour une connexion facile. BrosTrend AX4L et AX1L\nAX1800 Clé WiFi 6 USB Linux\nAX1800 Clé WiFi 6 USB Longue Portée Linux La BrosTrend AX4L, avec sa capacité de 1800 Mbps et l'intégration de la technologie WiFi 6, se distingue par sa performance en termes de vitesse et de portée, grâce notamment à ses antennes externes qui améliorent la qualité et la stabilité du signal sur de longues distances. Cela la rend particulièrement adaptée pour des utilisateurs recherchant une connexion réseau rapide et fiable, que ce soit pour du streaming de contenu en haute définition, des jeux en ligne, ou tout autre activité nécessitant une bande passante élevée. En revanche, la AX1L, sans antennes externes, pourrait être plus adaptée pour des usages standards avec une préférence pour un design plus compact et discret. Chacun de ces modèles a donc ses avantages spécifiques, à considérer en fonction des besoins et de l'environnement d'utilisation. Systèmes d'exploitation pris en charge sous Linux : Compatible avec les kernels jusqu'à la version 6.5, y compris Ubuntu de la version 16.04 à la 23.10 (toutes variantes), Raspberry Pi OS, Debian de la version 8 à la 12, Linux Mint de la version 18 à la 21, LMDE de la version 1 à la 6, ainsi que Pop!OS, Zorin, MX Linux, Linux Lite, elementary OS et bien d'autres. Le processus d'installation nécessite une connexion Internet initiale et peut nécessiter une familiarité avec le terminal et les commandes de base :\n  sh -c 'wget linux.brostrend.com/install -O /tmp/install && sh /tmp/install' <note important>Distributions Linux Non Supportées : Actuellement NON compatible avec Kali Linux, deepin, RHEL, CentOS, openSUSE Leap, OpenWrt, Guix, Puppy, Tails, Endless OS, LibreELEC, OSMC, SteamOS.</note>  Il est important de noter que, en raison des contraintes liées à certaines versions de Linux, j'ai des réserves concernant le choix des modèles AX1L et AX4L de la gamme BrosTrend. Ces modèles ne sont pas compatibles avec certaines distributions Linux, ce qui peut limiter l'accès aux avancées en matière de connectivité réseau, telles que le WiFi 6, connu pour sa vitesse et son efficacité accrues. Il est donc crucial de vérifier attentivement la compatibilité matérielle et logicielle lors de la sélection d'adaptateurs WiFi pour des systèmes spécifiques, afin de garantir une expérience utilisateur optimale. Support et Documentation: Consultez la documentation de BrosTrend pour des problèmes spécifiques à l'adaptateur. https:linux.brostrend.com/ Étapes d'installation génériques\n0. Prérequis\nSystème Linux: Assurez-vous que votre système est à jour.\nPermissions: Droits d'administrateur pour l'installation des paquets.\nInformation du système: Connaître le type de kernel et la version du système. 1. Connexion de l'adaptateur Branchez la clé USB Wifi sur un port USB disponible de votre ordinateur. 2. Vérification de la reconnaissance de l'appareil Ouvrez le terminal et tapez la commande suivante pour vérifier si le système reconnaît l'adaptateur: Recherchez une entrée correspondant à votre clé USB Wifi ou à l'ID de l'appareil. 3. Installation des dépendances Avant d'installer le pilote, vous devrez peut-être installer des paquets prérequis tels que build-essential et linux-headers. Utilisez le gestionnaire de paquets de votre distribution pour les installer. 4. Téléchargement et installation du pilote Rendez-vous sur le site officiel du constructeur et téléchargez le pilote correspondant à votre modèle et à la version de votre kernel. Décompressez l'archive et lisez le fichier README pour les instructions spécifiques.  En général, les étapes suivantes sont requises: 1. Naviguez dans le dossier du pilote décompressé.\n1. Compilez et installez le pilote à l'aide des commandes make et make install. 5. Chargement du module du pilote Après l'installation, chargez le module du pilote en utilisant la commande: 6. Configuration de la connexion WiFi Vous pouvez utiliser l'interface graphique de gestion réseau de votre distribution ou la commande  pour configurer votre réseau sans fil. <u>Dépannage et support**</u> Consultez les forums: Les forums Linux spécifiques à votre distribution sont une excellente ressource pour obtenir de l'aide. {{page>AC650 11ac Dual-Band Wireless USB Adapter}}"},{"uuid":"a150a0d3-caac-4d1f-915d-8d3c35624df1","slug":"postfix","title":"PostFix : serveur de messagerie sous Linux","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-12-29 17:29:08","created_at":"2023-12-29 17:29:08","updated_at":"2023-12-29 17:29:08","tags":[],"plain":"Cet article est destiné aux débutants qui veulent configurer un serveur de messagerie électronique de base. Il est préférable d'avoir une connaissance élémentaire en administration système, ainsi que la capacité d'installer des logiciels et de modifier des fichiers de configuration. L'article a été rédigé en se basant sur Debian 11, mais les instructions devraient également convenir aux autres versions. Veuillez noter que des différences peuvent exister dans les autres versions. Postfix est un logiciel de serveur de messagerie open source largement adopté. En tant que \"MTA\" (Agent de Transfert de Message), il joue un rôle central dans le traitement, la transmission et la distribution des courriels. Doté de fonctionnalités avancées en matière de sécurité, de filtrage et de personnalisation, Postfix est un choix prisé pour la gestion des systèmes de messagerie. <nav stacked=\"true\"  fade=\"true\"> </nav>\nIntroduction\nL'objectif fondamental de cette procédure est de permettre à n'importe quelle machine ou serveur d'envoyer des courriels vers une adresse spécifique. Pour y parvenir, il est nécessaire de préparer le courrier électronique à l'aide d'un programme externe, puis de le transmettre efficacement au serveur de messagerie de destination en utilisant le protocole SMTP (Simple Mail Transfer Protocol). Le processus de l'envoi de courriel via SMTP s'articule comme suit, prenons un exemple concret avec un courriel destiné à l'adresse alice@example.com : 1. L'utilisateur ou un programme externe crée le courrier électronique, en spécifiant les informations du destinataire (alice@example.com), en rédigeant le contenu du message et en incluant d'autres détails nécessaires. 2. Le courriel est ensuite remis au serveur SMTP local, qui se trouve sur la machine ou le serveur à partir duquel l'envoi est effectué. 3. Le serveur SMTP analyse le domaine du destinataire (dans ce cas, \"example.com\") pour déterminer comment atteindre le serveur de messagerie de destination. 4. Le serveur SMTP établit un contact avec le serveur de messagerie de destination (le serveur SMTP de \"example.com\" dans cet exemple) en utilisant le protocole SMTP. 5. Le serveur de messagerie de destination accepte le courriel, le stocke temporairement, puis le transfère éventuellement dans la boîte aux lettres de l'utilisateur Alice, située sur son propre serveur de messagerie. 6. Si tout se déroule sans problème, le courriel est ainsi livré avec succès à Alice, qui peut alors le consulter dans sa boîte de réception. Ce processus est la façon dont le protocole SMTP assure la transmission de courriels, encheminant ces derniers de l'expéditeur au destinataire, en utilisant les serveurs de messagerie appropriés à travers Internet.\nAxe de travail\nIl existe de nombreuses configurations et combinaisons différentes possibles lors de la mise en place d'un serveur de messagerie électronique, bien trop nombreuses pour être toutes couvertes ici. Par conséquent, cet article effectue certaines choix fondamentaux pour vous, tels que les logiciels que nous allons utiliser (Postfix et Dovecot). D'autres options nécessiteront des modifications de la part de l'utilisateur, comme les adresses réseau et les noms de domaine. Les paramètres plus avancés, comme la gestion de domaines virtuels et des utilisateurs, ne sont pas abordés dans cet article et ne seront pas traités ici. Dans ce contexte, nous utilisons Postfix comme agent de transfert de messagerie (MTA). Dovecot est utilisé pour permettre aux utilisateurs d'accéder à leur courrier électronique via les protocoles IMAP ou POP. Nous partons du principe que le nom de domaine utilisé est example.com, mais cela devrait être adapté par le lecteur. Vous pouvez utiliser un véritable nom de domaine pour un serveur de messagerie pleinement qualifié ou un faux nom de domaine si vous souhaitez uniquement créer un serveur de messagerie interne. Notre exemple suppose que le serveur de messagerie physique (hôte) porte le nom mail.example.com et est situé à l'adresse IP privée 192.168.0.1 (veuillez personnaliser ces informations en fonction de vos besoins). Le serveur de messagerie fournira des comptes de messagerie basés sur les comptes système d'utilisateurs standards, et les utilisateurs accéderont à leur courrier en utilisant leur nom d'utilisateur et leur mot de passe de compte système. Nous illustrons cela avec un utilisateur nommé John Smith, qui dispose d'un compte système avec le nom d'utilisateur john.\nServeurs SMTP\nSous Linux Debian, il existe plusieurs programmes d'envoi de courriels, chacun avec ses propres fonctionnalités et avantages. Voici quelques-uns des programmes les plus couramment utilisés pour envoyer des courriels sous Debian : 1. ssmtp: Simple SMTP est un programme léger qui permet d'envoyer des courriels via SMTP. Il est particulièrement adapté aux tâches d'envoi de courriels automatisées et ne prend pas en charge la réception de courriels. 2. msmtp: MSMTP est un autre client SMTP léger qui facilite l'envoi de courriels depuis la ligne de commande ou depuis des scripts. Il peut être configuré pour transmettre des courriels à travers un serveur SMTP externe. 3. Postfix: Bien que Postfix soit principalement un serveur de messagerie, il peut également être utilisé pour envoyer des courriels depuis une machine Debian. Il offre une grande flexibilité en matière de configuration, mais sa configuration peut être plus complexe que celle des clients SMTP plus simples. 4. sendmail: Sendmail est un programme de messagerie historique sous Unix/Linux, bien qu'il soit maintenant souvent remplacé par des alternatives plus modernes. Cependant, il est toujours disponible sur Debian et peut être utilisé pour envoyer des courriels. 5. Exim: Exim est un autre serveur de messagerie qui peut être configuré pour envoyer des courriels. Il est également capable de gérer la réception de courriels, ce qui en fait une option plus complète. Le choix du programme d'envoi de courriels dépendra de vos besoins spécifiques, de votre niveau de confort avec la configuration et de la complexité de votre infrastructure de messagerie. Pour des tâches simples d'envoi de courriels depuis la ligne de commande ou depuis des scripts, ssmtp ou msmtp sont souvent des choix pratiques. Pour des besoins plus avancés, Postfix ou Exim peuvent être mieux adaptés.\nInstaller Postfix\nPour installer Postfix sur Debian, vous devez utiliser le gestionnaire de paquets APT (Advanced Package Tool). Voici comment vous pouvez procéder : La première commande  met à jour la liste des paquets disponibles dans les dépôts Debian, et la deuxième commande \"apt install\" installe Postfix ainsi que ces dépendances. Choisir  Entrer la valeur FQDN de votre adresse de serveur si vous devez relancer la configuration de Postfix\n  sudo dpkg-reconfigure postfix\n  \nPour supprimer Sendmail, vous pouvez utiliser la commande suivante : Cette commande supprime le programme Sendmail de votre système Debian. Après avoir installé Postfix, vous devrez configurer ces logiciels pour les adapter à vos besoins spécifiques.\nConfigurer Postfix\nLes fichiers de configuration de postfix sont stockés dans /etc/postfix. Les deux principaux fichiers de configuration de postfix sont master.cf et main.cf, bien que nous ne traiterons que de main.cf ici. Tout d'abord, nous allons ajouter ou modifier certaines lignes dans le fichier de configuration main.cf. Les lignes suivantes doivent être ajoutées, modifiées ou décommentées :\nTests\nFaire un essai d'envoi de mail\n  echo \"Le contenu du mail\" | mail -s \"ceci est le sujet\" mail@domaine.tld Le programme mail est une composante du package mailutils. Donc, si le programme n'est pas installer sur la machine, utilisez \n- Pour modifier un paramètre dans Postfix, il faut éditer le fichier de configuration\n  sudo nano /etc/postfix/main.cf\n  \nRedémarrer le service\n  sudo systemctl restart postfix\n  \n   Gestion des Alias\nAjouter dans le fichier de configuration de Postfix,    virtualaliasmaps = hash:/etc/postfix/virtual\n  \nPuis ajouter dans le fichier  les alias désirés tel que le modèle suivant : Enfin, exécuter le bloc suivant. Il sera nécessaire de l’exécuter à chaque modifications effectuées du fichier .\n  sudo postmap /etc/postfix/virtual\n  sudo systemctl restart postfix Mails en attente\nPour connaître les mails en attente\n  sudo postqueue -p\n- Pour traiter tous les mails en attente\n  sudo postqueue -f\n- Pour supprimer tous les mails en attente\n  sudo postsuper -d ALL Reprise de la configuration de Postfix\nLe fichier de configuration de Postfix est . Il est éditable par nano ou vim. On va le reprendre pour configurer Postfix.\n--   myhostname = myserver.example.com Il est important que l'option  corresponde au FQDN (fully qualified domain name) du serveur. La valeur à renseigner et celle qui renvoyée par la commande :\n  nslookup 91.134.243.56\n|\n  \nDans l'exemple précédent, le serveur est noté dans le  Cette information est gérée par le serveur DNS Cette option se trouve les paramètres , chez kimsufi.com \n| Cette option, reverse DNS, se trouve dans les options du serveur VPS de vos serveurs dédiés, chez ovh.com\n|\n|\n-- Configurer le nom du serveur SMTP, domaine à afficher dans le courrier sortant   myorigin = example.com Configuer le nom du serveur SMTP    mydomain = example.com Configure to which SMTP domains to relay messages to, for example:   relaydomains = example.com\n-- Configuration minimaliste du SMTP Greeting Banner:   smtpdbanner = $myhostname\n-- Limiter les attaques par déni de services : Consulter le fichier log\nLe fichier log standard de postfix est  Vous pouvez garder un oeuil sur les logs\n  sudo tail -f /var/log/mail.info&\n  \n  \nEnvoyer un mail\nIl y a deux possibilités :\nenvoie depuis un client : mail\nconnexion en Telnet sur le serveur SMTP L'utilitaire mail fait parti de la suite mailutils\n  sudo apt install mailutils\n-- Utilisation de l'utilitaire mail depuis un poste client. Pour envoyer un mail à  de la part de \n  echo \"This is the message body\" | mail -s \"This is the subject\" mail@example.com -aFrom:sender@example.com\n  \nPour envoyer un mail à \n   echo \"This is the message body\" | mail -s \"Hello World\" username\n-- Utilisation de telnet pour se connecter sur le serveur SMTP    telnet mail.mymailserver.com 25\n  \nPuis saisir les commandes SMTP   EHLO checkeremail.com   MAIL FROM:<sender@mailserver.fr>   RCPT TO:<dest@mymailserver.com>   DATA\n  Subject: Sending an email using telnet\n  Hello,\n  Here is my body? Do you like it?\n  Cédric\n  .   QUIT Vider tous les mails\nVider tous les mails présents dans la boite d'un utilisateur. On considère que la boite mail (mbox) de l'utilisateur  se trouve dans le fichier    sudo sh -c \"> /var/mail/www-data\" Gestion des certificats\nPour configurer Postfix et Certbot pour utiliser les certificats SSL/TLS de \"smtp.monserveur.fr\" avec Let's Encrypt, suivez ces étapes générales. Assurez-vous d'avoir les droits nécessaires sur le serveur et que vous êtes à l'aise avec l'édition de fichiers de configuration en ligne de commande. Configurer Postfix pour utiliser SSL/TLS\n1. Accédez à la configuration de Postfix:\nConnectez-vous à votre serveur en tant que sudouser.\nOuvrez le fichier de configuration principal de Postfix avec un éditeur de texte, tel que  ou . Le fichier est généralement situé à . 2. Définissez les chemins des certificats:\nLocalisez ou ajoutez les lignes suivantes dans  pour spécifier l'emplacement des fichiers de certificat et de clé privée (remplacez les chemins par les vôtres si nécessaire) :\nActivez l'utilisation de TLS en ajoutant ou en s'assurant que la ligne suivante est présente : 3. Redémarrez Postfix:\nSauvegardez vos modifications et fermez le fichier.\nExécutez la commande  pour appliquer les modifications. Configurer Dovecot pour SSL/TLS\nSi vous utilisez Dovecot comme serveur IMAP/POP3 : 1. Les fichiers de configuration de Dovecot se trouvent généralement dans . Le fichier principal de configuration est souvent nommé , et il peut inclure d'autres fichiers de configuration situés dans . 2. Dans les fichiers de configuration de Dovecot, vous devrez trouver et modifier les lignes qui définissent le chemin du certificat SSL et de la clé privée. Recherchez quelque chose comme ceci : Pensez à désactiver la configuration présente dans . 3. Redémarrez Dovecot avec . 4. Après le redémarrage, assurez-vous que tout fonctionne comme prévu. Vous pouvez vérifier que Dovecot écoute avec le nouveau certificat en vous connectant avec un client de messagerie ou en utilisant OpenSSL : Configurer Let's Encrypt pour le renouvellement automatique\n1. Certbot gère généralement les renouvellements automatiquement. Cependant, vous pouvez personnaliser ou ajouter des scripts de renouvellement dans le dossier de hooks de renouvellement. 2. Scripts de renewal-hooks:\nPlacez les scripts personnalisés dans . Vous pouvez avoir des scripts , , et  pour s'exécuter avant, pendant, et après le renouvellement.\nUn script typique dans  pourrait redémarrer Postfix et Dovecot pour appliquer les nouveaux certificats. Voir les pages : \nSi vous avez deux scripts distincts,  et  et vous souhaitez exécuter les deux après le renouvellement de certificat Let's Encrypt par Certbot, vous pouvez configurer les hooks dans le fichier de configuration de renouvellement de Certbot ou les placer dans les répertoires de hook appropriés. Vous devriez ajouter des lignes pour posthook dans la section . Votre fichier pourrait ressembler à ceci : 3. Tester le renouvellement:\nExécutez  pour tester le processus de renouvellement et s'assurer que tout fonctionne comme prévu. Vérification et maintenance\nVérifiez les logs de Postfix et Dovecot pour les erreurs liées aux certificats SSL/TLS.\nAssurez-vous que les certificats se renouvellent correctement en vérifiant les dates d'expiration et en observant le comportement du système lors des renouvellements planifiés. Remarques\nFaites toujours une copie de sauvegarde des fichiers de configuration avant de les modifier.\nLes chemins exacts et les commandes peuvent varier légèrement en fonction de votre distribution Linux et de la version de vos logiciels.\nAssurez-vous que les ports nécessaires sont ouverts sur votre pare-feu pour permettre les connexions TLS/SSL. En suivant ces étapes, vous devriez être capable de configurer Postfix et Dovecot pour utiliser les certificats SSL/TLS avec Let's Encrypt, améliorant ainsi la sécurité de votre serveur de messagerie. Assurez-vous de tester votre configuration pour vérifier que tout fonctionne correctement avant de la mettre en production. Biblio\nhttps:www.tecmint.com/install-postfix-mail-server-with-webmail-in-debian/\nhttps:*wiki.centos.org/HowTos(2f)postfix.html"}]