NixOS - config déclarative et rollback

Déclarer l’OS plutôt que le configurer

Sur un système classique - Debian, Arch, Ubuntu - la configuration système c’est un tas de fichiers éparpillés dans /etc, modifiés à la main, sans historique de ce qui a été touché ni dans quel ordre. Réinstaller depuis zéro veut dire refaire tout ça de mémoire, ou maintenir un script shell qui finit toujours par dater.

NixOS renverse ça : l’état du système se décrit dans des fichiers Nix, et nixos-rebuild switch l’applique. Si quelque chose casse, une commande ramène à la génération précédente.

configuration.nix

Le point d’entrée c’est /etc/nixos/configuration.nix. Un fichier qui décrit ce que le système doit être :

{ config, pkgs, ... }:
{
  networking.hostName = "laptop";
  time.timeZone = "Europe/Paris";

  users.users.alice = {
    isNormalUser = true;
    extraGroups = [ "wheel" "networkmanager" ];
  };

  environment.systemPackages = with pkgs; [
    vim git firefox
  ];

  system.stateVersion = "25.11";
}

Aucune commande shell, aucune étape séquentielle. On décrit l’état voulu, Nix calcule comment l’atteindre.

Le système de modules

Tout ce qui est configurable dans NixOS est organisé en modules. Chaque module expose des options que la config principale peut renseigner.

Activer SSH en interdisant les mots de passe :

services.openssh = {
  enable = true;
  settings.PasswordAuthentication = false;
};

services.openssh n’est pas une variable magique - c’est une option définie dans le module OpenSSH de NixOS. Nix fusionne toutes les options de tous les fichiers chargés, vérifie les types, et génère la config finale.

Pour trouver les options disponibles : search.nixos.org/options. C’est la page à garder ouverte quand on écrit une config.

La config peut être découpée en plusieurs fichiers avec imports :

{ ... }:
{
  imports = [
    ./hardware-configuration.nix
    ./modules/desktop.nix
    ./modules/dev.nix
  ];

  networking.hostName = "laptop";
}

Dans ma config, j’ai un common.nix pour ce qui est partagé entre toutes mes machines, un desktop.nix pour ce qui est graphique, et un default.nix par machine pour ce qui lui est spécifique.

nixos-rebuild

Les commandes du quotidien :

# Applique la config et redémarre les services concernés
sudo nixos-rebuild switch

# Construit sans activer - pour vérifier que ça compile
sudo nixos-rebuild test

# Applique au prochain boot seulement
sudo nixos-rebuild boot

# Avec un flake
sudo nixos-rebuild switch --flake .#laptop

Générations et rollback

Chaque nixos-rebuild switch crée une nouvelle génération. L’ancienne reste dans le store et dans le menu GRUB.

# Lister les générations
nix-env --list-generations --profile /nix/var/nix/profiles/system

# Revenir à la génération précédente
sudo nixos-rebuild switch --rollback

Si une mise à jour casse quelque chose, redémarrer et sélectionner une génération plus ancienne dans le menu de démarrage suffit. Pas besoin de clé USB de secours.

Mon parcours

La première fois que j’ai essayé NixOS, je me suis lancé directement dans les flakes. Sur le papier c’est la bonne façon de faire. En pratique, je ne connaissais pas encore le langage, je ne savais pas où chercher les options, et je recopiais des configs d’autres personnes sans vraiment comprendre ce que je collais. Je savais que c’était puissant, mais je n’arrivais pas à construire quelque chose qui m’appartienne vraiment.

J’ai fini par tout laisser tomber et me contenter d’un configuration.nix minimal, sans flakes, avec des dotfiles gérés à part avec des outils classiques. Ça marchait. Mais ce n’était pas vraiment dans la logique de Nix - j’utilisais la moitié du système, la partie la moins intéressante.

Ce qui m’a fait revenir c’est un besoin concret : déployer des services sur mon Proxmox de façon reproductible. Aucun autre outil n’a fait le job proprement. Et cette fois j’avais un an de plus d’expérience - j’ai reconstruit une config complète avec flakes et Home Manager, en comprenant ce que je faisais. Pas parfaite, mais à moi.

Le vrai déclencheur ça n’a pas été “Nix c’est bien en théorie”. Ça a été d’en avoir besoin concrètement, et de voir que rien d’autre ne faisait l’affaire.

L’article suivant couvre les flakes - comment verrouiller les dépendances et gérer plusieurs machines depuis un seul repo.