varlog/_cache/similar/5ce0ba61-e5c8-47ee-bb6d-2adc5a393717.json

[{"uuid":"9b76aca1-e2d8-4894-a4b0-604c63cf5543","slug":"installer-le-scanner-epson-perfection-v200-photo-version-11901","title":"Comment faire pour installer le scanner Epson Perfection V200 Photo ? (version 1.19.0-1)","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-02-28 20:02:47","created_at":"2023-02-28 20:02:47","updated_at":"2023-02-28 20:02:47","tags":[],"plain":"<note warning>Une version plus récente de ce document est disponbile sur ce Wiki. La version que vous consultez comporte des éléments qui ne sont plus d'actualité. Merci de vous rediriger vers la page </note> Obtenir les pilotes\nRécupérer l'application de numérisation pour Linux depuis la page pilotes Epson pour Linux. Elle redirigera vers la page des pilotes Avasys Scanner.. [^note: depuis le 25/11/2011 EPSON a repris cette activité]\nepson.net - driver download core V200 Linux et epson.net - driver download plugin V200 Linux Par exemple :\niscan-data-1.19.0-1.noarch.rpm\niscan-2.29.1-5.usb0.1.ltdl7.x8664.rpm\niscan-plugin-gt-f670-2.1.2-1.x8664.rpm\nInstaller les programmes\nInstallez-les  dans cet ordre : Vérifier la détection du scanner\nIl est possible de vérifier que le scanner soit bien détecté sur un des ports usb avec la comme lsusb. La commande sane-find-scanner permettra de vérifier que le scanner soit bien détecté. Initialiser\nLors du premier lancement, lancer le programme iscan en root. La nuémrisation peut également s'effectuer depuis Gimp :\n1. Fichier\n1. Créer\n1. Scanning (iscan)... L’application sane ne pilotera pas le scanner."},{"uuid":"7c6f23ab-873a-4f54-9b4e-146e7e86ebc2","slug":"simplescreenrecorder","title":"Simple Screen Recoder","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-02-15 22:41:29","created_at":"2023-02-15 22:41:29","updated_at":"2023-02-15 22:41:29","tags":[],"plain":"SimpleScreenRecorder est un logiciel libre et gratuit pour l'enregistrement de l'écran sous Linux. Il permet aux utilisateurs d'enregistrer leur écran avec une grande variété d'options, notamment l'enregistrement audio, l'enregistrement de la webcam, la sélection d'une zone de l'écran à enregistrer, etc. Le logiciel est facile à utiliser et peut être utilisé pour diverses tâches, telles que la création de tutoriels, l'enregistrement de jeux vidéo, l'enregistrement de conférences et de présentations, et bien plus encore. Il est également doté de fonctionnalités avancées, telles que l'enregistrement à des fréquences d'images élevées et la possibilité de compresser les fichiers vidéo en temps réel pour réduire leur taille. SimpleScreenRecorder est compatible avec la plupart des distributions Linux et est disponible dans les dépôts de la plupart des distributions populaires. Il est largement considéré comme l'un des meilleurs logiciels d'enregistrement d'écran disponibles sous Linux. Il peut être utilisé sur d'autres environnements de bureau tels que GNOME, KDE Plasma, Xfce, LXQt et d'autres. SimpleScreenRecorder prend en charge Wayland depuis la version 0.4.3, publiée en janvier 2020, X11 et OpenGL. SimpleScreenRecorder est disponible dans le référentiel RPMFusion-Free, qui est un référentiel tiers pour les distributions Linux telles que Fedora et CentOS. Pour installer SimpleScreenRecorder à partir de RPMFusion-Free, vous devez d'abord activer ce référentiel sur votre système. Vous pouvez le faire en installant le package rpmfusion-free-release, qui contient les informations de configuration nécessaires pour activer le référentiel. Une fois le référentiel activé, vous pouvez installer SimpleScreenRecorder en utilisant votre gestionnaire de paquets préféré. Par exemple :   sudo dnf install simplescreenrecorder"},{"uuid":"89c5d6a3-fd31-4727-8171-5c37cdd42010","slug":"20230201-nala-un-outil-de-gestion-de-paquets-plus-simple-plus-rapide-et-plus-efficace-pour-linux","title":"Nala : un outil de gestion de paquets plus simple, plus rapide et plus efficace pour Linux","category":"Journal geek","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-02-01 08:15:44","created_at":"2023-02-01 08:15:44","updated_at":"2023-02-01 08:15:44","tags":[],"plain":"Nala semble être un excellent outil de gestion de paquets. Cependant, son développeur ne se base pas sur les bibliothèques fournies dans les dépôts officiels, ce qui rend l'application incompatible avec le gestionnaire de paquets APT. Il est fréquent que les développeurs choisissent de ne pas utiliser les bibliothèques fournies dans les dépôts officiels pour leur application, soit pour des raisons de fonctionnalité ou de contrôle de qualité. Cela peut rendre l'application incompatible avec les outils de gestion de paquets tels qu'APT et nécessiter une installation manuelle ou une configuration supplémentaire pour être utilisée. Il est toujours important de vérifier les prérequis et les compatibilités avec les autres logiciels avant d'installer une nouvelle application. Nala est un outil de gestion de paquets pour les systèmes d'exploitation Linux. Il a été conçu pour être plus simple, plus rapide et plus efficace que les autres outils de gestion de paquets tels qu'APT. Nala se concentre sur la simplification du processus d'installation et de mise à jour des paquets, en offrant une interface en ligne de commande claire et facile à utiliser. L'un des avantages de Nala par rapport à d'autres outils de gestion de paquets est qu'il utilise un cache local des paquets pour accélérer les opérations de mise à jour et d'installation. De plus, Nala propose également une gestion intelligente des dépendances, ce qui signifie que lorsque vous installez un paquet, les paquets requis pour son fonctionnement seront également installés automatiquement. Nala permet également d'installer des paquets à partir de plusieurs sources différentes, y compris les dépôts officiels, les dépôts tiers et les fichiers de paquets locaux. Cette fonctionnalité permet aux utilisateurs de sélectionner les sources les plus fiables et les plus rapides pour l'installation de leurs paquets. Enfin, Nala offre une commande facile pour gérer les paquets obsolètes et inutiles, ce qui peut aider à libérer de l'espace disque sur le système. Côté technique\nAPT (Advanced Package Tool) est utilisé sur les systèmes d'exploitation Debian et Ubuntu. Nala est conçu pour fonctionner avec APT sur les systèmes d'exploitation Debian et Ubuntu et ne peut pas être utilisé sur les systèmes d'exploitation qui utilisent RPM (Red Hat Package Manager). Comparaison : Nala vs APT\nNala et APT sont tous deux des outils de gestion de paquets pour les systèmes d'exploitation Linux. Cependant, ils ont quelques différences clés :\n<u>Simplicité d'utilisation</u> : Nala a été conçu pour être plus simple et plus facile à utiliser que APT, avec une interface en ligne de commande claire et concise. APT peut être plus complexe pour les utilisateurs débutants, avec de nombreuses options et commandes différentes.\n<u>Vitesse</u> : Nala utilise un cache local pour accélérer les opérations de mise à jour et d'installation. De plus, Nala est conçu pour être plus rapide que APT en termes de temps de traitement pour les opérations de paquetage.\n<u>Sources de paquets</u> : Nala permet d'installer des paquets à partir de plusieurs sources différentes, y compris les dépôts officiels, les dépôts tiers et les fichiers de paquets locaux. APT ne prend en charge que les dépôts officiels et les dépôts tiers.\n<u>Résolution de dépendances</u> : Nala propose une gestion intelligente des dépendances pour gérer les conflits de dépendances et s'assurer que les paquets sont installés dans le bon ordre. APT utilise également une gestion des dépendances, mais elle peut parfois nécessiter une intervention manuelle pour résoudre les conflits. Comment installer Nala\nJe n'ai pas trouvé de preuve de l'existence d'un paquet Nala officiel dans les dépôts de Debian ou de tout autre système d'exploitation Linux populaire. Il est possible que Nala soit disponible en tant que paquet tiers, mais cela dépendra de la source du paquet.\nDans le site Phoenix Ap, il n'est fait aucune mention des incompatibilités avec les bibliothèques courantes. D'après le site officiel de nala, vous pouvez l'installer en utilisant la commande . Le mainteneur, Blake Lee, rencontre des difficultés à créer des paquets pour les dépôts officiels. \"Ces paquets ne sont pas dans la version 20.04. Auparavant, j'avais créé un paquet séparé, nala-legacy, qui utilisait une compilation bancale pour les regrouper. Il comportait beaucoup de bogues et était lourd à maintenir. Vous pouvez tirer ces paquets de 22.04 ou même les obtenir de Debian Sid si vous le souhaitez. Vous pouvez également construire à partir des sources. Il fera tout via pip mais ne sera pas automatiquement mis à jour avec le reste du système.\" (source)"},{"uuid":"4cf2f515-33ef-40ca-86a8-8f9360be8d1f","slug":"que-faire-avec-votre-ancien-operateur","title":"Que faire avec votre ancien opérateur ?","category":"Journal geek","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2020-04-17 18:06:54","created_at":"2020-04-17 18:06:54","updated_at":"2020-04-17 18:06:54","tags":[],"plain":"Free a lancé son nouveau forfait, mais vous êtes nombreux à vous demander comment faire pour se désabonner de chez SFR, Bouygues ou Orange.\nUn Responsable Juridique de UFC QUE CHOISIR répond à Jean Marc MORANDINI. Résiliation, numéro RIO, procédure de changement d'opération sans changer de numéro (vous conservez le même numéro)... Un engagement de 12 mois est à payer jusqu'au bout.\nPar contre, un engagement de 24 mois, vous ne devez payer que 25% des sommes restantes à payer au-delà du 12ème mois. Votre durée engagement vous est annoncé au numéro de téléphone au 3179 (appel gratuit). Vous recevrez une confirmation par SMS."},{"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"}]