Configuration sous forme de données

Lorsqu’une mise à jour d’Arch, un mardi matin, exige une nouvelle solution de contournement pour un iGPU Intel particulier, que fait un programme d’installation traditionnel ? Rien, jusqu’à ce que quelqu’un corrige le script bash qui le pilote, publie une nouvelle image ISO (de 1 à 3 Go) et attende que les utilisateurs la téléchargent. Des jours dans le meilleur des cas, plus souvent des semaines.

Ditana adopte une approche fondamentalement différente : la configuration sous forme de données.

Trois éléments distincts

L’architecture de Ditana est répartie sur trois dépôts :

Le moteur (ditana-installer) – un petit programme générique qui sait comment afficher des boîtes de dialogue, partitionner les disques, détecter le matériel et exécuter pacstrap.
La base de connaissances (ditana-config) – une base de données structurée écrite en KDL v2. Elle déclare chaque paramètre, chaque particularité matérielle, chaque dépendance de paquet, chaque script de cycle de vie, ainsi que les relations logiques entre eux.
La chaîne de production des paquets (ditana-build) – ce qui compile les paquets que nomme la base de connaissances. Le dépôt de Ditana repose sur celui d’Arch, et les recettes qu’il contient sont recompilées à partir des sources, examinées et signées par cette chaîne plutôt que reprises telles quelles.

Lorsque vous démarrez sur l’image ISO de Ditana, le moteur se connecte à GitHub et télécharge la dernière version de la base de connaissances (en se rabattant sur un instantané hors ligne fourni avec l’image ISO si vous n’avez pas de connexion Internet).

Ce que la récupération à l’exécution ne couvre pas mérite aussi d’être connu. Le moteur lui-même et le convertisseur avec lequel il lit le KDL se trouvent sur le support et ne changent qu’avec un nouveau support. Et ce canal transmet une erreur aussi facilement qu’un correctif : une configuration qui nomme un paquet que le dépôt d’un support plus ancien ne peut pas fournir rend toute installation impossible avec ce support, ce qui est exactement ce qui s’est passé lorsque Arch a retiré bubblewrap-suid en septembre 2026.

Pourquoi c’est important

Trois avantages, par ordre d’impact immédiat :

Mises à jour sans nouvelle image ISO. Si un utilisateur signale qu’une mise à jour récente d’Arch exige une nouvelle solution de contournement, le correctif arrive dans ditana-config sous la forme d’une petite modification KDL. La toute prochaine personne qui démarre sur une image ISO de Ditana télécharge automatiquement la logique mise à jour. Le correctif atteint les utilisateurs immédiatement, sans que quiconque ait besoin de télécharger une nouvelle image ISO.
Raisonnement transparent. Comme les paramètres sont déclarés sous forme de données structurées avec des conditions explicites, les règles sont vérifiables de bout en bout. Tout le monde peut lire les fichiers KDL et voir exactement pourquoi un paquet est installé, quelle combinaison de paramètres déclenche le déploiement d’un fichier de configuration, ou quelle propriété matérielle conditionne une option. Aucun travail de détective dans du bash.
Contributions faciles à dériver. Ajouter une solution de contournement matérielle, un nouvel ajustement du bureau ou un nouveau choix d’empaquetage implique généralement de modifier un seul fichier KDL. Aucune modification du moteur d’installation – et, hormis les détecteurs de matériel, qui sont des expressions Raku d’une ligne, pas de Raku du tout. Le README de ditana-config guide les contributeurs à travers le schéma ; la plupart des demandes de fusion ne touchent qu’un seul fichier.

Pourquoi KDL, et non JSON ou YAML

La base de connaissances aurait pu utiliser n’importe quel format structuré. KDL a été choisi parce qu’il possède les propriétés dont la configuration de Ditana a réellement besoin :

Commentaires natifs. YAML et JSON ont tous deux des difficultés sur ce point – YAML prend en charge les commentaires, mais les outils les gèrent de manière inégale ; JSON n’en a pas du tout. Les paramètres de Ditana comportent de nombreux commentaires de justification qui expliquent pourquoi une valeur par défaut est ce qu’elle est. Ces commentaires sont l’essentiel.
Chaînes brutes. Les fragments de shell intégrés, les expressions sed et les motifs d’expressions régulières sont des éléments à part entière. Pas de double échappement de " et de \ pour satisfaire l’analyseur.
Hiérarchique sans cérémonie. Enfants, propriétés et arguments coexistent proprement. Le même nœud peut décrire un paramètre et contenir des sous-nœuds pour ses paquets, ses scripts et ses fichiers.
Adapté aux diffs. L’ordre d’insertion est conservé. La revue de code d’un ajout d’une ligne montre un diff d’une ligne, et non une structure réordonnée.

Le format est analysé par un petit convertisseur écrit en Rust (json-kdl-converter, dont les versions sont également gérées avec le schéma) avant que le programme d’installation en Raku ne l’utilise sous forme de JSON. La section suivante explique comment les données sont validées de bout en bout avant tout cela.

À quoi cela ressemble en pratique

Un paramètre complet et fonctionnel dans ditana-config se présente ainsi :

// XFCE fallback for Wayland-only primary terminals (foot, cosmic-term).
// Fires when the user picks a Wayland-native terminal AND also installs
// XFCE. Writes to xfce-xdg-terminals.list only; xdg-terminals.list still
// points at the primary terminal for Wayland sessions.
- name="fallback-kitty-for-xfce" \
  default-value="`(install-foot OR install-cosmic-term) AND install-xfce`" {
    arch-packages "kitty" \
                  "imagemagick" \
                  "python-pygments" \
                  "libcanberra" \
                  "xdg-terminal-exec-git"
    files "/etc/xdg/kitty/kitty.conf" \
          "/usr/share/pixmaps/ditana-logo-tiny.png"
    chroot-script "mkdir -p /etc/xdg" \
                  "echo kitty.desktop >/etc/xdg/xfce-xdg-terminals.list"
}

Ce nœud déclare un paramètre dérivé sans boîte de dialogue propre, une expression logique portant sur trois autres paramètres, les paquets à installer lorsqu’elle est vraie, et le fichier qui amène XFCE à les utiliser. La justification se trouve à côté de la règle, là où la personne qui l’examine peut en voir la raison. La documentation complète du schéma se trouve dans le README de ditana-config.

La même forme exprime aussi des choses qui ne sont pas du tout des paquets. Un programme qui a besoin d’un espace de noms utilisateur non privilégié pour son bac à sable l’indique juste à côté de lui-même :

- name="flatpak" default-value=#true {
    arch-packages "flatpak"
    // Every Flatpak, not only the browsers, runs bwrap to build its outer
    // sandbox, and bwrap needs a user namespace. This is the declaration
    // that buys it one.
    userns-allow "/usr/bin/bwrap"
  }

Ditana n’accorde pas d’espaces de noms utilisateur non privilégiés à chaque programme. Un programme BPF minimal, ditana-userns-guard, est attaché au crochet userns_create du noyau lui-même et refuse un espace de noms à tout exécutable pour lequel aucun paramètre n’en a fait la demande. Un crochet de ce type ne peut que refuser, jamais accorder ; c’est pourquoi le sysctl qui désactive les espaces de noms n’est levé qu’une fois le programme chargé – une machine qui ne peut pas le charger les garde entièrement désactivés. C’est l’état par défaut d’une option de System Hardening ; désactivez-la et les espaces de noms sont ouverts à tout, comme sur la plupart des distributions.

Ditana refuse les espaces de noms utilisateur à tout ce qui n’en a pas fait la demande. Ce qui rend cela praticable, c’est que la demande est locale : elle est écrite là où le paquet est choisi, de sorte que rien n’a besoin de tenir à jour une liste centrale synchronisée, et désactiver le paramètre retire l’autorisation avec lui. Le programme d’installation rassemble les déclarations des paramètres qui restent finalement activés et génère la liste d’autorisation à partir de celles-ci.

Validation : détecter les erreurs avant leur publication

Une base de connaissances de cette taille a besoin de garde-fous. Chaque commit – aussi bien localement via des crochets pre-commit qu’à distance sur GitHub Actions – passe par une chaîne de validation à plusieurs niveaux qui détecte les erreurs qu’un relecteur humain pourrait manquer :

Syntaxe KDL (kdlfmt) – le fichier est analysable, tout simplement.
Validation du schéma (ditana-schema.json) – chaque champ a le bon type, aucune propriété inconnue, aucun champ obligatoire manquant. Détecte les fautes de frappe dans les noms de champs, comme arc-packages au lieu de arch-packages.
Intégrité des références de fichiers – chaque fichier référencé par un paramètre existe réellement dans folders/ ; inversement, chaque fichier de folders/ est référencé par au moins un paramètre. Les fichiers orphelins sont signalés. Les références à des répertoires (qui n’auraient silencieusement aucun effet, parce que le programme d’installation utilise cp sans -R) sont rejetées.
Exactitude du cycle de vie – les lignes chroot-script qui touchent à /etc/skel/ sont rejetées, car l’utilisateur est créé après l’exécution de chroot-script – le bon champ est early-chroot-script. Un bogue subtil qui produirait sinon un système dans lequel le répertoire personnel du nouvel utilisateur ne contient pas les fichiers attendus.
Validité des scripts shell – chaque fragment de shell contenu dans l’un des champs de listes de scripts passe par bash -n pour la syntaxe et par shellcheck pour la qualité. Un guillemet manquant ou un bogue du type [ "$x" = $y ] est détecté au moment du commit, et non lors de la première installation.
Autorisations déclarées et paramètres du noyau – une entrée userns-allow doit être un chemin absolu, et une entrée sysctl doit nommer quelque chose qui est bien une clé sysctl et lui donner une valeur que le noyau acceptera. Ces deux champs ont été ajoutés dans la 0.9.4 et sont déclarés dans ditana-schema.json.
Paramètres du noyau contradictoires – deux paramètres qui écrivent la même clé sysctl avec des valeurs différentes arrêtent l’installation, et le message les nomme tous les deux. Lorsque tout était assemblé sous forme de texte shell, comme avant la 0.9.4, la dernière ligne écrite l’emportait simplement, sans que personne en soit informé.
Intégrité des expressions logiques – les accents graves doivent aller par paires ; chaque nom de paramètre référencé dans une expression default-value ou available doit réellement exister quelque part dans la base de connaissances. Une faute de frappe comme install-cosmik au lieu de install-cosmic est détectée au moment du commit au lieu de provoquer un plantage silencieux à l’exécution.

La vérification complète s’exécute localement en quelques secondes avec pre-commit run --all-files, puis à nouveau à chaque envoi sur GitHub. Vert en local signifie vert dans l’intégration continue ; les commits défectueux n’arrivent jamais dans une version publiée.

Pour aller plus loin

Lisez comment les paramètres dépendent les uns des autres – c’est dans available et default-value que réside la logique de la base de connaissances.
Parcourez le dépôt ditana-config pour voir comment les règles sont organisées par boîte de dialogue et par thème.
Lisez le README de ditana-config pour le modèle de données : comment les paramètres, les scripts, les boîtes de dialogue et les fichiers sont liés entre eux.
Consultez le code source de ditana-installer si vous voulez voir le moteur qui lit la configuration et agit en conséquence.

Cette traduction a été réalisée par une machine. Les lecteurs l’améliorent sur Weblate.