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

Recherche effectué dans :

Tous type de notes (104)

evergreen_note (55)

journal_note (49)

Filtre actif, cliquez pour en enlever un tag :

linux

Cliquez sur un tag pour affiner votre recherche :

Résultat de la recherche (104 notes) :

Il y a quelques jours, dans ma note "Setup Fedora CoreOS avec LUKS et TPM", je disais :

Attention, j'ai découvert que cette méthode n'est pas sécurisée en cas de vol physique du serveur !

Si un attaquant boot depuis un autre disque avec le même firmware et le même kernel, il pourra extraire en clair la clé LUKS stockée dans le TPM 🫣.

source

Une solution pour traiter ce point faible est d'utiliser un pin éloigné physiquement du serveur qui l'utilise.

Le framework Clevis utilise le terme "pins" pour désigner les différents méthodes de déverrouillage d'un volume LUKS.

Origine du mot "pin" ?
Claude Sonnet 4.5 m'a expliqué que le terme "pin", qui se traduit par "goupille" en français, désigne la pièce mécanique qui bloque l'ouverture d'un cadenat.

Par exemple, dans un contexte self hosting dans un homelab, je peux héberger physiquement un serveur dans mon logement et le connecter à un pin sur un serveur Scaleway ou sur un serveur dans le homelab d'un ami.

Les pins distants, accessibles via réseau, sont appelés serveurs Network-Bound Disk Encryption.

Si le serveur Network-Bound Disk Encryption est configuré pour répondre uniquement aux requêtes provenant de l'IP de mon réseau homelab, en cas de vol du serveur, le voleur ne pourra pas récupérer le secret permettant de déchiffrer le volume LUKS.

Dans le playground install-coreos-iso-on-qemu-with-luks-and-tang, j'ai testé avec succès le déverrouillage d'un volume LUKS avec un serveur Network-Bound Disk Encryption nommé tang.

Pour être précis, dans la configuration de ce playground, deux pins sont obligatoires pour déverrouiller automatiquement le volume : un pin tang et un pin TPM2. Le nombre minimum de pins requis pour le déverrouillage est défini par le paramètre threshold.

clevis, qui permet de configurer les pins et de gérer la récupération de la passphrase à partir des pins, utilise l'algorithme Shamir's secret sharing (SSS) pour répartir le secret à plusieurs endroits.

Voici quelques scénarios de conditions de déverrouillage que clevis permet de configurer grâce à SSS :

TPM2 ou Tang serveur 1
TPM2 et Tang serveur 1
Tang serveur 1 ou Tang serveur 2
2 parmi Tang serveur 1, Tang serveur 2, Tang serveur 3
...

Si les conditions ne sont pas remplies, systemd-ask-password demande à l'utilisateur de saisir sa passphrase au clavier.

Je n'ai pas trouvé d'image docker officielle de tang. Toutefois, j'ai trouvé ici l'image non officielle padhihomelab/tang (son dépôt GitHub : https://github.com/padhi-homelab/docker_tang).
Dans mon playground, je l'ai déployé dans ce docker-compose.yml.

J'ai trouvé la configuration butane de tang simple à définir (lien vers le fichier) :

  luks:
    - name: var
      device: /dev/disk/by-partlabel/var
      wipe_volume: true
      key_file:
        inline: password
      clevis:
        tpm2: true
        tang:
          - url: "http://10.0.2.2:1234"
            # $ docker compose exec tang jose jwk thp -i /db/pLWwUuLhqqFb-Mgf5iVkwuV4BehG9vzd2SXGMyGroNw.jwk
            # pLWwUuLhqqFb-Mgf5iVkwuV4BehG9vzd2SXGMyGroNw
            thumbprint: dx9dNzgs-DeXg0SCBQW5rb7WQkSIN1B8MIgcO6WxJfI
        threshold: 2 # TMP2 + Tang (or passphrase keyboard input)

La seule complexité que j'ai rencontrée est la méthode pour récupérer le paramètre thumbprint de l'instance tang.

Voici la méthode que j'ai utilisée :

$ docker compose exec tang jose jwk thp -i /db/pLWwUuLhqqFb-Mgf5iVkwuV4BehG9vzd2SXGMyGroNw.jwk
pLWwUuLhqqFb-Mgf5iVkwuV4BehG9vzd2SXGMyGroNw

Autre difficulté, il faut ajouter les arguments kernel suivants pour activer l'accès réseau dès le début du process de boot afin de permettre à clevis d'accéder au serveur tang :

variant: fcos
version: 1.6.0
kernel_arguments:
  should_exist:
    - ip=dhcp
    - rd.neednet=1

J'ai intégré au README.md du playground une section nommée "How to switch from 2 required ping to 1 or the opposite?", pour documenter comment modifier à chaud la configuration clevis.
Par exemple pour changer de serveur tang ou modifier le nombre de pins nécessaires pour déverrouiller la partition chiffrée.

Il est conseillé d'activer le pin TPM2 en complément de tang pour éviter ce type d'attaque décrit par Claude Sonnet 4.5 :

Imaginons un admin malveillant dans ton entreprise :

Il a accès physique aux serveurs

Il a accès au réseau (donc au serveur Tang)

Il clone un disque pendant la nuit

Il essaie de le monter sur sa propre machine pour extraire des données

Tang seul : ❌ Il réussit
TPM + Tang : ✅ Il échoue

Claude Sonnet 4.5

À noter que l'instance tang ne contient pas la passphrase et ne voit jamais passer la passphrase via son API.
Voici les explications que m'a données Claude Sonnet 4.5 :

Tang ne stocke pas la passphrase secrète de chiffrement LUKS. C'est justement tout l'intérêt de cette solution !

Voici comment ça fonctionne :

Le principe de Tang + Clevis

Génération de clé dérivée : Clevis (le client) contacte le serveur Tang et récupère sa clé publique

Chiffrement avec la clé de Tang : Clevis utilise cette clé publique pour chiffrer la passphrase LUKS

Stockage local : La passphrase chiffrée est stockée localement dans l'en-tête LUKS du disque (pas sur le serveur Tang)

Déchiffrement au boot :

La machine contacte Tang

Tang utilise sa clé privée pour aider à déchiffrer

La passphrase LUKS est reconstituée

Le disque est déverrouillé

Ce que Tang sait et ne sait pas

❌ Tang ne connaît jamais votre passphrase LUKS

❌ Tang ne stocke rien concernant vos clés

✅ Tang fournit juste un service cryptographique (un oracle de déchiffrement)

✅ C'est un serveur sans état (stateless)

C'est du chiffrement asymétrique avec un mécanisme appelé "network-bound disk encryption" : le disque ne peut être déchiffré que si la machine peut contacter le serveur Tang sur le réseau.

Claude Sonnet 4.5

Voici quelques ressources supplémentaires au sujet des techniques de déverrouillage automatique des volumes LUKS :

Comme je l'ai dit dans cette précédente note, jusqu'il y a peu de temps, je ne m'étais jamais intéressé et j'avais même évité les technologies liées aux trusted computing.

Il y quelques jours, j'ai testé avec succès l'installation d'une Fedora CoreOS avec une clé de déchiffrement LUKS sauvegardée dans une puce TPM2 à l'aide de clevis.

Grâce à TPM, cette configuration évite de devoir saisir la clé de déchiffrement au moment du boot de l'OS.
Je trouve cette approche particulièrement pertinente sur une distribution CoreOS qui utilise zincati pour appliquer automatiquement les mises à jour de l'OS à des horaires définis (voir note à ce sujet).

Pour tester cette configuration, j'ai créé le playground install-coreos-iso-on-qemu-with-luks , qui me permet de tester localement l'installation dans une VM QEMU.
Pour émuler le TPM2, j'utilise swtpm et le BIOS UEFI Open source edk2-ovmf .

Dans ce test, j'ai choisi de créer et de chiffrer une partition pour stocker les données du dossier /var/, qui sur CoreOS est l'emplacement qui contient les données mutables (accessibles en écriture).

Voici la configuration butane de LUKS encryption avec les options TPM2 et clevis que j'ai utilisées (fichier complet) :

storage:
  disks:
    - device: /dev/nvme0n1
      wipe_table: false
      partitions:
        - number: 4
          label: root
          size_mib: 15000
          resize: true
        - number: 5
          label: var       <=== label
          size_mib: 0  # 0 = use all remaining space

  luks:
    - name: var            <=== label
      device: /dev/disk/by-partlabel/var
      wipe_volume: true
      key_file:
        inline: password
      clevis:
        tpm2: true
        
  filesystems:
    - path: /var
      device: /dev/mapper/var
      format: xfs
      wipe_filesystem: true
      label: var
      with_mount_unit: true

Je trouve le contenu de ce fichier de configuration assez simple et explicite.

J'ai ensuite créé un second playground install-coreos-iso-on-baremetal-with-luks.

L'installation automatique s'est déroulée sans problème sur un serveur baremetal.

J'ai testé la désactivation de TPM2 dans le BIOS : la console m'a alors demandé de saisir la clé manuellement. C'est plutôt pratique en cas de problème TPM, branchement du disque sur une autre machine…

La clé de chiffrement LUKS n'est pas stockée en clair dans le fichier ISO, il n'est donc pas nécessaire de sécuriser l'accès à ce fichier.

Attention, j'ai découvert que cette méthode n'est pas sécurisée en cas de vol physique du serveur !

Si un attaquant boot depuis un autre disque avec le même firmware et le même kernel, il pourra extraire en clair la clé LUKS stockée dans le TPM 🫣.

D'après mes recherches, la seule approche qui semble permettre à la fois la protection contre le vol physique et le reboot automatique serait d'utiliser clevis avec un serveur tang plutôt que le TPM.

Je compte tester cette configuration dans les prochaines semaines (depuis, cette note a été publiée : Setup Fedora CoreOS avec LUKS et Tang).

Comme beaucoup de libristes, en 2002, j'ai été effrayé par le projet Palladium de Microsoft.

Palladium (NGSCB) était une initiative Microsoft annoncée en 2002 pour créer une plateforme de "trusted computing" basée sur du matériel sécurisé (une puce TPM dédiée) contrôlant strictement quels logiciels pouvaient s'exécuter et quels périphériques étaient autorisés à communiquer avec le système. L'objectif était de permettre à Microsoft de certifier cryptographiquement l'intégrité de toute la chaîne matérielle et logicielle, depuis le démarrage de l'ordinateur jusqu'aux applications en cours d'exécution.

On imaginait des scénarios concrets comme une carte son qui refuserait de capturer de l'audio depuis une sortie protégée par DRM, ou une carte graphique qui bloquerait la capture d'écran de contenu vidéo protégé.

À cette époque, Microsoft était en position hégémonique écrasante sur le marché des ordinateurs personnels : MacOS d'Apple représentaient moins de 3% des parts de marché.
Palladium représentait concrètement une forme de totalitarisme numérique sous contrôle total de Microsoft et des ayants droit.

Pour la communauté du libre, cela signifiait concrètement que ce système pourrait empêcher l'exécution de systèmes d'exploitation libres, bloquer l'accès aux périphériques sans drivers signés par Microsoft, et conduire à une génération d'ordinateurs où Linux serait techniquement banni ou très difficile à installer.

Heureusement, les critiques venues de toutes parts , combinées aux accusations de monopole et aux risques antitrust, ont contraint Microsoft à faire marche arrière. Cela a abouti à la situation actuelle où le TPM est davantage orienté vers la sécurité que vers le DRM et la restriction des libertés des utilisateurs.

Cet épisode a eu des conséquences durables pour moi : depuis, dès que j'entendais parler de puce de sécurité ou de TPM, j'avais immédiatement une réaction de rejet, parce que cela évoquait pour moi vendor lock-in, restrictions et contrôle par Microsoft. Je n'ai jamais cherché à en savoir plus.

C'est seulement en septembre 2025, lors de mon exploration du filesystem fs-verity, que j'ai découvert que les fonctionnalités du TPM2 sont en réalité très intéressantes et peuvent servir des objectifs de sécurité légitimes, très bien supportées par Linux.

Mon objectif du weekend est d'avancer sur le Projet 34 - "Déployer un cluster k3s et Kubevirt sous CoreOS dans mon Homelab".

Je veux apprendre à configurer LUKS encryption sous CoreOS avec un démarrage automatique basé sur TPM2 via clevis.

Je veux aussi m'assurer qu'en cas de problème, je peux toujours monter la partition chiffrée en saisissant manuellement la clé secrète.

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 : "Support OCI de CoreOS (image pull & updates)".

Colin Walters, le principal développeur de libostree a initié le projet bootc en mars 2021. J'ai découvert le projet bootc en début d'année et lisant des articles liés à systemd.

La vision de bootc est assez simple : rendre la création d'images de système d'exploitation aussi simple que la création d'images de conteneurs d'applications tout en utilisant les mêmes outils. Pour avoir un peu de contexte historique, je conseille l'article lwn de juin 2024 : Making containers bootable for fun and profit

Les images bootc utilisent la même technologie de stockage que les images des container classique : OCI.

D'après ce que j'ai compris, ce type d'image bootc ne porte pas nom officiellle, elles sont nommés aussi bien "bootc image", que "bootable container image" ou "bootable OCI image".

En janvier 2025, Red Hat a transféré le projet bootc à la CNCF. Le but est de permettre à toutes les distributions de l'adopter comme standard, indépendamment de Red Hat.

Parmis les distributions qui ont adopté bootc, trois retiennent mon attention :

fedora-bootc
fedora-coreos (mais attention, cette version n'est pas encore prête à être utilisé)
Bluefin du projet Universal Blue

Au moment où j'écris ces lignes, je pense migrer d'ici quelques mois ma workstation vers une distribution Desktop bootc, probablement Bluefin, qui est déjà disponible, ou Fedora Silverblue, une fois que son support bootc sera finalisé.

J'aurai donc certainement l'occasion de tester en pratique comment créer des images bootc personnalisées.

Voici diverses ressources que j'ai trouvées concernant le support bootc pour Fedora Silverblue :

Issue dans "Fedora Atomic Desktops / SIG Issue Tracker" :
- Roadmap to Fedora Bootable Containers
Pages dans "Fedora Project Wiki" :
- Initiatives/Fedora bootc
- Changes/OstreeNativeContainerStable
Section "First step towards Bootable Containers: dnf5 and bootc" dans l'article "What’s new for Fedora Atomic Desktops in Fedora 41"

Je compte aussi tester bootc et tout particulièrement Bluefin dans le cadre de mon "Projet 26 - "Expérimentation de migration de deux utilisateurs grand public vers des laptops sous Fedora"".

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 : "L'utilisation de OSTree par Flatpak".

Le format Open Container Initiative (Docker image) utilise le media type application/vnd.oci.image.layer.v1.tar+gzip et se compose de métadonnées au format JSON accompagnées de plusieurs archives tar.gz. Ce format est beaucoup moins optimisé pour le stockage et le transfert que celui de libostree, qui utilise un système de déduplication basé sur les objets et des deltas binaires (pour en savoir plus, voir la note "2014-2018 approche alternative avec Atomic Project").

La déduplication OCI s'effectue au niveau des layers complets. Par exemple, si je build localement une image à partir du Dockerfile suivant :

# image frontend
FROM fedora:39            # layer 1
RUN dnf install -y pkg1   # layer 2 - 50Mb
COPY app.js /app/         # layer 3

Puis une seconde image avec ce Dockerfile :

# image backend
FROM fedora:39                 # layer 1
RUN dnf install -y pkg1 pkg2   # layer 4 - 100 Mb
COPY app.js /app/              # layer 3

Les layers 2 et 4 sont considérés comme différents car leurs contenus diffèrent (commandes RUN différentes). Les fichiers du package pkg1 sont donc stockés deux fois. La taille totale sur disque et lors du transfert est de 150 MB (au lieu de 100 MB avec une déduplication au niveau fichier).

Malgré cette limitation, depuis la version 42 , Fedora CoreOS utilise le support OCI de OSTree pour télécharger les mises à jour système. Ce changement constitue la première itération vers la migration de CoreOS vers bootc.

Le format OCI semble privilégié à libostree comme format d'échange car son écosystème est plus populaire : utilisation par Docker, Kubernetes, podman, disponibilité sur Docker Hub, et maîtrise généralisée du format Dockerfile.

Depuis la version 4.0.0 , podman supporte le format de compression zstd:chunked , basé sur les zstd skippable frames . Ce format permet une déduplication plus fine en découpant les layers en chunks, améliorant ainsi l'efficacité des téléchargements différentiels, bien que restant inférieur à des capacités de libostree. À noter que seul le registry quay supporte actuellement ce format — Docker Hub ne le prend pas encore en charge.

En explorant ce sujet de déduplication (qui permet de réduire la taille des données à télécharger lors des mises à jour), #JaiDécouvert bsdiff, bspatch, Rolling hash (je l'avais déjà croisé).

Note suivante : "Convergence vers Bootc".

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 : "Quelques outils CoreOS : coreos-installer, graphe de migration et zincati".

En 2021, Alexander Larsson a initié composefs, un nouveau filesystem. Pour faire simple, composefs permet de monter un filesystem depuis un checkout libostree.

composefs est un filesystem de type "stacking filesystem" qui combine plusieurs technologies :

EROFS : fournit la couche read-only et l'efficacité de stockage
overlayfs : gère la superposition de layers
fs-verity : assure la vérification d'intégrité des fichiers à la volée

Avec libostree seul (sans composefs), les checkout s'appuient sur des hardlinks vers un store central. Cette approche économise de l'espace disque, mais présente deux limitations :

L'utilisateur root peut modifier les fichiers et corrompre le store partagé
Il n'y a pas de vérification d'intégrité lors de l'accès aux fichiers

Grâce à EROFS, un filesystem read-only, la structure de fichier checkout devient immuable, ces fichiers ne sont plus des hardlink.

composefs a l'avantage de pouvoir utiliser différents filesystèmes comme couche de stockage : ext4, XFS, btrfs, etc.

Comme l'explique Alexander Larsson dans ce post de 2022, le second objectif de composefs est d'adresser une limitation de sécurité d'OSTree identifiée par Lennart Poettering : les fichiers gérés par libostree ne sont vérifiés qu'au moment de leur téléchargement, pas lors de leur utilisation.

Grâce à fs-verity (une fonctionnalité du kernel Linux), composefs permet la vérification cryptographique des fichiers à chaque accès (runtime verification). Cette approche peut détecter toute modification ou corruption au moment de l'utilisation du fichier. Je précise que je maîtrise assez mal cette partie sécurité.

Pour approfondir le sujet composefs, je vous conseille l'article lwn "Composefs for integrity protection and data sharing " de décembre 2022 ou encore tous les billets de Alexander Larsson au sujet de composefs, ainsi que ce "OSTree and composefs tutorial" qui m'a aidé à mieux comprendre par la pratique.

composefs a été intégré dans la version 41 de Fedora CoreOS et la version 42 de Fedora Silverblue. Voici une vérification de la présence de composefs sous CoreOS :

stephane@stephane-coreos:~$ ostree --version
libostree:
Version: '2025.4'
Git: 99a03a7bb8caa774668222a0caace3b7e734042e
Features:
- inode64
- initial-var
- libcurl
- libsoup3
- gpgme
- composefs   <==== ici
- ex-fsverity
- libarchive
- selinux
- openssl
- sign-ed25519
- sign-spki
- libmount
- systemd
- release
- p2p

stephane@stephane-coreos:~$ mount | grep -i composefs
composefs on / type overlay (ro,relatime,seclabel,lowerdir+=/run/ostree/.private/cfsroot-lower,datadir+=/sysroot/ostree/repo/objects,redirect_dir=on,metacopy=on)

Note suivante : "L'utilisation de OSTree par Flatpak".

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 : "Fusion de CoreOS et Atomic Project en 2018".

coreos-installer

L'outil coreos-installer est un composant essentiel de Fedora CoreOS. Il propose différentes méthodes pour installer Fedora CoreOS.

La commande coreos-installer download permet de télécharger tout type de version de CoreOS, sous différents formats, par exemple iso, raw, qemu, cloud image, etc (toutes celles présentes dans la page download).

Ensuite, la commande coreos-installer install permet d'installer la version téléchargée vers un disque. Cette commande est par exemple disponible à la fin du boot d'une image ISO. Contrairement à Fedora Silverblue qui propose d'installer la distribution avec Anaconda, l'installation de CoreOS s'effectue en cli via coreos-installer install.

Ensuite, la commande coreos-installer install permet d'installer la version téléchargée sur un disque. Cette commande est notamment accessible après le démarrage d'une image ISO. Contrairement à Fedora Silverblue qui utilise l'installateur graphique Anaconda, CoreOS s'installe exclusivement en cli via coreos-installer install.

Toutefois, coreos-installer permet de préparer une installation automatique. La commande coreos-installer iso customize modifie une image ISO existante pour y intégrer directement une configuration ignition, rendant l'installation entièrement automatisée au démarrage.

Voici un exemple dans mon playground : atomic-os-playground/create-coreos-custom-iso.sh.

coreos-installer pxe permet aussi d'effectuer une configuration automatique par réseau, via PXE, mais je ne l'ai pas testé.

Graphe de migration de versions

Lors de mes tests d'upgrade de CoreOS à partir d'une ancienne release (environ n-10), j'ai constaté que la transition vers la dernière version ne se faisait pas directement mais nécessitait le passage par des versions intermédiaires.

J'ai découvert que CoreOS maintient un graphe qui définit le parcours d'upgrade requis. Certaines versions intermédiaires doivent être installées pour gérer des breaking changes, comme la migration de configurations.

zincati

Un autre composant important de Fedora CoreOS est zincati, le service responsable de l'exécution des mises à jour automatiques.

zincati décide d'effectuer les mises à jour en fonction du seuil de prudence de déploiement (rollout_wariness) et de la stratégie de mise à jour : immediate ou periodic (plage horaire définie dans la semaine).

CoreOS utilisant par défaut la stratégie immediate, zincati détecte automatiquement les nouvelles releases dès le premier démarrage et lance immédiatement leur téléchargement, suivi d'un redémarrage.

Le téléchargement par deltas rend l'upgrade vers la dernière release très rapide.

zincati permet également de coordonner les mises à jour de plusieurs serveurs, fonctionnalité particulièrement utile dans le contexte d'un cluster Kubernetes. Je n'ai pas encore testé cette fonctionnalité.

Note suivante : "composefs, un filesystem spécialement créé pour les besoins des distributions atomic".

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 : "2014-2018 approche alternative avec Atomic Project".

Suite au rachat de la société CoreOS par Red Hat en 2018, les projets CoreOS Container Linux et Fedora Atomic Host ont fusionné en juillet 2019 pour donner Fedora CoreOS.

D'après mon analyse, mise à part ignition, le projet Fedora CoreOS est construit sur les bases de Fedora Atomic Host et n'a gardé de CoreOS Container Linux que le nom "CoreOS".

Cette nouvelle distribution Fedora CoreOS reste atomic et immutable comme l'ancien CoreOS Container Linux, mais utilise désormais rpm-ostree et OSTree (au lieu du système dual partition A/B), et permet le package layering si nécessaire. La philosophie "100% conteneurs" reste encouragée, mais n'est plus une contrainte absolue.

Voici une chronologie sur l'histoire de CoreOS que m'a proposée Claude Sonnet 4.5 :

2013-2017: CoreOS Container Linux
           ├─ Atomic ✓ (dual partition)
           ├─ Immutable ✓
           └─ Package layering ✗

2014-2018: Fedora/RHEL Atomic Host
           ├─ Atomic ✓ (OSTree)
           ├─ Immutable ✓
           └─ Package layering ✓ (rpm-ostree)

2018:      Rachat CoreOS par Red Hat

2019+:     Fedora CoreOS (fusion des deux)
           ├─ Atomic ✓ (OSTree)
           ├─ Immutable ✓
           ├─ Package layering ✓ (possible mais découragé)
           └─ Philosophie: conteneurs first, mais flexible

Note suivante : "Quelques outils CoreOS : coreos-installer, graphe de migration et zincati".

#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 : "CoreOS de 2013 à 2018".

La première version d'Atomic Project paraît en 2014, avec rpm-ostree comme élément central, développé principalement par Colin Walters de Red Hat.

rpm-ostree utilise libostree comme fondation, composant qui lui confère "toute sa puissance".

OSTree composant central de Atomic Project

Colin Walters a créé libostree en 2011 pour les besoins de GNOME Continuous.

libostree est un outil qui s'inspire de Git, mais se spécialise dans la gestion d'arbres de fichiers complets de système d'exploitation.

Principales différences avec Git :

Aucune copie lors des checkouts : libostree repose sur des hardlinks, donc pas de working copy du fait de l'immutabilité des fichiers.
libostree préserve les contextes SELinux, les xattrs, les uid/gid, ainsi que des timestamps précis
libostree peut gérer les device nodes (/dev/zero, /dev/null…), les sockets (/run/systemd/notify...), et tous les types de fichiers d'un filesystem d'OS
Un mécanisme de déduplication
…

Avec OSTree, pas besoin de double partition

À la différence de CoreOS Container Linux qui utilisait le système de mise à jour A/B (seamless) system updates, Fedora Atomic Host (puis Fedora CoreOS) n'a pas besoin de deux partitions grâce à libostree.

Lors d'un upgrade, libostree réalise un "checkout" en utilisant la commande ostree-admin-deploy . Puis grub communique au kernel le paramètre ostree= qui détermine sur quel déploiement booter.

Voici les avantages de l'utilisation de libostree par rapport au système A/B (seamless) system updates :

libostree permet de conserver plusieurs déploiements, sans se limiter à 2
Grâce au système de déduplication, libostree consomme beaucoup moins d'espace disque
Grâce au téléchargement uniquement des deltas, les mises à jour sont très rapides

Néanmoins, alors que libostree offre techniquement la possibilité de créer autant de déploiements que souhaité, d'après mes tests, Fedora CoreOS semble actuellement limité à 2 déploiements seulement.
J'ai trouvé cette issue qui aborde ce sujet : support configuring host to retain more than two deployments.

rpm-ostree

Les utilisateurs d'Fedora Atomic Host n'interagissent pas directement avec libostree mais avec rpm-ostree.

rpm-ostree s'appuie sur les librairies libostree et libdnf pour installer des packages rpm et propose de nombreuses commandes d'administration de l'OS :

stephane@stephane-coreos:~$ rpm-ostree
Usage:
  rpm-ostree [OPTION…] COMMAND

Builtin Commands:
  apply-live             Apply pending deployment changes to booted deployment
  cancel                 Cancel an active transaction
  cleanup                Clear cached/pending data
  compose                Commands to compose a tree
  db                     Commands to query the RPM database
  deploy                 Deploy a specific commit
  finalize-deployment    Unset the finalization locking state of the staged deployment and reboot
  initramfs              Enable or disable local initramfs regeneration
  initramfs-etc          Add files to the initramfs
  install                Overlay additional packages
  kargs                  Query or modify kernel arguments
  override               Manage base package overrides
  rebase                 Switch to a different tree
  refresh-md             Generate rpm repo metadata
  reload                 Reload configuration
  reset                  Remove all mutations
  rollback               Revert to the previously booted tree
  search                 Search for packages
  status                 Get the version of the booted system
  uninstall              Remove overlayed additional packages
  upgrade                Perform a system upgrade
  usroverlay             Apply a transient overlayfs to /usr

Note suivante : "Fusion de CoreOS et Atomic Project en 2018.

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 : "Système de mise à jour d'Android, Chrome OS, MacOS et MS Windows".

Première version de CoreOS Container Linux en 2013

La première version de CoreOS Container Linux sortie en 2013 utilisé la méthode A/B (seamless) system updates inspirée de manière transparente à Chrome OS :

Upgrading CoreOS is a bit different than the usual distros. Our update system is based on ChromeOS. The big difference is that we have two root partitions; lets call them root A and root B. Initially your system is booted into the root A partition and CoreOS begins talking to the update service to find out about new updates. If there is an update available it is downloaded and installed to root B.

source

D'après ce repository coreos/coreos-overlay, CoreOS Container Linux était basé sur les packages de Gentoo.

Première version d'Ignition en 2016

En avril 2016, l'équipe CoreOS a publié la première version de ignition, outil toujours utilisé en 2025 par Fedora CoreOS.

Ignition is a utility created to manipulate disks during the initramfs. This includes partitioning disks, formatting partitions, writing files (regular files, systemd units, etc.), and configuring users. On first boot, Ignition reads its configuration from a source of truth (remote URL, network metadata service, hypervisor bridge, etc.) and applies the configuration.

source

ignition est un système qui ressemble à cloud-init, mais qui est exécuté seulement une seule fois, lors du premier boot et est lancé en tout premier, avant même systemd.

Depuis 2019, les fichiers json ignition ne sont plus édités manuellement grâce à l'outil butane qui convertit des fichiers YAML butane en fichiers json ignition.

Voici la documentation de butane qui vous permet de voir les actions que peut effectuer ignition : https://coreos.github.io/butane/specs/.

À la différence de cloud-init, ignition fonctionne à un niveau plus bas. La spec Butane Fedora CoreOS v1.6.0 permet par exemple de configurer les partitions, le Raid, LUKS encryption…

Voici dans mon playground un exemple de son utilisation : atomic-os-playground/create-coreos-custom-iso.sh.

Note suivante : "2014-2018 approche alternative avec Atomic Project".

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 : "Ajout de packages dans des distributions atomiques".

Chrome OS et Android implémentent la stratégie de double partition A/B (seamless) system updates.
Cette technologie offre des mises à jour complètement transparentes en arrière-plan et un redémarrage immédiat.
En revanche, contrairement à la solution CoreOS (méthode détaillée dans cette note), cette méthode a pour inconvénient de consommer deux fois plus d'espace de stockage.

MacOS s'appuie sur les snapshots de son filesystem APFS (fonctionnalité qu'offre aussi btrfs). Cela garantit un retour en arrière rapide vers la version antérieure si des problèmes surviennent.
En revanche, l'upgrade se termine durant le reboot, pouvant prendre de 2 à 5 minutes, alors que le redémarrage reste instantané avec Chrome OS, Android, CoreOS ou Fedora Silverblue.

Comme d'habitude, je n'arrive pas à trouver des informations précises sur le fonctionnement interne de MS Windows 😔. D'après Claude Sonnet 4, le système de mise à jour de Windows 10 et Windows 11, baptisé Unified Update Platform (UUP), semble plutôt daté : pas d'A/B (seamless) system updates, absence d'atomicité, installation longue lors du reboot (10 à 30 minutes), possibilité d'échec en cours de processus, rollback complexe, aucun système de snapshot comparable à MacOS. J'ai du mal à croire ce bilan tellement catastrophique, ce qui m'amène à questionner sur l'exactitude des informations rapportées par Claude Sonnet 4.

D'après cette documentation particulièrement riche et mes recherches complémentaires, je pense que la stack libostree + composefs (avec zstd:chunked ) tel qu'implémenté dans Fedora CoreOS est probablement la technologie de mise à jour la plus avancée actuellement disponible.

Avant de présenter le fonctionnement du système de mise à jour de Fedora CoreOS en 2025, je vais retracer l'évolution technique de cette solution.

Note suivante : "CoreOS de 2013 à 2018".

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".

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 : "En 2016, j'ai testé Fedora Atomic Host, une expérience pénible".

Après avoir étudié et testé CoreOS pendant une semaine, je réalise que la plupart des informations que j'avais entendues sur cette distribution, et plus généralement sur les immutables ou atomiques, étaient approximatives et m'ont conduit à des erreurs de compréhension.

Quelques exemples de propos que j'ai entendus de la part d'amis sur ce sujet.

En 2025 :

« Une distribution readonly ça empêchait pas mal de choses. Je n'ai pas creusé, je n'y connais rien, mais j'ai vu beaucoup de gens se plaindre. »

ou encore 2024 :

Les distributions immuables (comme feu CoreOS) garantissent une cohérence ultime. Pas de gestion de paquets, donc ni ajout ni suppression ni mises à jour possibles. Tout est gravé dans le marbre. Pour protéger le marbre, la partition racine est montée en lecture seule. Note suivante : "Ajout de packages dans des distributions atomiques". Le choix est extrême, mais l’idée est de servir de socle pour une abstraction de plus haut niveau. Imaginé pour les conteneurs, ils peuvent aussi gérer des machines virtuelles.

Pour mettre à jour, il suffit de redémarrer sur une nouvelle version. Techniquement, il y a deux partitions bootables, la courante, en lecture seule, la version suivante sur laquelle on a appliqué des patchs, soit n et n+1. Si le redémarrage de mise à jour se passe mal, rembobinage sur la dernière version connue comme stable.

Ma première erreur consistait à penser que distribution atomic et distribution immutable désignaient la même chose.

Les distributions immutables ont les caractéristiques suivantes :

Système de fichiers racine en lecture seule
Protection contre les modifications accidentelles
Peut ou non avoir des mises à jour transactionnelles

Les distributions atomics ont les caractéristiques suivantes :

Toujours immutable (par nature)
Mises à jour transactionnelles (tout ou rien)
Capacité de rollback complet
Basé sur des images système versionnées (généralement OSTree)

Les distributions atomic modernes, telles que Fedora CoreOS, Fedora Silverblue permettent en plus :

La modification de l'image de manière transactionnelle, par exemple d'installer des packages supplémentaires via rpm-ostree
Personnalisation tout en gardant les bénéfices de l'approche atomic

En 2016, lors de ma première utilisation de Fedora Atomic Host, j'avais compris que cette distribution était immutable comme CoreOS, sans réaliser qu'elle était aussi atomic. Contrairement à CoreOS qui interdisait tout ajout de packages système, Fedora Atomic Host permettait déjà via rpm-ostree d'installer des packages de manière transactionnelle (package layering), tout en conservant les bénéfices des mises à jour atomiques et du rollback.

À l'époque, CoreOS mettait l'accent sur son approche "100% conteneurs" et son immutabilité stricte, ce qui m'avait fait passer à côté de cette différence importante.

D'après ce que j'ai compris, la terminologie autour des distributions immutables et atomic a évolué au fil du temps. Si les concepts techniques sont bien définis (immutabilité du système, mises à jour transactionnelles), leur usage dans la communication a varié selon les projets et les époques. J'ai l'impression que cette ambiguïté persiste aujourd'hui.

Note suivante : "Ajout de packages dans des distributions atomiques".

Dans cette issue, #JaiDécouvert le projet Kairos (https://kairos.io).

Dans ce thread du Subreddit self hosted, #JaiDécouvert Quadlet, une fonctionnalité de podman.

D'après ce que j'ai compris, Quadlet est un système qui permet de lancer des containers podman via systemd de manière déclarative. Techniquement, Quadlet transforme des fichiers .container en fichier unit files systemd classique.

Exemple d'un fichier .container :

# ~/.config/containers/systemd/nginx.container
[Unit]
Description=Nginx web server
After=network-online.target

[Container]
Image=docker.io/library/nginx:latest
PublishPort=8080:80
Volume=/srv/www:/usr/share/nginx/html:ro,Z

[Service]
Restart=always

[Install]
WantedBy=default.target

Et pour ensuite lancer ce container :

$ systemctl --user daemon-reload
$ systemctl --user start nginx
$ systemctl --user enable nginx

J'ai aussi découvert le projet podlet, (https://github.com/containers/podlet) qui permet de générer des fichiers Quadlet à partir de fichiers docker compose.

J'apprécie que podman incarne la philosophie Unix en s'intégrant nativement aux composants Linux comme systemd, plutôt que de réinventer la roue comme Docker.

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.

Pendant mon travail d'étude pratique de IPv6, #JaiDécouvert le projet Containerlab :

Containerlab was meant to be a tool for provisioning networking labs built with containers. It is free, open and ubiquitous. No software apart from Docker is required! As with any lab environment it allows the users to validate features, topologies, perform interop testing, datapath testing, etc. It is also a perfect companion for your next demo. Deploy the lab fast, with all its configuration stored as a code -> destroy when done.

source

Projet qui a commencé en 2020 et semble principalement développé par un développeur de chez Nokia.

D'après ce que j'ai compris, Containerlab me permet de facilement créer des réseaux dans un simulateur.

Je me souviens que je cherchais ce type d'outil en 2018, quand je travaillais sur un projet baremetal as service chez Scaleway.

Voici un exemple de fichier créé par Claude.ia pour simuler un environnement composé de deux réseaux IPv6 connectés entre eux : 3 serveurs sur le premier réseau et 2 serveurs sur le second.

Je précise que je n'ai pas encore testé ce fichier. J'ignore donc s'il fonctionne correctement.

name: dual-network-ipv6-lab
topology:
  nodes:
    # Routeur avec IPv6
    router:
      kind: linux
      image: alpine:latest
      exec:
        # Activer IPv6
        - sysctl -w net.ipv6.conf.all.disable_ipv6=0
        - sysctl -w net.ipv6.conf.all.forwarding=1
        # Adresses IPv6 sur les interfaces
        - ip -6 addr add 2001:db8:1::1/64 dev eth1
        - ip -6 addr add 2001:db8:2::1/64 dev eth2
        # IPv4 en parallèle (dual-stack)
        - ip addr add 192.168.1.1/24 dev eth1
        - ip addr add 192.168.2.1/24 dev eth2
        - echo 1 > /proc/sys/net/ipv4/ip_forward
    
    # Réseau A (2001:db8:1::/64)
    vm-a1:
      kind: linux  
      image: alpine:latest
      exec:
        - sysctl -w net.ipv6.conf.all.disable_ipv6=0
        - ip -6 addr add 2001:db8:1::10/64 dev eth1
        - ip -6 route add default via 2001:db8:1::1
        - ip addr add 192.168.1.10/24 dev eth1
        - ip route add default via 192.168.1.1
        
    vm-a2:
      kind: linux
      image: alpine:latest  
      exec:
        - sysctl -w net.ipv6.conf.all.disable_ipv6=0
        - ip -6 addr add 2001:db8:1::11/64 dev eth1
        - ip -6 route add default via 2001:db8:1::1
        - ip addr add 192.168.1.11/24 dev eth1
        - ip route add default via 192.168.1.1
        
    vm-a3:
      kind: linux
      image: alpine:latest
      exec: 
        - sysctl -w net.ipv6.conf.all.disable_ipv6=0
        - ip -6 addr add 2001:db8:1::12/64 dev eth1
        - ip -6 route add default via 2001:db8:1::1
        - ip addr add 192.168.1.12/24 dev eth1
        - ip route add default via 192.168.1.1
    
    # Réseau B (2001:db8:2::/64)
    vm-b1:
      kind: linux
      image: alpine:latest
      exec:
        - sysctl -w net.ipv6.conf.all.disable_ipv6=0
        - ip -6 addr add 2001:db8:2::10/64 dev eth1  
        - ip -6 route add default via 2001:db8:2::1
        - ip addr add 192.168.2.10/24 dev eth1
        - ip route add default via 192.168.2.1
        
    vm-b2:
      kind: linux
      image: alpine:latest
      exec:
        - sysctl -w net.ipv6.conf.all.disable_ipv6=0
        - ip -6 addr add 2001:db8:2::11/64 dev eth1
        - ip -6 route add default via 2001:db8:2::1
        - ip addr add 192.168.2.11/24 dev eth1
        - ip route add default via 192.168.2.1

  links:
    # Réseau A
    - endpoints: ["router:eth1", "vm-a1:eth1"]  
    - endpoints: ["router:eth1", "vm-a2:eth1"]
    - endpoints: ["router:eth1", "vm-a3:eth1"]
    
    # Réseau B
    - endpoints: ["router:eth2", "vm-b1:eth1"]
    - endpoints: ["router:eth2", "vm-b2:eth1"]

Hier, j'ai écrit la note "AlmaLinux ou Rocky Linux ?".

En ce moment, je suis en train d'approfondir mes connaissances sur le fonctionnement des différents network backend de QEMU et j'en ai profité pour comparer le comportement d'Ubuntu, AlmaLinux, Rocky Linux et CentOS.

J'ai lancé QEMU avec le paramètre qemu ... -nic user avec chacune de ces distributions et voici les résultats de ip addr dans chacune de ces VMs:

Ubuntu :

$ 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: ens3: <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
    inet 10.0.2.15/24 metric 100 brd 10.0.2.255 scope global dynamic ens3
       valid_lft 83314sec preferred_lft 83314sec
    inet6 fec0::5054:ff:fe12:3456/64 scope site dynamic mngtmpaddr noprefixroute
       valid_lft 86087sec preferred_lft 14087sec
    inet6 fe80::5054:ff:fe12:3456/64 scope link
       valid_lft forever preferred_lft forever

Rocky Linux :

$ 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: ens3: <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 enx525400123456
    inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic noprefixroute ens3
       valid_lft 83596sec preferred_lft 83596sec
    inet6 fec0::5054:ff:fe12:3456/64 scope site dynamic noprefixroute
       valid_lft 86379sec preferred_lft 14379sec
    inet6 fe80::5054:ff:fe12:3456/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

CentOS :

$ sudo 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: ens3: <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 enx525400123456
    inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic noprefixroute ens3
       valid_lft 86341sec preferred_lft 86341sec
    inet6 fec0::5054:ff:fe12:3456/64 scope site dynamic noprefixroute
       valid_lft 86342sec preferred_lft 14342sec
    inet6 fe80::5054:ff:fe12:3456/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

AlmaLinux :

$ 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 84221sec preferred_lft 84221sec
    inet6 fec0::5054:ff:fe12:3456/64 scope site dynamic noprefixroute
       valid_lft 86053sec preferred_lft 14053sec
    inet6 fe80::5054:ff:fe12:3456/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

Ce que j'observe :

Rocky Linux et CentOS semblent se comporter de manière identique :
- une interface réseau nommée ens3 qui signifie : ethernet slot 3
- et les noms alternatifs :
  - enp0s3 qui signifie : ethernet, PCI bus 0, slot 3
  - enx525400123456 qui signifie : ethernet + x + la adresse MAC sans les :
Ubuntu :
- une interface réseau nommée ens3
- et un nom alternatif : enp0s3
AlmaLinux :
- une interface réseau nommée eth0
- et les noms alternatifs :
  - ens3
  - enp0s3
  - enx525400123456

Voici les configurations de GRUB_CMDLINE_LINUX_DEFAULT :

Rocky Linux et CentOS :

GRUB_CMDLINE_LINUX_DEFAULT="console=ttyS0,115200n8 no_timer_check crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M"

AlmaLinux :

GRUB_CMDLINE_LINUX="console=tty0 console=ttyS0,115200n8 no_timer_check biosdevname=0 net.ifnames=0"

Ubuntu :

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

Conclusion de cette analyse : il me semble que Rocky Linux cherche à reproduire CentOS de manière très fidèle, alors qu'AlmaLinux se permet davantage de libertés dans son approche.

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.

En étudiant IPv6 et Linux bridge, j'ai découvert que le projet bridge-utils est déprécié. À la place, il faut utiliser iproute2.

Ce qui signifie que je ne dois plus utiliser la commande brctl, chose que j'ignorais jusqu'à ce matin.

iproute2 remplace aussi le projet net-tools. Par exemple, les commandes suivantes sont aussi dépréciées :

ifconfig remplacé par ip addr et ip link
route remplacé par ip route
arp remplacé par ip neigh
brctl remplacé par ip link
iptunnel remplacé par ip tunnel
nameif remplacé par ip link set name
ipmaddr remplacé par ip maddr

Au-delà des aspects techniques — iproute2 utilise Netlink plutôt que ioctl — l'expérience utilisateur me semble plus cohérente.
J'ai une préférence pour une commande unique ip accompagnée de sous-commandes plutôt que pour un ensemble de commandes disparates.
Cette logique de sous-commandes s'inscrit dans une tendance générale de l'écosystème Linux, et je pense que c'est une bonne direction.
Je pense notamment à systemctl, timedatectl, hostnamectl, localectl, loginctl, apt, etc.

Quand j'ai débuté sous Linux en 1999, j'ai été habitué à utiliser les commande ifup et ifdown qui sont en réalité des scripts bash qui appellent entre autre ifconfig.
Ces scripts ont été abandonnés par les distributions Linux qui sont passées à systemd et NetworkManager.

En simplifiant, l'équivalent des commandes suivantes avec NetworkManager :

$ ifconfig
$ ifup eth0
$ ifdown eth0

est :

$ nmcli device status
$ nmcli connection up <nom_de_connexion>
$ nmcli connection down <nom_de_connexion>

Contrairement à mon intuition initiale, NetworkManager n'est pas un simple "wrapper" de la commande ip d'iproute2.

En fait, nmcli fonctionne de manière totalement indépendante d'iproute2, il utilise l'interface Netlink comme l'illustre cet exemple de la commande nmcli device show :

nmcli device show
    ↓ (Method call via D-Bus)
org.freedesktop.NetworkManager.Device.GetProperties()
    ↓ (NetworkManager traite la requête)
nl_send_simple(sock, RTM_GETLINK, ...)
    ↓ (Socket netlink vers kernel)
Kernel: netlink_rcv() → rtnetlink_rcv()
    ↓ (Retour des données)
RTM_NEWLINK response
    ↓ (libnl parse la réponse)
NetworkManager met à jour ses structures
    ↓ (Réponse D-Bus)
nmcli formate et affiche les données

Autre différence, contrairement à iproute2, les changements effectués par NetworkManager sont automatiquement persistants et il peut réagir à des événements, tel que le branchement d'un câble réseau et la présence d'un réseau WiFi connu.

Les paramètres de configuration de NetworkManager se trouvent dans les fichiers suivants :

Fichiers de configuration globale de NetworkManager :

# Fichier principal
/etc/NetworkManager/NetworkManager.conf

# Fichiers de configuration additionnels
/etc/NetworkManager/conf.d/*.conf

Fichiers de configuration des connexions NetworkManager :

# Configurations système (root)
/etc/NetworkManager/system-connections/

# Configurations utilisateur
~/.config/NetworkManager/user-connections/

Comme souvent, Ubuntu propose un outil "maison", nommé netplan qui propose un autre format de configuration. Mais je préfère utiliser nmcli qui est plus complet et a l'avantage d'être la solution mainstream supportée par toutes les distributions Linux.

En étudiant IPv6 et Linux bridge, j'ai découvert que Netlink a été introduit pour remplacer ioctl et procfs.

Netlink permet à des programmes user-land de communiquer avec le kernel via une API asynchrone. C'est une technologie de type inter-process communication (IPC).

La partie "Net" de "Netlink" s'explique par l'histoire : au départ, Netlink servait exclusivement à iproute2 pour la configuration réseau.
L'usage de Netlink s'est ensuite généralisé à d'autres aspects du kernel.

#JaiLu cet excellent article "The future of Flatpak".

J'y ai appris énormément de choses au sujet de Flatpak. Le sujet est bien plus complexe que je l'imaginais. Je découvre aussi que les axes d'amélioration du projet sont nombreux.

#JaiDécouvert l'origine du nom du projet Flatpak :

Flatpak was originally developed by Alexander Larsson, who had been working on similar projects stretching back to 2007. The first release was as XDG-App in 2015. It was renamed to Flatpak in 2016, a nod to IKEA's "flatpacks" for delivering furniture.

source

J'adore l'idée derrière ce nom !

Aujourd'hui, j'ai implémenté des tests de montée en charge à l'aide de Grafana k6. En ciblant un site web hébergé sur un petit serveur Scaleway DEV1-M, j'ai constaté que le serveur est devenu inaccessible à la fin des tests. Aucun swap n'était configuré sur cette Virtual machine de 4Go de RAM.

Je me suis souvenu qu'en 2019, j'ai rencontré aussi des problèmes de freeze sur une VM AWS EC2 que j'ai corrigés en ajoutant un peu de swap au serveur. Après cela, je n'ai constaté plus aucun freeze de VM pendant 4 ans.

Ce sujet de swap m'a fait penser à la question qu'un ami m'a posée en octobre 2024 :

Désactiver le swap sur une Debian, recommandé ou pas ?

Alors que j'ai 29Go utilisé sur 64, le swap était plein (3,5Go occupé à 100%), les 12 cœurs du serveur partaient dans les tours. J'ai désactivé le swap et me voilà gentiment avec un load average raisonnable, pour les tâches de cette machine.

C'est une très bonne question que je me pose depuis longtemps. J'ai enfin pris un peu de temps pour creuser ce sujet.

Sept mois plus tard, voici ma réponse dans cette note 😉.

#JaiDécouvert le paramètre kernel nommé Swappiness.

swappiness

This control is used to define how aggressive the kernel will swap memory pages. Higher values will increase aggressiveness, lower values decrease the amount of swap. A value of 0 instructs the kernel not to initiate swap until the amount of free and file-backed pages is less than the high water mark in a zone.

The default value is 60.

documentation du kernel

Dans la documentation SwapFaq d'Ubuntu j'ai lu :

The swappiness parameter controls the tendency of the kernel to move processes out of physical memory and onto the swap disk. Because disks are much slower than RAM, this can lead to slower response times for system and applications if processes are too aggressively moved out of memory.

swappiness can have a value of between 0 and 100

swappiness=0 tells the kernel to avoid swapping processes out of physical memory for as long as possible

swappiness=100 tells the kernel to aggressively swap processes out of physical memory and move them to swap cache

The default setting in Ubuntu is swappiness=60. Reducing the default value of swappiness will probably improve overall performance for a typical Ubuntu desktop installation. A value of swappiness=10 is recommended, but feel free to experiment. Note: Ubuntu server installations have different performance requirements to desktop systems, and the default value of 60 is likely more suitable.

source

D'après ce que j'ai compris, plus swappiness tend vers zéro, moins le swap est utilisé.

J'ai lu ici :

vm.swappiness = 60 : Valeur par défaut de Linux : à partir de 40% d’occupation de Ram, le noyau écrit sur le disque.

source

Cependant, je n'ai pas trouvé d'autres sources qui confirment cette correspondance entre la valeur de swappiness et un pourcentage précis d'utilisation de la RAM.

J'ai ensuite cherché à savoir si c'était encore pertinent de configurer du swap en 2025, sur des serveurs qui disposent de beaucoup de RAM.

#JaiLu ce thread : "Do I need swap space if I have more than enough amount of RAM?", et voici un extrait qui peut servir de conclusion :

In other words, by disabling swap you gain nothing, but you limit the operation system's number of useful options in dealing with a memory request. Which might not be, but very possibly may be a disadvantage (and will never be an advantage).

source

Je pense que ceci est d'autant plus vrai si le paramètre swappiness est bien configuré.

Concernant la taille du swap recommandée par rapport à la RAM du serveur, la documentation de Ubuntu conseille les ratios suivants :

       RAM      Swap    Maximum Swap
      256MB    256MB           512MB 
      512MB    512MB          1024MB
     1024MB   1024MB          2048MB
        1GB      1GB             2GB
        2GB      1GB             4GB
        3GB      2GB             6GB
        4GB      2GB             8GB
        5GB      2GB            10GB
        6GB      2GB            12GB
        8GB      3GB            16GB
       12GB      3GB            24GB
       16GB      4GB            32GB
       24GB      5GB            48GB
       32GB      6GB            64GB
       64GB      8GB           128GB
      128GB     11GB           256GB
      256GB     16GB           512GB
      512GB     23GB             1TB
        1TB     32GB             2TB
        2TB     46GB             4TB
        4TB     64GB             8TB
        8TB     91GB            16TB

source

#JaiDécouvert aussi que depuis le kernel 2.6, les fichiers de swap sont aussi rapides que les partitions de swap :

Definitely not. With the 2.6 kernel, "a swap file is just as fast as a swap partition."

source

Suite à ces apprentissages, j'ai configuré et activé un swap de 2G sur la VM Scaleway DEV1-L équipée de 4G de RAM, avec le paramètre swappiness réglé à 10.

J'ai relancé mon test Grafana k6 et je n'ai constaté plus aucun freeze, je n'ai pas perdu l'accès au serveur.

De plus, probablement grâce au paramètre swappiness fixé à 10, j'ai observé que le swap n'a pas été utilisé pendant le test.

Suite à ces lectures et à cette expérience concluante, j'ai décidé de désormais configurer systématiquement du swap sur tous mes serveurs de la manière suivante :

if swapon --show | grep -q "^/swapfile"; then
    echo "Swap is already configured"
else
    get_swap_size() {
        local ram_gb=$(free -g | awk '/^Mem:/ {print $2}')
        
        # Why this values? See https://help.ubuntu.com/community/SwapFaq#How_much_swap_do_I_need.3F
        if [ $ram_gb -le 1 ]; then
            echo "1G"
        elif [ $ram_gb -le 2 ]; then
            echo "1G"
        elif [ $ram_gb -le 6 ]; then
            echo "2G"
        elif [ $ram_gb -le 12 ]; then
            echo "3G"
        elif [ $ram_gb -le 16 ]; then
            echo "4G"
        elif [ $ram_gb -le 24 ]; then
            echo "5G"
        elif [ $ram_gb -le 32 ]; then
            echo "6G"
        elif [ $ram_gb -le 64 ]; then
            echo "8G"
        elif [ $ram_gb -le 128 ]; then
            echo "11G"
        else
            echo "11G"
        fi
    }

    SWAP_SIZE=$(get_swap_size)
    fallocate -l $SWAP_SIZE /swapfile
    chmod 600 /swapfile
    mkswap /swapfile
    swapon /swapfile

    if ! grep -q "^/swapfile.*swap" /etc/fstab; then
        echo "/swapfile none swap sw 0 0" >> /etc/fstab
    fi
fi

# Why 10 instead default 60? see https://help.ubuntu.com/community/SwapFaq#:~:text=a%20value%20of%20swappiness%3D10%20is%20recommended
echo 10 | tee /proc/sys/vm/swappiness
echo "vm.swappiness=10" | tee -a /etc/sysctl.conf

#JaiDécouvert bootc (https://github.com/bootc-dev/bootc)

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/"

Le dimanche 17 novembre 2024, j'ai signé la pétition "nº 0729/2024, présentée par N. W., de nationalité autrichienne, sur le déploiement d’un système d’exploitation «UE-Linux» dans les administrations publiques de tous les États membres".

La commission des pétitions du Parlement européen a communiqué sa réponse le 10 janvier 2025 : PETI-CM-767965_FR.pdf .

Quelques extraits :

Le pétitionnaire demande à l’Union de développer un système d’exploitation pour ordinateur sous Linux, appelé «EU-Linux», et de le déployer dans tous les services publics des États membres.
Cette initiative vise à réduire la dépendance à l’égard des produits Microsoft, à garantir le respect du règlement général sur la protection des données et à favoriser la transparence, la durabilité et la souveraineté technologique au sein de l’Union.
Le pétitionnaire insiste sur l’importance de recourir à des solutions open source se substituant à Microsoft 365, telles que Libre Office et Nextcloud, et propose d’adopter le système d’exploitation mobile E/OS sur les appareils utilisés par les pouvoirs publics. Il souligne par ailleurs le potentiel de création d’emplois dans le secteur des technologies de l’information.

page 1

Bon résumé 👍️.

L’Union soutient toujours davantage la création de logiciels open source, qui limitent la dépendance à l’égard de fournisseurs uniques, favorisent la transparence et renforcent la sécurité des données. Récemment, le règlement pour une Europe interopérable, entré en vigueur en avril 2024 afin de favoriser une coopération fluide entre les États membres, a fait du recours à l’open source et aux normes ouvertes dans les services publics une priorité; les administrations sont ainsi plus transparentes, sûres et à l’abri de tout enfermement propriétaire.

page 2

Lien vers le texte du règlement : "Règlement (UE) 2024/903 du Parlement européen et du Conseil du 13 mars 2024 établissant des mesures destinées à assurer un niveau élevé d’interopérabilité du secteur public dans l’ensemble de l’Union (règlement pour une Europe interopérable)".

#UnJourPeuxÊtre je lirais ce règlement qui, après un parcours rapide de son contenu, me semble très intéressant.

a Commission continue de soutenir une transformation numérique de l’Union fondée sur des solutions open source, en établissant des programmes tels que le programme pour une Europe numérique, le CEF Telecom, et l’ancien programme d’interopérabilité ISA². De plus, son programme de financement Horizon Europe subventionne de nombreux projets qui ont trait au développement et à l’utilisation de logiciels et de matériel open source. Enfin, son initiative sur l’internet de nouvelle génération a permis d’investir plus de 140 millions d’EUR dans plus d’un millier de projets participatifs open source.

page 2

Dans cet extrait, #JaiDécouvert :

Le programme pour une Europe numérique
CEF Telecom
- J'ai suivi des liens et j'ai constaté qu'il est possible de consulter les projets financés. Par exemple, 200 000 € sont allés à DINUM pour un travail sur France Connect : Setting up, integration with “France Connect” and implementation of eID
ISA² - Interoperability solutions for public administrations, businesses and citizens
Horizon Europe
- En lisant cette présentation en français, je constate que le soutien aux free software est indirect et secondaire.
NGI Innovations - qui finance en partie des projets NLNET, qui finance précisément des free software.

La Commission surveille également l’adoption de l’open source par les services publics de l’Union. Pendant près de deux décennies, son Observatoire open source a passé au crible des articles, des rapports ainsi que des études de cas témoignant de l’adoption croissante de l’open source à travers l’Union.

page 2

#JaiDécouvert : Open Source Observatory.

Mentionnons notamment les récents efforts des gouvernements nationaux afin de développer et de mettre en œuvre des solutions open source se substituant aux suites collaboratives de logiciels propriétaires, situation largement conforme à la volonté du pétitionnaire.

page 2

#JaiDécouvert ici le projet openDesk.

Le portail «Europe interopérable», hébergeur de l’Observatoire, incite par ailleurs au partage et à la réutilisation de solutions communes, notamment open source, grâce au catalogage de logiciels.

page 2

Le lien est ici. J'ai l'impression que la page contient une liste de documents d'actualités.

Afin de simplifier ce partage, la Commission a mis sur pied la licence publique de l’Union européenne; elle est disponible en vingt-trois langues officielles de l’Union et est compatible avec de nombreuses licences open source.

page 2

#JaiDécouvert la licence EUPL.

La Stratégie logicielle open source de la Commission incite à l’utilisation de l’open source en interne, encourage la collaboration sur le site code.europa.eu et ouvre la voie à des infrastructures numériques plus durables et transparentes. La Commission organise des hackathons et prévoit des primes aux bogues pour tester des solutions open source prometteuses, comme Nextcloud; elle soutient du reste le passage à l’open source dans des domaines clés, ce qui est d’autant plus conforme aux volontés exprimées dans la pétition.

page 2

Open source software strategy 2020-2023

Je découvre la forge https://code.europa.eu qui semble être limitée à un usage interne. Je suis surpris de ne voir aucun projet public 🤔.

Conclusion

Il n’y a actuellement pas de projet officiel d’établir un «EU-Linux», mais un grand nombre d’initiatives soutiennent activement l’adoption de solutions open source au sein des administrations publiques des États membres. Ces efforts contribuent plus largement aux objectifs européens de transparence, de sécurité et d’indépendance technologique dans le domaine numérique.

page 3

Je suis actuellement à la recherche de modèles de laptop pour mon "Projet 26", qui répondent aux caractéristiques suivantes :

si possible à moins de 1000 € ;
entre 14 et 15 pouces, avec une résolution verticale de 1200 pixels minimum ;
16Go de RAM ;
un trackpad et un châssis avec un maximum de qualité ;
idéalement convertible en 2 en 1 ou 3 en 1 ;
silencieux ;
support GNU/Linux parfait.

Je viens d'effectuer des recherches sur le Subreddit LinuxHardware et je suis tombé sur ce thread "Framework, System76, Tuxedo, Slimbook... Are any of them worth it?" :

Est-ce que les « ordinateurs portables de marque Linux » en valent la peine ? J'ai vu qu'ils offraient des machines avec d'excellentes spécifications pour mon cas d'utilisation, mais j'ai aussi lu de nombreuses plaintes sur la construction fragile et bon marché.

Est-ce que l'une de ces marques propose quelque chose de durable, pas quelque chose de plastique ou de bon marché ?
J'aimerais vraiment soutenir ces entreprises si elles peuvent apporter tout ce qu'il faut au jeu. J'aime le support Linux. Je vois qu'ils offrent de bons composants, parfois évolutifs. Je suis juste préoccupé par la qualité de construction.
J'ai aussi entendu de mauvaises critiques sur l'autonomie de la batterie. Est-ce que j'ai de la chance de voir toutes les critiques et tous les posts pleurer sur la qualité de construction et que ce n'est pas un problème, ou est-ce que je devrais juste acheter un XPS, ou un Thinkpad ?

source

Je me pose les mêmes questions 🙂.

Je connaissais déjà Framework (USA) et System76 (USA). Il y a quelques semaines, j'ai découvert le fabricant espagnol basé à Valence nommé Slimbook (company).

Dans ce thread, #JaiDécouvert l'existence des fabricants suivants :

Malibal (USA)
Starlabs (Company) (UK)
et Tuxedo (DE)

J'ai très bien conscience que ces laptops sont fabriqués par des Original design manufacturer (https://en.wikipedia.org/wiki/Original_design_manufacturer).

Par exemple, je lis ici que les laptop Framework sont fabriqués par Compal Electronics (https://en.wikipedia.org/wiki/Compal_Electronics), une entreprise taïwanaise, qui fabrique entre autres des laptop pour Lenovo, DELL, etc.

Je me suis intéressé à Tuxedo et en particulier le modèle Tuxedo Infinity Flexible 14 Gen 1.

Le modèle suivant est à 1067 € TTC :

Intel Core i5-1335U (10 Cores | 12 Threads | Max. 4.6 GHz | 12 MB Cache | 15 W TDP)
16 GB (2x 8GB) 3200MHz CL22 Samsung
Touch Display | non-glare | WUXGA 1920 x 1200 | 16:10 | 400nits | Stylus MPP2.0
500 GB Samsung 980 (NVMe PCIe 3.0)
FRENCH (FR AZERTY) with backlit with TUX super-key
Intel Wi-Fi 6E AX211 (802.11ax | 2.4, 5 & 6 GHz | Bluetooth 5.3)
USB to LAN Adapter - USB-C & -A - 1GBit USB3.0
USB-C wall mount charger | 100 Watt | EU, UK, US, AU Power Plug
2 years warranty (Incl. parts, labour & shipping)

Concernant le chassis, je lis :

D'une hauteur totale de moins de 2 cm, le tout premier PC convertible de TUXEDO accueille deux types d'appareils dans un seul boîtier : Ordinateur portable et tablette. Le premier convertible à voir le jour dans le monde Linux est livré dans un boîtier partiellement en aluminium argenté, les surfaces extérieures (couvercle et coque inférieure) étant fabriquées dans ce métal stable mais léger pour un transport en toute sécurité.

source

Difficile de se faire un avis avec une photo.

Autre élément qui m'intéresse fortement, c'est la possibilité d'imprimer un layout custom de clavier 😮. C'est la première fois que je rencontre cette possibilité. Je pourrais enfin pouvoir avoir un layout Bépo sur laptop 🙂.

Par le passé, j'avais lu des threads à ce sujet dans le forum de Framework : custom layout

We therefore provide you with the option to customize your TUXEDO to your personal taste thanks to high-quality logo or photo printing as well as custom keyboard laser etching. Get creative and create your unique TUXEDO notebook!

source

Autre élément sympathique, il est aussi possible de customiser le capot du laptop :

Individual keyboard laser etching and logo printing.

source

Tuxedo met à disposition des drivers supplémentaires packagés pour Fedora :

TUXEDO Computers offers a well-maintained repository for Fedora Linux to install additional software such as keyboard drivers or the TUXEDO Control Centre. The repository is to be found on our server.

source

Suite à la lecture de toutes ces informations, je suis très tenté de tenter l'achat d'un Infinity Flexible 14 - Gen 1 pour le Projet 26 - "Expérimentation de migration de deux utilisateurs grand public vers des laptops sous Fedora".

J'ai pris le temps de lire un maximum de commentaires à propos de Tuxedo sur linuxhardware, hackernews. Pour le moment, mon sentiment est positif. J'ai vu quelques commentaires négatifs et beaucoup de commentaires positifs.

J'ai effectué des recherches sur Hardware for Linux https://linux-hardware.org/?view=computers&vendor=TUXEDO et je n'ai pas trouvé de données pour le modèle Infinity Flexible 14 - Gen 1.

Je viens de poster la question suivante sur le Subreddit de Tuxedo et sur sa page de contact de support : Can you execute hw-probe on InfinityFlex 14 Gen1 to upload data to linux-hardware.org ?.

En rédigeant la note 2025-02-12_1044, je me suis demandé quelle est la différence de performance entre un Unix Socket et un INET socket.

Durant mes recherches, j'ai découvert qu'Unix Socket est plus rapide que INET sockets. Je n'ai pas été surpris, j'avais cette intuition.

Toutefois, j'ai été surpris d'apprendre que le gain est non négligeable, de 30% à 50% de gains !

Exemple :

On my machine, Ryzen 3900X, Ubuntu 22,

A basic C++ TCP server app that only sends 64K packets, and a basic c++ receiver that pulls 100GB of these packets and copies them to it's internal buffer only, single-threaded:

achieves ~30-33 GBit/sec for TCP connection (~4.0GB/sec) (not MBit)

and ~55-58GBit/sec for a socket connection, (~7.3 GB/sec)

and ~492Gbit/sec for in-process memcopy (~61GB /sec)

source

Conséquence : je vais essayer d'utiliser des Unix sockets autant que je peux.

#JaiDécouvert le site Linux Performance de Brendan Gregg.

Note de type #aide-mémoire : contrairement à ~/.zprofile, .zshenv est chargé même lors de l'exécution d'une session ssh en mode non interactif, par exemple :

$ ssh user@host 'echo "Hello, world!"'

Je me suis intéressé à ce sujet parce que mes scripts exécutés par ssh dans le cadre du projet /poc-capacitor/ n'avaient pas accès aux outils mis à disposition par Homebrew et Mise.

J'ai creusé le sujet et j'ai découvert que .zprofile était chargé seulement dans les cas suivants :

« login shell »
« interactive shell »

Un login shell est un shell qui est lancé lors d'une connexion utilisateur. C'est le type de shell qui exécute des fichiers de configuration spécifiques pour préparer l'environnement utilisateur. Un login shell se comporte comme si tu te connectais physiquement à une machine ou à un serveur.

Un shell interactif est un shell dans lequel tu peux entrer des commandes de manière active, et il attend des entrées de ta part. Un shell interactif est conçu pour interagir avec l'utilisateur et permet de saisir des commandes, d'exécuter des programmes, de lancer des scripts, etc.

ChatGPT

Suite à cela, dans ce commit "Move zsh config from .zprofile to .zshenv", j'ai déplacé la configuration de Homebrew et Mise de ~/.zprofile vers .zshenv.

Cela donne ceci une fois configuré :

$ cat .zshenv
eval "$(/opt/homebrew/bin/brew shellenv)"
eval "$(mise activate zsh)"

Mais, attention, « As /etc/zshenv is run for all instances of zsh ». Je pense que ce n'est pas forcément une bonne idée d'appliquer cette configuration sur une workstation, parce que cela peut "ralentir" légèrement le système en lançant inutilement ces commandes.

ChatGPT me conseille cette configuration pour éviter cela :

# Ne charge Brew et Mise que si on est dans un shell interactif ou SSH
if [[ -t 1 || -n "$SSH_CONNECTION" ]]; then
  eval "$(/opt/homebrew/bin/brew shellenv)"
  eval "$(mise activate zsh)"
fi

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 !

Note de type #mémento.

Bien que gnome-software prenne en charge (code source) l'upgrade des firmware avec fwupd en mode GUI, j'aime effectuer ces mises à jour en ligne de commande.

Voici les commandes fwupd utiles.

Tout d'abord, pour m'aider à retenir le nom de cet outil : "fwupd" est tout simplement la contraction de "firmware update".

Pour rafraîchir la liste des firmwares disponibles :

$ sudo fwupdmgr refresh

Pour obtenir la liste des mises à jour disponibles :

$ sudo fwupdmgr get-updates

Pour installer les mises à jour disponibles :

$ sudo fwupdmgr update

Dans le blog de Richard Jones, j'ai découvert nbdkit.

nbdkit is an NBD server. NBD — Network Block Device — is a protocol for accessing Block Devices (hard disks and disk-like things) over a Network.

-- from

Dans le tutoriel "Proxmox Template with Cloud Image and Cloud Init", #JaiDécouvert un usage de la commande virt-customize :

# wget https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img
# virt-customize -a noble-server-cloudimg-amd64.img --install qemu-guest-agent --run-command 'systemctl enable qemu-guest-agent.service'

Je trouve cela extrêmement pratique, cela évite de devoir utiliser Packer pour personnaliser une image disque.

J'ai fait quelques recherches et j'ai appris que la fonctionnalité d'installation de package est ancienne, elle a été implémentée dans libguestfs en 2014 par Richard Jones, employé de chez Red Hat (auteur de libguestfs).

#JaiLu 20 years of Linux on the Desktop (part 1) de Ploum, j'y ai appris des choses, comme :

At the start of 2004, I was contacted by Sébastien Bacher, a Debian developer who told me that he had read my "Perfect Desktop" essay months ago and forwarded it to someone who had very similar ideas. And lots of money. So much money that they were already secretly working on it and, now that it was starting to take shape, they were interested in my feedback about the very alpha version.

Chose amusante, j'ai vécu la même expérience que Ploum pendant ma jeunesse :

I had been one of those teenagers invited everywhere to "fix" the computer. Neighbours, friends, family. Yes, that kind of nerdy teenager. You probably know what I mean. But I was tired of installing cracked antivirus and cleaning infested Microsoft Windows computers, their RAM full of malware, their CPU slowing to a crawl, with their little power LED begging me to alleviate their suffering.

Alexandre m'a partagé l'article "Linux : Enregistrer toutes les commandes saisies avec auditd" qui présente Linux Audit.

The Linux audit framework provides a CAPP-compliant (Controlled Access Protection Profile) auditing system that reliably collects information about any security-relevant (or non-security-relevant) event on a system. It can help you track actions performed on a system.

-- from

La norme de sécurité de l'industrie des cartes de paiement (Payment Card Industry Data Security Standard ou PCI DSS) est un standard destiné à poser les normes de la sécurité des systèmes d'information amenés à traiter et stocker des process ou des informations relatives aux systèmes de paiement.

Dans ce cadre, de nombreuses conditions sont à respecter afin d'être compatible avec cette norme. Parmi celles-ci, l'enregistrement des commandes et instructions saisies par les utilisateurs à privilèges sur un système.

-- from

D'après ce que j'ai compris, la fonctionnalité Linux Audit est implémentée au niveau du kernel.

Linux Audit permet de surveiller les actions effectuées sur les fichiers (lecture, écriture…) et les appels syscalls.

D'après ce que je comprends, Linux Audit est conçu à des fins de sécurité. Il semble peu adapté pour documenter les opérations réalisées sur un serveur dans le cadre d'un travail collaboratif.

#JaiLu l'article My Wayland Your Wayland Our Wayland de Mike Blumenkrantz un développeur Wayland.

#JaiLu Google Authenticator - ArchWiki.

Code source de Google Authenticator PAM module : https://github.com/google/google-authenticator-libpam.

#JaiLu Securing A Linux Server.

J'ai trouvé cet article excellent.

J'y ai découvert :

#JaiLu Is Linux collapsing under its own weight? On Rust for Linux, j'ai trouvé cela très intéressant (from).

À la suite de cette lecture, j'ai lu ce thread Lobster : https://lobste.rs/s/yx57uf/is_linux_collapsing_under_its_own_weight.

J'ai lu Rust for Linux revisited de Drew DeVault, bien que n'étant pas un spécialiste du sujet, je trouve son idée intéressante.

Je dois passer par un VPN pour accéder à un projet professionnel.

Ce VPN est propulsé par OpenVPN.

Ma workstation tourne sous Fedora, sous GNOME.

J'ai réussi à configurer facilement l'accès OpenVPN via NetworkManager-openvpn via l'import de fichier .ovpn.

Cependant, cette méthode de configuration m'a posé un problème : le routage par défaut était dirigé vers le VPN. Conséquence, l'intégration de mon accès à Internet passait par le réseau VPN qui était bien plus lent que mon accès Internet.
Ceci était très frustrant.

De plus, cette configuration ajoutait une charge réseau supplémentaire inutile au VPN.

J'ai essayé d'utiliser l'option "N'utiliser cette connexion que pour les ressources sur ce réseau" mais cela n'a pas fonctionné.

Peut-être un problème DNS 🤔.

J'ai donc choisi une autre stratégie. J'ai configuré cela sans GUI.

Voici le skeleton de mon dossier de connexion au VPN : https://github.com/stephane-klein/openvpn-client-skeleton (celui-ci ne contient aucun secret).

Ce projet me permet :

D'utiliser le serveur DNS présent dans le réseau privé seulement pour un certain type de sous domaine.
Le VPN est utilisé uniquement pour les serveurs qui se trouvent à l'intérieur du réseau privé. Par exemple, je ne passe pas par ce VPN pour accéder à Internet.
La totalité de cette configuration est basé sur des fichiers et est scripté (pratique GitOps)
OpenVPN client est managé par SystemD

Voir aussi 2024-08-14_1511.

Je suis victime du bug suivant depuis 2 ou 3 jours sous ma Fedora :

Unexpected Logouts and System Instability: The second, more critical issue I’ve been facing is unexpected system logouts. Over the past two days, my screen has suddenly gone black as if the system has shut down. After less than a second, the login screen reappears, and upon logging in, I find that all my applications have closed. Yesterday, August 11, 2024, this happened twice within a three-minute span. Today, August 12, 2024, while studying with only Firefox open, I suspended my laptop and left.

-- from

J'en apprends plus ici :

A new regression for AMD APU’s is present in kernel 6.10 that wil cause intermittent full system crashes in combination with Mesa 24.1.5. The only option is to power down and restart the machine.

Kernel 6.9 is unaffected.

Issue upstream : https://gitlab.freedesktop.org/drm/amd/-/issues/3497

Je vais donc reboot sous un kernel 6.9 🤷‍♂️.

Je suis sûr qu'Alexandre va me dire qu'il n'a aucun problème sous ArchLinux ! Mais je ne le croirai pas, c'est un bug upstream !

Voir aussi ma doctrine Linux Desktop.

2024-08-22 : J'ai posté ce message AMD APU regression (full halt) on kernel 6.10 - how to best report?

2024-09-12 : J'ai posté ce message How to list Mesa versions included in my flatpak applications?

2024-10-15 : J'ai posté ce message.

Dans ce thread je lis :

Linus Torvalds himself uses Fedora

et aussi un peu plus bas, je lis :

the second guy in linux (greg k.-h.) uses arch though 😊

Greg Kroah-Hartman

Linus vient s'ajouter aux nombreux developeurs mainstreams qui utilisent Fedora.

#JaimeraisUnJour commencer à dresser cette liste (chose que j'ai commencé à faire avec cette note).

Fedora 40 version stable est sortie le 23 avril 2024 et presque un mois plus tard, j'ai upgrade mon Thinkpad T14s de la version 39 vers la version 40.

Que ce soit par le passé avec MacOS et maintenant avec Fedora, pour éviter d'être impacté par des bugs, ou des régressions, j'ai pris l'habitude d'attendre quelques semaines avant d'effectuer un upgrade d'OS majeur de ma workstation.

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=40
# 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.

Je viens de modifier ma configuration (dotfiles) tmux :

https://github.com/stephane-klein/dotfiles/commit/f370721781f6ea1b72c1954f43ce50196112e72e

La configuration suivante

set -g window-status-current-format "#[fg=colour231,bg=colour33,bold] #{?window_name,#{window_name},#{b:pane_current_path}} #[nobold]"
set -g window-status-format "#[fg=colour33,bg=colour254,bold] #{?window_name,#{window_name},#{b:pane_current_path}} #[nobold]"

permet de définir cette ligne status :

Pour chaque fenêtre est affichée soit le nom de la fenêtre, soit le nom du dossier courant du shell actif dans la fenêtre.

La syntaxe suivante est documentée ici :

#{?window_name,#{window_name},#{b:pane_current_path}}

Ce qui signife #{?condition,true_value,false_value}.

La configuration suivante

bind-key c new-window -c "#{pane_current_path}" -n ""

-n "" permet de définir par défaut le nom des nouvelles fenêtres avec un chaine vide.

Sujet : Doctrine Linux Desktop.

Suite aux bugs décrits dans ma note du 2024-01-28, je pense que si je devais installer un Linux Desktop pour des amis non hackers, comme ma petite amie ou ma mère, je choisirais une version de Fedora n-1.
La dernière version de Fedora est actuellement la numéro 39, donc j'opterais pour la version 38.

Les versions de Fedora sont maintenues pendant un an.
Après six mois, les mises à jour se concentrent exclusivement sur les corrections de bugs et de sécurité, sans mise à niveau du kernel ou des autres composants principaux.

Bien que la version la plus récente de Fedora soit très stable, les mises à jour sont fréquentes et proches des versions upstream.
Cela peut exposer les utilisateurs à des bugs upstream, comme cela m'est arrivé récemment.

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

Vous êtes sur la première page | [ Page suivante (54) >> ]