Le parcours média de bout en bout

En mode miroir, un transfert est un répertoire. Tobby synchronise le contenu demandé par une zone dans un store autonome, le store voyage sur un média amovible à travers l’air gap, et une instance Tobby côté zone isolée le vérifie puis le pousse dans la registry de zone. Déplacer le répertoire, c’est le transfert — il n’y a aucune étape d’empaquetage ou de dépaquetage propriétaire.

Cette page est la carte. Le détail opérationnel vit sur trois pages à côté d’elle : préparer le poste source, importer côté zone isolée et gérer les supports dans la durée. La conception derrière tout cela, c’est ADR-0006 et ADR-0016, SRS FR-050 à FR-056.

Deux instances, un répertoire

La même application tourne des deux côtés.

• L’instance source tourne en mode miroir sur un poste connecté. Elle résout le Retriever de la zone, télécharge et vérifie le contenu, et l’écrit dans un store transportable : les artefacts, les recipes signées qui les justifient, les journaux d’opération et un manifeste de média, réunis dans un seul répertoire relogeable.
• L’instance de destination tourne dans la zone isolée. Pointée sur le répertoire transporté, elle re-vérifie tout depuis zéro et pousse le contenu de façon différentielle vers la registry de zone. Ses propres journaux d’opération sont écrits en retour sur le média : le média est aussi le canal d’audit au retour.

Rien d’autre ne traverse. Le matériel de confiance ne voyage jamais avec le contenu — les trust roots configurées côté destination sont la seule autorité (voir le modèle de sécurité du média).

Les cinq étapes

Les noms des étapes sont stables : procédures, écrans et messages d’erreur les emploient de façon cohérente — une procédure de site écrite avec ces noms n’aura pas à être renommée plus tard.

#	Étape	Ce qui se passe	Qui agit
1	Préparer	Le poste source est configuré : mode miroir, Retriever de la zone, trust roots, liste blanche de registries.	admin
2	Pré-vol	Tobby calcule ce qui voyagerait et refuse les transferts impossibles avant qu’ils ne commencent.	operator
3	Exporter	Une synchronisation déclenchée manuellement remplit le store transportable ; le manifeste de média est écrit en dernier.	operator
4	Transporter	Le média traverse physiquement le sas, via les contrôles de gestion des supports du site.	procédure média du site (hors Tobby)
5	Importer	L’instance de destination vérifie le média, puis pousse le contenu vérifié vers la registry de zone.	operator (admin pour les deux dérogations auditées)

1 — Préparer

Une instance sert exactement une zone, dans exactement un mode, choisi au démarrage. Préparer le poste source, c’est installer Tobby, sélectionner le mode miroir, et configurer le Retriever de la zone, les trust roots et la liste blanche de registries. Les secrets (credentials de registry, clés TLS) vivent dans le répertoire d’état du poste — jamais dans le store transportable.

Checklist :

• Le poste est installé selon la procédure d’installation hors-ligne de votre site.
• L’instance tourne en mode miroir et nomme le Retriever de la zone de destination.
• Les trust roots et la liste blanche de registries correspondent à la politique de la zone.
• Aucun fichier de secret ne réside sous le chemin du store transportable.
• Le média est formaté avec un système de fichiers adapté (pas de FAT32) et, si votre site l’exige, chiffré au niveau de l’OS (LUKS, BitLocker).

Détail complet : préparer le poste source.

2 — Pré-vol

Avant toute écriture, Tobby calcule le volume à transférer — par recipe, dédupliqué par digest, net de ce que la cible détient déjà — et le compare à l’espace libre du média. Il refuse de démarrer quand la projection ne tient pas (en énonçant les octets manquants) et refuse les systèmes de fichiers qui ne peuvent pas contenir la charge, comme FAT32 et sa limite de 4 Gio par fichier.

Checklist :

• Le volume projeté, par recipe et total, a été relu.
• L’espace libre du média dépasse la projection plus la marge de sécurité.
• Le système de fichiers du média a été accepté par le pré-vol.
• Les refus éventuels ont été résolus par un prune ou un média plus grand — pas en sautant le contrôle (il n’y a pas de contournement).

Un système de fichiers dont ce build ne connaît aucun plafond est rapporté comme non identifié plutôt que comme capable : c’est un avertissement, pas un refus. Le contrôle complet, ses deux refus et le dry-run scriptable qui l’accompagne sont sur préparer le poste source.

3 — Exporter

L’opérateur déclenche la synchronisation manuellement — depuis l’interface ou l’API, jamais sur un planning : en mode miroir, la préparation d’un média est toujours un acte humain supervisé. Tobby télécharge ce qui manque, vérifie signatures et digests à l’entrée, écrit tout dans le store sur le média, et termine par l’écriture du manifeste de média : l’inventaire, les recipes couvertes, l’identité de zone, le run ID et la version du format de store.

Checklist :

• La synchronisation s’est terminée sans recipe bloquée, ou chaque recipe bloquée est comprise et son absence acceptée.
• Le manifeste de média a été écrit (c’est toujours la dernière écriture).
• Le run ID de la synchronisation est reporté dans votre dossier de transfert.
• Le média a été démonté proprement.

Le manifeste est écrit après tout prune — c’est pour cela qu’il est la dernière écriture et pas simplement une écriture tardive. Voir préparer le poste source.

4 — Transporter

Tobby est volontairement absent de cette étape. Le média suit la procédure de gestion des supports de votre site : chaîne de responsabilité, station de décontamination ou d’inspection, enregistrement. La charge est conçue pour survivre à l’inspection — fichiers ordinaires, checksums vérifiables, aucune particularité exotique de système de fichiers — et pour être entièrement re-vérifiée après, si bien que la station n’a pas besoin d’être de confiance pour l’intégrité.

Checklist :

• La chaîne de responsabilité est documentée de l’export à l’import.
• Le média a passé la station de décontamination ou d’inspection du site.
• Le média est remis à l’opérateur de la zone isolée avec son dossier de transfert (zone, date, run ID).

Cette étape est purement organisationnelle : vous pouvez l’écrire et la répéter dès aujourd’hui.

5 — Importer

L’instance de destination traite le média comme non fiable jusqu’à preuve du contraire. La vérification précède tout push, tout service, toute écriture locale : complétude et checksums du manifeste d’abord, puis signatures des recipes contre les trust roots propres à la destination, puis chaque digest d’ingrédient. Les recipes qui vérifient sont poussées de façon différentielle vers la registry de zone ; tout le reste est bloqué et nommé. Les journaux de la destination sont écrits en retour sur le média.

Checklist :

• L’identité de zone du média correspond à la zone de cette instance.
• Les verdicts de vérification ont été relus par étape et par recipe.
• Les recipes bloquées, s’il y en a, sont listées dans le rapport et traitées selon votre procédure de site. Deux refus seulement peuvent être levés, par un administrateur et avec consignation à l’audit : un support adressé à une autre zone, et un support plus ancien que le dernier importé ici. Les échecs d’intégrité et de signature n’admettent aucune dérogation, pour personne.
• Le push est terminé ; le média de retour porte les journaux de la destination.

L’écran Média

Tout ce qui précède a un écran : Média, dans la navigation principale, des deux côtés du transfert. À la source, c’est la liste de colisage — à quelle zone le support est adressé, quand il a été résolu, ce qu’il livre, ce qu’il pèse — à lire avant de démonter le disque. À la destination, il ouvre l’enchaînement guidé :

1. Vérifier. Relit et recalcule l’empreinte de chaque fichier couvert, puis vérifie la signature de chaque recipe contre les trust roots de cette instance. Sur un disque plein cela prend plusieurs minutes : la vérification tourne en arrière-plan avec une progression en direct, vous pouvez quitter la page et y revenir.
2. Rapport. Les trois étapes nommées séparément — complétude et sommes du manifeste, empreintes des ingrédients, signatures des recipes — et un verdict par livraison. Une livraison bloquée nomme le fichier fautif, ce qui fait la différence entre « recopier le disque » et « appeler la zone source ». Le rapport brut se télécharge en JSON.
3. Pousser. Le bouton n’existe pas tant qu’un verdict n’a pas validé au moins une livraison. Pas grisé : absent.

Un désaccord de zone et un support plus ancien que le dernier importé ici sont les deux seuls refus qu’un administrateur peut lever, depuis l’étape Vérifier, avec consignation au journal d’audit. Les verdicts d’intégrité et de signature n’admettent aucune dérogation, pour personne. Pas à pas : importer côté zone isolée.

Un support non vérifié ne sert rien

Une instance de destination démarrée sur un store transporté n’en sert pas le contenu tant que la vérification ne l’a pas validé — le « tout service » de la règle ci-dessus, appliqué et pas seulement écrit. /v2/ et /files/ répondent 403 avec TBY-MED-030 et la marche à suivre ; l’interface, l’API et les sondes restent disponibles, puisque ce sont elles qu’il faut pour vérifier. L’instance est vivante et prête : /readyz répond 200 et indique dans son corps quelles surfaces sont fermées.

Le verrou s’ouvre sur un support intact et sur rien d’autre. Un support partiellement endommagé livre quand même ses recipes intactes dans la registry de zone — c’est tout l’intérêt de porter plusieurs livraisons sur un disque — mais cette instance ne servira pas depuis le disque, parce que /v2/ distribue des blobs et qu’un blob atteint par une recipe bloquée est exactement le contenu qui a échoué. Aucun réglage ne permet de servir un support non vérifié ; le verdict n’est pas non plus conservé d’un redémarrage à l’autre.

Une instance miroir côté source n’est pas concernée : son store porte un manifeste de média parce qu’elle en a écrit un, et elle sert normalement. Les deux côtés se distinguent par l’identité de zone, que seule une instance de destination configure.

Après l’import

La registry de zone sert désormais le contenu. Y raccorder les clusters et les hôtes de la zone fonctionne exactement comme en mode passthrough — voir Brancher vos clients.

Les supports qui repartent pour un cycle de plus — identité, fraîcheur, prune, dimensionnement et remise à zéro — sont sur gérer les supports dans la durée.