bisko.be - Dev

Faire tourner Ollama avec de vieux GPU sur CachyOS

Sat, 28 Feb 2026 00:00:00 GMT

TL;DR;

ollama-cuda sur CachyOS ne supporte (à l’heure actuelle) que compute >= 7.5.

Si vous avez de vieux GPU avec un compute inférieur, vous DEVEZ faire l’une de ces 2 choses :

Compiler ollama-cuda depuis les sources, avec le support des anciennes cibles de compute
Installer ollama-vulkan

J’ai choisi ollama-vulkan et ça marche parfaitement !

L’heure du récit

Aujourd’hui, j’ai eu l’inspiration d’enfin éteindre ma VM Windows 11 et de la migrer vers Linux.

Il fallait que je puisse faire tourner :

Ollama - pour la magie des modèles en local
Docker - pour le développement à distance
Steam - pour jouer
Jellyfin - pour l’archive de vidéos familiales

Je vais me concentrer uniquement sur Ollama, parce que l’expérience était intéressante et qu’elle m’a fait me demander pourquoi les choses ne sont pas plus évidentes.

La machine contient 2 GPU :

GTX 1070 - 8 Go
GTX 970 - 4 Go

Je voulais faire tourner Ollama dessus, pour jouer avec des modèles locaux et voir comment je pourrais l’intégrer dans certains projets. Par exemple : anonymiser des données en local, monter une implémentation non destructive d’OpenClaw adaptée à mes cas d’usage, faire de l’OCR local pour les documents que je scanne avec mon téléphone, automatiser certaines tâches de la gestion quotidienne d’une maison.

Alors naturellement, j’ai installé ollama et ollama-cuda, puisque j’ai 2 GPU Nvidia là-dedans, en m’attendant à ce que ça marche sans souci, vu que ça fonctionnait sous Windows quelques minutes plus tôt.

J’ai lancé Ollama, chargé qwen3:8b pour un test rapide et… ça tournait sur le CPU 🤔

Les GPU étaient parfaitement capables de le garder en VRAM, mais pour une raison quelconque Ollama choisissait de le faire tourner sur le CPU.

Après avoir essayé de comprendre à partir des logs, j’ai demandé un coup de main à Claude, qui est arrivé à cette conclusion plutôt décourageante :

The logs tell the story clearly. Both your GPUs are detected but then filtered out because they fail CUDA initialization:

  "filtering device which didn't fully initialize" id=GPU-eb132a13-b9f4-40e3-d85d-60f211dfd21e ... library=CUDA
  "filtering device which didn't fully initialize" id=GPU-550263c8-37e2-2a25-c0b6-10cc7511ed20 ... library=CUDA

  The reason is the CUDA library bundled with Ollama 0.17.4 was compiled for these architectures only:

  CUDA.0.ARCHS=750,800,860,870,880,890,900,1000,1030,1100,1200,1210

  The minimum supported compute capability is 7.5 (Turing / RTX 20xx series). Your GPUs are older than that:

  ┌──────────┬────────────────────┬──────────────┐
  │   GPU    │ Compute Capability │ Architecture │
  ├──────────┼────────────────────┼──────────────┤
  │ GTX 1070 │ 6.1                │ Pascal       │
  ├──────────┼────────────────────┼──────────────┤
  │ GTX 970  │ 5.2                │ Maxwell      │
  └──────────┴────────────────────┴──────────────┘

  Neither is in the supported list, so CUDA initialization fails for both, and Ollama falls back to CPU-only inference.

  Your options:

  1. Downgrade Ollama to an older version that still included Pascal/Maxwell support (pre-0.6.x era had broader arch coverage, but check release notes for specifics).
  2. Build Ollama from source with CUDA_ARCHITECTURES="52;61;75;80;86" to include your GPU architectures.
  3. Upgrade GPUs to at least an RTX 2060 or newer (compute 7.5+).

Franchement, ça m’a un peu douché, parce que je veux exploiter ces GPU au maximum avant de passer à un nouveau.

Je n’avais pas envie de recompiler Ollama depuis les sources, vu que ça devrait fonctionner out of the box, et j’étais très perplexe de voir que ce n’était pas le cas, alors que sous Windows ces architectures étaient bien supportées.

Ces cartes étaient même indiquées comme supportées sur le site d’Ollama !

Pour résumer des heures de recherches Google :

Il se trouve que ollama-cuda ne vient qu’avec les prérequis listés plus haut… et la suggestion était d’installer ollama-vulkan.

Après ça, tout s’est mis à fonctionner très bien !

[Linux] Récupérer une session `apt dist-upgrade` déconnectée

Wed, 23 Oct 2024 00:00:00 GMT

Aujourd’hui, je mettais à jour mon installation Proxmox à distance via la console intégrée, mais j’ai oublié ce que j’étais en train de faire et j’ai fermé l’onglet en plein milieu.

Résultat : impossible de me reconnecter, car les paquets étaient déjà en cours de mise à jour en arrière-plan et la mise à jour avait posé une question sur le remplacement d’un fichier et attendait ma réponse.

Je pouvais donc me connecter en SSH, mais je ne pouvais rien faire, puisque le processus attendait toujours une réponse sur une console à laquelle je n’arrivais pas à me connecter, l’interface ne s’ouvrant pas.

Après avoir fouillé un peu, je suis tombé sur un fil Serverfault qui mentionnait l’utilisation de reptyr pour reprendre la main sur une session de terminal via SSH.

Je note ici ce que j’ai fait exactement pour récupérer la session et terminer la mise à jour :

D’après ce commentaire :

git clone https://github.com/nelhage/reptyr
cd reptyr
make install

Cela a installé reptyr sur la machine.

Ensuite, j’ai cherché toutes les sessions ouvertes avec ps ax | grep pts pour trouver le processus qui m’intéressait.

Puis j’ai trouvé le processus le plus haut dans l’arbre d’appels auquel un pts était assigné, et je m’y suis attaché via son PID :

reptyr -T 1390511

Et j’ai enfin pu terminer la mise à jour ! 🎉

[Linux] Syncthing – système de fichiers en lecture seule lorsqu’il tourne en tant que service

Wed, 06 Apr 2022 00:00:00 GMT

J’utilise Syncthing depuis un moment pour synchroniser ma copie de travail avec un serveur de dev local, depuis quelques mois.

Au début, je l’utilisais en me connectant et en le lançant à la main via la CLI. Ça marchait bien, donc je n’ai pas réfléchi à deux fois quand je suis passé à un lancement en tant que service. Il a démarré, il a synchronisé des données, tout allait bien.

Jusqu’à ce que ça ne soit plus le cas, bien sûr ! 🙂

Il s’avère que je n’avais pas remarqué toute une série d’erreurs qui apparaissaient dans les logs, indiquant que le système de fichiers du serveur de dev était en lecture seule, ce qui empêchait Syncthing de synchroniser quoi que ce soit.

Je pensais que c’était un bug et qu’il affichait simplement Out of Sync pour les dossiers, mais qu’il synchronisait quand même. Eh bien, je me trompais.

Après avoir débogué pendant quelques heures sans trouver le moindre indice sur les forums à coups de recherches Google, je suis tombé sur un article sur Syncthing dans l’ArchWiki, qui décrivait exactement mon cas :

read-only file system error on /etc although run as root

C’était exactement mon cas d’usage, sauf que le dossier problématique n’était pas /etc, mais /usr/local/src.

Bref, après avoir lu ce que ça disait, il s’avère que si vous lancez Syncthing (ou n’importe quoi d’autre) via systemd et que ProtectSystem est réglé sur full pour le service, certains répertoires seront en lecture seule par défaut. /usr fait partie de ces chemins.

Pour corriger ça, il faut ajouter une nouvelle ligne dans la configuration du service et redémarrer le service (sans oublier daemon-reload) :

ReadWritePaths=/usr/local/src

Après ça, Syncthing devrait fonctionner correctement.

[Linux] Exécuter plusieurs commandes sur plusieurs serveurs en parallèle

Mon, 19 Apr 2021 00:00:00 GMT

J’ai chez moi un cluster de Raspberry Pi qui font tourner Docker Swarm. Pour garder le contrôle sur tout ça, ils utilisent tous la même configuration : utilisateurs, versions de Docker, etc.

Parfois, certaines mises à jour demandent d’exécuter la même chose sur tous les nœuds du cluster – par exemple – créer un nouveau réseau Docker macvlan.

Pour ça, il faut soit lancer les mêmes commandes à la main sur tous les nœuds, en se connectant en ssh sur chacun d’eux, en exécutant les commandes puis en passant au suivant.

Comme j’essaie de me faciliter la vie sur le long terme et de garder les choses aussi organisées que possible, je me suis mis à chercher des moyens d’exécuter des commandes sur tous les nœuds en même temps.

Itération 1 : un script Python maison

La première itération a consisté à écrire un script Python maison. D’un côté, ça me permettait d’apprendre un peu mieux Python ; de l’autre, je ne trouvais pas de moyen correct d’exécuter des commandes de façon plus native.

Comme on peut s’y attendre (eh, j’ai encore peu d’expérience dans ce langage 🙂 ), c’est devenu un gros bazar assez vite, et ça cassait très facilement.

Il me fallait trouver une autre solution, sans avoir à réapprendre ce que j’avais fait il y a 3 semaines et ce qui avait planté la dernière fois.

Itération 2 : `pssh`

En fouillant sur Google, je suis tombé sur [pssh](https://linux.die.net/man/1/pssh), qui permet d’exécuter des commandes en parallèle via SSH.

Tout bien considéré, c’était plutôt facile à mettre en place.

Le problème, c’est que pour exécuter certaines choses, j’avais besoin de passer par sudo. Faire circuler des mots de passe n’était pas l’idéal, alors j’ai dû chercher à nouveau comment envoyer le mot de passe sudo quand le serveur distant le demandait.

Il s’avère que c’est assez simple si on tombe sur le bon commentaire StackOverflow.

La version TL;DR; :

stty -echo; printf "Password: "; read PASS; stty echo; echo "${PASS}" | \
pssh -h <HOSTFILE> -o /tmp/output -t 0 -I "`cat ./commands.sh`"

Le -I "`cat ./commands.sh`" doit obligatoirement être écrit comme ça (entouré de guillemets et d’accents graves), sinon les commandes ne s’exécutent pas correctement. Le mot de passe sera envoyé comme une commande à part et non récupéré comme une entrée de sudo.

L’autre subtilité : vu la façon dont tout ça est configuré, il faut lancer sudo avec le paramètre -S pour qu’il lise correctement le mot de passe.

Deviner le mot de passe numérique d'un fichier zip uniquement avec des utilitaires en ligne de commande

Mon, 14 Sep 2020 00:00:00 GMT

Aujourd’hui j’ai reçu ma facture mensuelle de mon fournisseur internet et quelque chose m’a semblé bizarre.

La facture, contenue dans le mail, était dans un fichier ZIP avec un mot de passe.

Sans parler de l’étrangeté de recevoir une pièce jointe sous forme de fichier ZIP de nos jours (spam, malware, phishing, etc.), le mot de passe qu’ils avaient choisi m’a paru très faible.

C’est la date de naissance du titulaire du compte au format YYMMDD.

J’ai fait un calcul très grossier dans ma tête pendant que j’étais à la salle de sport et le résultat était un nombre très réduit de combinaisons possibles. Après avoir utilisé un outil en ligne pour calculer le nombre de jours écoulés (puisque toutes les combinaisons ne donneraient pas une date valide) depuis le 1900-01-01, il s’avère que les combinaisons sont seulement 44 075 (jusqu’au 2020-09-14).

Sachant que des outils optimisés utilisant la puissance du GPU pour craquer des hashs peuvent faire des millions de tentatives par seconde, je voulais voir à quelle vitesse le mot de passe pouvait être deviné sans les utiliser, en me servant uniquement de la ligne de commande Linux/macOS (n’ayant accès qu’à un VPS depuis la salle de sport).

J’ai concocté le code suivant qui fonctionne sur macOS :

echo {1..44000} | xargs -P 16 -n 1 -I{} date -v "-{}d" +"%y%m%d" | xargs -P 16 -I{} sh -c 'unzip -qqoP "{}" 0417160508.zip && echo "{}" && exit 255'

La commande est assez simple dans son fonctionnement, même si elle paraît compliquée.

echo {1..44000} génère les nombres de 1 à 44 000 et les transmet à l’étape suivante.

xargs -P 16 -n 1 -I{} date -v "-{}d" +"%y%m%d" – prend l’entrée de la première étape et génère des dates au format YYMMDD en exploitant la fonctionnalité de date permettant « d’augmenter » une date d’une quantité spécifique. Dans ce cas, cela va soustraire X jours à la date actuelle. Où X est le nombre généré à la première étape. Ainsi, on peut générer des dates depuis aujourd’hui jusque dans les années 1900.

La troisième étape est la plus intéressante, donc je vais la diviser en deux parties :

xargs -P 16 -I{} sh -c '...'

Cela prend les dates générées à l’étape 2 et exécute une commande sur chacune de ces dates. -P 16 signifie ici que cela va s’exécuter sur 16 processus parallèles, pour accélérer le traitement des données. La même astuce est appliquée à l’étape 2 pour accélérer la génération des dates.

La deuxième partie est l’endroit où les tentatives ont lieu :

unzip -qqoP "{}" 0417160508.zip && echo "{}" && exit 255

Ce que cela fait, c’est d’abord essayer de décompresser le fichier zip en utilisant le mot de passe généré à l’étape 2. Si c’est réussi, cela affiche (echo) le mot de passe deviné puis exit 255 force xargs à arrêter l’exécution. On ne veut pas continuer à deviner si le mot de passe a été trouvé.

En somme, c’était une assez mauvaise décision de choisir cela comme mot de passe pour le fichier, car exécuter la commande ci-dessus prend seulement environ 10 secondes pour deviner le bon mot de passe de ma facture. Pas beaucoup plus pour n’importe qui d’autre.

Gérer le code spaghetti en PHP : utiliser des fonctions anonymes pour extraire des morceaux de code de template

Sat, 08 Aug 2020 00:00:00 GMT

Récemment, j’ai aidé un ami à essayer de comprendre du code et à voir comment le modifier pour qu’il fonctionne bien avec des appels asynchrones vers le backend. Un bonus serait de pouvoir l’écrire de façon plus modulaire et réutilisable.

Le code est un plugin WordPress écrit avec une approche très legacy : un mélange de logique métier et de logique frontend au même endroit. Des manipulations de données faites en plein milieu du code de template, et ainsi de suite.

Bref, ce qu’on voyait sur les sites PHP au début des années 2000, avant toutes les super additions OOP au langage et avant l’arrivée d’un tas de frameworks matures.

Le cas sur lequel j’ai planché aujourd’hui était le suivant : vous avez un tableau qui affiche plein d’entrées. Il fallait ajouter plusieurs filtres au tableau et le faire fonctionner via AJAX pour rafraîchir rapidement l’UI, sans recharger toute la page d’administration de WordPress.

Filtrer les données était facile : un petit array_filter en ligne pour filtrer les données avant de les passer au code du template (pour garder le même style de code, c’était aussi dans le fichier de template 😇).

Le problème est arrivé quand on a commencé à vouloir rendre le tableau affichable via AJAX.

Il se trouve au milieu d’un tas d’autre code de template et de code métier. Si on voulait limiter la sortie AJAX au seul tableau, on n’avait que quelques options.

La première serait d’entourer le HTML avant et après le tableau de GROS blocs if pour s’assurer qu’il ne soit pas rendu.

Une autre serait d’extraire le template dans un fichier séparé et de l’inclure dans l’action AJAX que l’on définirait dans le code du plugin.

Les fonctions anonymes à la rescousse !

En réfléchissant à la façon la plus simple de gérer ça, j’ai essayé de définir une fonction PHP normale contenant le code du tableau, mais il y avait un problème.

Le code s’exécute dans une méthode de classe. Il y a des références à $this dans le template du tableau. Si on ne veut pas trop changer le code, on voudrait passer $this en argument de la fonction. Eh bien ça ne marche pas trop, car on ne peut pas passer $this en paramètre 🤷‍♂️.

J’étais un peu déçu à l’idée de devoir réécrire un tas de choses dans le template, et il y avait pas mal de références qu’on voulait garder en tête pour que tout continue de fonctionner.

Puis je me suis rappelé que le site ne tourne pas sous PHP 5.2 mais sous PHP 7, et que les fonctions anonymes seraient donc supportées.

Elles ont cette fonctionnalité bien pratique qui permet de définir quelles variables du scope appelant seront passées à la fonction quand elle est appelée. Par exemple :

$table_function = function() use ( $pages, $current_page, $items ) {
    // ... Table render code
}

Cela vous permet de référencer directement $pages ou $items dans le corps de la fonction.

Ce qui est génial, c’est qu’on peut aussi passer $this comme variable dans le scope de la fonction !

On a donc pu extraire complètement le code de rendu du tableau dans une fonction séparée, qu’on peut appeler de façon isolée pendant l’appel AJAX !

Bien sûr, il faut faire très attention aux variables utilisées dans le corps de la fonction, car elles doivent être définies ; soyez donc prudent quant à l’endroit où la fonction AJAX peut être appelée.

Pour nous, cela signifie qu’on va ajouter une toute petite action dans la classe principale qui fera toujours le require du fichier, mais on aura plus de contrôle pour désactiver toutes les autres sorties qui se produiraient.

Arduino/ESP32 : désactiver le watchdog des tâches

Wed, 29 Apr 2020 00:00:00 GMT

Récemment, je me suis amusé avec les fonctionnalités multicœur de l’ESP32 et l’épinglage de tâches sur des cœurs spécifiques.

J’utilisais AutoConnect pour gérer la connexion WiFi sans stocker d’identifiants dans le code et proposer des mises à jour OTA via l’interface web.

C’était pour un projet qui devait contrôler des ventilateurs CPU PWM à 4 broches qui se trouvent dans mon placard serveur, pour refroidir l’air à l’intérieur. Pour cela, je voulais séparer la logique en deux tâches.

Une tâche pour gérer les API, la lecture des capteurs, les mises à jour, le WiFi, etc., et une tâche pour gérer l’interruption et le contrôle PWM des ventilateurs.

Tout allait bien, les tâches étaient créées, mais à l’exécution du code, si je mettais l’ESP32 dans le mode où il faut se connecter à lui pour lui dire de rejoindre votre réseau WiFi, il se mettait à avoir un comportement étrange : il réinitialisait le contrôleur toutes les quelques secondes et je n’arrivais pas à établir la connexion.

Ce fut un moment pénible, car il fallait démonter le contrôleur de son emplacement et le brancher en USB pour flasher un nouveau firmware.

Après ça, j’ai remarqué que l’erreur venait du watchdog :

Task watchdog got triggered. The following tasks did not feed the watchdog in time:

IDLE (CPU 1)
Tasks currently running:
CPU 0: ManageTask
CPU 1: ControllerTask

En fouillant un peu, il s’avère que c’est déclenché par le Task Watchdog de l’ESP32, qui s’assure que les tâches aient leur tour d’exécution sur le CPU.

Il semblait aussi qu’AutoConnect n’était pas très flexible dans le contexte d’une tâche, comparé à une exécution en dehors, directement avec tout le reste du code et des fonctionnalités.

Après avoir creusé un peu et essayé différentes choses, il semble que le moyen le plus simple de s’en sortir soit de simplement désactiver le watchdog et d’espérer que tout s’exécute à temps 🙂 La tâche n’est pas critique, donc ce n’est pas grave d’attendre plus longtemps qu’elle termine ce qu’elle fait.

Pour désactiver le watchdog, il faut faire deux choses :

D’abord, inclure l’en-tête esp_task_wdt.h. Pour cela, ajoutez #include <esp_task_wdt.h> dans votre section d’includes.

Ensuite, faire en sorte que le watchdog ne réinitialise pas le contrôleur et attende plus longtemps. Pour cela, ajoutez esp_task_wdt_init(30, false); au début du code de votre tâche.

void manage_core_task(void *pv_parameters) {
    esp_task_wdt_init(30, false);
    // .... rest of the code ...
}

Cela règle le délai du watchdog à 30 SECONDES et désactive la réinitialisation du contrôleur s’il se déclenche.

Si vous voulez que le contrôleur se réinitialise quand même après le déclenchement du watchdog, changez le second paramètre de l’appel de fonction de false à true.

Configurer une YubiKey pour signer ses commits Git

Wed, 08 Jan 2020 00:00:00 GMT

J’utilise une YubiKey comme clé d’authentification à deux facteurs et pour signer mes commits Git. Jusqu’à il y a quelques jours, j’utilisais une YubiKey 4. Comme mon ordinateur actuel n’a aucun port USB-A, je jongle depuis un an avec des adaptateurs USB-A vers USB-C dans mon sac à dos, et utiliser la clé est devenu une vraie galère. C’est pour ça que j’ai décidé qu’il était temps de passer à ma « nouvelle » YubiKey 5C, et de ne plus avoir à jongler avec ces adaptateurs.

En fait, j’ai cette clé depuis un moment : je l’avais commandée en même temps qu’une YubiKey 4 de remplacement, à cause du problème du TPM Infineon qu’ils avaient identifié, mais ce n’est que maintenant que je me décide à passer à la nouvelle clé.

L’autre raison de le faire maintenant, c’est que mes anciennes clés GPG ont expiré et que j’ai dû les réémettre, donc je peux utiliser la clé pour signer mes commits Git.

La folie GPG

Si vous avez déjà eu affaire aux clés GPG (ou si c’est le cas en ce moment), vous savez qu’il peut être assez difficile de tout mettre en place correctement et en toute sécurité quand on ne l’a jamais fait. Garder les clés maîtresses hors ligne, faire circuler les clés publiques, réémettre les clés quand elles expirent, éventuellement les signer avec les clés précédentes pour les vérifier, révoquer des clés… Il n’est déjà pas facile de suivre les bonnes pratiques en théorie. Quand il s’agit de les appliquer en pratique, ça devient extrêmement compliqué.

La plupart des tutoriels en ligne expliquent comment générer ses clés en ligne de commande, en naviguant dans des menus au design peu commun, et c’est une vraie plaie à mettre en place. La plupart disent d’utiliser une machine hors ligne, comme un Raspberry PI, et/ou de générer les clés maîtresses et les sous-clés hors ligne, puis de garder la clé maîtresse loin de votre ordinateur.

🤯

Je me coltine ça chaque début de janvier depuis presque 4 ans. Je redoute le moment où j’obtiens l’erreur suivante, qui m’indique que mes clés de signature ont expiré.

error: gpg failed to sign the data
fatal: failed to write commit object

Cette année, j’ai décidé qu’il était temps d’essayer de rendre ce processus beaucoup plus simple, en utilisant la génération de certificats intégrée et en évitant toute la galère de la génération de clés GPG et compagnie.

Génération des clés directement sur la YubiKey

Il faut toujours passer par l’interface en ligne de commande, mais c’est un peu plus évident, car il y a moins d’étapes.

Il faut d’abord configurer la carte/l’appareil.

Configuration de la carte/de l’appareil

Lancez gpg --card-status dans le terminal et vous devriez voir quelque chose comme ceci :

Reader ………..: Yubico Yubikey 4 OTP U2F CCID
Application ID …: <Serial number>
Version ……….: 2.1
Manufacturer …..: Yubico
Serial number ….: <Device serial number>
Name of cardholder: unspecified
Language prefs …: en
Sex …………..: unspecified
URL of public key : \[not set\]
Login data …….: <e-mail or nothing>
Signature PIN ….: not forced
Key attributes …: rsa4096 rsa4096 rsa4096
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 0 3
Signature counter : 9

Si vous voyez quelque chose de similaire et qu’aucune erreur n’apparaît, vous pouvez continuer.

Lancez gpg --card-edit

Vous arriverez dans une interface en ligne de commande qui affiche les mêmes informations qu’au début, puis une invite de commande en bas : gpg/card>.

Tapez admin et appuyez sur Entrée.

Vous pouvez maintenant taper help pour découvrir comment modifier les informations du titulaire et les codes PIN de la carte.

Il y a une chose que vous DEVEZ faire : changer les codes PIN par défaut de la carte. Il y en a deux. Le premier est le code PIN que vous utilisez pour accéder aux clés de la carte. Le second est le PIN « Admin » ou PUK (Personal Unblocking Code, code de déblocage personnel).

Pour cela, tapez passwd et vous verrez un menu :

gpg/card> passwd  
gpg: OpenPGP card no. <Serial number> detected

1 - change PIN  
2 - unblock PIN  
3 - change Admin PIN  
4 - set the Reset Code  
Q - quit

Tapez 1 et suivez les instructions pour changer votre PIN. Le PIN par défaut est 123456.

Ensuite, choisissez 3 pour changer le PIN Admin. Celui par défaut est 12345678.

Une fois les deux PIN changés, revenez au menu principal pour terminer la mise à jour des informations de la clé.

Les commandes que vous pouvez utiliser sont :

name – pour changer le nom du titulaire
login – pour changer l’adresse e-mail ou l’identifiant du titulaire

Après cela, nous pouvons passer à la génération des clés proprement dite.

Génération des clés

Il est maintenant temps de générer les clés.

Pour cela, tapez generate.

On vous demandera Make off-card backup of encryption key? (Y/n), mais comme l’indique la documentation de YubiKey, il ne s’agit que d’une sauvegarde factice qui ne crée pas de sauvegarde complète des clés secrètes, donc peu importe que vous répondiez Yes ou No. Je réponds No(n).

S’il y a déjà des clés stockées sur la carte, on vous demandera si vous voulez les remplacer :

gpg: Note: keys are already stored on the card!

Replace existing keys? (y/N)

Assurez-vous de ne pas remplacer quelque chose d’important dont vous n’avez pas de sauvegarde, puis continuez avec Y. S’il y a quelque chose d’important, mieux vaut quitter tout le processus avec Ctrl+C.

On vous demandera le code PIN de la carte que vous avez défini plus tôt.

Ensuite, vous devrez choisir la durée de validité des clés :

Please specify how long the key should be valid.
        0 = key does not expire
      <n> = key expires in n days
     <n>w = key expires in n weeks
     <n>m = key expires in n months
     <n>y = key expires in n years
 Key is valid for? (0)

Si vous voulez que les clés ne soient valides qu’un an, tapez 1y.

On vous demandera de confirmer la date d’expiration. Vérifiez que tout est correct et confirmez.

Ensuite, on vous demandera de saisir les informations du propriétaire de la clé :

Is this correct? (y/N) y
GnuPG needs to construct a user ID to identify your key.
Real name: <Your name>
Email address: <Your e-mail>
Comment: <Comment is optional>
 You selected this USER-ID:
     "<Your name> <comment> <your e-mail>
 Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit?

Type `O` to confirm if everything seems correct.

Ensuite, on vous demandera votre PIN Admin ou PUK. C’est nécessaire, car cela effectue une opération d’écriture sur la carte.

Si tout est correct, la YubiKey se mettra à clignoter et continuera un bon moment (pour moi, environ cinq minutes).

Une fois terminé, vous verrez le message suivant :

gpg: key <Short ID> marked as ultimately trusted
gpg: revocation certificate stored as '/Users/bisko/.gnupg/openpgp-revocs.d/<LONG ID>.rev' public and secret key created and signed.

Notez bien le <Short ID>, car nous l’utiliserons plus tard.

À ce stade, vous pouvez quitter l’invite GPG avec quit ou Ctrl+C.

Il est maintenant temps de sauvegarder la clé publique, afin de pouvoir réutiliser la clé sur un autre ordinateur.

Pour cela, lancez la commande suivante :

gpg --armor --export <Short ID> > <Short ID>.asc

Cela exportera la clé publique dans un fichier nommé <Short ID>.asc. Il vous servira plus tard si vous voulez utiliser la YubiKey sur un autre ordinateur ou si vous perdez votre configuration GPG.

Pour restaurer la clé publique dans votre trousseau, il faut faire :

gpg --import < <Short ID>.asc
gpg: key <Short ID>: public key "Your Name <your@email>" imported
gpg: Total number processed: 1
gpg: imported: 1

Une remarque très importante ici. S’il s’agit d’une nouvelle installation de GPG ou d’un autre ordinateur, GPG ne reconnaîtra pas tout seul les clés présentes sur la carte. Vous devez lancer gpg --card-status pour qu’il lise la carte et détecte les clés qui s’y trouvent.

Configurer Git pour la signature

Pour configurer Git afin qu’il signe vos commits, vous devez ajouter ce qui suit à votre ~/.gitconfig.

Dans la section [user], ajoutez (ou mettez à jour) la ligne suivante :

signingkey = 0x<Short ID>

Ensuite, si vous voulez signer tous vos commits, ajoutez ce qui suit à la fin du fichier :

[gpg]
  program = /usr/local/bin/gpg
[commit]
  gpgsign = true

Git signera alors tous vos commits.

Pour configurer GitHub, vous devez ajouter votre clé publique à votre profil. Pour cela, allez dans GitHub -> Settings -> SSH and GPG keys -> New GPG key.

Vous verrez alors une zone de texte dans laquelle vous devez coller tout le contenu du fichier <Short ID>.asc que nous avons généré plus haut.

Si vous voulez copier le contenu du fichier (sur macOS), vous pouvez faire :

cat <Short ID>.asc | pbcopy

Cela copiera le contenu de tout le fichier dans le presse-papiers.

Collez-le dans la zone de texte sur GitHub et cliquez sur le bouton Add GPG key.

Après ça, vous pouvez essayer de faire un commit et un push vers GitHub, et vous devriez voir le joli badge Verified.

Débogage

Parfois, les choses ne fonctionnent pas du premier coup. Pour obtenir plus d’informations, vous pouvez essayer ce qui suit :

Signer avec GPG

Essayez d’abord de signer quelque chose avec la clé :

gpg -s <file>

Si ça échoue, essayez de comprendre pourquoi. Je ne suis pas expert, donc je ne pourrai pas vous aider sur ce point.

Regardez la sortie de Git avecGIT_TRACE=1 git commit -am “test”

Cela vous donnera le détail de tout ce que Git fait quand il essaie de faire le commit et de le signer. Cela devrait vous donner une idée de la raison de l’échec de la signature.

Vous pouvez aussi y voir que Git exécute la commande suivante :

/usr/local/bin/gpg --status-fd=2 -bsau <Key ID>

Vous pouvez essayer de l’exécuter manuellement pour voir si elle vous donne une meilleure erreur.

e1000e eth0: Detected Hardware Unit Hang

Wed, 18 Dec 2019 00:00:00 GMT

Récemment, mon serveur maison et hôte de VM a commencé à perdre sa connectivité réseau de façon aléatoire. De l’extérieur, on aurait dit qu’il fonctionnait toujours, mais impossible d’y accéder à distance, quelle que soit la méthode. L’adaptateur ethernet semblait actif d’après le switch, donc le problème devait se trouver quelque part côté logiciel.

Ce ne serait pas la première fois qu’un pilote est à l’origine d’une connexion réseau qui plante. Par le passé, je me suis déjà fait avoir par des pilotes WiFi buggés sur des machines Linux et Windows.

Après avoir fouillé un peu dans les logs système, je suis tombé sur ceci :

vmhost kernel: e1000e 0000:00:1f.6 eth0: Detected Hardware Unit Hang:
vmhost kernel: TDH <0>
vmhost kernel: TDT <1>
vmhost kernel: next_to_use <1>
vmhost kernel: next_to_clean <0>
vmhost kernel: buffer_info[next_to_clean]:
vmhost kernel: time_stamp <10fbc2f81>
vmhost kernel: next_to_watch <0>
vmhost kernel: jiffies <10fbc3871>
vmhost kernel: next_to_watch.status <0>
vmhost kernel: MAC Status <40080083>
vmhost kernel: PHY Status <796d>
vmhost kernel: PHY 1000BASE-T Status <7800>
vmhost kernel: PHY Extended Status <3000>
vmhost kernel: PCI Status <10>
vmhost kernel: e1000e 0000:00:1f.6 eth0: Reset adapter unexpectedly
vmhost kernel: vmbr0: port 1(eth0) entered disabled state

Ensuite, il réinitialisait l’adaptateur réseau, puis recommençait un peu plus tard, jusqu’à ce que la machine passe complètement hors ligne.

En cherchant des réponses en ligne, je suis tombé sur ce fil ServerFault.

Cause

D’après différentes sources et listes de rapports de bugs, la meilleure façon de reproduire le problème semble être de mettre l’appareil dans une situation de forte bande passante, c’est-à-dire de faire transiter de grandes quantités de données qui saturent l’interface.

Dans mon cas, ça arrivait généralement quand je diffusais des médias depuis le serveur Plex local vers un appareil. À cause de la façon dont le réseau est configuré, la VM Windows qui fait tourner Plex doit récupérer le fichier média depuis un partage réseau NFS sur un autre appareil, le transcoder dans la VM, puis l’envoyer à l’appareil de lecture.

Ça représente beaucoup de trafic réseau, généralement ~40-100 mbit/s, selon l’appareil qui lit le fichier et la qualité du fichier source.

Le même problème s’est manifesté en streamant des jeux via Steam Link vers notre Apple TV. La connexion est filaire, mais il n’est pas rare que le réseau tombe. Je pense que c’est lié au même problème, mais je garde un œil dessus pour voir si ça se reproduit après le correctif.

Correctif possible

Il semblerait qu’un correctif possible consiste à désactiver GSO (Generic Segmentation Offload), TSO (TCP Segmentation Offload) et GRO (Generic Receive Offload) sur l’interface réseau* :

ethtool -K eth0 gso off gro off tso off

J’ai appliqué ça à ma configuration et j’attends de voir si ça résout vraiment le problème sur le long terme.

Notes de bas de page

* Ces options servent à déléguer la segmentation des paquets au contrôleur d’interface réseau afin de réduire l’utilisation du CPU de la machine. Plus de détails dans cet article de Wikipédia.

Snippets : faire tourner un registre d'images Docker local/privé avec swarm

Fri, 11 Oct 2019 00:00:00 GMT

Aujourd’hui, j’essayais de générer une image Docker à partir d’un projet Node.js et je voulais la déployer sur mon swarm de test local.

Malheureusement, quand on construit une image Docker en local, elle n’est stockée et accessible que sur le nœud où elle a été créée, et les autres nœuds du swarm n’y ont pas accès.

Pour régler ça, il faut pousser l’image vers un registre Docker où tous les nœuds du swarm pourront la récupérer.

Création du registre

Pour instancier un service de registre dans le swarm, lancez :

docker service create —name registry —publish 5000:5000 registry:latest

Cela va créer le service de registre et l’exécuter dans le swarm, le rendant accessible à tous les nœuds du swarm.

Pousser une image vers le registre

Pour pousser une image vers le registre, il y a deux choses à faire : taguer l’image, puis la pousser.

Voici un exemple pour construire et taguer l’image en une seule fois :

docker build . -t localhost.localdomain:5000/:latest

Et comment la pousser vers le registre :

docker push localhost.localdomain:5000/:latestUtiliser l’image dans un service/conteneur/etc.

Pour utiliser l’image dans un service ou un conteneur, on indique le chemin complet vu plus haut, c’est-à-dire localhost.localdomain:5000/<image-name>:latest.

Les nœuds du swarm auront accès à l’image et pourront la récupérer et l’exécuter.

Remarque importante sur l’adresse du registre

Dans la plupart des tutoriels en ligne, l’URL du registre est donnée sous la forme localhost:5000. Malheureusement, ça ne fonctionne pas et on obtient généralement un timeout quand on essaie de l’utiliser. Si on la remplace par localhost.localdomain, ça marche !

Je ne sais pas pourquoi ça se passe ainsi, alors que localhost et localhost.localdomain se résolvent tous les deux en 127.0.0.1.

Snippets : remapper la touche Section des claviers Apple sur l'accent grave ( § vers ` )

Wed, 31 Jul 2019 00:00:00 GMT

J’utilise des claviers Apple depuis un moment, mais quand on vit en Europe, il n’est pas facile de trouver les modèles avec la disposition US auxquels je suis habitué.

Sur macOS, il existe une façon « facile » de remapper le clavier avec une simple commande dans le terminal :

watch -n1 -x hidutil property -m ’{“ProductID”:592, “VendorID”:1452}’ —set ’{“UserKeyMapping”:[{“HIDKeyboardModifierMappingSrc”:0x700000035,“HIDKeyboardModifierMappingDst”:0x700000064}]}’

Ce que fait ce morceau de code, c’est changer le mappage de la touche Section ( § ) pour qu’elle écrive la touche accent grave/tilde ( `/ ~ ).

La partie watch -n1 -x répète l’opération toutes les secondes, parce que macOS aime parfois perdre le réglage, généralement quand l’ordinateur se met en veille ou quand le clavier est débranché puis rebranché.

Notez que sur certaines versions de macOS, l’utilitaire watch n’est pas installé et doit être récupéré via quelque chose comme Homebrew ou MacPorts.

Le code ci-dessus fonctionne avec le clavier externe Apple en USB, disposition européenne avec lettres bulgares. Il faudra peut-être ajuster légèrement les valeurs hexadécimales des touches pour d’autres types de claviers.

Une variante de la commande fonctionne bien pour le même type de clavier sur le MacBook Pro lui-même. Il suffit d’inverser la position des valeurs 0x700000035 et 0x700000064.

J’ai pensé à écrire un outil pour faire ça automatiquement, mais pour l’instant, je crois qu’il vaut mieux investir dans un nouveau clavier avec la bonne disposition 🙂

Réinitialiser/Redémarrer la télécommande de l'Apple TV

Sun, 17 Feb 2019 00:00:00 GMT

Hier soir, pendant la visite d’invités, j’ai réussi à plonger notre télécommande Apple TV sous l’eau. Le manque de sommeil et des verres instables, ça donne des accidents.

La télécommande fonctionnait très bien hier soir, mais aujourd’hui, elle ne marche plus. Aucune réaction, quoi que je fasse. J’ai essayé de la cogner contre ma main, de la secouer pour en faire sortir l’eau. Ça n’a servi à rien.

On a pensé qu’elle était fichue et on a commencé à chercher le sachet de riz dans les placards.

Je suis allé sur internet, surtout pour rire, pour voir si je pouvais essayer de la « redémarrer ».

Un guide bien utile m’a indiqué de maintenir enfoncés les boutons Volume Plus et Menu pendant 2-3 secondes pour réinitialiser la télécommande et la mettre en mode d’appairage.

J’ai été vraiment surpris quand ça a vraiment marché !

Donc, si quelque chose cloche, essayez d’abord de réinitialiser la télécommande. Si ça ne marche pas, vous pourrez toujours tenter le riz et l’intervention matérielle.

TL;DR;

Maintenez Menu + Volume Plus pendant 2-3 secondes
Attendez quelques secondes
Essayez d’interagir avec l’Apple TV

bisko.be - Dev

Faire tourner Ollama avec de vieux GPU sur CachyOS

TL;DR;

L’heure du récit

[Linux] Récupérer une session `apt dist-upgrade` déconnectée

[Linux] Syncthing – système de fichiers en lecture seule lorsqu’il tourne en tant que service

[Linux] Exécuter plusieurs commandes sur plusieurs serveurs en parallèle

Itération 1 : un script Python maison

Itération 2 : pssh

La version TL;DR; :

Deviner le mot de passe numérique d'un fichier zip uniquement avec des utilitaires en ligne de commande

Gérer le code spaghetti en PHP : utiliser des fonctions anonymes pour extraire des morceaux de code de template

Arduino/ESP32 : désactiver le watchdog des tâches

Configurer une YubiKey pour signer ses commits Git

La folie GPG

Génération des clés directement sur la YubiKey

Configuration de la carte/de l’appareil

Génération des clés

Configurer Git pour la signature

Débogage

Signer avec GPG

e1000e eth0: Detected Hardware Unit Hang

Snippets : faire tourner un registre d'images Docker local/privé avec swarm

Snippets : remapper la touche Section des claviers Apple sur l'accent grave ( § vers ` )

Réinitialiser/Redémarrer la télécommande de l'Apple TV

Itération 2 : `pssh`