Fedora Atomic Sway au quotidien

Fedora Atomic Sway au quotidien

Nouvelle mise à jour : Descendez pour voir comment mon flux de travail a évolué avec un Dev Container partagé entre tous mes dépôts.

Le début d’une nouvelle année m’a semblé être le bon moment pour réévaluer la configuration de mon poste de travail. Je ne veux pas que mon système d’exploitation soit une source d’excitation (bon, peut-être un peu). Je le veux fiable, prévisible et suffisamment moderne pour ne pas me gêner.

Mon poste de travail n’est pas simplement « un ordinateur portable Linux quelconque ». C’est le PC que j’utilise tous les jours pour gérer des machines virtuelles, accéder à des ressources, écrire du Terraform, de l’Ansible, des outils en Python, etc.

Voici un bref retour sur mon utilisation et ma configuration de Fedora Atomic.

J’ai envisagé NixOS, mais je ne voulais pas que mon système d’exploitation devienne un projet de plus, et NixOS n’est pas exactement léger. Fedora Atomic m’a semblé être le bon compromis. La configuration a été vraiment très simple : une journée, une installation propre, quelques ajustements minimes, et c’était terminé.

1. Avant Fedora Atomic : Debian Testing

Avant, j’utilisais Debian Testing, toujours avec l’excellent gestionnaire de fenêtres Sway. Debian Stable était un peu trop conservatrice pour mes besoins. À l’époque — peut-être moins aujourd’hui —, les versions de Sway étaient déjà dépassées à leur sortie, ce qui faisait de Testing un compromis pas si évident.

La plupart du temps, tout fonctionnait, mais les mises à jour étaient fréquentes et apportaient parfois leur lot de frustration.

Pourquoi Sway

J’utilise Sway depuis assez longtemps pour être à l’aise avec lui, et il fonctionne bien sans difficulté.

J’ai essayé Hyprland : il y a beaucoup d’animations, mais cela n’apportait rien de significatif à mon flux de travail. Avec Sway, tout fonctionne et, surtout, je garde mes habitudes :).

2. Qu’est-ce que Fedora Atomic ?

Fedora Atomic repose sur l’immuabilité : le système de base est fourni sous la forme d’une image OSTree, et non comme un ensemble de RPM individuels.

Cette commande indique quelle image immuable du système d’exploitation est actuellement utilisée et quels changements (mises à jour, paquets ajoutés en couche, retours arrière) seront appliqués au prochain démarrage.

rpm-ostree status

Les mises à jour du système sont atomiques : une nouvelle image du système est préparée à côté de celle qui est actuellement utilisée.

sudo rpm-ostree upgrade

Le système de fichiers racine est en lecture seule par défaut.

Si vous avez besoin de paquets au niveau du système, vous pouvez ajouter des RPM en couche. Cela signifie que rpm-ostree reconstruit l’image du système avec ces paquets, au lieu de modifier le système en cours d’exécution.

rpm-ostree install restic

La nouvelle image (après une mise à jour ou l’ajout de RPM en couche) ne devient active qu’après un redémarrage :

systemctl reboot

N’ajoutez un paquet en couche que s’il est nécessaire au niveau du système, au démarrage, avant la connexion, ou pour le matériel et les services essentiels.

3. Les paquets : Flatpak et Toolbox

Si vous ne voulez pas redémarrer, n’ajoutez pas le paquet en couche.

Vous avez deux options principales :

Outils de développement et CLI → utilisez un conteneur avec Toolbox

Applications de bureau → utilisez Flatpak

Toolbox permet d’exécuter un environnement Fedora modifiable sur un système immuable ; il utilise Podman. Il crée un conteneur qui ressemble à une installation Fedora classique et s’utilise comme telle.

toolbox enter
sudo dnf install ansible

Flatpak est conçu pour les applications de bureau. Les applications s’exécutent dans un environnement isolé, avec des dépendances séparées et des mises à jour indépendantes.

flatpak install flathub org.mozilla.Firefox

Toolbox et Flatpak préservent la propreté du système d’exploitation tout en offrant de la souplesse.

4. Gestion de mes dotfiles

J’utilise la très bonne combinaison de Git et GNU Stow.

Tous les fichiers de configuration sont réunis dans un dépôt Git situé à la racine de mon répertoire personnel, dans ~/.

Stow crée ensuite des liens symboliques entre ce dépôt et les emplacements appropriés.

mkdir ~/dotf-stow
cd ~/dotf-stow
cp ~/.bashrc .
cp -r ~/.config .
stow .

Stow lie ~/dotf-stow/.bashrc à ~/.bashrc.

Protection pré-commit avec Gitleaks

J’utilise aussi Gitleaks pour bloquer les secrets avant qu’ils n’entrent dans l’historique Git.

Installez-le dans l’environnement où vous effectuez vos commits (Toolbox dans mon cas) :

toolbox enter
sudo dnf install gitleaks

Le dépôt contient un hook versionné :

ls -l ~/dotf-stow/.githooks/pre-commit

Contenu du hook :

#!/usr/bin/env sh
set -e
gitleaks git --staged --redact --verbose --exit-code 1

Indiquez à Git d’utiliser le répertoire des hooks du dépôt :

git config core.hooksPath .githooks

Test rapide (le commit doit échouer) :

echo "ghp_123456789012345678901234567890123456" > leak.txt
git add leak.txt
git commit -m "test gitleaks"

5. Gestion des alias : .zshrc et .bashrc

Zsh est désormais mon shell interactif principal. Sa configuration est conservée dans le dépôt de dotfiles et répartie dans de petits fichiers sous ~/.config/zsh/ :

• .zshenv définit le PATH commun à tous les processus Zsh.
• .zshrc charge la configuration interactive.
• Les fichiers numérotés configurent Oh My Zsh, l’historique et la complétion, les alias, les fonctions et l’invite de commande.

Les alias sont donc gérés dans 20-aliases.zsh, plutôt que dans un fichier main.sh partagé. La configuration de Zsh reste ainsi facile à lire et les fichiers sont chargés dans un ordre prévisible. Une petite configuration Bash reste disponible en secours ; .bash_profile charge .bashrc pour les sessions de connexion.

# ~/.zshrc
[[ -o interactive ]] || return

for config_file in "$HOME"/.config/zsh/*.zsh(N); do
    source "$config_file"
done

6. Configuration de VSCodium

J’ai testé VSCodium en Flatpak, comme RPM ajouté en couche et dans Toolbox. Flatpak ajoutait des contraintes liées au bac à sable et à l’environnement, tandis que l’éditeur complet dans Toolbox semblait moins bien intégré et entraînait une surcharge perceptible sur mon matériel.

Le RPM ajouté en couche était la solution la plus fluide des trois : performances natives, accès direct au système de fichiers et aucune couche intermédiaire entre l’éditeur et l’hôte. Son inconvénient est d’ajouter un paquet à l’image Fedora Atomic et d’imposer un redémarrage après l’installation.

C’était ma configuration préférée à l’époque. Comme je l’explique dans la mise à jour de juillet ci-dessous, j’utilise maintenant Visual Studio Code sur l’hôte Fedora et je garde toute la chaîne d’outils de développement d’infrastructure dans un Dev Container partagé.

7. Configuration des captures d’écran

Parlons maintenant de la configuration d’un outil de capture d’écran presque parfait : Swappy. Il faut au préalable disposer de :

grim slurp wl-copy

Ils étaient déjà installés par défaut, à l’exception de Swappy. Je l’ajoute en couche, car ce n’est pas qu’un simple outil CLI : il est étroitement intégré au système d’exploitation et au gestionnaire de fenêtres.

sudo rpm-ostree install swappy

Il faut ensuite configurer les paramètres par défaut de Swappy dans le fichier géré par nos dotfiles :

vi dotf-stow/.config/swappy/config

puis :

[Default]
save_dir=$HOME/Pictures
save_filename_format=screenshot-%Y%m%d-%H%M%S.png
show_panel=true
paint_mode=rectangle
fill_shape=false

Et pour terminer, ajoutez ceci à Sway :

v dotf-stow/.config/sway/config.d/20-keys.conf

bindsym $mod+Shift+a exec grim -g "$(slurp)" - | swappy -f -

Admirez cette magnifique capture de mon outil de capture d’écran, Swappy !

8. Restic pour les sauvegardes chiffrées

Restic protège les données importantes de mon ordinateur portable grâce à des sauvegardes chiffrées et versionnées dans un dépôt sur mon serveur de sauvegarde. Le dépôt est accessible par SFTP ; le serveur a donc seulement besoin de Restic, d’un compte dédié aux sauvegardes et des accès SSH appropriés.

La sauvegarde comprend mes documents, mon bureau, mes photos, mes dotfiles, ma configuration SSH et mes trousseaux de clés locaux. Un petit script dans mon dépôt de dotfiles lance la sauvegarde et supprime les anciens instantanés selon une politique de rétention. Restic demande le mot de passe du dépôt lorsque c’est nécessaire ; celui-ci n’est ni stocké dans le dépôt ni ajouté à Git.

J’installe Restic sur l’hôte Fedora Atomic comme paquet ajouté en couche, puis je lance le script depuis mon dépôt de dotfiles. Une sauvegarde n’est utile que si elle peut être restaurée : je vérifie donc régulièrement les instantanés et effectue une restauration de test dans un répertoire temporaire.

Et voici le bureau complet :

Mise à jour de juillet 2026 : un Dev Container pour tous les dépôts

Quelques mois plus tard, l’hôte Fedora Atomic fonctionne toujours bien, mais mon flux de développement a évolué. Visual Studio Code s’exécute maintenant directement sur l’hôte, avec l’accélération GPU désactivée pour éviter des problèmes d’affichage, tandis que Podman exécute un Dev Container Debian Trixie partagé.

J’utilise toujours Fedora Toolbox, mais uniquement pour les opérations qui concernent l’hôte lui-même. Je ne gère plus aucun de mes dépôts d’infrastructure, ni leur code et leurs outils, depuis Toolbox ; tout ce travail se fait désormais dans le Dev Container.

Au lieu de conserver la configuration du Dev Container dans un seul dépôt, je l’ai déplacée dans un espace de travail central :

~/Documents/1-WKS/
├── .devcontainer/
│   ├── devcontainer.json
│   └── Dockerfile
├── multi-repos.code-workspace
└── repos/
    ├── ansible-homelab/
    ├── ansible-inventory/
    ├── homelab-terraform/
    └── ...

Le fichier .code-workspace ouvre plusieurs dépôts Git indépendants dans une seule fenêtre VS Code ; ils partagent tous la même configuration de conteneur. Le conteneur part de l’image Debian Trixie standard de Dev Containers :

FROM mcr.microsoft.com/devcontainers/base:trixie

Le Dockerfile installe les outils système, renomme l’utilisateur vscode par défaut en alex, configure Zsh et sudo sans mot de passe, puis prépare /home/alex. Le fichier devcontainer.json utilise ensuite alex comme remoteUser, désactive updateRemoteUserUID pour éviter le problème d’UID/GID que j’avais rencontré auparavant, et installe Ansible, OpenTofu et l’extension Codex.

J’ouvre l’espace de travail depuis Fedora et le rouvre dans le conteneur :

code ~/Documents/1-WKS

Les mêmes fichiers sont alors accessibles en lecture et en écriture sous /workspaces/1-WKS. Ils restent stockés sur Fedora ; le conteneur Debian ne fournit que l’environnement de développement.

Un détail important concerne la propriété des fichiers. L’utilisateur Fedora et l’utilisateur alex dans le conteneur doivent avoir les mêmes identifiants numériques, normalement uid=1000 et gid=1000. J’évite les commandes chown récursives dans l’espace de travail monté, car elles modifieraient aussi la propriété des fichiers sur l’hôte. Avec Podman et SELinux, les montages liés utilisent relabel=shared.

Je monte aussi directement dans le conteneur le répertoire Codex de l’hôte :

"containerEnv": {
    "CODEX_HOME": "/home/alex/.codex"
},

"mounts": [
    "source=${localEnv:HOME}/.codex,target=/home/alex/.codex,type=bind,relabel=shared",
    "source=${localEnv:HOME}/.ssh/config,target=/home/alex/.ssh/config,type=bind,readonly,relabel=shared"
]

Ainsi, config.toml, auth.json, l’authentification et la confiance accordée à l’espace de travail persistent entre les reconstructions du conteneur.

Réutiliser ma configuration SSH de l’hôte

Je voulais que le conteneur utilise les mêmes alias d’hôtes SSH que Fedora, sans y copier mes clés privées. Le second montage lié ci-dessus expose uniquement ~/.ssh/config, en lecture seule. Les commandes comme ssh dmz-app-01, Ansible, Git et les autres clients SSH peuvent ainsi utiliser les noms d’hôtes, utilisateurs, ports et paramètres de proxy déjà définis sur Fedora.

Les clés privées restent sur l’hôte. VS Code Dev Containers relaie l’agent SSH de l’hôte et crée un socket proxy dans le conteneur, accessible par SSH_AUTH_SOCK. Avant d’ouvrir VS Code, on peut vérifier que la configuration fonctionne sur Fedora :

echo "$SSH_AUTH_SOCK"
test -S "$SSH_AUTH_SOCK" && echo "socket exists"
ssh-add -l

Puis, depuis le conteneur :

echo "$SSH_AUTH_SOCK"
ssh-add -l

Un problème subtil m’a fait perdre un peu de temps : VS Code peut conserver une ancienne valeur de SSH_AUTH_SOCK. Dans mon cas, l’éditeur essayait toujours d’accéder à /home/alex/.ssh/agent/fedora.sock, alors que mon shell actuel utilisait un autre socket fonctionnel. Reconstruire le conteneur n’a rien changé, car la valeur périmée venait du processus VS Code exécuté sur Fedora, et non de l’image du conteneur.

Après avoir rouvert l’espace de travail dans le conteneur, le socket relayé doit afficher les mêmes clés. Il n’est pas nécessaire de monter manuellement le socket de l’agent ni les fichiers de clés privées.

J’installe aussi sshs, une petite interface de terminal qui construit sa liste d’hôtes à partir de ~/.ssh/config. Le Dockerfile télécharge une version précise, vérifie sa somme de contrôle SHA-256 et l’installe sous /usr/local/bin/sshs. Avec le montage de configuration en lecture seule et le relais de l’agent en place, il me suffit de lancer :

sshs

La configuration finale est simple : Fedora Atomic gère le bureau, VS Code, Podman, les fichiers source, les clés SSH privées, l’agent SSH et l’état de Codex ; un Dev Container Debian reproductible fournit Ansible, OpenTofu, Git, Zsh, sshs et Codex pour tous les dépôts. La séparation entre un poste de travail stable et un environnement de développement éphémère est ainsi plus nette.