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. 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 décrit maintenant les commandes, préconditions, contrôles et arrêts. Le bilan 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.