docs : la migration du poste d'intégration #1

Merged
foXaCe merged 5 commits from docs/migration-poste into main 2026-10-17 16:24:45 +02:00
Collaborator

Ce que fait cette branche

Le guide de migration du poste d'intégration : le PC porte les trois exécutants Forgejo et la source du
miroir, et rien de tout cela ne se reconstitue tout seul.

Le document dit :

  • l'inventaire — chemins, comptes, unités, disque, clés — et ce qui ne bouge pas (Forgejo, le 108,
    pve-control, le nœud Proxmox) ;
  • avant de débrancher : arrêter le minuteur puis les exécutants dans l'ordre, emporter
    l'enregistrement (/home/atelier/.config/forgejo-runner, c'est le fichier .runner qui porte le droit de
    se présenter à la forge), les chaînes Rust si on ne veut pas les réinstaller, les versions qui font passer
    la CI ;
  • sur le nouveau poste : identité réseau reprise telle quelle, comptes (atelier avec
    /home/atelier), paquets, outillage Rust, binaire de l'exécutant, disque, activation, et la procédure de
    ré-enregistrement si le .runner est perdu ;
  • les vérifications du jour de la bascule, dont une PR d'essai qui doit passer ses quatre étapes ;
  • les pièges, tous constatés : /home/atelier écrit en dur, loginctl enable-linger,
    ProtectHome=tmpfs, jq devenu dépendance de la livraison, Playwright et son Chromium, le dossier de
    captures, et le shellcheck resté dans /tmp qui faisait sauter le pas de style de la CI en silence.

Aucun secret : les jetons et les clés privées restent sur les machines, le guide ne cite que des noms de
fichiers et des chemins.

## Ce que fait cette branche Le guide de **migration du poste d'intégration** : le PC porte les trois exécutants Forgejo et la source du miroir, et rien de tout cela ne se reconstitue tout seul. Le document dit : - **l'inventaire** — chemins, comptes, unités, disque, clés — et ce qui ne bouge pas (Forgejo, le 108, pve-control, le nœud Proxmox) ; - **avant de débrancher** : arrêter le minuteur puis les exécutants dans l'ordre, emporter l'enregistrement (`/home/atelier/.config/forgejo-runner`, c'est le fichier `.runner` qui porte le droit de se présenter à la forge), les chaînes Rust si on ne veut pas les réinstaller, les versions qui font passer la CI ; - **sur le nouveau poste** : identité réseau reprise telle quelle, comptes (`atelier` **avec** `/home/atelier`), paquets, outillage Rust, binaire de l'exécutant, disque, activation, et la procédure de ré-enregistrement si le `.runner` est perdu ; - **les vérifications du jour de la bascule**, dont une PR d'essai qui doit passer ses quatre étapes ; - **les pièges**, tous constatés : `/home/atelier` écrit en dur, `loginctl enable-linger`, `ProtectHome=tmpfs`, `jq` devenu dépendance de la livraison, Playwright et son Chromium, le dossier de captures, et le `shellcheck` resté dans `/tmp` qui faisait sauter le pas de style de la CI en silence. Aucun secret : les jetons et les clés privées restent sur les machines, le guide ne cite que des noms de fichiers et des chemins.
Le PC n'est pas qu'un poste de travail : il porte les trois exécutants Forgejo
et la source du miroir. Le jour où il déménage, il faut savoir quoi emporter,
dans quel ordre, et ce qui ne se voit qu'après avoir débranché l'ancien.

Le guide couvre l'inventaire (chemins, comptes, unités), ce qu'il faut faire
avant de débrancher, l'installation sur le nouveau poste, les vérifications du
jour de la bascule, et les pièges — `/home/atelier` écrit en dur, le `linger`
du minuteur, `ProtectHome=tmpfs`, `jq` devenu dépendance de la livraison, le
`shellcheck` resté dans `/tmp` qui faisait sauter le pas de style en silence.

Identité réseau reprise telle quelle (même nom, même adresse) : aucune
référence à corriger dans les dépôts ni dans la forge.
Le guide disait quoi faire ; il le fait maintenant. Deux scripts, relisibles
avant d'être engagés (`--a-blanc`), et idempotents :

- `poste-migration-preparer.sh` — arrête le minuteur puis les exécutants, emporte
  l'enregistrement (le fichier `.runner`, sans lequel il faut ré-enregistrer),
  l'outillage Rust et le côté opérateur, n'emporte ni les espaces de travail ni
  `/tmp`, écrit l'inventaire (versions, comptes, UUID, linger, unités) et vérifie
  chaque archive.
- `poste-migration-restaurer.sh` — restaure, recharge systemd, active les trois
  exécutants, pose la clé au bon propriétaire, active `linger` et le minuteur,
  puis **vérifie** : nom, adresse, comptes, outils, exécutants actifs, disque par
  son UUID, forge joignable, service du 108, dossier des captures.

Éprouvés en `--a-blanc` sur le poste réel : le préparateur énumère ce qu'il
ferait, le vérificateur ne trouve qu'une seule lacune — `shellcheck`, qui manque
vraiment, et qui faisait sauter le pas de style de la CI en silence.

La sauvegarde de configs du homelab suivait encore `/opt/mirror-status` (le
serveur Python retiré le 17/10/2026) : elle suit maintenant `pcmirror-serveur`
— l'unité, la documentation posée et le commit livré.

Trois défauts de mes propres scripts trouvés en les essayant : `tar` échouait sur
les unités qui n'existent pas ici (la cible « pc » n'a jamais été posée), le
contrôle du dossier de captures criait « manque » faute de root, et une boucle à
un seul tour que shellcheck a raison de refuser.
Le préparateur n'avait qu'une allure : tout préparer *et* tout arrêter. Or l'arrêt
coupe l'intégration continue jusqu'à ce que le nouveau poste soit en ligne — ce
n'est pas un geste à faire des jours avant.

`--sans-arret` sépare les deux : il emporte l'enregistrement des exécutants,
l'outillage et le côté opérateur, écrit l'inventaire et vérifie ses archives, sans
rien arrêter. Sans risque : un exécutant n'écrit plus son enregistrement une fois
posé.

Le guide dit maintenant quand choisir l'un ou l'autre.
Deux manques révélés en préparant le déménagement.

**Les archives vivaient sur le disque qu'elles protègent.** `/root/migration-poste` est sur `/`, donc sur
le disque qu'on déplace : si celui-ci meurt, l'archive meurt avec lui. Le guide dit maintenant de les
copier sur le 108, qui reste debout et ne déménage pas.

**Le cas du disque entier n'était pas prévu.** Ce PC n'a qu'un disque : `/`, `/boot`, `/var/tmp` et
`/mnt/Media` sont dessus. Le sortir emporte tout le système — exécutants, outillage, comptes, minuteur —
et la migration se réduit à débrancher, rebrancher, démarrer ; les archives ne sont plus le chemin, juste
le filet. Le guide dit ce qu'il faut savoir avant de tirer : éteindre proprement (btrfs et ext4), ne
jamais faire tourner les deux PC ensemble (même nom, même adresse), réserver l'adresse pour la nouvelle
carte réseau (le bail est lié à la MAC), garder Secure Boot dans le même état, et laisser Proxmox debout.

Mesures faites sur le poste : adresse en DHCP liée à la MAC, aucun chiffrement de disque, Secure Boot à
vérifier au BIOS.
Deux précisions tirées du poste réel.

**L'adresse ne suit pas le disque.** `192.168.1.183` est un bail DHCP lié à l'adresse MAC de la carte —
et la MAC vit dans la carte mère, qui reste dans l'ancien PC. Le profil NetworkManager, lui, n'est lié ni
à une interface ni à une MAC : il se lèvera sur la carte du nouveau, y compris un adaptateur USB. Une
autre adresse ne gêne pas la chaîne, qui ne fait que sortir ; pour garder la même, le guide donne la
commande qui emprunte la MAC de l'ancienne carte.

**Les scripts sont posés sur le disque** (`/mnt/Media/Linux/homelab`) : ils voyagent avec lui, donc ils
sont là-bas aussi — et la vérification, qui se fait sur le nouveau poste, n'a pas besoin de la forge.
foXaCe merged commit 95f9c64608 into main 2026-10-17 16:24:45 +02:00
Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
foXaCe/homelab!1
No description provided.