Cédrix
1 line
24 KiB
JSON
1 line
24 KiB
JSON
[{"uuid":"32453f3a-32cd-4499-bf9c-b71f274f7803","slug":"traitement-json-tic-edf","title":"Envoyer la sortie de RASPJSON vers une unité de traitement","category":"Électronique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2021-01-01 23:18:54","created_at":"2021-01-01 23:18:54","updated_at":"2021-01-01 23:18:54","tags":[],"plain":"La TIC du compteur électrique reliée à un démodulateur ASK nous fournit des trames JSON par le biais du programme raspjson. Ces informations JSON doivent être communiquer à l'unité de traitement principale. Il faut s'attendre aux pires :\nquantité de trames lues trop importante par rapport au nombre pouvant être traitée par l'unité de traitement dans un même laps de temps\ntemps de réponse de l'unité de traitement très long\nunité de traitement injoignable Dans ces cas, il faut continuer à réceptionner les informations et les mémoriser.\n- Lecture du fichier buffer"},{"uuid":"0e0b8d1d-3352-4ab7-bc70-7bc1f02ee485","slug":"imagemagick-sur-debian-pourquoi-convert-im6-et-ou-trouver-magick","title":"ImageMagick sur Debian : pourquoi `convert-im6` et où trouver `magick`","category":"linux","author":"cedric@abonnel.fr","cover":"cover.svg","published":true,"published_at":"2025-12-28 15:32","created_at":"2025-12-28 15:32:01","updated_at":"2026-05-12 00:29:00","tags":[],"plain":"Si tu as déjà installé ImageMagick sur un serveur Debian, tu es probablement tombé sur cette étrangeté : la commande historique est là, mais elle s'appelle . Et la commande moderne , présente partout ailleurs, semble manquer à l'appel — sauf si tu es sur Debian 13, où elle est revenue.\r\n\r\nLe sujet est un peu plus subtil qu'il n'y paraît, et beaucoup d'explications qui circulent sur le web sont fausses (notamment celle qui prétend que entrerait en conflit avec un binaire de — c'est un mythe). Voilà ce qui se passe réellement.\r\n\r\nUn peu de contexte sur ImageMagick\r\n\r\nImageMagick, c'est une suite d'outils en ligne de commande pour manipuler des images : conversion de formats, redimensionnement, compression, génération de vignettes, watermarks, lecture de métadonnées… Le genre d'outil qu'on retrouve aussi bien dans un script bash de cinq lignes que dans une chaîne de traitement industrielle ou un pipeline CI.\r\n\r\nHistoriquement, la suite est composée de plusieurs binaires distincts, chacun avec son rôle : pour la conversion, pour lire les métadonnées, pour le traitement par lot, pour combiner des images, pour les planches. C'est l'architecture d'ImageMagick 6, la version qui a régné en maître pendant une bonne quinzaine d'années.\r\n\r\nDepuis 2016, ImageMagick 7 est disponible. Le grand changement, c'est qu'il unifie tout derrière une seule commande : . Les anciennes commandes deviennent des sous-commandes (, , etc.), même si pour la rétrocompatibilité un binaire peut continuer à se comporter comme quand on l'appelle avec une syntaxe d'IM6.\r\n\r\nPourquoi le suffixe sur Debian\r\n\r\nC'est ici que beaucoup d'articles racontent n'importe quoi. La vraie raison n'a rien à voir avec un conflit avec — je l'ai vérifié, aucun paquet système ne fournit de commande . Tu peux le vérifier toi-même : ne renvoie rien qui vienne de util-linux.\r\n\r\nLa vraie raison est plus prosaïque. Pendant des années, Debian a voulu pouvoir packager IM6 et IM7 en parallèle dans la même distribution, pour permettre une transition en douceur. Le souci, c'est que les deux versions fournissent des binaires aux mêmes noms (, , …) avec des comportements légèrement différents. Impossible de les installer côte à côte sans renommer.\r\n\r\nLa solution adoptée par les mainteneurs Debian a été d'ajouter un suffixe explicite au nom de chaque binaire :\r\nles outils d'IM6 deviennent , , etc.\r\nles outils d'IM7 deviennent et compagnie\r\n\r\nLe indique la profondeur quantique du binaire (16 bits par canal, la valeur par défaut), et le / indique la version d'ImageMagick. Les noms classiques (, ) ne sont alors que des symlinks gérés par , qui pointent vers la version active. C'est le même mécanisme que pour , , ou à une époque.\r\n\r\nCe qui change entre Debian 11, 12 et 13\r\n\r\nC'est l'autre point que la plupart des articles ratent : la situation n'est pas la même selon la version de Debian.\r\n\r\nSur Debian 11 (bullseye) et 12 (bookworm), le paquet installe IM6 (version 6.9.11.60). Tu n'as que et ses copains, et n'existe pas dans les dépôts officiels (le paquet existe mais n'est pas le défaut). C'est cette situation que décrivent la plupart des tutoriels qui traînent sur le web.\r\n\r\nSur Debian 13 (trixie), sorti en août 2025, le défaut a basculé sur IM7 (version 7.1.1.43). La commande est disponible, et est désormais un symlink vers . Tu peux le vérifier :\r\n\r\n\r\n\r\nAutrement dit, sur Trixie, si tu écris , tu appelles en réalité IM7 sous un nom d'IM6. Ça fonctionne pour la plupart des usages, mais attention : IM7 est plus strict sur l'ordre des arguments en ligne de commande (), donc certains scripts anciens peuvent grogner.\r\n\r\nCorrespondance entre les deux versions\r\nImageMagick 6 (Debian 11/12) | ImageMagick 7 (Debian 13) |\r\n---------------------------- | ------------------------- |\r\n| |\r\n| |\r\n| |\r\n| |\r\n\r\nPour les cas simples, le comportement est identique. Une commande de redimensionnement classique passe sans modification :\r\n\r\n\r\n\r\nFaut-il s'inquiéter sur un serveur en production ?\r\n\r\nSi tu administres une machine Debian 12 ou plus ancienne, non. IM6 est toujours activement maintenu pour les CVE (les correctifs sont régulièrement backportés dans les paquets stable), et la plupart des scripts existants continueront de fonctionner. Le dans le nom du binaire est juste du marquage, pas une dépréciation.\r\n\r\nSi tu migres vers Debian 13, prévois un peu de temps pour relire tes scripts. Les pièges classiques :\r\nl'ordre des options qui devient plus strict ;\r\nquelques comportements de couleur et d'alpha qui ont changé entre les deux versions, notamment sur les opérations chaînées ;\r\nle fichier qui a déménagé : devient . Si tu avais assoupli les restrictions sur les PDF ou PostScript (un grand classique), il faut reporter la modification.\r\n\r\nPour un projet PHP comme les tiens, l'extension Imagick côté PHP est sensible à cette transition : la version compilée doit correspondre à la version d'IM installée, sinon échoue. Sur Trixie, c'est IM7 qu'il faut lier.\r\n\r\nEn pratique\r\n\r\nSur Debian 11/12, utilise , , etc. C'est la convention locale, pas une version dégradée. Si tu veux malgré tout, tu peux installer le paquet (présent dans les dépôts depuis bookworm) et basculer les alternatives manuellement, mais ce n'est presque jamais nécessaire.\r\n\r\nSur Debian 13, utilise directement. La commande reste disponible par compatibilité, mais elle pointe en réalité vers IM7 — autant utiliser le nom officiel.\r\n\r\nEt dans tous les cas, évite les alias globaux qui réécrivent : ça finit toujours par mordre quelqu'un, soit toi dans six mois, soit le prochain qui reprendra le serveur."},{"uuid":"976fd7f0-e53d-44e2-a879-58194765f3cf","slug":"activer-les-mises-a-jour-automatiques-sur-debian-pour-une-gestion-simplifiee-des-correctifs-de-securite","title":"Activer les mises à jour automatiques sur Debian pour une gestion simplifiée des correctifs de sécurité","category":"linux","author":"cedric@abonnel.fr","cover":"cover.svg","published":true,"published_at":"2026-01-06 20:45","created_at":"2026-01-06 20:45:52","updated_at":"2026-05-14 07:54:59","tags":{"logiciels":["Debian"]},"plain":"Dans un environnement de serveur ou de poste de travail, maintenir un système à jour avec les derniers correctifs de sécurité est crucial pour limiter l'exposition aux vulnérabilités. Debian fournit pour cela le paquet , qui automatise l'application des correctifs sans intervention manuelle. Cet article décrit comment l'installer, le configurer pour ne traiter que les mises à jour de sécurité, vérifier qu'il est bien actif, et tester son fonctionnement. La progression va du chemin minimal (sections 1 à 3) vers les réglages avancés utiles en production (sections 4 et suivantes). Étapes pour activer les mises à jour automatiques 1. Installer les paquets nécessaires On installe (qui applique les mises à jour) et, optionnellement mais recommandé, (qui résume les changements appliqués et peut les envoyer par e-mail) : À noter : sur Debian 12 (Bookworm) et versions ultérieures, n'est plus installé par défaut, même avec un environnement de bureau. À l'installation, pose quelques questions débconf (mode de remise : , , ; adresse mail destinataire ; fréquence). La valeur par défaut () convient pour un poste de travail ; sur un serveur, choisir et indiquer l'adresse de l'administrateur, après s'être assuré qu'un MTA local (postfix, msmtp…) est en place. Pour reconfigurer ultérieurement : 2. Activer le scheduling : La configuration d' se fait via deux fichiers dans :\n: quand déclencher la mise à jour (activation du scheduling)\n: quoi mettre à jour (origines, blacklist, redémarrage, mail…) Le premier peut être généré automatiquement avec : Une unique question débconf apparaît — « Automatically download and install stable updates? » — répondez Oui. Cela crée avec le contenu suivant : Sans ce fichier, est installé mais ne s'exécute jamais automatiquement. 3. Vérifier les origines dans Éditez le fichier : Sur Debian, les origines autorisées sont définies dans le bloc . Par défaut, seules les mises à jour de sécurité sont actives. Vérifiez la présence des lignes suivantes, non commentées : (La seconde ligne couvre l'ancien format d'étiquetage des dépôts de sécurité ; il est prudent de conserver les deux.) Optionnel : pour appliquer aussi les mises à jour fonctionnelles (corrections de bugs non critiques), décommentez la ligne correspondant aux updates : À utiliser avec discernement sur un serveur de production : ces mises à jour ne sont pas urgentes du point de vue sécurité et peuvent introduire des changements de comportement. À ce stade, la configuration minimale est terminée : les mises à jour de sécurité Debian seront appliquées automatiquement. Les sections suivantes couvrent les réglages utiles pour un usage en production. 4. Tester la configuration Lancez une simulation pour vérifier ce qui serait installé sans rien modifier : (Le binaire s'appelle bien au singulier ; le pluriel fonctionne aussi grâce à un lien symbolique.) La sortie est verbeuse. Les lignes à repérer sont :\n: doit lister les origines configurées en section 3 (au moins ).\n: les paquets exclus (voir section 6).\nou : ce qui serait installé.\n: message normal si aucune mise à jour de sécurité n'est en attente. Si une origine attendue n'apparaît pas dans Allowed origins, la ligne correspondante dans est probablement encore commentée. 5. Planification (timers systemd) L'exécution est pilotée par deux timers systemd fournis par le paquet : (téléchargement) et (installation). Par défaut, l'installation se déclenche tous les jours autour de 6h avec un délai aléatoire d'une heure. Pour vérifier l'état des timers : Pour modifier l'heure d'installation, créez un override : Et placez-y : Puis rechargez : 6. Réglages utiles en production Toujours dans , quelques options méritent d'être activées : Si vous désactivez le redémarrage automatique (recommandé en production), il faut un mécanisme pour savoir quand un reboot devient nécessaire — sinon les mises à jour de noyau s'accumulent silencieusement et la machine reste vulnérable jusqu'au prochain redémarrage manuel. Trois pistes complémentaires :\nLe fichier est créé automatiquement par les paquets qui exigent un reboot. Un simple dans un script de monitoring ou un motd suffit à le signaler à la connexion.\nInstaller () : il identifie les services à redémarrer après la mise à jour d'une bibliothèque (libc, openssl…), ce qui évite souvent un reboot complet. La commande liste les actions à entreprendre.\nLe mail envoyé par mentionne explicitement les paquets installés ; un redémarrage de noyau y est visible. 7. Cas des dépôts tiers Le bloc par défaut ne couvre que les dépôts Debian officiels. Les paquets installés depuis des dépôts tiers (Docker, PostgreSQL upstream, Nodesource, dépôts maison…) ne seront pas mis à jour automatiquement, alors même qu'ils concentrent souvent les CVE critiques sur un serveur. Pour les inclure, il faut ajouter leur pattern à . Par exemple pour Docker : Pour identifier l'origine et l'archive d'un dépôt : Repérez les champs (origin) et (archive/suite) dans la sortie ; ce sont eux qui doivent correspondre à votre pattern. Activer un dépôt tiers en mise à jour automatique demande de la confiance dans la stabilité de ce dépôt — testez d'abord en . 8. Vérifier les logs Les actions effectuées sont journalisées dans : Le premier trace l'activité d' lui-même (origines, paquets pris en compte, succès/échec) ; le second contient la sortie complète de pour chaque paquet installé.\n-- En activant correctement configuré, les correctifs de sécurité Debian sont appliqués rapidement et sans intervention manuelle. Sur un serveur de production, il reste essentiel de blacklister les paquets critiques pour votre stack, de configurer une notification par mail, de surveiller si le redémarrage automatique est désactivé, et de penser explicitement à inclure vos dépôts tiers dans . Les mises à jour majeures (changement de version Debian) restent toujours à faire à la main."},{"uuid":"b2273ad3-797f-4ec6-905b-c7d58c0c33d3","slug":"installation-postgres-client-17-debian-ubuntu","title":"Installation d'un client postgre SQL 17 sur une distribution basée sur Debian/Ubuntu","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2025-02-09 09:18:30","created_at":"2025-02-09 09:18:30","updated_at":"2025-02-09 09:18:30","tags":[],"plain":"L'objectif de cet article est d'expliquer pas à pas l'installation du client PostgreSQL version 17 () sur une distribution Linux basée sur Debian ou Ubuntu. Ce guide s'adresse aux développeurs et administrateurs système souhaitant interagir avec une base de données PostgreSQL en utilisant uniquement le client.\n-- Pré-requis\nAvant de commencer, assurez-vous que :\n1. Vous avez les privilèges administrateur (accès ).\n1. Votre système est à jour avec les derniers correctifs de sécurité.\n-- Étapes d'installation\n1. Créer le répertoire pour le dépôt PostgreSQL\nLe premier pas consiste à créer le répertoire qui contiendra la clé de signature du dépôt PostgreSQL. Cela garantit la vérification de l'authenticité des paquets téléchargés. 2. Télécharger et ajouter la clé GPG\nLa clé GPG du dépôt PostgreSQL doit être téléchargée et installée pour valider les paquets téléchargés. Utilisez la commande suivante :\n⚠️ Astuce : Assurez-vous que la connexion Internet est active pour télécharger la clé depuis le site officiel de PostgreSQL. 3. Ajouter le dépôt PostgreSQL au gestionnaire de paquets\nAjoutez le dépôt PostgreSQL approprié à votre fichier de sources APT. La commande suivante le fait automatiquement, en détectant la version de votre système () : Cette ligne configure le fichier de sources pour qu'il utilise le dépôt officiel PostgreSQL. 4. Mettre à jour la liste des paquets\nMettez à jour la liste des paquets disponibles sur votre système avec la commande suivante : 5. Installer le client PostgreSQL version 17\nPour installer le client PostgreSQL version 17, exécutez simplement :\nNote : Le permet d'automatiser l'acceptation des invites lors de l'installation.\n-- Vérification de l'installation\nPour vérifier que le client PostgreSQL 17 est correctement installé, utilisez la commande suivante : La sortie doit indiquer la version 17. Par exemple :\n-- Conclusion\nVous avez maintenant installé avec succès sur votre système. Vous pouvez l'utiliser pour interagir avec n'importe quel serveur PostgreSQL. Pour des commandes comme la connexion à une base de données distante, utilisez : N'hésitez pas à consulter la documentation officielle de PostgreSQL pour approfondir vos connaissances."},{"uuid":"0bba1ad7-e4cb-49a6-9467-fcfac2e09a93","slug":"deuxiemes-pas-devops-durcir-et-fiabiliser-un-serveur-debian","title":"Deuxièmes pas DevOps : durcir et fiabiliser un serveur Debian","category":"informatique","author":"cedric@abonnel.fr","cover":"cover.jpg","published":true,"published_at":"2026-06-08 07:00","created_at":"2026-05-12 23:01:34","updated_at":"2026-05-13 22:53:46","tags":{"logiciels":["Fail2ban","Debian"]},"plain":"Une fois le système de base configuré (dépôts, mises à jour, , identification — sujets traités dans l'article précédent), la machine est fonctionnelle mais encore vulnérable et un peu fragile pour un usage sérieux. Ce deuxième article s'attaque aux gestes qui transforment un serveur « qui marche » en un serveur sur lequel on peut raisonnablement faire tourner quelque chose : sécuriser l'accès SSH, mettre en place un pare-feu, automatiser les correctifs de sécurité et soigner quelques détails opérationnels.\r\n\r\nSécuriser l'accès SSH\r\n\r\nSSH est la porte d'entrée principale d'un serveur Linux. C'est aussi, statistiquement, la cible la plus attaquée : n'importe quelle IP publique reçoit en permanence des tentatives de connexion automatisées. Deux gestes simples changent radicalement la donne.\r\n\r\nPasser à l'authentification par clé\r\n\r\nLes mots de passe, même longs, restent vulnérables aux attaques par force brute et au phishing. Une paire de clés cryptographiques est à la fois plus sûre et plus pratique au quotidien.\r\n\r\nCôté poste de travail, on génère une paire de clés modernes :\r\n\r\n\r\n\r\nL'algorithme est aujourd'hui le choix par défaut recommandé : clés courtes, signatures rapides, sécurité solide. Le commentaire () facilite l'identification de la clé quand on en gère plusieurs.\r\n\r\nOn copie ensuite la clé publique sur le serveur :\r\n\r\n\r\n\r\nCette commande dépose la clé publique dans côté serveur avec les bonnes permissions. À partir de là, la connexion se fait sans saisir de mot de passe — il faut tester depuis une nouvelle session avant de passer à l'étape suivante, sous peine de risquer de se retrouver enfermé dehors.\r\n\r\nDésactiver la connexion root et les mots de passe\r\n\r\nUne fois la connexion par clé validée, on durcit la configuration SSH. Le fichier à modifier est :\r\n\r\n\r\n\r\nLes directives importantes à positionner (ou décommenter) sont :\r\n\r\n\r\n\r\nLa première interdit toute connexion directe en via SSH : on devra obligatoirement se connecter avec un utilisateur normal puis élever ses droits via . La deuxième supprime complètement l'authentification par mot de passe, ne laissant plus que les clés. La troisième confirme explicitement que l'authentification par clé est active.\r\n\r\nOn recharge ensuite le service pour appliquer les changements :\r\n\r\n\r\n\r\nImportant : garder la session SSH actuelle ouverte et tester la nouvelle configuration depuis un autre terminal avant de fermer la première. En cas de problème, on peut encore corriger le tir.\r\n\r\nPour aller un cran plus loin, changer le port SSH par défaut (22) vers un port moins évident réduit considérablement le bruit dans les logs. Ce n'est pas de la sécurité au sens strict (un scan le retrouvera), mais c'est un filtre efficace contre les attaques automatisées.\r\n\r\nMettre en place un pare-feu\r\n\r\nPar défaut, Debian n'a aucun pare-feu actif. Tout port ouvert par un service installé sera donc directement exposé. Deux outils standards existent : (le successeur officiel d', bas niveau et puissant) et (une surcouche pensée pour la simplicité). Pour démarrer, est le bon compromis.\r\n\r\n\r\n\r\nLa logique consiste à tout bloquer en entrée par défaut, puis à n'ouvrir explicitement que ce qui doit l'être :\r\n\r\n\r\n\r\nSi SSH écoute sur un port non standard, remplacer par (ou le port choisi). Oublier cette étape avant un est un grand classique du verrouillage involontaire.\r\n\r\nPour les services web, on ouvrira typiquement les ports 80 et 443 :\r\n\r\n\r\n\r\nL'état du pare-feu se vérifie avec :\r\n\r\n\r\n\r\nSur une architecture où la machine est derrière un reverse proxy (cas fréquent quand on expose plusieurs services sur un même domaine), seuls les ports utiles côté proxy doivent être ouverts au monde extérieur. Les services applicatifs eux-mêmes restent accessibles uniquement depuis le réseau interne.\r\n\r\nAutomatiser les correctifs de sécurité\r\n\r\nLes failles de sécurité ne préviennent pas, et personne n'a envie de lancer manuellement chaque matin sur dix machines. Le paquet applique automatiquement les mises à jour du dépôt .\r\n\r\n\r\n\r\nLa configuration se trouve ensuite dans . Par défaut, seuls les correctifs de sécurité sont appliqués automatiquement, ce qui est généralement le bon compromis : on profite des patches critiques sans risquer qu'une mise à jour fonctionnelle introduise une régression sur un service en production.\r\n\r\nQuelques options qui méritent l'attention dans ce fichier :\r\n: à régler sur si l'on accepte les redémarrages automatiques après une mise à jour de noyau, ou si l'on préfère les piloter à la main. La directive permet alors de choisir l'horaire.\r\n: pour recevoir un rapport par mail des mises à jour appliquées, à condition d'avoir un MTA configuré sur la machine.\r\n\r\nLe bon réflexe consiste à vérifier de temps en temps les logs dans pour s'assurer que tout se déroule sans heurts.\r\n\r\nSoigner les détails opérationnels\r\n\r\nQuelques outils complémentaires améliorent significativement le confort et la résilience d'un serveur.\r\n\r\nFail2ban surveille les logs d'authentification et bannit temporairement les IP qui tentent trop de connexions échouées. Même avec SSH par clé uniquement, le service réduit considérablement le bruit dans les journaux :\r\n\r\n\r\n\r\nLa configuration par défaut surveille déjà SSH ; elle peut être étendue à d'autres services (nginx, Postfix, etc.) via des fichiers dans .\r\n\r\nLogwatch ou journalctl méritent qu'on s'y attarde. Sur une Debian récente, est l'outil central pour consulter les logs systemd :\r\n\r\n\r\n\r\nPrendre l'habitude de jeter un œil aux logs régulièrement — ou de mettre en place une remontée centralisée si l'on gère plusieurs machines — change beaucoup de choses en exploitation.\r\n\r\nUn swap raisonnable, sur une VM ou un serveur dédié, évite que la machine ne devienne complètement injoignable en cas de pic de consommation mémoire. Sur un conteneur LXC en revanche, c'est généralement géré au niveau de l'hyperviseur.\r\n\r\nEt après ?\r\n\r\nAvec ces réglages, le serveur est dans un état correct pour accueillir des services réels : la surface d'attaque est réduite, les correctifs s'appliquent tout seuls, et les logs racontent ce qui se passe. La suite logique est l'installation de la pile applicative proprement dite (serveur web, base de données, runtime) et la mise en place d'un reverse proxy pour exposer plusieurs services derrière un même point d'entrée.\r\n\r\nComme évoqué dans le premier article, le moment où l'on commence à enchaîner ces étapes sur plusieurs machines est exactement celui où il faut basculer vers de l'automatisation : un script shell bien rangé pour commencer, puis Ansible ou un équivalent quand le parc grossit. Une bonne pratique consiste à versionner ces scripts dans un dépôt Git dédié à l'infrastructure, au même titre que le code applicatif."}] |