arch-system/docs/reconstruction-baseline.md

# Référence de reconstruction d’ArchASP — observations du 2 octobre 2026

Ce document distingue l’**intention déjà documentée**, l’**état observé** et une **proposition à décider**. Il ne constitue ni un inventaire à déployer tel quel, ni une procédure de réinstallation validée. Les preuves et limites techniques sont détaillées dans [le suivi d’audit](audits/2026-10-02-followup.md). Les exports d’`inventory/` datent principalement du 26 juillet 2026 et conservent leur valeur d’archive d’observation.

## Responsabilités et ordre de retour

1. **Premier démarrage et administration** : Arch, accès au dépôt et à ses dépendances minimales, EFI montée sur `/boot`, racine Btrfs, noyau et initramfs, entrée Limine normale, réseau et compte administrateur. Le Secure Boot documenté exige une chaîne de confiance vérifiée avant de compter sur un démarrage avec cette politique activée.
2. **Fonctions système du poste après ce démarrage** : Snapper et entrées de secours, services voulus, impression, énergie, pare-feu et outils root. Leur présence actuelle ne les rend pas tous indispensables au premier démarrage.
3. **Charges de travail et projets** : Trainlog, calcul scientifique, VM et stockage de travail. Le dépôt peut noter leurs dépendances système, tandis que leurs données et unités utilisateur gardent leur propre responsable.
4. **Hors Git système** : `~/.dotfiles`, données, sauvegardes, connexions réseau, secrets, clés Secure Boot et matériel de récupération. `arch-system` ne les sauvegarde pas.

## Matrice de décision

« À décider » ne donne aucune autorisation de modifier la machine ou les manifests. Les commandes citées en preuve sont des lectures effectuées le 2 octobre 2026 ; aucun identifiant de disque ou secret n’est reproduit.

| Composant / fonction | Intention déjà documentée | État observé au 2026-10-02 | Preuve | Périmètre de reconstruction | Proposition | Décision encore requise | Validation attendue |
|---|---|---|---|---|---|---|---|
| Arch, EFI, Btrfs, noyaux et Limine | Base Arch ; EFI `/boot` ; `@`, `@home`, `@log`, `@pkg`, `@/.snapshots` ; Limine Zen/LTS | Montages conformes au schéma ; deux noyaux et initramfs présents ; entrée EFI courante sur le chemin de repli `EFI/BOOT/BOOTX64.EFI` | `findmnt`, `lsblk`, `efibootmgr`, `/boot/limine.conf:14-27` | Premier démarrage | Garder le schéma comme cible structurelle ; paramétrer disque et UUID lors de l’installation | Choix du SSD cible et accès au support live | Démarrage normal depuis le nouveau SSD, montages et UUID vérifiés |
| Secure Boot et signature | Clés personnelles gérées par sbctl | Secure Boot activé ; hook pacman `zz-sbctl.hook` masqué ; post-hook mkinitcpio sbctl présent ; signatures non vérifiées | `sbctl status` sans privilège ; lien `/etc/pacman.d/hooks/zz-sbctl.hook` ; `/usr/lib/initcpio/post/sbctl:11-25` | Chaîne de démarrage | Établir la politique pour noyaux et chargeurs EFI avant toute action | Pourquoi le hook pacman est-il masqué ? Quels fichiers doivent être signés et par quel déclencheur ? | `sbctl list-files` et `verify` autorisés, contrôle après mise à jour, démarrage Secure Boot |
| Snapper et retour arrière | Entrées de snapshots via limine-snapper-sync | Entrées générées ; hooks `snap-pac`, plugin Snapper et appel depuis cleanup présents ; service observateur inactif ; restauration configurée `replace` | `/boot/limine.conf:29`, `/usr/share/libalpm/hooks/05-snap-pac-pre.hook`, `/usr/lib/snapper/plugins/10-limine-snapper-sync:17-18` | Secours après démarrage | Conserver ces voies comme mécanismes observés, puis vérifier leurs résultats | Politique de conservation et scénario de restauration voulu | Liste des snapshots et fichiers associés, démarrage d’essai, retour normal |
| Paquets officiels / natifs | `pkglist/pacman.txt` = export explicite de juillet | 251 natifs explicites contre 216 dans l’export ; certains outils récents servent aux projets | `pacman -Qqen`, `comm`, `/var/lib/pacman/sync/*.db` | Base puis fonctions | Sélectionner les fonctions nécessaires avant d’éditer les listes | Quels ajouts deviennent durables sur un futur poste ? | Installation de test par étapes ; origine des paquets confirmée |
| Paquets étrangers et `yay` | `pkglist/aur.txt` = export explicite ; `deploy.sh` attend `yay` | 17 étrangers explicites contre 12 dans l’export ; `yay` installé ici ; plusieurs `-debug` et `colmap` nouveaux | `pacman -Qqem`, `pacman -Qm`, `scripts/deploy.sh:171-180` | Après premier démarrage | Documenter l’amorçage futur de `yay` et choisir les paquets AUR utiles séparément | Source, intégrité et besoin des paquets étrangers | Construction contrôlée depuis sources vérifiées, versions et dépendances relevées |
| Réseau et pare-feu | NetworkManager et nftables voulus ; fichier du dépôt orienté `wg0` | NetworkManager actif ; `wg-quick@wg0` en échec ; fichier nftables déployé orienté `wlp1s0` ; règles effectives non lisibles | `systemctl show`, comparaison expurgée des deux `nftables.conf` | Réseau initial puis politique du poste | Prévoir l’accès réseau minimal avant d’appliquer une politique restrictive | VPN obligatoire ou facultatif ? Quels flux du poste et des VM doivent passer par quelle interface ? | Règles effectives examinées, flux DNS/Web/VM testés sans perte d’accès |
| Impression / numérisation | `cups.service` dans le manifest | CUPS service, socket et path activés et actifs ; `hplip`, `sane`, `sane-airscan` explicites | `systemctl list-unit-files 'cups*'`, `list-units`, `pacman -Qi` | Fonction du poste après démarrage | Documenter la disponibilité CUPS voulue au démarrage ; qualifier scanners et matériel | Périphérique et usage durable de la numérisation | Redémarrage, impression et numérisation testées |
| nginx pour Trainlog | Non présent dans le manifest de juillet | Paquet explicite et service activé/actif ; serveur local en boucle locale avec proxy vers backend Trainlog | `pacman -Qi nginx`, `systemctl show nginx`, `/etc/nginx/nginx.conf:28-37` | Dépendance d’application après démarrage | Décrire le paquet, l’activation éventuelle, la configuration système et le backend attendu ; laisser Trainlog et ses données au projet | Cette fonction doit-elle être rétablie sur tout futur ArchASP ? Où sera conservée sa configuration nginx ? | Proxy local testé après restauration du backend, sans recopier les données ici |
| Avahi | Non présent dans le manifest de juillet | Service et socket activés/actifs ; dépendance de paquets impression/scan observée | `systemctl list-unit-files 'avahi*'`, `pacman -Qi hplip sane sane-airscan` | Fonction du poste à qualifier | Examiner l’usage réel avant de le classer comme indispensable | Découverte réseau nécessaire à quels périphériques ? | Impression/scan et découverte testés avec la politique retenue |
| VMware / Samba | Services lancés à la demande | Quatre services ciblés désactivés et inactifs au relevé | `manifests/on-demand-system-services.txt`, `systemctl show` | Charge de travail après démarrage | Maintenir la séparation système/helpers et commandes utilisateur | VMware et Samba restent-ils nécessaires sur le futur poste ? | Démarrage/arrêt à la demande contrôlés |
| Zram et swaps supplémentaires | Ancien socle : zram 6 Gio, sans swapfile permanent | Zram 6 Gio ; swapfile 8 Gio déclaré dans `/etc/fstab` ; swap sur périphérique et autres entrées de travail | `swapon --show`, `/etc/fstab:18-25` expurgé | Base mémoire puis charge de travail | Conserver zram comme référence historique ; qualifier séparément les swaps ajoutés | Quels swaps doivent persister après reconstruction et pourquoi ? | Après redémarrage : capacité, priorité et dépendance au disque de travail vérifiées |
| Outils récents | Aucun statut global dans le dépôt | `colmap`/`colmap-debug` étrangers ; `rclone`, `smartmontools` natifs explicites ; `opencode` absent malgré la liste de juillet ; `openai-codex-desktop` absent du paquet installé malgré la liste AUR de juillet | `pacman -Q`, `-Qm`, `-Qqen`, `-Qqem` | Projets / administration à qualifier | Ne pas transformer l’export de juillet en cible automatique | Usage durable, source des paquets et sauvegarde de configuration ? | Fonction testée uniquement après décision et installation ciblée |
| Dotfiles, données et secrets | Dotfiles séparés ; secrets hors Git | `~/.dotfiles` existe ; disponibilité d’une copie externe et restauration non vérifiées | `README.md:5`, `docs/security.md`, vérification ciblée de présence | Hors `arch-system` | Préparer un accès indépendant du SSD remplacé | Où sont les copies récupérables et qui en est responsable ? | Copie datée accessible puis restauration d’essai sans publier les secrets |

`pacman -Qn` signifie présent dans les bases de synchronisation locales, qui étaient datées des 1er–2 octobre ; ce n’est pas une preuve universelle de dépôt « officiel » si d’autres dépôts sont configurés. `pacman -Qm` signifie absent de ces bases, pas nécessairement construit depuis l’AUR. Le `pacman.conf` lisible ne montre que `core`, `extra` et `multilib` activés au relevé.

Pour Trainlog, le minimum système observé est le paquet nginx, son activation,
un serveur écoutant uniquement en boucle locale, un nom local résolu sur cette
boucle et un proxy vers le backend. La configuration nginx effective n’est pas
suivie par `rootfs/` ; sa destination de sauvegarde et sa forme portable restent
à décider. Le backend, ses unités utilisateur et ses données relèvent du
projet et des dotfiles, pas de cette configuration système. Pour l’impression,
CUPS est disponible par service, socket et path ; la nécessité d’Avahi pour le
périphérique utilisé reste à établir par un essai ciblé.

## Dépendances avant perte ou remplacement du SSD

| Élément | Responsable | Preuve nécessaire avant l’opération | État établi dans ce lot |
|---|---|---|---|
| Dépôt `arch-system` | Copie indépendante du SSD courant | Destination accessible, révision datée et récupération d’essai | Remote configuré seulement ; disponibilité et révision distante non vérifiées |
| `~/.dotfiles` et commandes utilisateur | Dépôt utilisateur séparé | Copie indépendante et méthode de restauration | Répertoire local présent ; copie externe non vérifiée |
| Données personnelles et projets, dont Trainlog | Sauvegarde de données hors Git | Destination, date, intégrité et restauration ciblée | Non vérifiées ; aucun contenu personnel lu |
| Connexions réseau, secrets, clés et politique Secure Boot | Conservation sécurisée hors dépôt public | Support récupérable, droits et procédure de réenrôlement/récupération | Non vérifiés ; aucune clé consultée |
| Support live et accès de secours | Matériel de récupération | Démarrage du support avec la politique Secure Boot retenue, réseau et accès aux copies | Support décrit dans `docs/ssd-migration.md`, disponibilité actuelle non vérifiée |

Pour chaque sauvegarde, distinguer quatre preuves : **destination mentionnée**, **destination accessible**, **copie datée constatée**, **restauration testée**. Aucune de ces étapes ne découle automatiquement de l’existence d’un remote Git ou d’un snapshot local.

## Décisions ouvertes à regrouper avant la procédure complète

1. Politique voulue pour la signature des noyaux, des chargeurs EFI et des copies historiques ; raison du masquage du hook pacman sbctl.
2. Politique réseau : VPN, flux directs, trafic des VM et comportement lorsque `wg0` est indisponible.
3. Fonctions durables du futur poste : impression/scan, nginx/Trainlog, Avahi, VMware/Samba et outils de projet.
4. Rôle et persistance des swaps supplémentaires, ainsi que destination vérifiable des copies hors SSD.

Ces arbitrages précèdent toute réécriture de `pkglist/`, `manifests/`, `rootfs/` ou des scripts.

## État du dépôt après finalisation logicielle

La [procédure de réinstallation](reinstall.md) décrit maintenant les commandes,
préconditions, contrôles et arrêts. Le [bilan](audits/2026-10-02-finalisation.md)
distingue corrections logicielles simulées, choix opérateur et preuves
physiques manquantes. Cette mise à jour ne modifie ni les listes de juillet,
ni les manifests, ni la politique Secure Boot/réseau. AS-001 et AS-009
restent ouverts tant que signatures, amorçage et restauration actuels ne sont
pas observés sur la cible. L’essai déclaré du 29 mai reste historique.