Lab : fournir l'image Rocky 10 des VM de test #53

New issue

Open

opened 2026-10-04 19:35:27 +00:00 by nicolas.boufideline · 0 comments

nicolas.boufideline commented

2026-10-04 19:35:27 +00:00

Owner

Constat

Le lab de #50 lance ses VM de test avec une Debian genericcloud modifiée sur place (source de
métadonnées NoCloud ajoutée, cf. image-qcow2.rst), faute de pouvoir utiliser l'image Rocky 10
de l'équipe, compatible avec le serveur de métadonnées de two : publiée dans le registre de paquets
Forgejo, son téléchargement depuis le serveur de lab (Scaleway, fr-par) prenait plus d'une heure
— hors de proportion avec une session facturée à l'heure, montée et démontée à chaque campagne.

Conséquence : les scénarios du lab (E5) qualifient two avec une image qui n'est pas celle utilisée
réellement.

Objectif

Une voie pour fournir l'image Rocky 10 au lab, vérifiée (somme de contrôle, comme les autres
images), en quelques minutes au plus depuis le serveur de lab.

Pistes

Héberger l'image au plus près du lab (stockage objet dans la même région que le serveur).
Réduire sa taille (compression qcow2, image allégée).
La construire dans le lab à partir de l'image Rocky du fournisseur, en suivant image-qcow2.rst —
au prix du temps de construction à chaque session, mais sans transfert.
Mettre en cache sur le serveur de lab : sans intérêt tant que le serveur est détruit à chaque
session.

Ensuite, côté lab

Une entrée images de la topologie pointant sur l'image Rocky et sa somme de contrôle — le
Fetcher de lab vérifie déjà SHA512SUMS.
Les scénarios utilisent cette image pour les VM de test au lieu de la Debian modifiée.

Analyse de risque

L'image est publique si elle reste hors authentification : elle ne doit contenir ni mot de passe,
ni clé, ni configuration interne (vérifié le 2026-10-04 : construite selon image-qcow2.rst,
faite pour être utilisée).
Une image hébergée hors de Forgejo doit rester vérifiée par une somme publiée depuis une source
de confiance.

Lié : #50.

## Constat Le lab de #50 lance ses VM de test avec une **Debian `genericcloud`** modifiée sur place (source de métadonnées NoCloud ajoutée, cf. `image-qcow2.rst`), faute de pouvoir utiliser l'image **Rocky 10** de l'équipe, compatible avec le serveur de métadonnées de two : publiée dans le registre de paquets Forgejo, son téléchargement depuis le serveur de lab (Scaleway, fr-par) prenait **plus d'une heure** — hors de proportion avec une session facturée à l'heure, montée et démontée à chaque campagne. Conséquence : les scénarios du lab (E5) qualifient two avec une image qui n'est pas celle utilisée réellement. ## Objectif Une voie pour fournir l'image Rocky 10 au lab, **vérifiée** (somme de contrôle, comme les autres images), en quelques minutes au plus depuis le serveur de lab. ## Pistes - Héberger l'image au plus près du lab (stockage objet dans la même région que le serveur). - Réduire sa taille (compression qcow2, image allégée). - La construire dans le lab à partir de l'image Rocky du fournisseur, en suivant `image-qcow2.rst` — au prix du temps de construction à chaque session, mais sans transfert. - Mettre en cache sur le serveur de lab : sans intérêt tant que le serveur est détruit à chaque session. ## Ensuite, côté lab - Une entrée `images` de la topologie pointant sur l'image Rocky et sa somme de contrôle — le `Fetcher` de `lab` vérifie déjà `SHA512SUMS`. - Les scénarios utilisent cette image pour les VM de test au lieu de la Debian modifiée. ## Analyse de risque - L'image est publique si elle reste hors authentification : elle ne doit contenir ni mot de passe, ni clé, ni configuration interne (vérifié le 2026-10-04 : construite selon `image-qcow2.rst`, faite pour être utilisée). - Une image hébergée hors de Forgejo doit rester vérifiée par une somme publiée depuis une source de confiance. Lié : #50.

nicolas.boufideline added this to the 0.2.0 milestone

2026-10-04 19:35:27 +00:00

nicolas.boufideline added the

bug fix

label

2026-10-04 19:35:27 +00:00

nicolas.boufideline referenced this issue

2026-10-04 19:54:35 +00:00

Lab virtuel multi-nœud : hyperviseurs en KVM imbriqué, route reflectors et switchs L3 en VM #50