Page de recherche dans les notes du jardin numérique de Stéphane Klein

Dans le cadre du Projet 34 - "Déployer un cluster k3s et Kubevirt sous CoreOS dans mon Homelab", j'étudie CoreOS.

Dans la page "Fedora CoreOS Release Notes stable" je vois quelques packages mis en avant :

Je constate que CoreOS installe par défaut containerd, moby-engine et podman.

Information de type #mémento #mémo au sujet de containerd, moby-engine et podman.

Kubernetes intéragie directement avec containerd.
Depuis 2017, Docker est basé sur containerd + moby-engine. Sous Fedora, la commande docker est installée par le package docker-cli.
podman est une alternative rootless à Docker. podman n'est pas basé sur containerd, ni moby-engine.

Note de type #mémento #mémo au sujet des fonctionnalités network de QEMU.

Pour bien comprendre le fonctionnement de la configuration network de QEMU, il est important de bien saisir deux concepts :

les "virtual network device" (-device)
les "network backend" (-netdev)

There are two parts to networking within QEMU:

the virtual network device that is provided to the guest (e.g. a PCI network card).

the network backend that interacts with the emulated NIC (e.g. puts packets onto the host's network).

source

Voici toute la liste des network backend supportés par QEMU :

$ qemu-system-x86_64 -netdev help
Available netdev backend types:
socket
stream
dgram
hubport
tap
user
l2tpv3
bridge
af-xdp
vhost-user
vhost-vdpa

Dans cette note, je m'intéresse uniquement aux backend user, tap et bridge.

Le network backend user permet uniquement des accès sortant de la machine virtuelle vers Internet, mais pas l'inverse sans configurer un forwarding de port.
La configuration s'effectue via les options -netdev et -device :

$ qemu-system-x86_64 \
    ... \
    -netdev user,id=n1 \      # configuration du network backend
    -device e1000,netdev=n1 \ # virtual network device
    ...

La version 2.12 de QEMU (2018) propose une alternative plus simplifiée avec l'option -nic. Voici une exemple équivalent à la configuration ci-dessus :

$ qemu-system-x86_64 \
	... \
	-nic user,model=e1000

La version 2.12 de QEMU (2018) propose une alternative plus simplifiée avec l'option -nic. Voici un exemple équivalent à la configuration ci-dessus :

$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
    altname enp0s3
    altname ens3
    altname enx525400123456
    inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic noprefixroute eth0
       valid_lft 47067sec preferred_lft 47067sec
    inet6 fec0::5054:ff:fe12:3456/64 scope site dynamic noprefixroute
       valid_lft 86251sec preferred_lft 14251sec
    inet6 fe80::5054:ff:fe12:3456/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

En approfondissant mes recherches, j'ai appris que quand le network backend user est configuré, QEMU prend en charge nativement les fonctionnalités DHCP et NAT. Il répond aux requêtes DHCP de la VM démarrée et gère aussi le routage IP en mode NAT.

On peut voir ici deux adresses IPv6 attachées à l'interface eth0 :

fec0::5054:ff:fe12:3456/64
fe80::5054:ff:fe12:3456/64

Une fois développées, ces deux adresses correspondent à :

fec0:0000:0000:0000:5054:00ff:fe12:3456
fe80:0000:0000:0000:5054:00ff:fe12:3456

Après avoir regardé cette vidéo, je pense avoir compris que dans une IPv6, la moitié gauche représente systématiquement un réseau (ici fe80:0000:0000:0000), nommé aussi "network prefix" ou "routing prefix", tandis que la partie de droite (ici 5054:00ff:fe12:3456) correspond à une adresse d'interface.

La partie interface de ces deux adresses est identique : 5054:00ff:fe12:3456.
Cette adresse d'interface est générée par conversion EUI-64 de l'adresse MAC 52:54:00:12:34:56 => 5054:00ff:fe12:3456.

Exemple de génération d'une autre adresse IPv6 si j'ajoute une interface réseau supplémentaire à la machine virtuelle :

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:12:34:57 brd ff:ff:ff:ff:ff:ff
    altname enp0s4
    altname ens4
    altname enx525400123457
    inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic noprefixroute eth1
       valid_lft 86388sec preferred_lft 86388sec
    inet6 fec0::5054:ff:fe12:3457/64 scope site dynamic noprefixroute
       valid_lft 86389sec preferred_lft 14389sec
    inet6 fe80::5054:ff:fe12:3457/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

Ici on peut voir que la conversion EUI-64 de 52:54:00:12:34:57 donne 5054:ff:fe12:3457.

Par rapport au fonctionnement d'IPv4, je trouve que le mécanisme de génération automatique des adresses d'interface réseau d'IPv6 très bien conçu 👌.

Je m'intéresse maintenant aux préfixes d'adresses IPv6 fec0::/10 et fe80::/10.

Le préfixe fe80::/10 est réservé aux adresses Link-Local. Ces adresses sont automatiquement configurées sur toutes les interfaces IPv6 actives et permettent une communication uniquement au sein du même segment réseau.

Exemple, dans le schéma ci-dessous, tous les serveurs présents sur le réseau A sont joignables via l'adresse Link-Local.
Cependant, les serveurs A n'ont pas la possibilité d'atteindre les serveurs B via Link-Local.

Note de type #mémento #mémo.

J'ai souvent besoin d'exécuter l'équivalent de :

$ scp -r root@myserver:/foo/bar/ ./tmp/

ou l'inverse :

$ scp -r ./tmp/ root@myserver:/foo/bar/

sur des serveurs sur lesquels je n'ai pas directement accès à l'utilisateur root par ssh.

J'accède, par exemple, à ce serveur via l'utilisateur ubuntu. L'utilisateur ubuntu n'a pas accès aux fichiers que je souhaite download ou upload.

Sur le serveur, j'ai accès aux fichiers de l'utilisateur root via sudo.

Voici une astuce pour download des fichiers via ssh et sudo :

$ ssh ubuntu@myserver "sudo tar cf - -C /foo/bar/ ." | tar xf - -C ./tmp/

Et, voici une méthode pour upload :

$ tar cf - -C ./tmp/ . | ssh ubuntu@myserver "sudo tar xf - -C /foo/bar/"

Note de type #mémento pour calculer la taille des tables PostgreSQL.

Commande pour calculer la taille de la base de données entière :

postgres=# select pg_size_pretty(pg_database_size('postgres'));
 pg_size_pretty
----------------
 74 GB

Commande pour voir les détails table par table :

SELECT
  nspname                                               AS "schema",
  pg_class.relname                                      AS "table",
  pg_size_pretty(pg_total_relation_size(pg_class.oid))  AS "total_size",
  pg_size_pretty(pg_relation_size(pg_class.oid))        AS "data_size",
  pg_size_pretty(pg_indexes_size(pg_class.oid))         AS "index_size",
  pg_stat_user_tables.n_live_tup                        AS "rows",
  pg_size_pretty(
    pg_total_relation_size(pg_class.oid) /
    (pg_stat_user_tables.n_live_tup + 1)
  )                                                     AS "total_row_size",
  pg_size_pretty(
    pg_relation_size(pg_class.oid) /
    (pg_stat_user_tables.n_live_tup + 1)
  )                                                     AS "row_size"
FROM
  pg_stat_user_tables
JOIN
  pg_class
ON
  pg_stat_user_tables.relid = pg_class.oid
JOIN
  pg_catalog.pg_namespace AS ns
ON
  pg_class.relnamespace = ns.oid
ORDER BY
  pg_total_relation_size(pg_class.oid) DESC;

 schema |      table      | total_size | data_size  | index_size |  rows   | total_row_size |  row_size
--------+-----------------+------------+------------+------------+---------+----------------+------------
 public | table1          | 72 GB      | 1616 MB    | 1039 MB    | 7456403 | 10 kB          | 227 bytes
 public | table2          | 1153 MB    | 754 MB     | 399 MB     | 2747998 | 440 bytes      | 287 bytes
 public | table3          | 370 MB     | 8192 bytes | 47 MB      |       8 | 41 MB          | 910 bytes
 public | table4        | 232 kB     | 136 kB     | 56 kB      |     422 | 561 bytes      | 329 bytes
(7 rows)

Note de type #mémento pour documenter mes paramètres de configuration LibreWolf.

Je me suis basé sur le repository firefox-csshacks pour implémenter mon fichier userChrome.css.

Liste des extension Firefox que j'ai réinstallées :

Petite note de type #mémento.

Si je rencontre l'erreur suivante avec Vagrant - VirtualBox :

$ vagrant up

...

Command: ["startvm", "2fa1ff70-52d8-4875-b48d-7c2df56f1507", "--type", "gui"]

Stderr: VBoxManage: error: VirtualBox can't enable the AMD-V extension. Please disable the KVM kernel extension, recompile your kernel and reboot (VERR_SVM_IN_USE)
VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component ConsoleWrap, interface IConsole

La solution est la suivante :

$ sudo modprobe -r kvm_amd
$ sudo modprobe -r kvm

Voici une astuce pour appliquer une configuration nftables en toute sécurité, pour éviter tout risque d'être "enfermé dehors".

Je commence par m'assurer que le fichier de configuration ne contient pas d'erreur de syntaxe ou autre :

# nft -c -f /etc/nftables.conf

Sauvegarder la configuration actuelle :

# nft list ruleset > /root/nftables-backup.conf

Application de la configuration avec un rollback automatique exécuté après 200 secondes :

# (sleep 200 && nft -f /root/nftables-backup.conf) & sudo nft -f /etc/nftables.conf

Après cette commande, j'ai 200 secondes pour tester si j'ai toujours bien accès au serveur.

Si tout fonctionne bien, alors je peux exécuter la commande suivante pour désactiver le rollback :

# pkill -f "sleep 200"

Alexandre m'a partagé l'article "Proxmox - Activer les mises à jour sans abonnement (no-subscription)".

Élément que je retiens :

Le processus de validation des paquets chez Proxmox est le suivant : Test -> No-Subscription -> Enterprise. Le dépôt No-Suscription est donc suffisamment stable. L'avertissement est à mon avis pour mettre hors cause l'équipe de Proxmox en cas de trou dans la raquette lors des tests de validation.

source

$ ssh root@192.168.1.43
# cat <<EOF > /etc/apt/sources.list.d/proxmox.list
deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription
EOF
# rm /etc/apt/sources.list.d/pve-enterprise.list
# rm /etc/apt/sources.list.d/ceph.list
# apt update -y
# apt upgrade -y
...
# reboot

Pour supprimer le message de warning au login, sur la version 8.3.2, j'ai appliqué le patch suivant :

# patch /usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js <<EOF
--- /usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js.old      2024-12-22 18:23:48.951557867 +0100
+++ /usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js  2024-12-22 18:18:50.509376748 +0100
@@ -563,6 +563,7 @@
                    let res = response.result;
                    if (res === null || res === undefined || !res || res
                        .data.status.toLowerCase() !== 'active') {
+                       /*
                        Ext.Msg.show({
                            title: gettext('No valid subscription'),
                            icon: Ext.Msg.WARNING,
@@ -575,6 +576,7 @@
                                orig_cmd();
                            },
                        });
+                       */
                    } else {
                        orig_cmd();
                    }
EOF
# systemctl restart pveproxy

Dans le Projet 17 - Créer un POC de création d'une app smartphone avec Capacitor, il semble que j'ai besoin d'installer Android Studio.

J'ai exploré la méthode Asdf / Mise, mais j'ai rencontré des difficultés : 2024-11-19_1029 et 2024-11-19_1102.

J'ai ensuite constaté ici que RPM Fusion ne propose pas de package Android Studio. J'ai ensuite cherché sur Fedora COPR, mais j'ai trouvé uniquement de très vieux packages.

J'ai lu ici qu'Android Studio est disponible via Flatpak sur Flathub : https://flathub.org/apps/com.google.AndroidStudio. Je n'avais pas pensé à Flatpak 🙊.

Après réflexion, je trouve cela totalement logique que Android Studio soit distribué via Flatpak.

Voici le repository GitHub de ce package : https://github.com/flathub/com.google.AndroidStudio. Il semble être bien maintenu par Alessandro Scarozza « Senior Android Developer, Android Studio Flatpak Mantainer and old Debian Linux user ».

Le package contient la version 2024.2.1.11 d'Android Studio, j'ai vérifié, elle correspond bien à la dernière version disponible sur https://developer.android.com/studio.

Voici ce que donne l'installation :

$ flatpak install com.google.AndroidStudio
Looking for matches…
Remotes found with refs similar to ‘com.google.AndroidStudio’:

   1) ‘flathub’ (system)
   2) ‘flathub’ (user)

Which do you want to use (0 to abort)? [0-2]: 1

com.google.AndroidStudio permissions:
    ipc                   network       pulseaudio      ssh-auth      x11      devices      multiarch      file access [1]
    dbus access [2]

    [1] home
    [2] com.canonical.AppMenu.Registrar, org.freedesktop.Notifications, org.freedesktop.secrets


        ID                                        Branch           Op           Remote            Download
 1. [✓] com.google.AndroidStudio.Locale           stable           i            flathub           5,6 Ko / 57,2 Ko
 2. [✓] com.google.AndroidStudio                  stable           i            flathub           1,3 Go / 1,3 Go

Installation complete.

Note #mémo : il est nécessaire d'utiliser l'option -O pour permettre à scp de se connecter à OpenWrt.

$ scp -O "root@192.168.1.1:/etc/config/*" etc/config

Pourquoi : https://forum.openwrt.org/t/ash-usr-libexec-sftp-server-not-found-when-using-scp/125772/3.

Pour effectuer une rotation du layout de mes windows Neovim comme la commande ctrl-b space sous tmux, j'ai trouvé les combinaisons de raccourcis suivantes :

ctrl-w J
ctrl-w H

Attention, les majuscules sont importantes.

2025-01-27 : voir 2025-01-27_1051.

Commandes valables sous Fedora mais aussi plus généralement sous Linux.

Affiche la configuration DNS actuelle :

$ resolvectl status
Global
         Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub
Current DNS Server: 127.0.0.1:5300
       DNS Servers: 127.0.0.1:5300
        DNS Domain: ~test

Link 2 (wlp1s0)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.31.1
       DNS Servers: 192.168.31.1

Intéroge directement un serveur DNS :

$ dig @127.0.0.1 -p 5300 server2.vagrant.test +short
192.168.56.21

Résolution d'un hostname avec resolvectl :

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

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

La commande suivante affiche toutes la configuration de resolved.conf :

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