Fedora

#distribution-linux

Journaux liées à cette note :

J'ai cherché une fonctionnalité pour calculer le coût total de l'utilisation d'Aider sur un projet. Je n'ai rien trouvé dans la documentation ni dans les issues du projet Aider.

Je sais qu'Aider enregistre toutes les informations de session dans .aider.chat.history.md.

Ce fichier contient des lignes du type : "Tokens: 49k sent, 1.9k received. Cost: $0.17 message, $1.68 session".

À partir de ces informations, j'ai généré avec Claude Sonnet 4.5 le script Python aider_cost_analyzer.py.

Installation sous Fedora :

$ mkdir -p ~/.local/bin
$ curl -o ~/.local/bin/aider_cost_analyzer.py https://gist.githubusercontent.com/stephane-klein/3b3808c1b03b7e6ddfc4b22b69fdf776/raw/4262faec0cb2f468ea6b6d8751339b8e8497f005/aider_cost_analyzer.py
$ chmod +x ~/.local/bin/aider_cost_analyzer.py

Exemple d'utilisation :

$ aider_cost_analyzer.py .
Analyzing 1 history file(s) in '.':

.aider.chat.history.md:
  Messages: 30
  Tokens sent: 639,200 | received: 65,613
  Cost: $1.86

============================================================
Total tokens sent: 639,200
Total tokens received: 65,613
Total cost: $1.86

J'ai posté l'issue suivante dans le repository aider-ce : "Calculate cumulative token usage and cost across all Aider sessions".

J'utilise habituellement lsof -i | grep "8080" pour identifier le processus qui écoute sur le port 8080.

Comme je le mentionnais dans 2025-07-04_1614, j'ai appris net-tools au début des années 2000 et j'ai gardé cette habitude depuis.

D'après Claude Sonnet 4.5, iproute2 est devenu le standard dans Debian, Ubuntu et Fedora vers 2013-2015. net-tools a été supprimé de l'installation par défaut entre 2017 et 2018.

lsof (pour LiSt Open Files) interroge /proc pour récupérer les informations. Cette implémentation, comme tous les outils net-tools, est ancienne et n'utilise pas l'API moderne Netlink.

En 2025, la méthode recommandée pour identifier les processus écoutant des ports est cette commande iproute2 (code source) :

$ ss -tlnp | grep 8080

Explication des options :

-t: TCP sockets
-l: Listening sockets uniquement
-n: Affichage numérique (pas de résolution DNS)
-p: Affiche les processus

J'ai écrit cette note et bridge-utils est déprécié, je dois remplacer "brctl" par "ip link" pour m'aider à adopter les commandes modernes iproute2.

Pour apprendre cette nouvelle commande, j'ai ajouté la carte-mémoire suivante dans Anki :

J'ai généré avec Claude Sonnet 4.5 le script Python text_to_audio.py. Il me permet de transformer automatiquement du texte en anglais en fichier audio mp3.
J'intègre ensuite ces fichiers dans mes carte-mémoire Anki pour travailler mon anglais.

Installation sous Fedora :

$ mkdir -p ~/.local/bin
$ curl -o ~/.local/bin/text_to_audio.py https://gist.githubusercontent.com/stephane-klein/1406e746f0253956062d4adff7a692bd/raw/8571cdd91cae8ebcd208435daacf431cfc1cd353/text_to_audio.py
$ chmod +x ~/.local/bin/text_to_audio.py

Exemple d'utilisation :

$ text_to_audio.py "Reinforcement Learning from Human Feedback"
Downloading audio for: 'Reinforcement Learning from Human Feedback'
Language: en-GB
URL: https://translate.google.com/translate_tts?ie=UTF-8&tl=en-GB&client=tw-ob&q=Reinforcement+Learning+from+Human+Feedback
Saving to: /home/stephane/english_audio/2025-12-01_Reinforcement_Learning_from_Human_Feedback.mp3

✓ Successfully downloaded to '/home/stephane/english_audio/2025-12-01_Reinforcement_Learning_from_Human_Feedback.mp3'
File size: 28224 bytes

J'utilise actuellement un endpoint HTTP de Google Translator pour générer les fichiers audio, en attendant de trouver une alternative plus open source / communautaire.

Suite à publication des notes "Setup Fedora CoreOS avec LUKS et TPM, non sécurisé contre le vol physique de serveur", "Setup Fedora CoreOS avec LUKS et Tang", j'ai réfléchi à mes prochaines itérations du Projet 34 - "Déployer un cluster k3s et Kubevirt sous CoreOS dans mon Homelab".

Je souhaite réaliser et publier un playground pour étudier et tester les solutions VPN suivantes :

Tailscale (solution partiellement libre, opéré par une entreprise basée au Canada)
netbird (solution totalement libre, qui propose une version SaaS opérée par une entreprise basée en Allemagne)
headscale (solution totalement libre à self hosted)

Dans un premier temps, je souhaite pouvoir accéder en ssh aux serveurs de mon Homelab depuis n'importe où. L'objectif est d'utiliser une méthode unique pour me connecter à ces serveurs en utilisant simplement leur hostname, sans avoir à gérer leurs adresses IP locales ni à configurer manuellement des entrées DNS.

Je souhaite tester l'installation de ces solutions sur des serveurs sous CoreOS, ma workstation sous Fedora et sous Android.

Idéalement, je souhaite configurer les services netbird et Tailscale via Terraform.

Je ne pense pas tester tout le suite headscale.

#JaiDécouvert les conférences Fedora annuelles nommées : Flock (https://fedoraproject.org/flock/)

Cette note fait partie de la série de notes : "J'ai étudié et testé CoreOS et je suis tombé dans un rabbit hole 🙈".

Note précédente : "Peu à peu depuis 2015, le terme immutable est remplacé par atomic".

Je constate que la plupart des personnes avec qui j'échange pensent qu'une distribution immutable ne permet que d'exécuter des containers Docker ou des applications Flatpak.
En réalité, grâce à la technologie libostree, il est possible d'installer des packages Fedora sur une instance Fedora CoreOS.

Voici un exemple sous Fedora CoreOS que j'ai réalisé avec le playground suivant : https://github.com/stephane-klein/atomic-os-playground.

Je commence par regarder l'état de l'OS avec rpm-ostree status :

stephane@stephane-coreos:~$ rpm-ostree status
State: idle
AutomaticUpdatesDriver: Zincati
  DriverState: active; periodically polling for updates (last checked Sat 2025-09-27 12:43:23 UTC)
Deployments:
● ostree-remote-image:fedora:docker://quay.io/fedora/fedora-coreos:stable
                   Digest: sha256:d196ab492e7cadab00e26511cdc6b49c6602b399e1b6f8c5fd174329e1ae10c1
                  Version: 42.20250901.3.0 (2025-09-14T22:45:05Z)

Je constate que la version 42.20250901.3.0 identifiée par le commit sha256:d196ab...ae10c1 est installée.
Cette version correspond au moment où j'écris cette note à la dernière release du stream stale listé sur cette page https://fedoraproject.org/coreos/release-notes?arch=x86_64&stream=stable.

Maintenant, j'utilise rpm-ostree install … pour installer neovim.

stephane@stephane-coreos:~$ sudo rpm-ostree install neovim
Checking out tree 1e5b81c... done
Enabled rpm-md repositories: fedora-cisco-openh264 updates fedora updates-archive
Updating metadata for 'fedora-cisco-openh264'... done
Updating metadata for 'updates'... done
Updating metadata for 'fedora'... done
Updating metadata for 'updates-archive'... done
Importing rpm-md... done
rpm-md repo 'fedora-cisco-openh264'; generated: 2025-03-19T16:53:39Z solvables: 6
rpm-md repo 'updates'; generated: 2025-09-27T01:07:36Z solvables: 24410
rpm-md repo 'fedora'; generated: 2025-04-09T11:06:59Z solvables: 76879
rpm-md repo 'updates-archive'; generated: 2025-09-27T01:38:59Z solvables: 44216
Resolving dependencies... done
Will download: 40 packages (121.6 MB)
Downloading from 'updates'... done
Downloading from 'fedora'... done
Importing packages... done
Checking out packages... done
Running systemd-sysusers... done
Running pre scripts... done
Running post scripts... done
Running posttrans scripts... done
Writing rpmdb... done
Writing OSTree commit... done
Staging deployment... done
Added:
  binutils-2.44-6.fc42.x86_64
  compat-lua-libs-5.1.5-28.fc42.x86_64
  ...
  neovim-0.11.4-1.fc42.x86_64
  ...
Changes queued for next boot. Run "systemctl reboot" to start a reboot

Neovim a bien été installé, mais je dois reboot pour l'utiliser. Voici ce que me dit rpm-ostree status :

stephane@stephane-coreos:~$ rpm-ostree status
State: idle
AutomaticUpdatesDriver: Zincati
  DriverState: active; periodically polling for updates (last checked Sat 2025-09-27 12:48:33 UTC)
Deployments:
  ostree-remote-image:fedora:docker://quay.io/fedora/fedora-coreos:stable
                   Digest: sha256:d196ab492e7cadab00e26511cdc6b49c6602b399e1b6f8c5fd174329e1ae10c1
                  Version: 42.20250901.3.0 (2025-09-14T22:45:05Z)
                     Diff: 40 added
          LayeredPackages: neovim

● ostree-remote-image:fedora:docker://quay.io/fedora/fedora-coreos:stable
                   Digest: sha256:d196ab492e7cadab00e26511cdc6b49c6602b399e1b6f8c5fd174329e1ae10c1
                  Version: 42.20250901.3.0 (2025-09-14T22:45:05Z)

La pastille ● m'indique la version (nommée déploiement) actuellement utilisée par l'instance.

Lors du démarrage du serveur, grub est configuré pour booter sur le premier déploiement de la liste. Exemple :

Une fois le serveur démarré, je peux voir que la version 42.20250901.3.0 est toujours utilisée, mais avec en plus un layer qui contient le package neovim :

[stephane@stephane-coreos ~]$ rpm-ostree status
rpm-ostree status
State: idle
AutomaticUpdatesDriver: Zincati
  DriverState: active; periodically polling for updates (last checked Sat 2025-09-27 13:04:36 UTC)
Deployments:
● ostree-remote-image:fedora:docker://quay.io/fedora/fedora-coreos:stable
                   Digest: sha256:d196ab492e7cadab00e26511cdc6b49c6602b399e1b6f8c5fd174329e1ae10c1
                  Version: 42.20250901.3.0 (2025-09-14T22:45:05Z)
          LayeredPackages: neovim

  ostree-remote-image:fedora:docker://quay.io/fedora/fedora-coreos:stable
                   Digest: sha256:d196ab492e7cadab00e26511cdc6b49c6602b399e1b6f8c5fd174329e1ae10c1
                  Version: 42.20250901.3.0 (2025-09-14T22:45:05Z)

Neovim est bien accessible :

[stephane@stephane-coreos ~]$ nvim --version
nvim --version
NVIM v0.11.4
Build type: RelWithDebInfo
LuaJIT 2.1.1748459687
Run "nvim -V1 -v" for more info

Avec la commande rpm-ostree apply-live il est même possible de commencer à utiliser le package sans avoir à reboot.
Cette fonctionnalité doit se limité à des petits utilitaires. Pour les composants systèmes, il est conseillé d'effectuer un reboot.

Note suivante : "Système de mise à jour d'Android, Chrome OS, MacOS et MS Windows".

La lecture du document "Team Silverblue - The Origins " m'a appris de nombreuses choses sur les origines de la distribution Fedora Silverblue.

Avant 2018, le prédécesseur de Fedora Silverblue s'appelait "Fedora Atomic Workstation", défini comme : "image-mode container-based Fedora Workstation based on rpm-ostree".

À ses débuts, Fedora Atomic Workstation était un side project, développé et utilisé par quelques membres seulement de l'équipe Project Atomic (version du site de 2017).

Durant la conférence DevConf.CZ de janvier 2018, des participants ont présenté leur projet "Atomic Desktop". Suite à cette présentation, Owen Taylor, Sanja Bonic et Matthias Clasen ont créé un Special interest group (SIG) dédié à ce sujet dans la communauté Fedora : https://fedoraproject.org/wiki/SIGs/AtomicDesktops.

Voici comment le nom "Team Silverblue" a été choisi 2018 par Matthias Clasen et Sanja Bonic :

Couldn’t you come up with a better name?

No.

And in more detail: Matthias and Sanja have vetted over 150 words and word combination for something suitable, starting with tree names and going to atoms, physics, nature, landscapes.

Several other people have been asked to contribute. The entire process lasted for roughly 2 months, culminating in an open discussion of naming in the SIG meeting on April 16.

On April 19, Matthias and Sanja decided for the name Team Silverblue, because it was :

available on Twitter, GitHub, and as a .org domain

makes sense and sounds nice within the Fedora realm (color alignment)

opens up fun and entertaining ways to have swag (silver-blue wigs, sports jerseys with the logo on it, phrasing like “Go, Team Silverblue!”, “Want to join the Team and improve Silverblue?”)

works as Fedora Silverblue or Team Silverblue without losing branding investment

source

"Team Silverblue" a ensuite donné le nom Fedora Silverblue.

Le document indique que Red Hat a acquis CoreOS juste quelques jours après le lancement de cette idée de projet par les développeurs. S'agit-il d'une coïncidence heureuse 🤔 ? Le document ne le précise pas.

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.

Suite à ma note "J'ai découvert ContainerLab, un projet qui permet de simuler des réseaux", j'ai implémenté et publié containerlab-playground.

Mon but était d'utiliser Containerlab pour simuler deux réseaux IPv6 connectés entre eux : 3 serveurs sur le premier réseau et 2 serveurs sur le second.

Comme je l'observe fréquemment depuis quelques mois, Claude Sonnet 4 m'a produit une implémentation qui, en pratique, ne fonctionne pas (voir son contenu dans 2025-07-20_1241).

La note courante reprend principalement en français le contenu du README.md de mon playground .

Voici les instructions que j'ai exécutées pour installer Containerlab sous Fedora :

$ sudo dnf config-manager addrepo --set=baseurl="https://netdevops.fury.site/yum/" && \
$ echo "gpgcheck=0" | sudo tee -a /etc/yum.repos.d/netdevops.fury.site_yum_.repo
$ sudo dnf install containerlab
$ sudo usermod -aG clab_admins stephane && newgrp clab_admins
$ sudo semanage fcontext -a -t textrel_shlib_t $(which containerlab)
$ sudo restorecon $(which containerlab)

Voici les instructions que j'ai exécutées pour installer Containerlab sous Fedora :

$ sudo containerlab deploy
11:27:03 INFO Containerlab started version=0.69.0
11:27:03 INFO Parsing & checking topology file=network-a-b.clab.yaml
11:27:03 INFO Creating docker network name=net-custom IPv4 subnet="" IPv6 subnet=2001:db8:a::0/48 MTU=0
11:27:03 INFO Creating lab directory path=/home/stephane/git/github.com/stephane-klein/containerlab-playground/clab-network-a
11:27:04 INFO Creating container name=vm-b1
11:27:04 INFO Creating container name=vm-a1
11:27:04 INFO Creating container name=vm-a2
11:27:04 INFO Creating container name=vm-a3
11:27:04 INFO Adding host entries path=/etc/hosts
11:27:04 INFO Adding SSH config for nodes path=/etc/ssh/ssh_config.d/clab-network-a.conf
╭──────────────────────┬───────────────────┬─────────┬─────────────────╮
│         Name         │     Kind/Image    │  State  │  IPv4/6 Address │
├──────────────────────┼───────────────────┼─────────┼─────────────────┤
│ clab-network-a-vm-a1 │ linux             │ running │ 192.168.0.2     │
│                      │ mitchv85/ohv-host │         │ 2001:db8:a:1::1 │
├──────────────────────┼───────────────────┼─────────┼─────────────────┤
│ clab-network-a-vm-a2 │ linux             │ running │ 192.168.0.3     │
│                      │ mitchv85/ohv-host │         │ 2001:db8:a:1::2 │
├──────────────────────┼───────────────────┼─────────┼─────────────────┤
│ clab-network-a-vm-a3 │ linux             │ running │ 192.168.0.4     │
│                      │ mitchv85/ohv-host │         │ 2001:db8:a:1::3 │
├──────────────────────┼───────────────────┼─────────┼─────────────────┤
│ clab-network-a-vm-b1 │ linux             │ running │ 192.168.0.5     │
│                      │ mitchv85/ohv-host │         │ 2001:db8:a:2::5 │
╰──────────────────────┴───────────────────┴─────────┴─────────────────╯

Globalement, j'ai trouvé l'expérience utilisateur de la cli Containerlab très agréable à utiliser :

$ containerlab help

  deploy container based lab environments with a user-defined interconnections

  USAGE


    containerlab [command] [--flags]  


  COMMANDS

    completion [bash|zsh|fish]   Generate completion script
    config [command] [--flags]   Configure a lab
    deploy [--flags]             Deploy a lab
    destroy [--flags]            Destroy a lab
    exec [--flags]               Execute a command on one or multiple containers
    generate [--flags]           Generate a Clos topology file, based on provided flags
    graph [--flags]              Generate a topology graph
    help [command] [--flags]     Help about any command
    inspect [command] [--flags]  Inspect lab details
    redeploy [--flags]           Destroy and redeploy a lab
    save [--flags]               Save containers configuration
    tools [command]              Various tools your lab might need
    version [command]            Show containerlab version or upgrade

  FLAGS

     -d --debug                  Enable debug mode
     -h --help                   Help for containerlab
     --log-level                 Logging level; one of [trace, debug, info, warning, error, fatal] (info)
     --name                      Lab name
     -r --runtime                Container runtime
     --timeout                   Timeout for external API requests (e.g. container runtimes), e.g: 30s, 1m, 2m30s (2m0s)
     -t --topo                   Path to the topology definition file, a directory containing one, 'stdin', or a URL
     --vars                      Path to the topology template variables file
     -v --version                Version for containerlab

J'ai eu quelques difficultés à trouver une image Docker à utiliser qui fournit directement un serveur ssh :

    vm-a1:
      kind: linux
      # image: alpine-ssh
      # https://hub.docker.com/r/mitchv85/ohv-host
      image: mitchv85/ohv-host
      mgmt-ipv6: 2001:db8:a:1::1

Le déploiement de cette image permet de facilement se connecter à l'host en ssh:

$ ssh admin@clab-network-a-vm-a1
admin@vm-a1:~$ exit

Il est possible de facilement lancer une commande sur tous les hosts :

$ sudo containerlab exec -t network-a-b.clab.yaml --cmd 'ip addr'
11:29:52 INFO Parsing & checking topology file=network-a-b.clab.yaml
11:29:52 INFO Executed command node=clab-network-a-vm-a2 command="ip addr"
  stdout=
  │ 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
  │        valid_lft forever preferred_lft forever
  │ 2: eth0@if192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
  │     link/ether aa:86:42:84:81:de brd ff:ff:ff:ff:ff:ff link-netnsid 0
  │     inet 192.168.0.3/20 brd 192.168.15.255 scope global eth0
  │        valid_lft forever preferred_lft forever
  │     inet6 2001:db8:a:1::2/48 scope global nodad
  │        valid_lft forever preferred_lft forever
  │     inet6 fe80::a886:42ff:fe84:81de/64 scope link
  │        valid_lft forever preferred_lft forever

11:29:52 INFO Executed command node=clab-network-a-vm-a3 command="ip addr"
  stdout=
  │ 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
  │        valid_lft forever preferred_lft forever
  │ 2: eth0@if193: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
  │     link/ether b2:42:6c:2b:d0:9d brd ff:ff:ff:ff:ff:ff link-netnsid 0
  │     inet 192.168.0.4/20 brd 192.168.15.255 scope global eth0
  │        valid_lft forever preferred_lft forever
  │     inet6 2001:db8:a:1::3/48 scope global nodad
  │        valid_lft forever preferred_lft forever
  │     inet6 fe80::b042:6cff:fe2b:d09d/64 scope link
  │        valid_lft forever preferred_lft forever

11:29:52 INFO Executed command node=clab-network-a-vm-a1 command="ip addr"
  stdout=
  │ 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
  │        valid_lft forever preferred_lft forever
  │ 2: eth0@if191: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
  │     link/ether 26:9f:87:52:d6:1c brd ff:ff:ff:ff:ff:ff link-netnsid 0
  │     inet 192.168.0.2/20 brd 192.168.15.255 scope global eth0
  │        valid_lft forever preferred_lft forever
  │     inet6 2001:db8:a:1::1/48 scope global nodad
  │        valid_lft forever preferred_lft forever
  │     inet6 fe80::249f:87ff:fe52:d61c/64 scope link
  │        valid_lft forever preferred_lft forever

11:29:52 INFO Executed command node=clab-network-a-vm-b1 command="ip addr"
  stdout=
  │ 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
  │        valid_lft forever preferred_lft forever
  │ 2: eth0@if194: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
  │     link/ether e2:81:7b:c7:eb:64 brd ff:ff:ff:ff:ff:ff link-netnsid 0
  │     inet 192.168.0.5/20 brd 192.168.15.255 scope global eth0
  │        valid_lft forever preferred_lft forever
  │     inet6 2001:db8:a:2::5/48 scope global nodad
  │        valid_lft forever preferred_lft forever
  │     inet6 fe80::e081:7bff:fec7:eb64/64 scope link
  │        valid_lft forever preferred_lft forever

Ou alors sur un host en particulier :

$ sudo containerlab exec -t network-a-b.clab.yaml --label clab-node-name=vm-a1 --cmd 'ip addr'
11:02:44 INFO Parsing & checking topology file=network-a-b.clab.yaml
11:02:44 INFO Executed command node=clab-network-a-vm-a1 command="ip addr"
  stdout=
  │ 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
  │        valid_lft forever preferred_lft forever

Par contre, je n'ai pas réussi à atteindre mon objectif 😟.

J'ai l'impression que pour le moment, Containerlab ne permet pas de créer plusieurs réseaux à partir d'un fichier topologie.

Je n'ai pas compris comment définir la longueur du prefix IPv6 des interfaces eth0 au niveau des nodes.

Pour le moment, tous les nodes appartiennent au même sous-réseau 2001:db8:a::0/48, alors que j'aimerais les séparer dans les deux sous-réseaux suivants :

2001:db8:a:1
2001:db8:a:2

# network-a-b.clab.yaml

...

topology:
  nodes:
    vm-a1:
      kind: linux
      # image: alpine-ssh
      # https://hub.docker.com/r/mitchv85/ohv-host
      image: mitchv85/ohv-host
      mgmt-ipv6: 2001:db8:a:1::1
      # <== ici je ne sais pas comment définir : 2001:db8:a:1::1/64

...

J'ai découvert l'issue suivante du principal développeur de Containerlab : « Multiple management networks ».
Je pense comprendre que ce que je cherche à faire n'est actuellement pas possible avec Containerlab.

Pour atteindre mon objectif, peut-être que je devrais plutôt m'orienter vers des alternatives mentionnées dans ce billet de blog : Open-source network simulation roundup 2024.

Je viens de poster le message suivant l'espace de discussion GitHub de Containerlab : « Does Containerlab support the creation of topologies with multiple subnets? ».
J'espère que le créateur de Containerlab pourra me suggérer une solution à mon problème, car je n'ai pas réussi à l'identifier dans la documentation 🤷‍♂️.

Voir la suite de cette note : 2025-09-19_1651.

De 2000 à 2016, j'ai essentiellement déployé la distribution Linux Debian sur mes serveurs et après cette date des Ubuntu LTS.

Depuis 2022, j'utilise une Fedora sur ma workstation. Distribution que je maitrise et que j'apprécie de plus en plus.

J'envisage peut-être d'utiliser une distribution de la famille Fedora sur mes serveurs personnels.

J'avais suivi de loin les événements autour de CentOS en décembre 2020 :

8 décembre 2020 : CentOS Project shifts focus to CentOS Stream
16 décembre 2020 : Rocky Linux: A CentOS replacement by the CentOS founder

J'ai enfin compris l'origine du nom Rocky Linux :

"Thinking back to early CentOS days... My cofounder was Rocky McGaugh. He is no longer with us, so as a H/T to him, who never got to see the success that CentOS came to be, I introduce to you...Rocky Linux"

Gregory Kurtzer, Founder

J'aime beaucoup cet hommage 🤗 !

J'ai étudié AlmaLinux et il me semble que cette distribution est principalement développée par l'entreprise CloudLinux, une entreprise à but lucratif qui vend du support Linux.

Personnellement, je trouve le positionnement d'AlmaLinux peu "fair-play" envers Red Hat : Red Hat investit massivement dans le développement de Red Hat Enterprise Linux et AlmaLinux récupère ce travail gratuitement pour ensuite vendre du support commercial en concurrence directe.

À mon avis, si une entreprise souhaite un vrai support sur une distribution de la famille Red Hat, elle devrait se tourner vers Red Hat Enterprise Linux et acheter du support directement à Red Hat plutôt qu'à CloudLinux.

Suite à ce constat, j'ai décidé d'utiliser Rocky Linux plutôt qu'AlmaLinux.

21h30 : j'ai reçu le message suivant sur Mastodon :

@stephane_klein you have things quite backwards. AlmaLinux is a non-profit foundation while Rocky is owned 100% by Greg kurtzer and they have over $100M in venture capital funding.

AlmaLinux has a community-elected board.

source

Suite à ce message, j'ai essayé d'en savoir plus, mais il est difficile d'y voir clair.

Par exemple : I’m confused about the different organizational structure when it comes to Rocky and Alma.

La page "AlmaLinux OS Foundation " que j'ai consultée m'a particulièrement plu.

J'ai révisé ma position, j'ai décidé d'utiliser AlmaLinux plutôt que Rocky Linux.

2025-12-02 : j'ai révisé ma position, pour des serveurs de production, j'ai décidé d'utiliser la version stable de CoreOS, plutôt que AlmaLinux ou Rocky Linux.