URL: https://linuxfr.org/news/fedora-silverblue-en-pratique Title: Fedora Silverblue en pratique Authors: Renault tankey, Benoît Sibaud, tisaac, palm123 et Xavier Claude Date: 2020-04-17T16:20:18+02:00 License: CC by-sa Tags: fedora et silverblue Score: 5 Fedora Silverblue tente d’établir un système fonctionnel conciliant Fedora Workstation, la version bureautique de la distribution éponyme, et le projet Atomic. Cette déclinaison de Fedora commence à monter en puissance en termes de développements depuis quelque temps et nous réalisons que pour beaucoup de personnes extérieures ce projet reste très flou tant dans ses objectifs que sur les implications techniques. Nous avons présenté dans [un article précédent](https://linuxfr.org/news/presentation-de-fedora-silverblue) l’historique et ce qui a motivé la conception de Fedora Silverblue. Ici nous allons nous attarder plutôt à un cas d’usage en pratique pour voir la différence avec une Fedora classique. ![Logo de Fedora Silverblue](https://blog.fedora-fr.org/public/renault/Illustrations/silverblue-logo.png) ---- [Site officiel de Fedora Silverblue](https://silverblue.fedoraproject.org/) [Site officiel du projet Fedora](https://getfedora.org/) [Site officiel de la communauté francophone de Fedora](https://www.fedora-fr.org/) ---- # Généralités Beaucoup de choses restent identiques par rapport à une Fedora Workstation classique. Même bureau, même interface, logithèque ou fraîcheur des versions. La procédure d’installation avec Anaconda ne change pas vraiment non plus. Si vous souhaitez tester, vous pouvez [télécharger Fedora Silverblue](https://silverblue.fedoraproject.org/download) directement ou [par Torrent](https://torrent.fedoraproject.org/). Ensuite pour l’installer vous pouvez lire [le début de cette page de documentation](https://doc.fedora-fr.org/wiki/Guide_d%27installation_de_Fedora_en_images), cela fonctionne aussi bien sur Silverblue. La différence, comme expliqué dans l’article précédent, réside dans la gestion de la logithèque. Et nous allons en étudier cela en pratique. # Base du système avec RPM ostree Comme vous le savez, la base du système est un tout uni et dans l’ensemble en lecture seule. Mettre à jour le système signifie passer d’un état vers un autre sans autre altération. Cela se passe avec la commande suivante : ```shell # rpm-ostree upgrade ``` [![Mise à jour de Fedora Silverblue avec GNOME Logiciels](https://blog.fedora-fr.org/public/renault/Silverblue/.Mise_a_jour_Silverblue_m.png)](https://blog.fedora-fr.org/public/renault/Silverblue/Mise_a_jour_Silverblue.png) Une fois cela fait, il suffit de redémarrer et vous basculez vers le nouvel état du système, à jour. Notons que GNOME Logiciels permet de réaliser la mise à jour aussi de la base du système mais graphiquement. On peut voir en effet qu’un nouvel état est installé sur votre machine via la commande : ```shell $ rpm-ostree status State: idle AutomaticUpdates: disabled Deployments: ostree://fedora:fedora/31/x86_64/silverblue Version: 31.20200410.0 (2020-04-10T14:27:44Z) Commit: 16f67d3577701f988cb6c32a6376700f24e720e0896b2f5f4a6b6ab65f030b31 GPGSignature: Valid signature by 7D22D5867F2A4236474BF7B850CB390B3C3359C4 Diff: 524 upgraded, 24 downgraded, 13 removed, 18 added ● ostree://fedora:fedora/31/x86_64/silverblue Version: 31.1.9 (2019-10-23T21:44:48Z) Commit: c4bf7a6339e6be97d0ca48a117a1a35c9c5e3256ae2db9e706b0147c5845fac4 GPGSignature: Valid signature by 7D22D5867F2A4236474BF7B850CB390B3C3359C4 ``` Le système avec le symbole _●_ est la version courante du système, sur lequel j’ai démarré après l’installation de Fedora. On constate qu’après la mise à jour un nouvel état est disponible avec sa date d’installation et la référence de la version employée. Notez la ligne _Diff_ pour cet autre état, il explique la différence entre l’état actuel et celui-ci qui consiste majoritairement en paquets plus récents ici. Et en effet, après redémarrage de la machine, le symbole a changé de place. La mise à jour a bien été effective et le redémarrage aussi rapide que d’habitude. La référence vers l’état précédent reste présente, ce qui nous autorise à revenir en cas de gros soucis pour démarrer sur le nouvel état, ou si on a un problème qu’on a constaté nous-même. Amusons-nous à revenir, cela se fait simplement : ```shell # rpm-ostree rollback ``` Et après un redémarrage, on a basculé vers l’état précédent. Simple, fiable et rapide. Notez qu’il est possible de choisir l’état au démarrage via GRUB. En cas d’installation mono-système, le menu de GRUB est caché par défaut, appuyez sur la touche _ESC_ au démarrage de GRUB pour l’afficher et faire votre choix. Bien sûr il est possible de configurer un peu ce système de base pour résoudre certains problèmes même si cela viole un peu l’esprit derrière Silverblue. Par exemple, si nous voulons profiter du pilote propriétaire de nVidia, car le pilote libre _nouveau_ ne fonctionne pas suffisamment bien sur notre machine. Nous pouvons faire les choses ainsi : D’abord il faut installer le dépôt externe [RPMFusion](https://rpmfusion.org/) qui dispose du paquet RPM nécessaire. Un redémarrage est évidemment nécessaire pour changer d’état avec ce dépôt disponible. ```shell # rpm-ostree install https://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-31.noarch.rpm https://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-31.noarch.rpm # systemctl reboot ``` Ensuite on peut installer le paquet nécessaire et changer l’argument de démarrage du noyau pour désactiver le recours au pilote _nouveau_. Un redémarrage sera encore nécessaire pour valider l’action. ```shell # rpm-ostree install akmod-nvidia xorg-x11-drv-nvidia-cuda libva-utils libva-vdpau-driver gstreamer1-libav # rpm-ostree kargs --append=modprobe.blacklist=nouveau --append=rd.driver.blacklist=nouveau # systemctl reboot ``` _rpm-ostree_ se charge de tout pour altérer l’état du système de base. Comme vous pouvez le voir, il reste possible d’installer des paquets RPM à l’ancienne bien que dans le cas de Silverblue cela reste déconseillé en dehors de quelques cas comme celui évoqué plus haut. Cela se fait dans une couche indépendante du système de base et sera déployé au-dessus de votre version de référence après chaque mise à jour de ce dernier. Notez que pour certaines applications, le fait que le système principal soit en lecture seule, peut poser des soucis de compatibilité. Et si jamais vous souhaitez revenir dans l’état de base de votre système, vous pouvez utiliser simplement cette commande : ```shell # rpm-ostree reset ``` Et comme Silverblue fonctionne par état pour les mises à jour, ce que l’on a vu plus haut, changer de branche de Fedora est également possible facilement. [![Menu GRUB avec les états de OSTree](https://blog.fedora-fr.org/public/renault/Silverblue/.GRUB_Silverblue_m.png)](https://blog.fedora-fr.org/public/renault/Silverblue/GRUB_Silverblue.png) D’abord listez les versions possibles et enfin déployez cette version. ```shell # ostree remote refs fedora # rpm-ostree rebase fedora:fedora/32/x86_64/silverblue ``` Redémarrez et mission accomplie, vous voilà sous Fedora 32. Cela fonctionne également dans l’autre sens, pour revenir sur Fedora 31 si vous êtes sur la version 32. # Fedora Toolbox Comme cela a été expliqué dans l’autre article, Fedora Toolbox est une surcouche à _podman_ et _buildah_. Son but est de facilement créer un conteneur avec une version de Fedora comme base. Il se charge lui-même de récupérer les données, de faire en sorte que l’utilisateur soit le même que sur l’hôte, etc. Par ailleurs le répertoire _/home_ est partagé entre l’hôte et les conteneurs ce qui autorise d’exploiter les outils sur vos données. _podman_ est pour rappel un utilitaire compatible avec Docker mais qui ne nécessite pas d’un démon avec les droits super utilisateurs pour fonctionner. Pour des raisons de sécurité. Créer un conteneur est très simple : ```shell $ toolbox create ``` Qui va en créer un avec un nom par défaut et la même version de Fedora que votre instance de Silverblue. Ici _fedora-toolbox-31_. Mais on peut bien entendu personnaliser tout ça ainsi : ```shell $ toolbox create --container --release $ toolbox create --container fedora30 --release f30 ``` Ensuite on peut utiliser une session de shell pour entrer dans le conteneur de votre choix : ```shell $ toolbox enter --container ``` Vous constaterez que le prompt se dote d’un _⬢_coloré au début, pour vous rappeler que vous êtes dans un conteneur. [![Notez le symbole dans le prompt qui signifie que nous sommes dans un conteneur](https://blog.fedora-fr.org/public/renault/Silverblue/.Podman_m.png)](https://blog.fedora-fr.org/public/renault/Silverblue/Podman.png) Une fois à l’intérieur, vous pouvez faire ce que vous voulez. Utilisez _dnf_ pour installer des paquets, les mettre à jour comme avant, configurer votre système, etc. Lancer des applications depuis un tel conteneur est aussi possible. D’ailleurs pour exécuter une commande dans un conteneur sans y obtenir un shell, vous pouvez faire : ```shell $ toolbox run --container $ toolbox run --container fedora30 gnome-builder ``` Pour vous y retrouver si vous avez plusieurs conteneurs, vous pouvez les lister ainsi : ```shell $ toolbox list Images created by toolbox IMAGE ID IMAGE NAME CREATED 64e68e194389 registry.fedoraproject.org/f31/fedora-toolbox:31 6 weeks ago Containers created by toolbox CONTAINER ID CONTAINER NAME CREATED STATUS IMAGE NAME dc75753d59a2 fedora-toolbox-31 2 hours ago Up 2 hours ago registry.fedoraproject.org/f31/fedora-toolbox:31 1a9eaf6067c9 fedora30 About an hour ago Up About an hour ago registry.fedoraproject.org/f31/fedora-toolbox:31 ``` Et si un conteneur n’est plus utile, vous pouvez le supprimer ainsi : ```shell $ toolbox rm $ toolbox rm silverblue ``` L’objectif de Toolbox est de vous simplifier la vie dans la configuration du conteneur pour cet usage, surtout si vous n’êtes pas habitués à cet écosystème. Mais rien ne vous empêche d’utiliser _podman_ ou Docker manuellement. Les commandes _podman_ peuvent être exploitées à la place de Toolbox par exemple sur les conteneurs créés par ce dernier. # Flatpak Par défaut il n’y a pas beaucoup de Flatpak disponibles dans Silverblue (mais c’est en cours de résolution). La première étape étant d’en installer un dépôt externe comme [Flathub](https://flatpak.org/setup/Fedora/). C’est très simple et rapide. [![GNOME Logiciels gère les Flatpak et indique sa provenance](https://blog.fedora-fr.org/public/renault/Silverblue/.GNOME_Logiciels_Flatpak_m.png)](https://blog.fedora-fr.org/public/renault/Silverblue/GNOME_Logiciels_Flatpak.png) Globalement cela consiste à exécuter cette commande : ```shell $ flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo ``` Ensuite vous pouvez utiliser GNOME Logiciels pour télécharger et mettre à jour ces applications. Ou alors à la main comme suit : ```shell $ flatpak update $ flatpak list Name Application ID Version Branch Origin Installation Platform org.fedoraproject.Platform f32 fedora system default org.freedesktop.Platform.GL.default 19.08 flathub system openh264 org.freedesktop.Platform.openh264 2.0 flathub system Geary org.gnome.Geary 3.36.1 stable fedora system Lollypop org.gnome.Lollypop 1.2.33 stable flathub system GNOME Application Platform version 3.36 org.gnome.Platform 3.36 flathub system ``` Comme vous pouvez le voir, Geary et Lollypop ont été installés par Flatpak, l’un via Flathub, l’autre via [Fedora Registry](https://registry.fedoraproject.org/) qui propose ses propres Flatpak aussi exploitables dans un conteneur podman ou Docker. Les runtimes nécessaire pour ces applications ont aussi été installés et sont listés ici comme _GNOME Application Platform_. Pour installer, il suffit de chercher si un tel paquet existe puis l’installer. Prenons GNOME Agenda comme exemple. ```shell $ flatpak search calendar Name Description Application ID Version Branch Remotes Agenda Agenda de GNOME org.gnome.Calendar 3.36.0 stable fedora,flathub $ flatpak install org.gnome.Calendar ``` Comme l’application existe dans Flathub et Fedora, Flatpak vous demandera la source à utiliser ici. Par défaut un Flatpak est installé dans _/var/lib_ pour être accessible pour l’ensemble des utilisateurs. Mais si pour une raison particulière vous souhaitez que seul votre utilisateur ait accès, vous pouvez ajouter l’argument _--user_ : ```shell $ flatpak install --user org.gnome.Calendar ``` L’un des avantages de Flatpak est qu’il repose aussi sur des états. Si une mise à jour ne vous plaît pas, car elle introduit une régression gênante pour vous, vous pouvez facilement revenir. D’abord il faut identifier la liste des états disponibles de votre application. ```shell $ flatpak remote-info --log flathub org.gnome.Geary ``` Ensuite choisir un état et l’appliquer. ```shell $ flatpak update --commit bba3bbb1ab3b127de0fd984279d99170f9ec671b05c18cc64a0c102243664a1c org.gnome.Geary ``` GNOME Shell permet de les lancer comme une application native évidemment, mais depuis le terminal c’est possible ainsi : ```shell $ flatpak run $ flatpak run org.gnome.Geary ``` Peu à peu les Flatpak disposent d’un système de permissions et de portails pour permettre l’accès aux ressources dont les applications ont besoin uniquement. Notons aussi que GNOME Logiciels peut présenter les choses de manière un peu trompeuse. Par exemple installer Lollypop qui était le premier Flatpak nécessitait de télécharger près de 1 Gio de données pour 40 Mio installés. En fait le gigaoctet de données était lié aux runtimes nécessaires à télécharger. Mais Geary qui utilise les mêmes runtimes n’a eu besoin que de quelques mégaoctets seulement pour être installé par après. Comme Silverblue repose énormément sur les Flatpak, vos runtimes seront rentabilisés car partagés par beaucoup d’applications. Si vous souhaitez voir les changements opérés sur les Flatpak comme les installations et mises à jour, une commande est possible : ```shell $ flatpak history Time Change Application Branch Installation Remote avril 11 18:00:17 add remote system flathub avril 11 18:06:07 deploy install org.fedoraproject.Platform f32 system fedora avril 11 18:06:12 deploy install org.gnome.Geary stable system fedora ``` # Mode de travail avec Silverblue Avant nous avions un système unifié avec des dépôts centralisés pour tout et il n’y avait pas beaucoup de possibilités pour installer des applications ou maintenir le système. Silverblue en plus introduit une certaine redondance par endroit. Comment s’y retrouver ? La base du système est globalement en lecture seule et minimaliste. À part le mettre à jour il n’y a pas grand-chose à faire en temps normal. Y toucher peut devenir essentiel pour ce qui a trait à la gestion du matériel comme le chargeur de démarrage GRUB ou le noyau et ses pilotes. En dehors de cela il n’est pas recommandé d’essayer de le manipuler. L’objectif est qu’il soit minimal, simple et fiable. Le reste repose sur les conteneurs et Flatpak. Les Flatpak seront à privilégier pour les applications graphiques. Après tout, seules ces applications peuvent être installées par ce biais. Pour le reste, il y a les conteneurs avec Fedora Toolbox. Utile pour les applications textes, environnements de développement, etc. Le fait d’avoir plusieurs conteneurs permet de séparer les tâches. Le développement Python d’un côté, le serveur Web de l’autre, l’expérimentation d’un projet, un environnement pour le travail professionnel, etc. À vous de voir selon vos envies et besoins. S’il reste possible d’avoir un conteneur fourre tout pour simuler une Fedora classique, cette approche n’est pas réellement dans l’esprit de Silverblue. # Le gain ? Une partie des gains a été largement relatée dans l’article précédent. Mais avec un peu de pratique, que pouvons-nous observer ? Tout d’abord la séparation du système en plusieurs parties permet de leur donner une responsabilité propre ce qui améliore dans un sens sa fiabilité mais aussi son élégance. Le système de base se charge de fournir un système qui démarre et qui est exploitable. Il est beaucoup plus difficile d’aboutir à une situation complexe inextricable avec une machine peu fonctionnelle. La flexibilité est plus grande, via Fedora Toolbox et Flatpak, il est plus facile d’expérimenter des choses et d’adapter votre système à vos besoins. Vous souhaitez tirer profit d’une version de Python qui est dans Fedora 32 et dans Fedora 29 pour vos tests ? Vous pouvez avoir les deux facilement avec Fedora Toolbox en ayant un conteneur pour chaque. Et si vous avez fini un projet professionnel et que vous n’avez plus besoin de ces conteneurs spécialisés de Python avec les versions spécifiques, il suffit de les supprimer. Plus besoin de chercher les paquets qui étaient nécessaires pour cette tâche et dont vous n’avez plus besoin pour toiletter le système. Vous souhaitez une version de Firefox très récente mais une de LibreOffice plus ancienne ? Flatpak le permet de concilier les deux facilement comme nous l’avons vu. Et chaque application n’aura accès qu’aux données et ressources pour lesquels il dispose de votre autorisation, limitant les problèmes dus à des bogues ou des failles. Mais bien sûr cela a un coût. Besoin de plus de bande passante, de mémoire, CPU et d’espace disque. Le système dans son ensemble est aussi plus complexe à appréhender, de nouvelles choses sont à apprendre.