Note d’orientation — sauvegarde / restauration d’un système Air (état = /etc/air + homes)

Statut : note d’orientation (non normative), figée le 2026-07-23 sur directive BDFL. Elle fixe une cible de conception transverse ; les décisions structurantes qui en découleront passeront par des ADR/RFC dédiés. S’appuie sur la doctrine de configuration binaire (ADR-073), le format d’artefact Cap’n Proto (ADR-040), la coexistence /etc (ADR-041) et le modèle de configuration (ADR-033).

1. Idée directrice — l’état d’une machine tient en deux ensembles

Un utilisateur qui acquiert une nouvelle machine et y pose un système Air de base (cf. §2) doit pouvoir reconstituer une machine identique — en fonctionnement et en configuration — en ne sauvegardant que deux ensembles :

1. Le contenu de /etc/air — l’état de configuration système (global machine).
2. L’ensemble des répertoires personnels (home directories) des utilisateurs présents sur la machine — l’état de configuration par-utilisateur.

Tout le reste — binaires, bibliothèques, toolchain, artefacts génériques du système — doit pouvoir être réinstallé de manière générique pour reconstituer un système Air de base. Autrement dit : le système de base est reproductible et fongible ; l’unicité d’une machine donnée est entièrement capturée par /etc/air + les homes. Rien d’essentiel à l’identité d’une machine ne doit vivre ailleurs.

Corollaire (invariant de conception) : aucun composant Air ne doit persister d’état de configuration signifiant en dehors de /etc/air (système) ou du home de l’utilisateur (par-utilisateur). Toute exception serait une fuite d’état non sauvegardée par ce schéma et doit être traitée comme un défaut de conception.

2. Ce qu’est un « système Air de base » (à lister — chantier ouvert)

Cette note ouvre la définition ; elle sera figée par un document dédié (spec/ADR). Le « système Air de base » est l’ensemble générique, réinstallable sans sauvegarde qui, combiné à /etc/air + les homes, redonne la machine d’origine. À caractériser :

• Le noyau Linux ciblé et son périmètre (tier-1, cf. ADR-004) — hors périmètre Air à proprement parler, mais prérequis.
• La toolchain et les artefacts de build reproductibles (ADR-025).
• Les crates/exécutables de couche 1 et 2 livrés en standard (dont les futurs air-ssh/air-sshd).
• Les services de base activés par défaut et leur configuration par défaut (celle qui vaut avant toute personnalisation dans /etc/air).
• Le contenu initial/squelette d’un home (skeleton) posé à la création d’un compte.

À faire : produire la liste normative d’un « système Air de base » (inventaire des composants génériques + versions + configuration par défaut). Tant que cette liste n’existe pas, la garantie de reproductibilité n’est qu’une orientation, pas un contrat.

3. Configuration par-utilisateur — se conformer à freedesktop.org (XDG)

Pour les fichiers de configuration propres à un utilisateur, stockés en référence au home de l’utilisateur, l’orientation est de se conformer aux spécifications freedesktop.org (XDG Base Directory Specification) : $XDG_CONFIG_HOME (défaut ~/.config), $XDG_DATA_HOME, $XDG_STATE_HOME, $XDG_CACHE_HOME, etc.

Conséquences :

• La config par-utilisateur d’un composant Air vit sous la cascade XDG dans le home (p.ex. ~/.config/air/<composant>/…), jamais en dehors du home. Ceci est déjà le comportement visé par air-config (résolution XDG, cf. docs/specs/layer-1/air-config.md).
• Sauvegarder le home capture donc par construction toute la configuration par-utilisateur — c’est ce qui rend le point (2) du §1 suffisant.
• Le format reste la doctrine binaire (Cap’n Proto via air-config, ADR-073/040) : XDG fixe où ranger, pas comment encoder. Les deux sont orthogonaux et compatibles.
• Nuance à cadrer : les données de $XDG_CACHE_HOME sont par définition régénérables et ne devraient pas être nécessaires à la restauration ; seule la config/état persistant (config/data/state) doit être considérée comme partie de la sauvegarde. À trancher dans la spec dédiée.

4. Ce que cette orientation contraint pour la suite

• /etc/air devient l’emplacement de référence pour l’état système. NB : cet emplacement précis (/etc/air vs autre) n’est pas encore ratifié par un ADR — cette note l’ORIENTE, mais air-config reste paramétré par un répertoire racine, jamais /etc codé en dur (cf. air-config.md). La ratification passera par ADR/RFC.
• air-sshd/air-ssh (ADR-093/094) doivent s’y conformer : conf système sous /etc/air, authorized_keys binaire par-utilisateur sous la cascade XDG du home. Cela confirme et cadre le « emplacement figé par l’incrément » laissé ouvert par ADR-094 (U.3).
• Toute nouvelle brique porteuse de configuration hérite de l’invariant du §1.

5. Packaging des exécutables air-ssh (client) / air-sshd (serveur)

Orientation figée le 2026-07-23 (directive BDFL, avis motivé consigné). Deux axes.

5.1 Client vs serveur — deux exécutables séparés

air-ssh (client) et air-sshd (serveur) sont deux binaires distincts, jamais un seul exécutable multi-appel (pas de dispatch busybox par argv[0]). Raisons :

• Frontière de privilège / surface d’attaque. Le serveur est un daemon privilégié (écoute, privsep, drop_to_user, lecture config système /etc/air + authorized_keys). Le client tourne comme l’utilisateur non privilégié et lit son home. Un binaire unique ferait cohabiter les deux surfaces — contraire à la posture secure-first (SecurityManager). Une invocation cliente ne doit pas embarquer le code serveur.
• Cohérence & moindre surprise. Le crate est déjà air-sshd ; air-ssh/air-sshd calque ssh/sshd.
• Système de base & reproductibilité (§1–§2) : un serveur headless livre air-sshd sans client, et inversement — inventaire plus net.
• Coût nul : toute la logique protocolaire vit dans le cœur sans-IO air-ssh-proto (ADR-091) ; les deux binaires ne sont que de minces pilotes I/O au-dessus du même cœur. On sépare deux main, on ne duplique rien.

5.2 Client — binaire unique air-ssh, verbes style git (pas de binaire « config-only »)

Le client est un seul binaire avec sous-commandes ; on n’introduit pas de troisième exécutable dédié à la seule manipulation de configuration cliente :

air-ssh connect user@host     # chemin quotidien (verbe primaire)
air-ssh config …              # lecture/écriture de la config binaire par-utilisateur (XDG)
air-ssh keygen …              # production d'identités/artefacts

• Les concerns (connexion chaude vs écriture de config) se séparent par verbe, pas par binaire : côté client, aucune frontière de privilège à isoler (tout tourne comme le même utilisateur, propriétaire de son home) — l’argument de surface d’attaque du §5.1 ne s’applique pas ici. Séparer par binaire coûterait en ergonomie sans rien acheter.
• Convention CLI moderne (git/cargo) : un outil, un arbre de doc, verbes découvrables.
• La logique d’écriture reste dans les crates (air-config-compile) ; le verbe n’est qu’un pilote. Un verbe peut être ré-adossé à un autre crate plus tard sans changer l’UX de air-ssh connect.

5.3 Réconciliation avec ADR-073 (config binaire, CLI dédié admin-gated)

• Le « CLI dédié exigeant la ressaisie du mot de passe administrateur » d’ADR-073 vise la config système/administrative. Côté client, la config est propriété de l’utilisateur dans son home : pas de frontière admin → un sous-commande de air-ssh est conforme.
• Le CLI admin-gated d’ADR-073 s’applique à la config serveur : /etc/air (politique sshd, host keys) + authorized_keys système. Cette production relève du côté serveur / d’un outil air-config admin-gated — pas du client air-ssh.

Décision structurante gravée et ratifiée : ADR-095 (Accepté 2026-07-23). La présente note en a porté l’orientation ; l’ADR-095 fait foi.

6. Points ouverts (honnêteté)

1. Liste normative du « système Air de base » : à produire (§2).
2. Emplacement /etc/air : orienté ici, non ratifié — ADR/RFC à venir (réconcilier avec config-specification-proposal.md, draft partiellement caduc car basé Protobuf).
3. Frontière cache vs état dans les homes (XDG_CACHE exclu de la sauvegarde ?) : à trancher.
4. État machine hors config (host keys, identités, secrets scellés) : confirmer qu’il tient bien dans /etc/air (artefact système) et non ailleurs.
5. Packaging air-ssh/air-sshd (§5) : ratifié par ADR-095 (Accepté 2026-07-23). ✅
6. Autres consignes propres à air-ssh (client/serveur) : à venir (suite de la directive BDFL) — seront gravées par addendum/RFC à ADR-095.

Cette note est une orientation de cadrage. Elle ne remplace aucun ADR et sera raffinée / ratifiée par les documents normatifs correspondants.