Fedora

Suite à mon problème de clavier son mon Thinkpad T14s : "Suddenly, the “v” key on my Thinkpad T14s Gen 3 returns keycode 47 instead of 55, hardware failure?", je teste l'outil keyd, qui permet de reconfigurer des touches de clavier.

Je souhaite utiliser la touche <Caps-Lock> pour afficher . et <Shift>+<Caps-Lock> par :.

Je commence par installer le package keyd pour Fedora (comme documenté ici) :

$ sudo dnf copr enable alternateved/keyd
$ sudo dnf install keyd

Je défini le fichier de configuration pour mapper <Caps-Lock> vers la touche <v> :

$ sudo tee /etc/keyd/default.conf > /dev/null <<EOF
[ids]
*

[main]
capslock = v
EOF

Je lance le service keyd :

$ sudo systemctl enable --now keyd

Et voila, ça fonctionne, il faut juste que je prenne l'habitude à taper la touche <Caps-Lock> à la place de <.>. Je me demande combien de temps cela va me prendre !

Depuis ce matin, la touche <v> du clavier de mon Thinkpad T14s ne fonctionne plus normalement. Maintenant, la touche <v> affiche <m> et la touche <m> affiche toujours <m> 🤔 (en Azerty ISO Layout).

Au départ, j'ai pensé que j'avais un problème au niveau de mon OS (Fedora), que la configuration du clavier qui avait changé par erreur…
J'ai branché mon clavier externe et je constate qu'il n'a pas de problème, la touche <v> affiche <v>.

Pourtant, tout fonctionnait bien quelques minutes avant. J'ai fait des mises à jour d'OS et de firmware il y a plus d'une semaine.

J'ai shutdown totalement le laptop, j'ai relancé et le problème était toujours présent 🤔.

J'ai ensuite redémarré et je suis entré dans l'outil de diagnostic Lenovo (touche <F10> au démarrage) et là, horreur, le problème est aussi présent dans le BIOS 😯😭.

Voici une vidéo : https://youtu.be/88335YSr6AQ

J'ai démonté la touche <v> pour la nettoyer sans grand espoir, étant donné qu'elle fonctionnait mécaniquement très bien. J'ai eu ensuite d'énormes difficultés à la remonter… et maintenant elle a un petit défaut 😭.

Désespéré, j'ai posté deux messages :

• Sur le forum Lenovo : Suddenly, the “v” key on my Thinkpad T14s Gen 3 returns keycode 47 instead of 55, hardware failure?
• Sur Reddit : Suddenly, the “v” key on my Thinkpad T14s Gen 3 returns keycode 47 instead of 55, hardware failure?

Mon thread Fediverse : https://social.coop/@stephane_klein/113811173930863045

Je croise les doigts ! 🤞

Un ami m'a partagé Zstandard (zstd), un algorithme de compression.

Il y a 2 ans, j'ai étudié et activé Brotli dans mes containers nginx, voir la note : Mise en œuvre du module Nginx Brotli.

Je viens de trouver un module zstd pour nginx : https://github.com/tokers/zstd-nginx-module

Mon ami m'a partagé cet excellent article : Choosing Between gzip, Brotli and zStandard Compression. Très complet, il explique tout, contient des benchmarks…

Voici ce que je retiens.

Brotli a été créé par Google, Zstandard par Facebook :

Zstandard is a newer compression method developed by Facebook.

source

Je lis sur canIuse, le support Zstandard a été ajouté à Chrome en mars 2024 et à Firefox en mai 2024, c'est donc une technologie très jeune coté browser.

Benchmark sur le dépôt officiel de Zstandard :

source

J'ai trouvé ces threads Hacker News :

• 2020-05-07 : Introduce ZSTD compression to ZFS
• 2022-08-20 : AWS switch from gzip to zstd – about 30% reduction in compressed S3 storage

Zstandard semble être fortement adopté au niveau de l'écosystème des OS Linux :

The Linux kernel has included Zstandard since November 2017 (version 4.14) as a compression method for the btrfs and squashfs filesystems.

source

Packages Ubuntu et Debian :

In March 2018, Canonical tested the use of zstd as a deb package compression method by default for the Ubuntu Linux distribution. Compared with xz compression of deb packages, zstd at level 19 decompresses significantly faster, but at the cost of 6% larger package files. Support was added to Debian in April 2018

source

Packages Fedora :

Fedora added ZStandard support to rpm in May 2018 (Fedora release 28) and used it for packaging the release in October 2019 (Fedora 31). In Fedora 33, the filesystem is compressed by default with zstd.

source

#JeMeDemande si dans mes projets de doit utiliser Zstandard plutôt que Brotli 🤔.

Je pense avoir trouver une réponse ici :

The research I’ve shared in this article also shows that for many sites Brotli will provide better compression for static content. Zstandard could potentially provide some benefits for dynamic content due to its faster compression speeds. Additionally:

• ...
• For dynamic content
  • Brotli level 5 usually result in smaller payloads, at similar or slightly slower compression times.
  • zStandard level 12 often produces similar payloads to Brotli level 5, with compression times faster than gzip and Brotli.
• For static content
  • Brotli level 11 produces the smallest payloads
  • zStandard is able to apply their highest compression levels much faster than Brotli, but the payloads are still smaller with Brotli.

source

#JaimeraisUnJour prendre le temps d'installer zstd-nginx-module à mon image Docker nginx-brotli-docker (ou alors d'en trouver une déjà existante).

Dans la note 2024-12-31_1853, j'ai présenté sish-playground qui permet de self host sish.

Je souhaite maintenant lister des alternatives à ngrok qui proposent des services gérés.

Quand je parle d'alternative à ngrok, il est question uniquement de la fonctionnalité d'origine de ngrok en 2013 : exposer des serveurs web locaux (localhost) sur Internet via une URL publique. ngrok nomme désormais ce service "Developer Preview".

Offre managée de sish

Les développeurs de sish proposent un service managé à 2 € par mois.

Ce service permet l'utilisation de noms de domaine personnalisés : https://pico.sh/custom-domains#tunssh.

Test de la fonctionnalité "Developer Preview" de ngrok

J'ai commencé par créer un compte sur https://ngrok.com.

Ensuite, une fois connecté, la console web de ngrok m'invite à installer le client ngrok. Voici la méthode que j'ai suivie sur ma Fedora :

$ wget https://bin.equinox.io/c/bNyj1mQVY4c/ngrok-v3-stable-linux-amd64.tgz -O ~/Downloads/ngrok-v3-stable-linux-amd64.tgz
$ sudo tar -xvzf ~/Downloads/ngrok-v3-stable-linux-amd64.tgz -C /usr/local/bin
$ ngrok --help
ngrok version 3.19.0
$ ngrok config add-authtoken 2r....RN
$ ngrok http http://localhost:8080
ngrok                                                                                                                                                         (Ctrl+C to quit)

👋 Goodbye tunnels, hello Agent Endpoints: https://ngrok.com/r/aep

Session Status                online
Account                       Stéphane Klein (Plan: Free)
Version                       3.19.0
Region                        Europe (eu)
Web Interface                 http://127.0.0.1:4040
Forwarding                    https://2990-2a04-cec0-107a-ea02-74d7-2487-cc11-f4d2.ngrok-free.app -> http://localhost:8080

Connections                   ttl     opn     rt1     rt5     p50     p90
                              0       0       0.00    0.00    0.00    0.00

Cette fonctionnalité de ngrok est gratuite.

Toutefois, pour pouvoir utiliser un nom de domaine personnalisé, il est nécessaire de souscrire à l'offre "personal" à $8 par mois.

Test de la fonctionnalité Tunnel de Cloudflare

Pour exposer un service local sur Internet via une URL publique avec cloudflared, je pense qu'il faut suivre la documentation suivante : Create a locally-managed tunnel (CLI).

J'ai trouvé sur cette page, le package rpm pour installer cloudflared sous Fedora :

$ wget https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-x86_64.rpm -O /tmp/cloudflared-linux-x86_64.rpm
$ sudo rpm -i /tmp/cloudflared-linux-x86_64.rpm
$ cloudflared --version
cloudflared version 2024.12.2 (built 2024-12-19-1724 UTC)

Voici comment exposer un service local sur Internet via une URL publique avec cloudflared sans même créer un compte :

$ cloudflared tunnel --url http://localhost:8080
...
Requesting new quick Tunnel on trycloudflare.com...
Your quick Tunnel has been created! Visit it at (it may take some time to be reachable):
https://manufacturer-addressing-surgeon-tried.trycloudflare.com

Après cela, le service est exposé sur Internet sur l'URL suivante : https://manufacturer-addressing-surgeon-tried.trycloudflare.com.

Voici maintenant la méthode pour exposer un service sur un domaine spécifique.

Pour cela, il faut que le nom de domaine soit géré pour les serveurs DNS de cloudflare.
Au moment où j'écris cette note, c'est le cas pour mon domaine stephane-klein.info :

$ dig NS stephane-klein.info +short
ali.ns.cloudflare.com.
sri.ns.cloudflare.com.

Ensuite, il faut lancer :

$ cloudflared tunnel login

Cette commande ouvre un navigateur, ensuite il faut se connecter à cloudflare et sélectionner le nom de domaine à utiliser, dans mon cas j'ai sélectionné stephane-klein.info.

Ensuite, il faut créer un tunnel :

$ cloudflared tunnel create mytunnel
Tunnel credentials written to /home/stephane/.cloudflared/61b0e52f-13e3-4d57-b8da-6c28ff4e810b.json. …

La commande suivante, connecte le tunnel mytunnel au hostname mytunnel.stephane-klein.info :

$ cloudflared tunnel route dns mytunnel mytunnel.stephane-klein.info
2025-01-06T17:52:10Z INF Added CNAME mytunnel.stephane-klein.info which will route to this tunnel tunnelID=67db5943-1f16-4b4a-a307-e8ceeb01296c

Et, voici la commande pour exposer un service sur ce tunnel :

$ cloudflared tunnel --url http://localhost:8080 run mytunnel

Après cela, le service est exposé sur Internet sur l'URL suivante : https://mytunnel.stephane-klein.info.

Pour finir, voici comment détruire ce tunnel :

$ cloudflared tunnel delete mytunnel

J'ai essayé de trouver le prix de ce service, mais je n'ai pas trouvé. Je pense que ce service est gratuit, tout du moins jusqu'à un certain volume de transfert de données.

#JeMeDemande comment lancer une image Docker pour l'architecture arm64 sur une architecture Intel sous Fedora ?

Par défaut, l'exécution de cette image Docker sous Intel avec l'option --platform linux/arm64 ne fonctionne pas :

$ docker run --rm -it --platform linux/arm64 hasura/graphql-engine:v2.43.0 bash
exec /usr/bin/bash: exec format error

J'ai consulté et suivi la documentation Docker officielle suivante : Install QEMU manually.

$ docker run --privileged --rm tonistiigi/binfmt --install all
installing: arm64 OK
installing: arm OK
installing: ppc64le OK
installing: riscv64 OK
installing: mips64le OK
installing: s390x OK
installing: mips64 OK
{
  "supported": [
    "linux/amd64",
    "linux/arm64",
    "linux/riscv64",
    "linux/ppc64le",
    "linux/s390x",
    "linux/386",
    "linux/mips64le",
    "linux/mips64",
    "linux/arm/v7",
    "linux/arm/v6"
  ],
  "emulators": [
    "qemu-aarch64",
    "qemu-arm",
    "qemu-mips64",
    "qemu-mips64el",
    "qemu-ppc64le",
    "qemu-riscv64",
    "qemu-s390x"
  ]
}

Après cela, je constate que j'arrive à lancer avec succès une image arm64 sous processeur Intel :

$ docker run --rm -it --platform linux/arm64 hasura/graphql-engine:v2.43.0 bash

root@bf74bfb8bc35:/# graphql-engine version
Hasura GraphQL Engine (Pro Edition): v2.43.0

J'ai pris un peu de temps pour explorer le repository tonistiigi/binfmt.
Je n'ai pas compris quelle est l'interaction entre les éléments installés par cette image et docker-engine.
Je constate que cette image a été créée en 2019 par deux développeurs de Docker : CrazyMax (un Français) et Tõnis Tiigi.

Dans le projet "Projet 17 - Créer un POC de création d'une app smartphone avec Capacitor" je disais :

• Essayer d'utiliser l'offre Apple Mac mini M1 de Scaleway pour builder l'app pour iOS

Voici mon retour d'expérience d'utilisation de l'offre Scaleway Apple Silicon.

Voici la liste des images MacOS disponibles :

$ scw apple-silicon os list
ID                                    NAME                LABEL               IMAGE URL                                                                       FAMILY   IS BETA  VERSION  XCODE VERSION
59bf09f1-5584-469d-a0f6-55c8fee1ab81  macos-ventura-13.6  macOS Ventura 13.6  https://scw-apple-silicon.s3.fr-par.scw.cloud/scw-console/os/macos-ventura.png  Ventura  false    13.6     14
e08d1e5d-b4b9-402a-9f9a-97732d17e374  macos-sonoma-14.4   macOS Sonoma 14.4   https://scw-apple-silicon.s3.fr-par.scw.cloud/scw-console/os/macos-sonoma.png   Sonoma   false    14.4     15
7a8d85fb-781a-4212-8e47-240ec0c3d23f  macos-sequoia-15.0  macOS Sequoia 15.0  https://scw-apple-silicon.s3.fr-par.scw.cloud/scw-console/os/macos-sequoia.png  Sequoia  true     15.0     16

Voici la liste des types de serveurs disponibles dans la zone fr-par-3 :

$ SCW_DEFAULT_ZONE="fr-par-3" scw apple-silicon server-type list
Name  CPU                 Memory  Disk    Stock       Minimum Lease Duration
M1-M  Apple M1 (8 cores)  8.0 GB  256 GB  high stock  1 days

Et la liste dans la zone fr-par-1 :

$ SCW_DEFAULT_ZONE="fr-par-1" scw apple-silicon server-type list
Name  CPU                      Memory  Disk    Stock       Minimum Lease Duration
M2-M  Apple M2 (8 cores)       16 GB   256 GB  high stock  1 days
M2-L  Apple M2 Pro (10 cores)  16 GB   512 GB  high stock  1 days

Je souhaite installer un serveur de type M1-M à 0,11 € HT / heure, soit 2,64 € HT / jour, 80,3 € HT / mois.

Lors de ma première tentative, j'ai essayé de créer un serveur avec la commande suivante :

$ scw apple-silicon server create name=capacitor zone=fr-par-3 "$SCW_PROJECT_ID" M1-M 7a8d85fb-781a-4212-8e47-240ec0c3d23f
Invalid argument '46ad009f-xxxxxx': arg name must only contain lowercase letters, numbers or dashes

Suite à cette erreur, j'ai créé l'issue siuvante : Reduce"scw apple-silicon server create" helper message ambiguity.

$ scw apple-silicon server create name=capacitor project-id=${SCW_PROJECT_ID}  type=M1-M os-id=7a8d85fb-781a-4212-8e47-240ec0c3d23f zone=fr-par-3

Mais l'OS n'était pas trouvé, je me suis rendu compte que cette image OS n'était pas disponible dans la zone fr-par-3.

$ SCW_DEFAULT_ZONE="fr-par-3" scw apple-silicon os list
ID                                    NAME                LABEL               IMAGE URL                                                                       FAMILY   IS BETA  VERSION  XCODE VERSION
59bf09f1-5584-469d-a0f6-55c8fee1ab81  macos-ventura-13.6  macOS Ventura 13.6  https://scw-apple-silicon.s3.fr-par.scw.cloud/scw-console/os/macos-ventura.png  Ventura  false    13.6     14
e08d1e5d-b4b9-402a-9f9a-97732d17e374  macos-sonoma-14.4   macOS Sonoma 14.4   https://scw-apple-silicon.s3.fr-par.scw.cloud/scw-console/os/macos-sonoma.png   Sonoma   false    14.4     15

Voici finalement la commande de création de serveur qui a fonctionné avec succès :

$ scw apple-silicon server create name=capacitor project-id=$SCW_PROJECT_ID  type=M1-M os-id=e08d1e5d-b4b9-402a-9f9a-97732d17e374 zone=fr-par-3
ID              bb34d8ef-6305-4104-801c-1cf1b6b0f99f
Type            M1-M
Name            capacitor
ProjectID       46ad009f-xxxx
OrganizationID  215d7434-xxxx
IP              51.xxx.xxx.xxx
VncURL          vnc://m1:xxxx@51.xxx.xxx.121:5900
SSHUsername     m1
SudoPassword    xxxxxxx
Os              ID            e08d1e5d-b4b9-402a-9f9a-97732d17e374
Name          macos-sonoma-14.4
Label         macOS Sonoma 14.4
ImageURL      https://scw-apple-silicon.s3.fr-par.scw.cloud/scw-console/os/macos-sonoma.png
Family        Sonoma
IsBeta        false
Version       14.4
XcodeVersion  15

CompatibleServerTypes:
[M1-M M2-M M2-L]
Status             starting
CreatedAt          now
UpdatedAt          now
DeletableAt        23 hours from now
DeletionScheduled  false
Zone               fr-par-3

Voici le serveur créé :

$ scw apple-silicon server list
ID                                    TYPE  NAME       PROJECT ID
bb34d8ef-6305-xxxxx  M1-M  capacitor  46ad009f-54bc-4125-xxxxxx

Le serveur est passé en ready après environ 1min.

$ scw apple-silicon server get bb34d8ef-6305-xxxxxxx
...

CompatibleServerTypes:
[M1-M M2-M M2-L]
Status             ready
...
DeletableAt        23 hours from now
DeletionScheduled  false
...

Je peux me connecter directement en ssh au serveur :

$ ssh m1@xxx.xxx.xx.xxx
Last login: Wed Nov 20 16:22:10 2024
m1@bb34d8ef-6305-4104-801c-1cf1b6b0f99f ~ % uname -a
Darwin bb34d8ef-6305-4104-801c-1cf1b6b0f99f 23.4.0 Darwin Kernel Version 23.4.0: Fri Mar 15 00:12:41 PDT 2024; root:xnu-10063.101.17~1/RELEASE_ARM64_T8103 arm64

Je peux aussi me connecter au serveur via VNC (lien vers la documentation à ce sujet).

Installation des dépendances sous Fedora :

$ sudo dnf install -y remmina remmina-plugins-vnc

J'utilise le client VNC nommé Remmina.

$ remmina -c vnc://m1:xxxxx@51.xxxx.xxx.xxxx:5900

Les paramètres vnc et le mot de passe de l'user m1 sont disponibles dans la sortie de :

$ scw apple-silicon server get bb34d8ef-6305-xxxxxxx -o json
{
  "id": "bb34d8ef-6305-4104-xxxx-xxxxxxxxx",
  ...
  "vnc_url": "vnc://m1:xxxx@xxx.xxx.xxx.xxx:5900",
  "ssh_username": "m1",
  "sudo_password": "bTgkdiVUs7yT",
  ...
}

Il est possible de coller le mot de passe via la fonctionnalité « Envoyer le contenu du presse-papiers comme une saisie au clavier » de Remmina :

Attention, la réinstallation d'un serveur Apple Silicon prend au moins 45min.

J'ai implémenté des scritps de déploiement d'un Apple Silicon dans le POC : poc-capacitor.

Prochaine étape du Projet 17 : Setup les iOS Requirements de Capacitor sur ce serveur Apple Silicon.

#iteration Projet 17 - Créer un POC de création d'une app smartphone avec Capacitor.

---

Dans la note 2024-11-19_1029, je disais :

Pour utiliser Capacitor, j'ai besoin d'installer certains éléments.

In order to develop Android applications using Capacitor, you will need two additional dependencies:

• Android Studio
• An Android SDK installation

Je me demande si Android Studio est optionnel ou non.

La réponse est non, Android Studio n'est pas nécessaire, ni pour compiler l'application, ni pour la lancer dans un émulateur Android. Android SDK est suffisant.

J'ai utilisé le plugin Mise https://github.com/Syquel/mise-android-sdk pour installer les "Android Requirements" de Capacitor. Les instructions détaillées pour Fedora sont listées dans le README.md du repository : https://github.com/stephane-klein/poc-capacitor/tree/4238e80f84a248fdb9e5bb86c10bea8b9f0fdade.

Fedora 41 version stable est sortie le 29 octobre 2024, 7 jours plus tard, j'ai upgrade mon Thinkpad T14s AMD Gen 3 de la version 40 vers la version 41.

J'ai suivi la méthode officielle de mise à jour :

# dnf install dnf-plugin-system-upgrade
# dnf upgrade --refresh
# dnf clean all
# dnf system-upgrade download --releasever=41
# dnf system-upgrade reboot

et cela c'est déroulé avec succès.

Après 1h d'utilisation, je n'ai observé aucune régression.

J'espère que cette version va régler ce problème.

Voir aussi : Upgrade de ma workstation de Fedora 39 vers 40.

Nouvelle #iteration de Projet 14.

Pour traiter ce problème, je souhaite essayer de remplacer Vagrant Host Manager par vagrant-dns.

-- from

Résultat : j'ai migré de Vagrant Host Manager vers vagrant-dns avec succès 🙂.

Voici le commit : lien vers le commit.

Voici quelques explications de la configuration Vagrantfile.

Les lignes suivantes permettent d'utiliser la seconde IP des machines virtuelles pour identifier les identifier (renseignés par le serveur DNS).

  config.dns.ip = -> (vm, opts) do
    ip = nil
    vm.communicate.execute("hostname -I | cut -d ' ' -f 2") do |type, data|
      ip = data.strip if type == :stdout
    end
    ip
  end

La commande hostname retourne les deux IP de la machine virtuelle :

vagrant@server1:~$ hostname -I
10.0.2.15 192.168.56.22

La commande hostname -I | cut -d ' ' -f 2 capture la seconde IP, ici 192.168.56.22.

La configuration DNS qui retourne cette IP est consultable via :

$ vagrant dns -l
/server1.vagrant.test/ => 192.168.56.22
/server2.vagrant.test/ => 192.168.56.23
/grafana.vagrant.test/ => 192.168.56.23
/loki.vagrant.test/ => 192.168.56.23

Autre subtilité :

vb.customize ["modifyvm", :id, "--natdnshostresolver1", "on"]

Cette ligne configure la machine virtuelle pour qu'elle utilise le serveur DNS de vagrant-dns.
Cela permet de résoudre les noms des autres machines virtuelles. Exemple :

vagrant@server1:~$ resolvectl query server2.vagrant.test
server2.vagrant.test: 192.168.56.23            -- link: eth0

-- Information acquired via protocol DNS in 12.3ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network

---

En mettant en place vagrant-dns sur ma workstation qui tourne sous Fedora, j'ai rencontré la difficulté suivante.

J'avais la configuration suivante installée :

$ cat /etc/systemd/resolved.conf.d/csd.conf
[Resolve]
DNS=10.57.40.1
Domains=~csd

Elle me permet de résoudre les hostnames des machines qui appartiennent à un réseau privé exposé via OpenVPN (voir cette note).

Voici ma configuration complète de systemd-resolved :

$ systemd-analyze cat-config systemd/resolved.conf
# /etc/systemd/resolved.conf

...

[Resolve]
...

# /etc/systemd/resolved.conf.d/1-vagrant-dns.conf
# This file is generated by vagrant-dns
[Resolve]
DNS=127.0.0.1:5300
Domains=~test

# /etc/systemd/resolved.conf.d/csd.conf
[Resolve]
DNS=10.57.40.1
Domains=~csd

Quand je lançais resolvectl query server2.vagrant.test pour la première fois après redémarrage de sudo systemctl restart systemd-resolved, tout fonctionnait correctement :

$ resolvectl query server2.vagrant.test
server2.vagrant.test: 192.168.56.23

-- Information acquired via protocol DNS in 7.5073s.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network

Mais, la seconde fois, j'avais l'erreur suivante :

$ resolvectl query server2.vagrant.test
server2.vagrant.test: Name 'server2.vagrant.test' not found

Ce problème disparait si je supprime /etc/systemd/resolved.conf.d/csd.conf.

Je n'ai pas compris pourquoi. D'après la section "Protocols and routing" de systemd-resolved, le serveur 10.57.40.1 est utilisé seulement pour les hostnames qui se terminent par .csd.

J'ai activé les logs de systemd-resolved au niveau debug avec

$ sudo resolvectl log-level debug
$ journalctl -u systemd-resolved -f

Voici le contenu des logs lors de la première exécution de resolvectl query server2.vagrant.test : https://gist.github.com/stephane-klein/506a9fc7d740dc4892e88bfc590bee98.

Voici le contenu des logs lors de la seconde exécution de resolvectl query server2.vagrant.test : https://gist.github.com/stephane-klein/956befc280ef9738bfe48cdf7f5ef930.

J'ai l'impression que la ligne 13 indique que le cache de systemd-resolved a été utilisé et qu'il n'a pas trouvé de réponse pour server2.vagrant.test. Pourquoi ? Je ne sais pas.

Ligne 13 : NXDOMAIN cache hit for server2.vagrant.test IN A

Ensuite, je supprime /etc/systemd/resolved.conf.d/csd.conf :

$ sudo rm /etc/systemd/resolved.conf.d/csd.conf

Je relance systemd-resolved et voici le contenu des logs lors de la seconde exécution de resolvectl query server2.vagrant.test : https://gist.github.com/stephane-klein/9f87050524048ecf9766f9c97b789123#file-systemd-resolved-log-L11

Je constate que cette fois, la ligne 11 contient : Cache miss for server2.vagrant.test IN A.

Pourquoi avec .csd le cache retourne NXDOMAIN et sans .csd, le cache retourne Cache miss et systemd-resolved continue son algorithme de résosultion du hostname ?

Je soupçonne systemd-resolved de stocker en cache la résolution de server2.vagrant.test par le serveur DNS 10.57.40.1. Si c'est le cas, je me demande pourquoi il fait cela alors qu'il est configuré pour les hostnames qui se terminent par .csd 🤔.

---

Autre problème rencontré, la latence de réponse :

$ resolvectl query server2.vagrant.test
server2.vagrant.test: 192.168.56.23

-- Information acquired via protocol DNS in 7.5073s.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network

La réponse est retournée en 7 secondes, ce qui ne me semble pas normal.

J'ai découvert que je n'ai plus aucune latence si je passe le paramètre DNSStubListener à no :

$ sudo cat <<EOF > /etc/systemd/resolved.conf.d/0-vagrant-dns.conf
[Resolve]
DNSStubListener=no
EOF
$ sudo systemctl restart systemd-resolved
$ resolvectl query server2.vagrant.test
server2.vagrant.test: 192.168.56.23

-- Information acquired via protocol DNS in 2.9ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network

Le temps de réponse passe de 7.5s à 2.9ms. Je n'ai pas compris la signification de ma modification.

---

Je récapitule, pour faire fonctionner correctement vagrant-dns sur ma workstation Fedora j'ai dû :

• supprimer /etc/systemd/resolved.conf.d/csd.conf
• et paramétrer DNSStubListener à no

Jusqu'à ce soir, j'installais sous Fedora des packages qui vennait du dépôt RPM Fusion sans vraiment avoir étudié ce qu'était-ce repository. Je viens de me renseigner et voici ce que j'ai appris.

"RPM Fusion" est l'équivalent des dépôts "contrib et non-free" chez Debian ou "universe et multiverse" chez Ubuntu.

Le terme "Fusion" dans "RPM Fusion" fait référence à l'origine du dépôt. RPM Fusion est né de la fusion de plusieurs dépôts tiers qui existaient avant sa création en 2007-2008, tels que : Livna, Freshrpms et Dribble.