Aux côtés de l’édition Workstation classique de Fedora grandit une autre variante, moins connue : Silverblue. Fondée sur le concept de système inaltérable et les conteneurs, ses concepteurs y voient le futur de la distribution.
Fedora est depuis longtemps le laboratoire de Red Hat pour tester l’ensemble des nouveautés logicielles qui l’intéressent. Tout ce qui a été éprouvé au cours des versions et assure un bon niveau de fiabilité peut être incorporé ensuite dans RHEL (Red Hat Enterprise Linux).
La distribution n’est cependant pas disponible qu’en une seule variante. Les plus connues, largement mises en avant sur le site officiel, sont Workstation et Server, dont les noms sont suffisamment parlants. Il en existe d’autres, dont Silverblue. Visuellement, il est difficile de les séparer. Sous le capot, c'est une autre paire de manches.
- Télécharger Fedora Silverblue 30 (ou 31 beta) 64 bits
- Fedora 31 : l'avance sur Wayland se confirme, multiples améliorations techniques
La philosophie derrière Silverblue
Avant d’aborder son fonctionnement particulier, il faut comprendre ce qu’est Silverblue, qui possède des bases techniques très différentes de Fedora, en dépit de son appartenance à la même famille.
Elle en reprend d’ailleurs peu ou prou les mêmes composants. L’idée générale est d’approcher l’architecture du système de manière plus moderne, pour obtenir des gains en fiabilité, sécurité et performances. Cette variante de la distribution repose donc sur deux concepts généraux : une base inaltérable et des conteneurs.
Cette base inaltérable (immutable en anglais) vient de la manière dont est géré le système proprement dit. Contrairement à la version classique de Fedora, Silverblue ne présente pas une collection paquets RPM s’installant les uns à la suite des autres. La base est en fait une image uniforme et cohérente copiée sur le disque de la machine pendant la phase d'installation (depuis une ISO), puis paramétrée en fonction du matériel et des choix de l’utilisateur.
Mais cela va plus loin, notamment dans la manière dont le système est mis à jour. L’application des rustines se fait ainsi sur une copie de l’image système. Ces modifications sont mises en attente jusqu’au redémarrage. La copie de l’image remplace alors la précédente et devient le système actif. Ces opérations sont effectuées par rpm-ostree.
Gros avantage de la méthode : la fiabilité et la sécurité. L’image système est en effet en lecture seule et ne peut donc être modifiée. Si d’aventure le processus de mise à jour échouait, il n’y aurait pas d’impact sur Silverblue puisque les opérations s’effectuent sur une copie, à part. En outre, on peut facilement revenir à l’état antérieur de la machine. Inconvénient bien sûr : les modifications ne seront prises en compte qu’après un redémarrage.
Ce dernier point peut représenter un problème selon l’usage que l’on souhaite faire de Silverblue. Mais la distribution est surtout présentée comme visant les machines de travail, pas les serveurs. La distribution s’appelait d’ailleurs Atomic Workstation précédemment. Pour les serveurs focalisés sur les conteneurs logiciels, Fedora propose CoreOS après son rachat en 2018, reprenant globalement les mêmes concepts, mais avec une approche nettement plus minimaliste. Red Hat en propose une version commerciale, nommée Container Linux (anciennement CoreOS aussi).
Notez que ce fonctionnement « immuable » n’est ni spécifique à Silverblue, ni même une nouveauté. D’autres systèmes d’exploitation, particulièrement Android et Chrome OS, se servent de ce type d’architecture. Plus récemment, macOS Catalina s’y est mis aussi, comme mentionné dans notre dossier qui lui est consacré.
L’autre grand versant de Silverblue, ce sont les conteneurs. Il s'agit, dans les grandes lignes, d'une forme de virtualisation ramenée au niveau d’une application. Dans un paquet isolé du reste du système, on embarque tout ce dont elle a besoin. Pour s’exécuter, il suffit de s’assurer que l’infrastructure utilisée est cohérente entre le système hôte et l’application.
Les développeurs n’ont ainsi pas à se soucier des versions des bibliothèques et donc de nombreux problèmes de compatibilité. Les modifications générées par le conteneur restent circonscrites à son espace virtualisé et ne peuvent atteindre le système. En contrepartie d’un poids plus élevé (toutes les dépendances sont embarquées notamment), on obtient un fonctionnement général plus fiable.
Il y a certains bénéfices inhérents à cette méthode, comme par exemple l’exécution concurrentielle de plusieurs versions différentes d’un même logiciel, sans qu’elles créent d’interférences.
Présentation générale de Fedora Silverblue
On l’aura compris, cette édition particulière de Fedora n’a pas grand-chose à voir techniquement avec la distribution d’origine. Ses différences ne sauteront d’ailleurs même pas aux yeux à l’installation, tant la procédure est pratiquement identique. Visuellement, rien ne distingue les deux variantes.
Il faudra attendre d’arriver sur le bureau GNOME (les briques logicielles sont globalement les mêmes) et de creuser un peu pour s’apercevoir des changements opérés. On remarque d'ailleurs vite que les performances sont excellentes. Comme nous l’avions noté dans notre article consacré à Fedora 31, la réactivité générale avait fait un nouveau bond plus que sensible. Cette impression est renforcée dans Silverblue.
Mais pour comprendre ce qui vous attend réellement avec cette variante, il faut ouvrir l'application Logiciels. Le constat est rapide : il y a beaucoup moins d'éléments proposés que dans Fedora classique. Pourquoi ? Parce que le gestionnaire de paquets DNF est absent. L’utilisateur ne peut donc pas procéder à des installations ordinaires.
Et la question de l’installation se pose vite, car Silverblue ne fournit que le strict minimum. Un coup d'œil à la grille des applications disponible le fait aisément comprendre :
En clair, seul Firefox est fourni. Si vous ouvrez les paramètres, section Logiciels par défaut, le désert applicatif vous sera confirmé. Il faut donc aller dans Logiciels et installer ce qui manque… si vous le pouvez.
On y trouve en effet seulement les versions Flatpak (donc des conteneurs) des applications dont les développeurs se sont donné la peine d’en produire. Elles sont peu nombreuses dans la boutique. La partie « Audio et vidéo » n’en possède par exemple que deux : Cheese et Enregistreur de son. On pourra trouver Thunderbird dans la partie « Communications », mais « Bureautique » n’embarque même pas LibreOffice.
L’utilisateur est-il condamné pour autant à devoir s’en contenter ? Non, car du propre aveu de Fedora, il est conseillé de se rendre sur la boutique indépendante Flathub, dont la sélection est beaucoup plus importante.
Pour celles et ceux qui ne connaîtraient pas, il suffit de chercher une application sur le site, puis de cliquer sur « Install ». Un petit fichier de quelques ko est alors téléchargé. Une fois ouvert, il lance Logiciels sur la page correspondante, permettant alors de déclencher l’installation.
Une fois que l'application Logiciels aura été ouverte une fois depuis Flathub, le dépôt correspondant sera automatiquement ajouté dans ses paramètres. En clair, toutes les recherches suivantes pourront se faire depuis, sans avoir à passer à nouveau par le site de Flathub. La sélection devient du coup beaucoup plus importante.
Besoin de VLC ? Il s’y trouve, la source mentionnant bien son origine (dl.flathub.org). Des logiciels propriétaires sont également présents, comme le binaire de Visual Studio Code. Notez que les installations classiques peuvent quand même se faire, via la commande rpm-ostree.
Elle n’est cependant pas recommandée, plutôt à garder s’il n’y a vraiment pas d’autre solution. Ce type d’installation va réclamer en effet une modification du système. Au vu du fonctionnement de Silverblue, la suite est donc prévisible : les changements ne seront pris en compte qu’après un redémarrage.
Créer ses propres conteneurs
Si vous aimez l’idée d’un système séparant par défaut sa base de tout l’applicatif, Silverblue peut d’emblée être une option, même si le système en tant que tel reste pour l’instant plus proche d’un travail en progression qu’une véritable version à mettre entre toutes les mains (nous y reviendrons).
Mais c’est bien avec les conteneurs que cette variante de Fedora prend tout son sens. Les flatpaks en sont déjà bien sûr, mais l’inclusion de Toolbox permet d’aller plus loin. Ce dernier est un outil pour créer des conteneurs et y insérer des applications via DNF. Une manière, en quelque sorte, de construire un type de flatpak personnalisé.
La commande toolbox create va générer le premier conteneur. À la première exécution, Silverblue détectera qu’aucun environnement n’est présent pour servir de base au conteneur. Il proposera donc de télécharger l’image correspondante, ici Fedora 31. 500 Mo plus tard, le socle est prêt à l’emploi et le premier conteneur apparaît sous la forme « user@toolbox », pour bien montrer le changement de périmètre (il n’est plus dans localhost).
Les conteneurs sont créés par podman (compatible avec les images OCI de Docker) en mode rootless, donc sans aucun droit administrateur. L’utilisateur y retrouve son nom, ses permissions, l’accès à son dossier personnel et les principaux outils en ligne de commande, dont DNF. Ce dernier permet alors d’installer d’autres outils en ligne de commande ou même directement des applications.
Toolbox fournit des commandes pour créer autant de conteneurs que souhaité, les lister, entrer et sortir (exit) de celui en cours ou encore les supprimer, y compris s’ils sont en cours de fonctionnement.
Une distribution pour l’instant surtout destinée aux développeurs
À quoi sert donc cette variante si particulière de Fedora ? Pour le commun des mortels, sans doute à rien… pour l’instant. Silverblue se destine actuellement aux développeurs ayant affaire aux conteneurs, Toolbox permettant de créer facilement un environnement temporaire pour orienter par exemple des tests de compatibilité pour un code particulier.
L’idée générale derrière Silverblue est de retrouver, dans un conteneur, l’environnement familier basé sur RPM, permettant au développeur de se lancer dans des opérations qui, en temps normal, pourrait mettre en danger l’intégrité du système. Il pourrait bien sûr créer une machine virtuelle et sauvegarder/restaurer des états avant et après les tests. Mais la création de conteneurs permet d’enchainer les opérations sans avoir à se soucier des états.
Quand les tests sont terminés, on sort simplement du conteneur.
L’étrange statut de Silverblue pour l’instant
Un système inaltérable peuplé uniquement de conteneurs, voilà la vision globale de Silverblue. Les développeurs de Fedora n’hésitent pas à annoncer sur la page officielle du projet que cette variante représente le futur de la distribution, même si personne ne se hasarde pour l’instant à donner de date.
Et pour cause, il reste de nombreuses questions en suspens, car ce fonctionnement particulier impose ses propres limites. Toutes les applications ne peuvent pas forcément fonctionner dans des conteneurs. Il y a plusieurs années par exemple, des éditeurs ont quitté le Mac App Store car Apple y imposait l’utilisation de la sandbox. Étaient notamment concernés des outils système ou de développement.
Le problème est pour l’instant en partie le même avec Silverblue. Des outils d’analyse réseau comme nmap ou tcpdump peuvent ne pas fonctionner, selon le paramétrage des conteneurs. Des soucis apparaitront également avec tous les applications qui auraient besoin, pour quelque raison que ce soit, d’accéder au matériel.
Exemple, dfu-util, dont la mission est l’envoi de firmwares dans des périphériques USB. Même l’installation des polices, qui passe par RPM, réclame un redémarrage du système.
En l’état, Silverblue garde un peu son statut de « bête curieuse », dont le test vaut le coup d’œil. Le fonctionnement général embarque son lot de promesses très intéressantes sur la sécurité, la fiabilité et les performances. Mais l’équipe de développement le dit elle-même : « Il est possible que Silverblue finisse par remplacer la Workstation classique. Mais il reste une longue route à parcourir pour que Silverblue fournisse les mêmes fonctionnalités et expérience utilisateur que la Workstation ». Et de préciser que jusqu’à nouvel ordre, les deux moutures seront proposées en même temps.
On imagine facilement que les prochaines évolutions de Silverblue se concentreront sur la facilité d’utilisation au quotidien, pour que des opérations aussi courantes que l’ajout d’une police puissent se faire de manière transparente.
En attendant, tester Silverblue – voire l’utiliser – ne représente aucune difficulté. On peut facilement récupérer son image ISO (environ 2 Go) et s’en servir dans un client de virtualisation comme VirtualBox ou VMware Workstation. On peut également l’installer nativement, avec un processus Anaconda strictement identique côté utilisateur.
Commentaires (20)
#1
C’est intéressant ce concept, même si je ne me vois pas l’utiliser au quotidien. De toutes façons, il est bien dit dans l’article que c’est quelque chose d’expérimental, dont acte.
Il me paraît envisageable que cela devienne le mode de fonctionnement des OS d’ici quelques années, l’isolation des logiciels dans des conteneurs avec leurs dépendances, pour qu’ils n’emportent pas le système avec eux en cas de pépin, ça paraît intéressant au non-spécialiste que je suis. Bien que je n’ai jamais rencontré moi-même ce problème sous Linux depuis bientôt 15 ans…
Après, je ne suis pas un spécialiste de la chose, et je suis ouvert à tous les avis argumentés sur la question. À suivre…
#2
Ce fonctionnement a cependant un problème, au delà de l’esapce de stockage grandissant des applications. En effet, l’effort de mise à jour des bibliothèques n’est plus portée par le système mais par les développeurs. S’il y a une faille sur l’une d’elle, un OS va souvent le patcher rapidement, les développeurs ne s’empresseront pas toujours. De plus cela ne les incitera pas à forcer la compitibilité avec les nouvelles versions des dépendances s’il est plus simple pour eux de garder les anciennes en cas de non rétrocompatibilité. En plus j’imagine la taille des mises à jours quand un openssl changera de version et que les 15 applications que tu as qui l’utilise redescendront en même temps.
Je reste donc partagé sur le principe, d’un côté c’est génial et de l’autre ça demande trop de faire confiance en matière de sécurité à des développeurs pour qui ce n’est pas forcément le travail.
#3
Ça ressemble fortement à QubeOS quand même. Pour du serveur je vois clairement l’intérêt, qui est de fournir une meilleure isolation des services. Pour de la workstation par contre…
#4
Donc, d’après les concepteurs de Fedora, l’avenir de Linux (en tout cas, de leur distribution), c’est de faire comme Windows* en ce qui concerne le processus de mises à jour (téléchargement puis installation mise en attente pour être effectuée au redémarrage de l’OS, dans un environnement où l’utilisateur n’a pas la main et où la machine est inutilisable pour autre chose en attendant) ? J’en connais déjà qui vont hurler… :/
* Et pas seulement lui : c’est aussi le cas sur Android, PlayStation 4…
Quant au fait que même le rajout de polices de caractères nécessite un redémarrage pour être effectif… :/ Ils ont intérêt à arranger ça d’ici à ce qu’ils considèrent cette déclinaison Silverblue comme mûre !
Linux, c’était mieux avant c’est plus ce que c’était…
#5
Pas du tout, l’installation via rpm-ostree se base sur des overlays, liens matériels et clichés du système. D’ailleurs ostree est souvent surnommé git du binaire. Donc en fait quand tu changes ton système, tu fais un changement d’état. Ce changement est indolore et instantané et tu peux revenir en arrière sans problèmes. D’ailleurs GRUB peut maintenant proposer les différentes versions de ton système pour revenir facilement en arrière si nécessaire.
Il n’y a donc absolument pas la latence de Windows là dessus qui repose sur des mécanismes très différents.
L’article est bien fait, par ailleurs je suis en train d’en rédiger un à ce sujet. Cependant il oublie (volontairement ou pas) des éléments. Silverblue et Atomic puisent leurs origines dans Fedora.next qui était la période de brainstorming de Fedora en 2013-2014. Silverblue n’est que la concrétisation de ce travail mais n’est aussi qu’un aspect et un test.
Il n’est pas sûr que Silverblue parvienne à devenir la version de Fedora Workstation par défaut. C’est l’objectif mais les difficultés restent nombreuses et tout le monde ignore si on pourra aboutir à ce que l’on souhaite.
Ensuite, l’objectif aussi de la distribution est de reposer au maximum sur les Flatpak et podman. Le système immuable doit être le plus minimal possible (dans l’idéal il n’y aurait que le noyau, le chargeur de démarrage et le système d’init et ce qui est nécessaire pour eux). Ce qui contourne la limitation liée à rpm-ostree.
Les conteneurs, surtout les Flatpak, devraient user de portails et de droits d’accès pour faire des actions nécessaires en dehors du conteneur. Mais c’est encore en développement et pas opérationnel. Fedora travaille aussi pour que les paquets RPM de logiciels graphiques génèrent automatiquement un Flatpak associé pour augmenter la quantité de logiciels disponibles via les dépôts de Fedora dans Silverblue. Mais ce n’est pas encore pleinement opérationnel.
Toolbox et podman sont plutôt dédiés dans l’idée aux outils de développements et aux codeurs. Genre si tu veux coder une application qui utilise Python 3.6 pour le contexte professionnel.
Très clairement Silverblue n’est qu’expérimental et reste un travail de R&D essentiellement. Il y a bien du chemin à parcourir avant d’envisager que Silverblue devienne la version de référence voire unique de Fedora Workstation.
#6
#7
L’espace de stockage ne sera pas vraiment un soucis dans les années à venir vu l’explosion de celui-ci sur les stations de travail (surtout si la taille de l’image du système de base + celles utilisées pour les containers diminuent). De plus l’isolation va ajouter une couche de sécurité supplémentaire.
Je suis vraiment curieux de voir ce que cela va donner quand le projet aura plus avancé. C’est réellement un concept intéressant qui peut avoir un grand intérêt dans un cadre de dev/QA.
#8
« Dans un paquet isolé du reste du système, on embarque tout ce dont elle a besoin. »
Ce n’est pas totalement vrai. Flatpak propose le concept de runtimes. Pour le moment il en existe trois : Freedesktop, GNOME et KDE. Le runtime Freedesktop contient par exemple Python, SDL, SQLite, Vulkan, OpenSSL, Mesa… et un paquet d’autres bibliothèques.
Quand il y a une faille dans l’une d’entre elles, le runtime est mis à jour et l’ensemble des Flatpak qui en dépendent bénéficient donc de la mise à jour. Ce n’est donc pas à chaque développeur de tout embarquer et de gérer lui-même la sécurité de l’ensemble des bibliothèques qu’il utilise.
#9
Espace de stockage peut être, mais pour les temps de chargement et l’utilisation de la RAM c’est la fête du slip.
Le flatpack est la négation même des librairie partagées.
#10
Même si je reste encore un adepte des paquets autant que possible, perso je ne vois pas grande différence au quotidien avec les quelques snap que j’ai sur mes machines niveau conso RAM/temps de chargement, etc (alors qu’ils sont plus lourds que les flatpack).
Bien sûr que ça va bouffer plus que des paquets. En contre partie ça permet aussi de garder son système propre, et dans certains cas c’est bien utile.
Sinon cf le commentaire au-dessus du tiens.
#11
Oui Flatpak va de fait réduire l’usage de bibliothèques partagées, du moins pour les moins connues car sinon les runtimes gèreront cet aspect de la manière la plus efficiente possible.
Mais il y a une raison aussi à cette conception, c’est que les bibliothèques partagées c’est sexy sur le papier mais ça a des inconvénients non négligeables. C’est à cause d’eux qu’il est difficile de distribuer une application proprement sous Linux entre les distributions car les dépendances et les versions diffèrent.
Puis cela génère des bogues, car le développeur de l’application X et celui de Y même s’ils utilisent la même bibliothèque, ils n’ont probablement pas développé et testé avec la même version. Or choisir une version commune aux deux peut engendrer des bogues difficiles identifier et à résoudre.
Et générer ces paquets, près de 10 000 pour Fedora seulement, demande beaucoup de travail que ce soit pour créer et maintenir ces paquets tout comme l’infra. Flatpak permet d’alléger la tâche, car ce travail peut être fait plus facilement par le développeur de l’application même ou par une mutualisation des efforts (comme Flathub) qui touche toutes les distributions.
Bref, Flatpak (et plus largement Silverblue) est une remise en cause de la distribution traditionnelle. C’est un but assumé. Car il y a des problèmes avec le modèle traditionnel qui ne sont solubles qu’avec une remise en cause de celui-ci. Et encore il y a tentative d’essayer de concilier les deux aspects au maximum, car cela reste des modèles antagonistes. De toute façon chaque distribution fera le choix d’adopter ce changement ou pas, il n’y a pas de contraintes, donc il y a aura toujours moyen de rester comme avant pour ceux qui le veulent.
#12
Je suis tout à fait d’accord.
Vu la taille des disques actuellement, l’espace utilisé par les conteneurs, bien que beaucoup plus important, n’est pas un problème à considérer.
Par contre, la charge de la mise à jour change de main (du système aux développeurs d’applications) ce qui compromet fortement la sécurité pour l’utilisateur (car les développeurs ne mettront pas à jour leurs applications aussi rapidement que Red Hat).
Quand on parle de sécurité améliorée pour les systèmes de conteneur, c’est par rapport à l’intégrité du système (qui ne risque plus de subir des modifications erronées) mais les applications et les données, sont elles beaucoup moins sécurisées de cette façon, car mises à jour de façon trop disparates.
Tant que la charge de mise à jour des applications conteneurisées dépendra des développeurs, ce type de système n’aura pas de réel avenir.
#13
L’avenir que dessine Red Hat pour sa distribution de bureau est techniquement original avec de nombreuses innovations pour le « bureau Linux » (conteneurisation, bac à sable, système inaltérable, flatpak…). Le rôle de laboratoire de développement de Fedora est bien perceptible, d’autant plus que cela s’intègre dans la réorganisation récente du monde des distributions soutenues par Red Hat (Fedora, Cent OS, Cent OS Stream, RHEL).
#14
En fait on passe d’un modèle distribution (OS + applis) a un nouveau framework qui ne fournis plus que l’OS, une sandbox et quelques exemple d’appli utilisant la sandbox.
L’OS se protège de l’applicatif et laisse se démerder développeurs et l’utilisateur entre eux.
#15
#16
#17
#18
Dans Fedora Silverblue, /var et /etc sont en lecture et écriture pour des raisons évidentes de configuration et de stockage de données de travail pour certaines applications serveurs ou systèmes. Cependant tes binaires ou bibliothèques qui sont dans /usr eux ne sont pas modifiables sans changement d’état du système.
#19
J’ai du mal à voir un quelconque avantage :
Donc tu ne peux rien changer, si t’as installé Gnome tant pis pour toi tu ne pourras pas essayer KDE ou XFCE ?!
C’est très windowsien comme philosophie, je dirais même à l’exact opposé du mode libre
taille des applis,
nombre et temps de mise à jour, (télécharger encore et encore les mêmes librairies)
reboot à chaque install
Ça n’est jamais complètement isolé (il faut bien copier/coller d’une appli à l’autre ou utiliser des fichiers communs). On le voit sous Android cette partie (partage entre appli et gestion des fichiers) est très mal gérée, et source de failles.
En cas de faille sur un composant majeur (ex récent openssh), il a suffi de prendre 5min pour mettre à jour la lib en central, avec le système de containeur il faudrait (attendre qu’elles soient dispo &) mettre à jour toutes les applis utilisant openssl ?! C’est vraiment un fonctionnement archaïque !
Par défaut tout est aussi en lecture seul, donc à moins de jouer du sudo comme un goret c’est assez compliqué de casser quoi que ce soit.
Ma distrib (une gentoo parfaitement à jour) a été installée vers 2004-2005, je n’ai jamais eu à réinstaller quoi que ce soit même en changeant tous les composants, ou en faisant des migrations majeures, les seuls reboot nécessaire sont pour les maj de noyaux.
#20