Introduction aux systèmes Linux immuables

 (dataswamp.org)
3 points par GN⁺ 2023-09-19 | 1 commentaires | Partager sur WhatsApp
  • Les distributions Linux immuables proposent un mode de fonctionnement où les mises à niveau sont préparées ailleurs que sur le système en cours d’exécution et appliquées au prochain démarrage, avec possibilité de revenir en arrière en cas d’échec.
  • Malgré le terme « immuable », de nombreuses zones du système peuvent toujours changer ; leur véritable point commun est plutôt proche des mises à jour transactionnelles et du rollback.
  • NixOS et Guix s’appuient sur une configuration déclarative et un dépôt en lecture seule, tandis que les familles OSTree, MicroOS et Vanilla OS abordent respectivement le sujet via /usr, des instantanés btrfs et des partitions racine A/B.
  • L’avantage est de maintenir le système stable pendant les changements de paquets et de pouvoir annuler les problèmes, mais la nécessité de redémarrer, les conflits avec les outils de gestion de configuration et la difficulté à suivre les changements demeurent.
  • La nouveauté ne tient pas tant aux instantanés eux-mêmes qu’au fait d’appliquer les changements dans un environnement non live, puis de les intégrer au bootloader et aux outils utilisateur pour les rendre plus faciles à manipuler.

La portée réelle du terme « immuable »

  • L’immuabilité désigne à l’origine un objet qui ne change pas, mais appliquée à un système d’exploitation, sa définition devient immédiatement floue.
  • Un LIVE-CD Linux peut sembler immuable, puisqu’il démarre à chaque fois avec les mêmes programmes et que le support disque est en lecture seule, mais pendant l’exécution il reste possible de créer des fichiers et des répertoires ou d’installer des paquets.
  • Pour qualifier aujourd’hui une distribution Linux d’immuable, trois conditions sont généralement nécessaires :
    • les mises à niveau du système ne sont pas effectuées directement sur le système live ;
    • les changements de paquets sont appliqués au prochain démarrage ;
    • il est possible de revenir à un état antérieur via un rollback.
  • Les fonctionnalités supplémentaires varient selon les implémentations, mais ces trois points correspondent à peu près aux critères minimaux actuels des distributions dites « immuables ».

Différences selon les implémentations

  • NixOS / Guix

    • NixOS et Guix reposent sur des implémentations de la même famille : Nix est apparu pour la première fois en 2003, et le gestionnaire de paquets Guix a été forké depuis Nix au début des années 2010 avec l’objectif d’être 100 % logiciel libre.
    • Les deux systèmes diffèrent fortement des systèmes Unix traditionnels et font de l’immuabilité un principe central.
    • Tous les paquets et fichiers générés sont stockés comme des entrées uniques dans un répertoire spécial en lecture seule, dans lequel seul le gestionnaire de paquets peut écrire.
    • Le système d’exploitation lui-même est un résultat produit par le gestionnaire de paquets, et l’utilisateur décrit l’état système souhaité sous forme de configuration déclarative.
    • La configuration inclut notamment les utilisateurs, les shells, les paquets installés, les services exécutés et leurs réglages, ainsi que les partitions à monter et leurs options.
    • Les modules fournissent des valeurs par défaut, si bien qu’il n’est pas nécessaire de préciser manuellement l’UID, le GID, le shell et le répertoire personnel lors de la création d’un utilisateur.
    • Des fichiers comme /etc/fstab ou /bin/sh sont également en lecture seule ; pour les modifier, il faut passer par le gestionnaire de paquets.
    • Le changement de configuration s’apparente à un changement de liens symboliques et peut donc être immédiat ; au démarrage, il est possible de sélectionner une configuration précédente pour revenir en arrière.
    • En dehors du répertoire de stockage spécial, /home, /etc, /var et d’autres emplacements restent modifiables ; on peut remplacer les liens symboliques système par d’autres, mais les sources d’origine ne peuvent pas être modifiées.
    • NixOS est considéré comme une bonne implémentation, mais il est si différent des systèmes existants que son adoption reste faible malgré ses avantages.

  • Endless OS

    • Endless OS est l’un des premiers OS immuables destinés au grand public ; il vise à fournir un système robuste utilisable même dans des pays où la couverture Internet ou électrique est limitée.
    • Il est basé sur Debian, mais implémente l’immuabilité avec OSTree.
    • OSTree gère l’image système centrale et ajoute par-dessus des couches de type paquets ; il peut aussi préparer une nouvelle image système pour le prochain démarrage.
    • Les changements de paquets sont appliqués à la nouvelle version du système qui sera utilisée au démarrage suivant, et il est possible de revenir à la version précédente au boot.
    • Les partitions sont généralement accessibles en écriture, mais /usr, la zone de paquets gérée par OSTree, est montée en lecture seule.
    • /etc ne dispose pas de rollback.
    • Les applications utilisateur sont installées via Flatpak, ce qui réduit le besoin de redémarrer à chaque installation de nouveau paquet.
    • Le bureau GNOME modifié ressemble à un menu de smartphone et vise une interface familière pour les utilisateurs non techniques.
    • L’installation d’outils DevOps n’est pas vraiment pratique, mais elle n’est pas impossible.

  • Fedora Silverblue

    • Fedora Silverblue s’inscrit dans la lignée de Project Atomic, qui cherchait à rendre Fedora / CentOS / RHEL immuables.
    • Il utilise rpm-OSTree, qui applique des changements de paquets RPM au-dessus d’OSTree.
    • Le système est composé d’une image de base unique par release et de couches de paquets ajoutées par-dessus.
    • Il est possible de lister les couches de paquets installées ; lorsqu’un paquet est supprimé, toute la pile est régénérée afin qu’il ne reste aucun résidu après suppression.
    • Ce processus de régénération est très lent.
    • L’installation d’un paquet ne s’appliquant pas au système actuellement démarré, un redémarrage est nécessaire par défaut ; au boot, il est possible de choisir une version précédente du système.
    • rpm-OSTree fournit une fonction qui fusionne temporairement les changements destinés au prochain démarrage dans le système live via un overlay tmpfs.
    • La politique de montage est en lecture seule, sauf pour /etc, /root et /var ; les répertoires personnels se trouvent par défaut dans /var/home, ce qui peut surprendre.
    • /etc n’étant pas géré par rpm-OSTree, il n’est pas restauré lors d’un rollback.
    • /usr/local est un lien symbolique vers un répertoire situé dans /var, ce qui facilite l’injection de changements utilisateur sans fichiers RPM.
    • Comme l’installation de paquets est lente et nécessite un redémarrage, l’usage de Flatpak ou de toolbox est recommandé.
    • toolbox crée des conteneurs Fedora sans droits root permettant d’utiliser bibliothèques de développement et outils depuis le terminal.

  • OpenSUSE MicroOS / Aeon

    • OpenSUSE MicroOS est une variante immuable d’OpenSUSE Tumbleweed, en rolling release, avec sa propre implémentation.
    • L’ensemble du système, à l’exception de certains répertoires comme /home et /var, repose sur des instantanés btrfs.
    • Lorsqu’un changement système est nécessaire, l’instantané actuel est cloné en un nouvel instantané, puis le changement est appliqué à ce nouvel instantané pour être utilisé au prochain démarrage.
    • Contrairement aux systèmes basés sur OSTree, /etc fait aussi partie de l’instantané et peut donc faire l’objet d’un rollback.
    • Il est possible d’utiliser un shell dans le nouvel instantané pour modifier n’importe quel fichier du système de fichiers, ce qui est utile pour des opérations comme l’injection de fichiers destinés à résoudre des problèmes de pilotes.
    • Ces changements ne sont toutefois pas suivis, ce qui rend difficile de garantir que le système reste dans un état « pur ».
    • Les changements sont effectués avec la commande transactional-update, qui permet d’ajouter ou de supprimer des paquets, ou d’ouvrir un shell dans un nouvel instantané pour y appliquer les modifications souhaitées.
    • /etc est inclus dans les instantanés mais reste toujours accessible en écriture ; si l’on modifie /etc sur le système live puis que l’on crée un nouvel instantané, ce changement est immédiatement hérité.
    • L’approche par défaut consiste à prévoir un redémarrage quotidien après les mises à jour ; comme il s’agit d’une rolling release, il y a des mises à jour tous les jours et l’on ne bénéficie pas des nouveaux paquets avant redémarrage.
    • Le redémarrage automatique peut être désactivé.
    • Comme sur Silverblue, la fonction permettant d’appliquer des changements au système live est actuellement expérimentale et pas encore utilisable.
    • À la place, l’usage de distrobox est recommandé pour installer des outils utilisateur dans des conteneurs sans droits root issus de plusieurs distributions.

  • Vanilla OS

    • Vanilla OS est un nouveau système de la famille immuable, basé sur Ubuntu et bientôt appelé à passer sur une base Debian.
    • L’immuabilité y est implémentée via ABroot.
    • ABroot utilise une partition racine A, une partition racine B et une partition pour les données persistantes comme /home ou /var.
    • Le flux de démarrage et de changement est le suivant :
      • le premier démarrage se fait depuis A, montée en lecture seule ;
      • les changements système, comme l’installation de nouveaux paquets ou la modification de fichiers dans /etc, sont appliqués à B, avec la possibilité de les appliquer aussi en live via un overlay tmpfs ;
      • après redémarrage, le système démarre sur B et, en cas de succès, ABroot scanne les différences entre A et B pour appliquer les changements de B à A ;
      • lorsqu’il n’y a pas de nouveau changement, A et B sont toujours identiques.
    • L’inconvénient est qu’il n’est possible de revenir en arrière que jusqu’au démarrage sur la nouvelle version.
    • Une fois la nouvelle version démarrée, les changements sont également appliqués à la partition de démarrage précédente et le rollback n’est plus possible.
    • Cette approche est surtout utile pour annuler une mise à niveau échouée ou un changement testé en live.
    • Vanilla OS fournit le gestionnaire de paquets apx.
    • apx est un outil créé par l’auteur de distrobox ; il permet à des utilisateurs non root d’installer des paquets provenant de plusieurs distributions comme Arch Linux, Fedora, Ubuntu ou Nix, et de les intégrer comme s’ils étaient installés localement.
    • Vanilla OS, ABroot et apx sont encore jeunes et présentent quelques aspérités.

  • Alpine Linux avec LBU

    • Alpine Linux permet de créer une configuration proche de l’immuabilité avec la commande lbu.
    • Elle utilise le programme d’installation d’Alpine comme système de démarrage de base et crée une archive tarball de « configuration enregistrée » qui est appliquée automatiquement au démarrage.
    • À chaque démarrage, les répertoires sont décompressés à nouveau et les paquets réinstallés ; tout est entièrement accessible en écriture dans la mémoire live.
    • Le système démarre toujours depuis un état propre, applique les changements par-dessus, et peut revenir en arrière puis repartir de zéro.
    • Cela ne satisfait pas totalement la définition d’immuabilité donnée plus haut, car les changements sont appliqués par-dessus le système de base.
    • Comme tout le système est en mémoire et que les éléments à sauvegarder et restaurer doivent être gérés manuellement, cette approche demande une bonne compréhension et l’archive peut devenir volumineuse.
    • La documentation est également insuffisante.

Avantages et contraintes opérationnelles

  • Avantages

    • En cas de problème, il est possible de revenir sur les changements.
    • Les mises à jour transactionnelles aident le système à continuer de fonctionner correctement pendant les changements de paquets.

  • Inconvénients

    • L’intégration avec les outils de gestion de configuration comme Ansible, Salt ou Puppet est très mauvaise.
    • Même s’ils ont été mis à jour pour connaître le mode d’application des changements de paquets, tenter de les administrer comme un système classique mène le plus souvent à un mur.
    • Le fait de devoir redémarrer après des changements est pénible, même si NixOS et Guix ne nécessitent pas de redémarrage à chaque changement.
    • Les systèmes basés sur OSTree manquent de souplesse.
      • Par exemple, sur un netbook nécessitant des fichiers supplémentaires dans un répertoire ALSA pour le son, il est impossible de les ajouter sans créer un paquet qui distribue ces fichiers.
    • Le rollback ressemble à un rollback à l’aveugle, car il est difficile de savoir quels changements existaient dans chaque version du système.
    • Les programmes comme Nix/Guix, qui nécessitent des répertoires dans le système de fichiers racine, ou l’installation système globale de logiciels non empaquetés peuvent poser problème.

Réalités et idées reçues sur les systèmes immuables

  • L’immuabilité, à strictement parler, est presque un abus de langage : de nombreuses parties du système restent modifiables.
  • Immuable ne signifie pas stateless.
  • NixOS et Guix sont considérés comme des implémentations ayant adopté dès le départ la bonne philosophie, car ils suivent l’ensemble du système avec un gestionnaire de paquets stable et peuvent utiliser un système de gestion de versions pour les sources.
  • L’immuabilité est souvent associée à des avantages de sécurité, mais un attaquant ayant obtenu les droits root peut manipuler le système live et aussi toucher à la partition /boot.
  • Rien n’empêche l’installation d’une backdoor destinée au prochain démarrage.
  • L’immuabilité exige discipline et maintenance.
    • Il faut prêter attention à la gestion de versions.
    • Les programmes supplémentaires comme apx, distrobox ou devbox doivent être mis à jour séparément du système.
    • NixOS et Guix intègrent cette partie.

Ce qui est réellement nouveau

  • Les systèmes d’exploitation immuables attirent l’attention dans la communauté des systèmes open source, mais le même terme regroupe plusieurs implémentations et cas d’usage.
  • Le nom « immuable » crée certaines attentes chez les utilisateurs, alors qu’il s’agit en réalité plutôt de mises à jour transactionnelles pour systèmes d’exploitation.
  • Les mises à jour transactionnelles elles-mêmes ne sont pas un concept nouveau.
    • Solaris et ZFS permettaient déjà de sélectionner un instantané système au démarrage.
    • FreeBSD semble avoir implémenté une fonction similaire il y a environ dix ans.
    • Les distributions Linux classiques peuvent aussi permettre de choisir un instantané au démarrage avec des instantanés btrfs.
  • Ce qui est vraiment nouveau, c’est l’application des changements transactionnels dans un environnement non live, leur intégration au bootloader et la fourniture d’outils permettant aux utilisateurs de les manipuler facilement.
  • Pour aller plus loin, l’article de Colin Walters « Immutable » → reprovisionable, anti-hysteresis est recommandé.

À lire aussi

1 commentaires

 
GN⁺ 2023-09-19
Avis sur Hacker News

  • Je suis content que Silverblue figure dans la liste, mais c’est dommage que Fedora CoreOS n’y soit pas
    FCOS est un OS adapté à la production, il a beaucoup évolué depuis l’acquisition de CoreOS, et il ressemble à un bon compromis par rapport à Nix : plus facile à apprendre et à utiliser tout en conservant l’immutabilité
    CoreOS Layering, ajouté par l’équipe de développement de FCOS, est une fonctionnalité puissante : on définit l’état du système avec un Dockerfile, FCOS se rebase sur cet état, et la configuration du serveur ne nécessite qu’un redémarrage
    Si vous avez besoin d’une VM pour votre prochain projet, ça vaut le coup d’essayer. J’ai aussi créé Bupy, un outil CLI en Python qui facilite la création locale de fichiers Butane sur une station de travail Linux, et il existe aussi un exemple faisant tourner Paperless NGX avec CoreOS Layering
    https://github.com/quickvm/bupy
    https://github.com/quickvm/fcos-layer-paperless-ngx
    https://coreos.github.io/rpm-ostree/container/
    https://github.com/coreos/enhancements/blob/main/os/coreos-l...
    https://github.com/coreos/layering-examples

    • Je serais aussi curieux d’avoir un avis sur Flatcar, un autre projet de la famille CoreOS
      Le plus difficile, pour moi, a été de comprendre comment utiliser ce type de projet sur du bare metal. Créer des images de VM, c’est très bien, mais en pratique on veut souvent l’installer sur un disque existant, ou l’installer avec un pool ZFS en dessous
    • CoreOS Layering a vraiment l’air utile. Pour l’instant, j’utilise openSUSE MicroOS sur quelques Raspberry Pi et un serveur x86_64, et l’une des raisons pour lesquelles j’ai choisi MicroOS est que l’installation sur Raspberry Pi était assez simple
      Je me demande à quel point il est difficile d’installer CoreOS sur un Raspberry Pi. Certains guides d’installation en ligne ont l’air assez complexes

  • Un autre axe qui manque toujours dans ces présentations de systèmes immuables, c’est l’approche basée sur des images
    Je travaille sur https://universal-blue.org/ avec des personnes bien plus compétentes que moi, où nous construisons des images de conteneurs OCI par-dessus Fedora Silverblue de base et plusieurs éditions de bureau
    Ces images peuvent être démarrées avec rpm-ostree, ou plus exactement servir de cible de rebase, et c’est une manière d’étendre le système plus robuste que la superposition de couches ; les mêmes changements peuvent être facilement hérités ou réutilisés par n’importe qui. Créer sa propre image est aussi très simple
    VanillaOS et SUSE semblent faire quelque chose de similaire, mais nous ne sommes pas un projet d’OS, seulement un downstream de Fedora. Le support officiel de Fedora est également en cours, et rien qu’avec ce qui fonctionne déjà, c’est d’après mon expérience l’une des méthodes les plus robustes et les plus simples pour des tâches comme la fourniture des pilotes Nvidia

    • C’est un peu un autre sujet, mais vers 2009 j’avais été impressionné par un gros hyperviseur faisant tourner des hôtes Windows Remote Desktop. C’était probablement Citrix
      Les VM démarraient depuis une image, et l’image comme le disque des modifications étaient entièrement en RAM. Les profils utilisateur étaient sur disque dur, mais un hôte de bureau pour 25 personnes démarrait en environ 4 secondes jusqu’à être prêt à accepter des connexions distantes
      C’était le système Windows le moins pénible à patcher
    • Je suis un peu perdu, car je pensais que Fedora Silverblue était aussi basé sur des images
      Je croyais que l’installation de base n’utilisait pas de layering, et que celui-ci n’intervenait que lorsqu’on voulait installer des paquets RPM supplémentaires
    • UBlue semble reconstruire régulièrement ses images avec GitHub Actions pour intégrer les mises à jour de paquets. Je me demande qui paie les coûts
      Je me demande aussi si les images sont fournies par GitHub, si GitHub facture le trafic sortant, et ce qui se passe si beaucoup d’utilisateurs essaient de télécharger la même image

  • Je m’intéresse davantage aux systèmes préconfigurés qu’aux systèmes immuables
    Ici, NixOS et Home Manager se distinguent, mais leur façon de configurer les choses est vraiment horrible. Je veux mettre toute la configuration sous contrôle de source, savoir que l’état actuel du système correspond à cette configuration, et que tout autre changement soit effacé au redémarrage. Ce serait bien que les changements effectués avant le redémarrage soient mis en évidence
    D’après mon expérience limitée avec des choses comme Silverblue, on peut configurer le système de base, mais dès qu’on commence à ajouter des applications comme Firefox, on finit par utiliser Flatpak, et je ne sais pas bien comment déclarer à la fois toute l’installation Flatpak souhaitée et sa configuration
    Il existe probablement une méthode pour installer les Flatpak en bloc et gérer le reste avec des dotfiles
    https://universal-blue.org/tinker/mindset/#resist-the-urge-t...

  • Le problème que j’ai rencontré avec Flatpak et, plus généralement, avec l’approche immuable, c’est qu’on ne peut pas modifier les choses d’une façon que les développeurs ne prennent pas en charge.
    Par exemple, je synchronise mon calendrier avec decsync et, à ma connaissance, il est impossible d’ajouter le plugin decsync au Flatpak d’Evolution.
    Tant que ces systèmes immuables ne prendront pas en charge comme fonctionnalité de premier ordre l’empilement de systèmes de fichiers en surcouche personnalisés pour les cas d’usage que les développeurs ne peuvent pas ou ne veulent pas prendre en charge, les gens continueront à utiliser des systèmes mutables.

    • NixOS offre justement ce type de contrôle de plusieurs manières.
      Certains paquets de nixpkgs ainsi que la plupart des modules NixOS et Home Manager exposent de nombreuses options permettant de configurer des plugins, des paquets supplémentaires, etc.
      Nix fournit aussi des overlays et des overrides pour ajouter des paquets personnalisés ou des variantes de paquets existants, et il permet même de remplacer une partie d’un paquet. Si cela ne suffit toujours pas, on peut appliquer directement un patch au code ou construire depuis un fork du dépôt upstream.
      En pratique, c’est l’un des aspects que je préfère dans Nix. Il est facile de dire « lors de la construction de ce paquet, remplace cette dépendance par ma version », ce qui me pousse à contribuer plus souvent à l’open source.
    • Des choses comme « ajouter le plugin decsync au Flatpak d’Evolution » sont très courantes dans les logiciels GUI sous Linux.
      En dehors de ce domaine, la plupart des logiciels fournissent les fonctionnalités nécessaires. Par exemple, Solidworks ne m’a jamais demandé de télécharger une dépendance optionnelle, alors que FreeCAD me réclamait littéralement quelque chose toutes les 15 minutes à chaque étape suivante d’un flux CAD/CAM/simulation/rendu.
      https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv... mérite aussi d’être lu.
      L’idée centrale est que les « 20 % que tout le monde utilise » ne sont jamais les mêmes. Ces dix dernières années, j’ai entendu parler de dizaines d’entreprises qui tentaient de sortir un traitement de texte « léger » n’implémentant que 20 % des fonctionnalités ; puis un journaliste, en écrivant sa critique, cherchait la fonction de comptage des mots, découvrait qu’elle faisait partie des « 80 % que personne n’utilise », et finissait par écrire quelque chose du genre « les programmes légers, c’est bien, le bloat, c’est mal, mais ce fichu truc ne sait pas compter les mots, donc il est inutilisable » — une histoire aussi vieille que le PC.
    • Si l’on en arrive à empiler des systèmes de fichiers en surcouche personnalisés comme fonctionnalité de premier ordre, autant utiliser simplement un système mutable, non ?
      Cela me rappelle tout le monde qui s’est rué vers NoSQL il y a dix ans, avant de réinventer presque aussitôt les schémas au sein de chaque projet.
    • On peut aussi ajouter des plugins aux applications Flatpak, et ces plugins peuvent être empaquetés sous forme de paquets d’extension.
      OBS en est un exemple. Sur Flathub, il existe plusieurs plugins OBS de la forme com.obsproject.Studio.Plugin.*.

  • Je pense qu’il faudrait définir cela ainsi : après avoir installé n’importe quel nombre de paquets, si on les supprime à n’importe quel moment futur et dans n’importe quel ordre, le système doit revenir à un état équivalent à celui dans lequel ils n’auraient jamais été installés au départ.
    Cette définition exclurait certaines distributions, mais je pense que la partie importante de ce concept est précisément cette propriété.

    • Le point essentiel me semble être que, sur un système destiné aux utilisateurs, cette propriété est pratiquement impossible.
      Quand on supprime un traitement de texte ou un éditeur de texte, veut-on aussi supprimer tous les fichiers qu’on a écrits avec ? Si on supprime un navigateur, tous les fichiers téléchargés doivent-ils disparaître ? Si la réponse est non, il n’existe aucun moyen fiable de distinguer les fichiers créés automatiquement par le programme de ceux que l’utilisateur a créés avec ce programme.
      Ce qui a été créé pendant l’installation peut être supprimé facilement, mais pas toutes les modifications ultérieures.
      On peut aussi imaginer le cas où l’on a changé d’implémentation DNS puis, plus tard, modifié le serveur DNS par défaut. Lorsqu’on supprime le provider pour revenir à l’ancienne implémentation, faut-il aussi revenir à l’ancien serveur, ou conserver la nouvelle configuration de serveur ? Personnellement, je voudrais seulement changer de provider et conserver le nouveau serveur.
      Les répertoires partagés entre plusieurs machines compliquent aussi les choses. Si /home/${USER} est un montage NFS ou Samba et que les mêmes fichiers sont utilisés sur plusieurs stations de travail, qu’un programme crée des fichiers dans le répertoire de configuration XDG, puis qu’on supprime ce programme sur une station, faut-il supprimer ces fichiers pour toutes les machines ? Le gestionnaire de paquets d’un système unique n’a aucun moyen de savoir si tous les appareils doivent être identiques ou si seul le répertoire personnel doit l’être.
    • La question est de savoir jusqu’où on veut appliquer cette propriété.
      Il peut être intéressant de regarder les structures de données à représentation unique et les structures de données indépendantes de l’historique.
      Il faudrait accorder une attention particulière à ce qu’un périphérique bloc, par exemple un SSD, alloue les blocs indépendamment de l’historique.
    • Cette propriété s’appelle la reproductibilité : une même configuration produit toujours le même état système.
    • Cette définition me plaît.
      On pourrait aussi dire que l’ensemble des paquets forme un treillis et que, quel que soit le chemin par lequel on atteint un sous-ensemble de paquets, il n’existe qu’un seul état.

  • J’utilise Fedora Silverblue depuis sa sortie, et c’est clairement l’avenir
    Je pense que tout le monde devrait utiliser ostree

    • Silverblue ne m’a pas semblé assez flexible pour un ordinateur personnel
      C’est peut-être que j’utilise Linux de façon un peu improvisée, mais ne pas avoir les droits d’écriture dans des dossiers comme /usr ou /bin me rendait fou environ une fois toutes les deux semaines
      Par exemple, un script écrit par un utilisateur d’Ubuntu cherchait une bibliothèque avec le nom et l’emplacement à la façon d’Ubuntu, alors que Fedora donne un autre nom à cette bibliothèque. Dans ce genre de cas, mon réflexe est de créer un lien symbolique avec le nom Ubuntu pointant vers la bibliothèque gérée par le RPM Fedora
      Mais en pratique, pour que ça fonctionne, il a fallu forker le script, faire en sorte qu’il se construise en local, le corriger pour qu’il cherche les deux noms de bibliothèque, lancer les tests en local, envoyer une PR upstream, etc. Une chose qui, d’ordinaire, se règle en une ligne de shell est devenue une tâche de 90 minutes
    • Ça fait un an que je l’utilise, et c’est vraiment excellent. Je me demande si Red Hat se rend compte de ce qu’ils ont entre les mains. Pas seulement Silverblue, mais Fedora lui-même
      J’ai lu dans une réponse Quora une estimation du budget de développement de Windows OS à environ 18 milliards de dollars sur la base des salaires. Si l’on imagine Red Hat investir 2 milliards de dollars dans Fedora pour en faire le Firefox du monde des OS de bureau, prendre ne serait-ce que 10 % de parts de marché face à Microsoft serait déjà énorme
      Ils sont arrivés jusque-là avec si peu de ressources, au-dessus de milliers de paquets open source. Cet argent pourrait servir à maintenir en vie ce type de projets et à les financer pendant leur développement. Les employés de Red Hat sont déjà impliqués dans beaucoup d’entre eux
    • J’aime l’idée d’ostree, mais d’après le survol rapide que j’en ai fait, ça ne m’a pas semblé aussi accueillant que Docker pour un utilisateur ordinaire ou intermédiaire. Docker peut s’apprendre en une après-midi par un particulier
      Je n’ai pas bien vu comment on arrive au point de « distribuer une distribution Debian sous forme de snapshots ostree »
      Je me demande si c’est conçu uniquement pour les administrateurs système professionnels ou les gens qui fabriquent des systèmes
    • Si vous avez essayé Nix, je serais curieux de savoir comment ça se compare
      Je n’ai pas essayé Silverblue, mais Nix aussi donne l’impression d’être l’avenir
    • Pour l’instant, j’utilise Ubuntu sur mon serveur et j’ai vu qu’ostree était dans les dépôts, mais je n’ai pas encore pu essayer
      Si possible, j’aimerais commencer à versionner mon système actuel tel quel. Si c’est trop difficile ou impossible, je pense migrer un jour le serveur vers Silverblue. J’aime vraiment l’idée d’ostree

  • Cet été, je suis tombé dans Tinycore
    Ça complète bien la philosophie de sécurité « un OS, une fonction » qui sous-tend Qubes, Tails et Whonix, dont on parlait ici il y a quelques jours
    C’est tellement léger qu’on peut lancer en quelques secondes une VM pour le serveur mail, une VM pour la base de données, et une VM pour le pare-feu/routeur
    Tinycore lui-même est immuable, donc il suffit de mettre les « paquets » et la configuration dans un vdisk et de le marquer en lecture seule. Un script Virsh gère le démarrage et l’arrêt du « service », chaque service étant une instance Tinycore
    C’est amusant et jusqu’ici solide, mais je ne suis pas encore sûr de le mettre en production chez quelqu’un

    • TinyCore est toujours absent de ce genre de présentations des Linux immuables. Il existe depuis longtemps et sa conception est excellente
      L’implémentation a ses défauts, et il n’y a sans doute pas non plus d’entreprise sponsor pour expliquer pourquoi les gens le connaissent mal
      Contrairement à d’autres distributions Linux immuables, il est robuste et simple

  • J’utilise Fedora Sericea depuis sa sortie. C’est essentiellement Fedora Silverblue, mais avec Sway-wm au lieu de Gnome-wm
    En pratique, c’est tout à fait utilisable, et il n’est pas non plus nécessaire de redémarrer à chaque commande rpm-ostree install. rpm-ostree live-apply s’en charge avec un overlay basé sur systemd

    • J’utilise Fedora Workstation depuis deux semaines et, en tant que quelqu’un qui revient à Linux après 20 ans, je peux dire que l’expérience s’est énormément améliorée
      Je n’ai pas encore eu besoin de redémarrer sous Windows. Si ça reste comme ça pendant les six prochains mois, je pense passer complètement à Linux et supprimer la partition Windows
    • Il faut quand même redémarrer pour appliquer réellement un nouveau noyau, non ? À moins que le noyau ne soit remplacé avec quelque chose comme kexec, je me demande

  • À propos de « l’immuabilité est un mensonge, et une grande partie du système est mutable. Je ne sais juste pas comment appeler autrement cette famille, quelque chose de transactionnel ? », dans le cas de Nix, ça donne plutôt l’impression que l’accent est mis sur la reproductibilité
    Cela semble vouloir dire que si l’on place le fichier de configuration Nix sur une autre machine, on devrait obtenir le même système, à l’exception peut-être de /home
    Les autres semblent plutôt fournir, via une autre implémentation, des fonctions de snapshots et de rollback que proposaient déjà des outils existants

    • Le terme « immuable » est étrange ici
      Si cela signifie qu’on ne fait pas de mise à niveau du système en direct, que les changements de paquets s’appliquent au prochain démarrage et qu’on peut annuler les modifications, c’est plus proche de transactions atomiques comme dans les bases de données. Cela dit, devoir éteindre le système pour committer, c’est un peu excessif
      Microsoft a ajouté il y a quelques années des transactions atomiques au système de fichiers, mais les transactions de système de fichiers n’ont pas été beaucoup utilisées
      Ce serait bien qu’un système d’installation puisse committer toutes les modifications d’un coup et, si un problème survient pendant l’installation, revenir à l’état précédent sans rien committer. En théorie, ce serait possible avec un système de fichiers transactionnel, mais en pratique il y a probablement beaucoup trop d’états non liés au système de fichiers qui s’entremêlent

  • Côté serveur, il y a Bottlerocket OS d’Amazon
    L’idée est d’utiliser des partitions A/B pour les mises à niveau, et de faire tourner tout ce qui ne fait pas partie du système de base dans des conteneurs
    Pour la configuration personnalisée au démarrage, on utilise des boot containers, et pour les services de longue durée, des host-containers, ou bien des DaemonSets dans Kubernetes
    https://github.com/bottlerocket-os/bottlerocket