From c77443b93ca480234071fc496d0a3de4fdd46cb9 Mon Sep 17 00:00:00 2001 From: fy59 Date: Fri, 2 Oct 2026 14:40:01 +0200 Subject: [PATCH] =?UTF-8?q?docs:=20=C3=A9tablir=20la=20r=C3=A9f=C3=A9rence?= =?UTF-8?q?=20de=20reconstruction=20ArchASP?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README.md | 16 ++++++- docs/architecture.md | 10 +++- docs/audits/2026-10-02-followup.md | 74 ++++++++++++++++++++++++++++++ docs/backup.md | 13 +++++- docs/reconstruction-baseline.md | 62 +++++++++++++++++++++++++ docs/reinstall.md | 16 ++++++- 6 files changed, 186 insertions(+), 5 deletions(-) create mode 100644 docs/audits/2026-10-02-followup.md create mode 100644 docs/reconstruction-baseline.md diff --git a/README.md b/README.md index 1be7ddb..041f01d 100644 --- a/README.md +++ b/README.md @@ -25,6 +25,12 @@ Ce dépôt couvre la partie système : paquets, services, stockage, énergie, d - `templates/` : fichiers nécessitant une adaptation à la machine ; - `docs/` : procédures d’entretien, de restauration et de migration SSD. +La [référence de reconstruction](docs/reconstruction-baseline.md) distingue la cible +documentée de l’état observé sur ArchASP le 2 octobre 2026. Son +[suivi d’audit](docs/audits/2026-10-02-followup.md) précise les preuves, les +limites d’accès et les décisions encore ouvertes. Les inventaires du 26 juillet +restent des observations datées, pas une cible automatique de déploiement. + ## Mise à jour du dépôt ```bash @@ -55,16 +61,22 @@ Pour tout appliquer : `/etc/fstab`, `limine.conf`, les clés Secure Boot et les connexions réseau ne sont jamais restaurés automatiquement. -## État fonctionnel visé +## Socle historiquement documenté - Arch Linux, Sway/SwayFX et Wayland ; - Btrfs avec `@`, `@home`, `@log`, `@pkg` et `@/.snapshots` ; - Limine + limine-snapper-sync ; - Secure Boot géré par `sbctl` ; -- zram 6 Gio, sans swapfile permanent ; +- zram 6 Gio ; l’affirmation ancienne « sans swapfile permanent » ne décrit + plus à elle seule le poste observé le 2 octobre 2026 ; - TLP avec seuil de charge ASUS à 60 % ; - Nextcloud, Proton Mail Bridge, VMware et Samba lancés uniquement à la demande. +Ce socle n’est pas une certification de réinstallation. Le poste observé possède +aussi des swaps supplémentaires, CUPS disponible au démarrage et nginx utilisé +localement pour Trainlog. Leur portée sur une future installation reste à +décider dans la référence de reconstruction. + ## Sécurité Le dépôt est public. Aucun mot de passe, token, clé privée, fichier `.netrc`, base SQLite, connexion NetworkManager ou configuration WireGuard ne doit y être ajouté. diff --git a/docs/architecture.md b/docs/architecture.md index ca14c81..2c0aa01 100644 --- a/docs/architecture.md +++ b/docs/architecture.md @@ -14,6 +14,11 @@ Les UUID réels sont enregistrés dans `inventory/storage/` uniquement à titre documentaire. Les modèles de réinstallation utilisent des placeholders. +Ce schéma de base est encore visible dans les montages relevés le 2 octobre 2026. +`/etc/fstab` du poste comporte également un swapfile et des entrées liées à un +espace de travail ; leur reconduction n’est pas décidée. Voir la +[référence de reconstruction](reconstruction-baseline.md). + ## Démarrage - Limine ; @@ -27,7 +32,10 @@ Les clés Secure Boot ne sont jamais versionnées. - 16 Gio de RAM physique environ ; - zram de 6 Gio, priorité 100 ; -- aucun swapfile permanent. +- à la date de l’ancien inventaire, aucun swapfile permanent n’était relevé. + +Le 2 octobre 2026, un swapfile déclaré dans `/etc/fstab` et un swap sur +périphérique sont actifs en plus de zram. Leur rôle futur reste à qualifier. ## Énergie diff --git a/docs/audits/2026-10-02-followup.md b/docs/audits/2026-10-02-followup.md new file mode 100644 index 0000000..2e0550e --- /dev/null +++ b/docs/audits/2026-10-02-followup.md @@ -0,0 +1,74 @@ +# Suivi ciblé de l’audit du 2 octobre 2026 + +Lot documentaire `ARCH_SYSTEM_RECONSTRUCTION_BASELINE_V1`. Observations effectuées sur ArchASP le 2 octobre 2026, branche `arch-system-reconstruction-baseline-v1`, à partir de HEAD `14e547ce564d2a6c8b24e430225650c034e9d363`. Aucun script du dépôt ni mécanisme de démarrage/restauration n’a été exécuté. La [matrice de reconstruction](../reconstruction-baseline.md) sépare les choix futurs des observations. + +## Niveaux de preuve et accès + +Les fichiers présents et les unités déclarées prouvent une **configuration**, pas son exécution réussie. Les dates et entrées générées prouvent un **résultat écrit**, pas l’amorçabilité. La déclaration de l’utilisateur du **29 mai 2026** selon laquelle démarrage et restauration fonctionnaient après essai est conservée comme **essai historique déclaré**, sans valider l’état du 2 octobre. + +Les huit lectures privilégiées autorisées (`sudo -n sbctl status`, `list-files`, `verify`, `btrfs subvolume list /`, `get-default /`, `snapper -c root list`, lecture de `/etc/snapper/configs/root`, `nft -nn list ruleset`) ont toutes répondu `sudo: a password is required`. Aucun mot de passe n’a été demandé. Le contrôle ultérieur nécessite un opérateur habilité ; son résultat devra être expurgé avant publication. + +## AS-001 et AS-009 — carte de démarrage, signature et snapshots + +Versions locales relevées par `pacman -Q` : `sbctl 0.18-2`, `mkinitcpio 42.1-1`, `limine 12.9.1-1`, `limine-snapper-sync 1.32.0-1`, `snapper 0.13.2-1`, `snap-pac 3.0.1-3`, `linux-lts 6.18.54-2`, `linux-zen 7.2.8.zen1-2`. + +```text +transaction pacman : 05-snap-pac-pre.hook puis 10-limine-snapper-lock.hook + -> snapshot pré-transaction possible ; verrou de synchronisation + -> installation ou mise à jour du noyau + -> hook ALPM 90-mkinitcpio-install.hook (PostTransaction, si déclenché) + -> presets locaux : noyau + initramfs Zen/LTS dans /boot ; UKI commentés + -> post-hook mkinitcpio /usr/lib/initcpio/post/sbctl : signe le noyau cible + si son contrôle de clés réussit ; ne signe pas ici l'initramfs séparé + -> zz-snap-pac-post.hook : snapshot post-transaction possible + +hook ALPM zz-sbctl.hook du paquet + -> masqué par /etc/pacman.d/hooks/zz-sbctl.hook -> /dev/null + -> son « sign-all -g » PostTransaction ne doit pas être supposé actif + +Snapper sur la racine + -> plugin /usr/lib/snapper/plugins/10-limine-snapper-sync + -> synchronisation asynchrone des entrées ; cleanup appelle aussi la sync + -> /boot/limine.conf et copies d'historique de noyau/initramfs/microcode + -> entrée normale ou entrée de snapshot sélectionnée dans Limine +``` + +Cette carte indique des **déclencheurs possibles**, pas une chronologie prouvée pour une transaction passée. Les hooks ALPM sont ordonnés par nom ; le fichier homonyme du répertoire prioritaire peut masquer celui du paquet par lien `/dev/null` ([alpm-hooks(5)](https://man.archlinux.org/man/alpm-hooks.5.en)). Les hooks `05-snap-pac-pre.hook` et `zz-snap-pac-post.hook` sont installés ; leurs homologues suffixés `.hook.disabled` ne sont pas des hooks actifs. `90-mkinitcpio-install.hook:34-38` invoque le helper mkinitcpio ; `/usr/bin/mkinitcpio:793-819,1240-1241` lance les post-hooks après génération sauf option contraire. `/usr/lib/initcpio/post/sbctl:6-25` choisit le noyau ou un UKI, puis appelle `sbctl sign`. Les presets `/etc/mkinitcpio.d/linux-{lts,zen}.preset` n’activent que l’image normale et commentent les UKI. L’existence du post-hook permet donc une voie de signature **du noyau**, sous conditions ; elle ne démontre ni son exécution passée, ni la signature du chargeur EFI, ni celle des copies d’historique. Le hook `zz-sbctl` masqué ne prouve pas l’absence de toute autre voie. + +| Artefact utilisé ou présent | Producteur et emplacement logique | Copie, authentification et déclencheur identifiés | Ce qui reste non vérifié | +|---|---|---|---| +| EFI de repli `EFI/BOOT/BOOTX64.EFI` | Binaire PE comportant un marqueur Limine sur l’ESP ; `efibootmgr` indique cette entrée comme courante | Secure Boot est activé d’après `sbctl status` non privilégié ; fichier EFI présent, daté de mai | Signature exacte, correspondance avec le binaire démarré et mécanisme de mise à jour | +| EFI sous `EFI/arch-limine/` | Autre binaire Limine présent sur l’ESP, différent de la copie de repli ; entrée EFI nommée Arch Linux Limine existe | Aucun hook local démontré pour le signer ou le mettre à jour | Quelle entrée doit rester disponible et quels fichiers sbctl suit | +| Noyaux Zen/LTS dans `/boot` | Paquets noyau et mkinitcpio ; fichiers datés du 2 octobre | Post-hook sbctl installé et exécutable, conditionné par l’état des clés ; hook ALPM mkinitcpio présent | Exécution passée, signature actuelle et politique de vérification Limine | +| Initramfs et microcode séparés dans `/boot` | mkinitcpio et paquet microcode ; référencés par `/boot/limine.conf:18-27` | Modules Limine ; aucune signature EFI directe identifiée pour ces fichiers séparés | Intégrité effective et cohérence avec le noyau chargé | +| Copies de noyaux, initramfs et microcode pour snapshots | `limine-snapper-sync` ; chemins `limine_history/..._sha256_...` dans le menu généré | Noms avec empreinte SHA-256, déduplication/intégrité propres à l’outil selon la documentation locale | Existence et contrôle de **toutes** les copies, lien avec la chaîne Secure Boot, capacité à démarrer | +| `limine.conf` et métadonnées de snapshots | Synchronisation Snapper/Limine ; `/boot/limine.conf` généré le 2 octobre | Section « Auto-generated » présente ; le modèle versionné garde seulement la partie non générée | Correspondance exacte entre menu, snapshots et fichiers, restauration réelle | + +`efibootmgr` montre l’entrée courante `UEFI OS` vers le chemin de repli et une entrée `Arch Linux Limine` distincte. `/boot/limine.conf:12` définit une entrée par défaut et les lignes 14–27 référencent Zen et LTS avec noyau et modules séparés ; aucun UKI actif n’a été observé dans les presets. Le nom `_sha256_` d’une copie historique n’est pas une preuve de signature EFI. Un futur `sbctl verify` vérifierait les fichiers qu’il examine, pas la totalité des dépendances d’une entrée ni un démarrage réel ([sbctl(8)](https://man.archlinux.org/man/sbctl.8.en)). + +Pour la synchronisation, le service `limine-snapper-sync.service` est désactivé/inactif ; ce n’est **pas** une preuve d’absence de synchronisation. Le plugin Snapper installé agit seulement sur le sous-volume `/` et lance la sync de façon asynchrone (`/usr/lib/snapper/plugins/10-limine-snapper-sync:17-18,64-102`). `snapper-cleanup.service.d/limine-snapper-override.conf:4` invoque aussi la sync après cleanup. Le journal des changements local de l’outil indique que l’observateur est optionnel depuis sa version 1.16.0. Les timers cleanup/timeline sont activés ; la configuration Snapper réellement chargée n’a pas été lue. + +La configuration du dépôt et celle lisible sous `/etc/limine-snapper-sync.conf` concordent : racine `@`, snapshots `@/.snapshots`, `RESTORE_METHOD=replace`, `SET_SNAPSHOT_AS_DEFAULT=no` (`rootfs/etc/limine-snapper-sync.conf:110-181`). Pour la version installée, la documentation locale décrit `replace` comme la création d’un nouveau sous-volume depuis le snapshot sélectionné, remplaçant l’ancien sous-volume racine ; l’ID de sous-volume change et la relation avec les anciens snapshots n’est plus suivie comme avec `snapper rollback`. Les montages séparés `@home`, `@log` et `@pkg` ne font pas partie du sous-volume racine `@` observé ; leur contenu ne doit pas être présumé restauré par cette opération. L’effet exact sur ce poste, le sous-volume Btrfs par défaut et le retour à l’état normal restent à éprouver. Le snapshot local ne protège pas de la perte du SSD. + +**Conclusion proportionnée :** AS-001 reste **ouvert** : hook pacman masqué confirmé, post-hook de signature du noyau confirmé, signatures et politique complète non vérifiées. AS-009 reste **ouvert** : voies de synchronisation et entrées de snapshots confirmées, démarrage/restauration actuels non vérifiés. La raison du masquage n’apparaît pas dans les documents actifs ni dans les commits ciblés du dépôt ; elle ne peut être inventée. Aucun hook n’a été réactivé. + +## Compléments ciblés AS-002 à AS-008 + +| ID | Réévaluation au 2026-10-02 | Preuve et suite | +|---|---|---| +| AS-002 | **Confirmé, ouvert.** Le premier démarrage n’est toujours pas une procédure complète. | `docs/reinstall.md:29-67` énumère Limine, Snapper et sbctl sans séquence testée. Ajouter la procédure seulement après décisions sur signature, réseau et disponibilité des copies. | +| AS-003 | **Confirmé, ouvert.** `yay` est installé sur ArchASP mais absent de l’ISO et non amorcé par `deploy.sh`. | `pkglist/aur.txt:12`, `scripts/deploy.sh:171-180`. Le noyau et le premier démarrage relèvent du socle ; l’intégration AUR/Snapper suit. Futur amorçage : outil de construction et dépendances disponibles, source et révision vérifiées, identité de l’utilisateur de construction, résultat installé et reproductible. Aucune construction ici. | +| AS-004 | **Confirmé pour les fichiers ; exécution non vérifiée.** Le dépôt cible `wg0`, `/etc/nftables.conf` cible `wlp1s0` pour DNS, Web, trafic des VM et NAT. `wg-quick@wg0` est en échec. | Comparaison ciblée des deux fichiers ; `systemctl show`. L’un ou l’autre fichier peut changer l’accès du poste et des VM. `nftables.service` inactif n’indique pas le contenu des règles effectives. `sudo -n nft -nn list ruleset` refusé ; politique VPN/flux encore à décider. | +| AS-005 | **Risque conditionnel inchangé.** Script destructif avec confirmation et contrôle des montages, mais sans preuve générale sur tous les usages actifs du disque ou sur une reprise après échec. | `scripts/prepare-disk.sh:15-69`. Renforcement et essais sur disques de test dans un lot ultérieur ; aucun script exécuté ici. | +| AS-006 | **Confirmé, nuancé.** Btrfs/EFI de base conforme. Zram 6 Gio coexiste avec un swapfile 8 Gio, déclaré dans `/etc/fstab`, et un swap de 64 Gio sur périphérique ; `/etc/fstab` mentionne aussi un espace de travail et des swaps avec `nofail`. | `findmnt`, `swapon --show`, `/etc/fstab:18-25` expurgé. Le swapfile est configuré pour persister ; le périphérique est actif mais sa pérennité et son besoin restent à décider. Le nom `/swap-colmap` ne prouve pas un usage temporaire. | +| AS-007 | **Confirmé, à qualifier.** CUPS service/socket/path activés et actifs, cohérent avec une disponibilité après démarrage ; `hplip`, `sane`, `sane-airscan` explicites. nginx activé/actif, configuration locale en boucle locale servant Trainlog ; Avahi service/socket activés/actifs, utilité exacte non établie. VMware/Samba demeurent désactivés/inactifs à la demande ; WireGuard est en échec. | `systemctl list-unit-files`, `list-units`, `pacman -Qi`, `/etc/nginx/nginx.conf:22-37`. Les unités utilisateur et données Trainlog restent hors dépôt. Tester impression, scan et proxy avant de modifier le manifest. | +| AS-008 | **Confirmé.** `backup.sh` exporte listes explicites, inventaires, fichiers système sélectionnés et modèle Limine ; il n’exporte pas les scripts utilisateur. `deploy.sh` tolère certaines sources absentes et peut laisser un état partiel. | `scripts/backup.sh:19-221`, `scripts/deploy.sh:74-99,184-289`. Corriger maintenant seulement la documentation ; revoir le diff et les données sensibles avant toute publication ; scripts et tests isolés dans un lot ultérieur. | + +`pacman -Qqen`/`-Qqem` donnent respectivement 251/17 noms contre 216/12 dans les exports de juillet. `opencode` et `openai-codex-desktop` sont **absents des paquets installés au relevé**, bien qu’encore listés ; `colmap` et plusieurs paquets `-debug` sont présents parmi les étrangers. `hplip`, `sane`, `sane-airscan`, `nginx`, `rclone` et `smartmontools` sont des installations natives explicites récentes à qualifier par fonction, sans import global dans `pkglist/`. Les bases de synchronisation locales sont datées des 1er–2 octobre ; `-Qm`/`-Qn` classent par rapport à ces bases et ne prouvent pas l’origine AUR ou officielle dans tous les cas ([pacman(8)](https://man.archlinux.org/man/pacman.8.en)). + +## Travaux suivants et preuve de fermeture + +1. **Arbitrer les points ouverts de la matrice** : déverrouille une cible de reconstruction explicite. Preuve : décisions datées sur signature, réseau, fonctions du poste, swaps et copies indépendantes. +2. **Rédiger la procédure complète de réinstallation** : déverrouille un parcours depuis le support live jusqu’au premier démarrage, puis au retour des fonctions. Preuve : essai sur installation de test avec critères d’arrêt et de reprise. +3. **Renforcer les scripts et les valider en isolement** : déverrouille une exécution moins fragile des étapes destructives et du déploiement. Preuve : tests de panne, reprises et diff d’export contrôlé, sans disque de production. +4. **Essayer démarrage et restauration de façon contrôlée** : déverrouille une conclusion opérationnelle limitée à la version testée. Preuve : vérification autorisée des signatures, snapshots et règles, démarrage normal et de secours, restauration ciblée et retour normal. diff --git a/docs/backup.md b/docs/backup.md index 9795670..25e9123 100644 --- a/docs/backup.md +++ b/docs/backup.md @@ -15,7 +15,13 @@ Le script exporte : - timers système et utilisateur ; - état Btrfs, zram, mémoire et SSD NVMe ; - configurations système explicitement autorisées ; -- scripts utilisateur suivis par le dépôt. +- un modèle Limine sans la section d’entrées de snapshots générées. + +`backup.sh` ne sauvegarde ni les scripts et unités utilisateur de `~/.dotfiles`, +ni les données, connexions réseau, secrets, clés Secure Boot ou sauvegardes +hors disque. Les inventaires qu’il produit sont des observations datées ; les +manifests demeurent l’intention de services. Une copie du dépôt sur un autre +support, accessible et récupérable, doit être vérifiée séparément. ## Contrôle avant commit @@ -31,3 +37,8 @@ Inspecter particulièrement : - les services qui apparaissent nouvellement activés ; - les modifications de `nftables.conf`, `mkinitcpio.conf` et `pacman.conf` ; - l’absence de secrets. + +Relire également le modèle Limine généré : le script retire la section +automatique et remplace `root=UUID=…`, mais ne démontre pas que tout autre champ +propre à la machine est devenu portable. Ne pas publier un export sans revue +de ses valeurs et de ses fichiers ajoutés. diff --git a/docs/reconstruction-baseline.md b/docs/reconstruction-baseline.md new file mode 100644 index 0000000..88e80e7 --- /dev/null +++ b/docs/reconstruction-baseline.md @@ -0,0 +1,62 @@ +# 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. diff --git a/docs/reinstall.md b/docs/reinstall.md index 2266e4b..50529d6 100644 --- a/docs/reinstall.md +++ b/docs/reinstall.md @@ -1,4 +1,12 @@ -# Réinstallation complète +# Réinstallation — trame partielle + +> **État au 2 octobre 2026 : procédure partielle, non éprouvée sur un SSD +> vierge dans ce lot.** Avant de l’employer, résoudre les décisions et +> dépendances de la [référence de reconstruction](reconstruction-baseline.md), +> vérifier une copie indépendante du dépôt, des dotfiles, des données et des +> moyens de récupération Secure Boot. Les étapes Limine, signature, Snapper et +> restauration des données ci-dessous ne forment pas encore une séquence +> complète validée jusqu’au premier démarrage. ## 1. Préparer le disque @@ -47,6 +55,12 @@ cd arch-system ## 5. Restaurer par étapes +`--packages` requiert `yay` pour la liste AUR, alors que `yay` figure lui-même +dans cette liste : sur une installation neuve, cette partie est reportée. +L’amorçage vérifié de l’outil AUR et le choix des paquets étrangers nécessaires +restent à documenter. Le noyau et le premier démarrage doivent être obtenus +avec le socle disponible avant cette intégration facultative. + ```bash ./scripts/deploy.sh --packages ./scripts/deploy.sh --configs