Skip to content

fix(appliance): neuf défauts remontés d'une VirtualBox, et un accueil qui guide - #309

Merged
stephrobert merged 1 commit into
mainfrom
fix/appliance-0.3.4
Oct 10, 2026
Merged

stephrobert merged 1 commit into
mainfrom
fix/appliance-0.3.4

Conversation

@stephrobert

Copy link
Copy Markdown
Owner

Summary

Tout ce lot vient d'une session d'usage réel sur l'image 0.3.3 publiée le
matin même. Aucun de ces défauts n'a été trouvé en relisant du code, et
plusieurs étaient invisibles depuis une machine de développement — c'est
précisément ce qui les a laissés passer.

Les trois qui rendaient l'appliance inutilisable

Pourquoi personne ne l'avait vu
Le bureau ne pouvait pas s'installer sans virtualisation imbriquée apt-get update vivait dans la branche if [ -e /dev/kvm ], alors que 90-nettoyage.sh retire /var/lib/apt/lists/*. Avec la virtualisation imbriquée, la branche était prise et tout marchait
La session graphique ne pouvait pas s'ouvrir chage -d 0 force le changement de mot de passe ; en console PAM le mène, le greeter LightDM non. Les essais se faisaient en console
dsoxlab hors du PATH d'un terminal du bureau uv installe dans ~/.local/bin, que .profile ajoute au PATH — mais .profile n'est lu que par un shell de login. La recette, elle, utilise bash -lc

Le premier est prouvé par deux VM QEMU démarrées sur l'image publiée,
seule la virtualisation imbriquée changeant entre les deux :

sans /dev/kvm   E: Unable to locate package lightdm        → bureau en échec
avec /dev/kvm   « Virtualisation imbriquée disponible »    → étape normale

Et corrigé puis revérifié sur une image construite ici et démarrée sans
/dev/kvm : « Bureau installé, la machine démarrera dessus. »

Le défaut de fond : rien ne disait pourquoi

dsoxlab : configuration INCOMPLÈTE — bureau — elle recommencera au prochain démarrage.

La cause existait — dans le journal et sur la console série. La fenêtre de
la machine, /dev/tty1, ne recevait que les titres d'étapes. Tout le
diagnostic était dans un endroit que personne ne regarde.

Chaque étape écrit maintenant dans /var/log/dsoxlab/<étape>.log, et un échec
affiche dans la fenêtre :

  ╭─ l'étape « bureau » a échoué (code 100)
  │
  │  Cause probable : l'index des paquets est vide ou périmé.
  │
  │  Ce que dit la commande :
  │      E: Unable to locate package lightdm
  │
  ╰─ trace complète : /var/log/dsoxlab/bureau.log

Six causes reconnues ; un message inconnu ne reçoit aucune cause inventée,
seulement sa sortie brute.

Ce que j'ai cassé en corrigeant, et réparé

TimeoutStartSec=3min était calculé pour trois questions. Avec le mot de
passe et le bureau, le pire cas monte à 240 s : systemd aurait tué l'assistant
en plein dialogue, donc avant son chage -d -1, laissant exactement la
machine inouvrable qu'il est là pour éviter. Passé à 8 min, calcul en
commentaire.

Deux ajouts

dsoxlab tapé seul guide au lieu d'afficher vingt-cinq commandes. L'état
de la machine, les gestes qui correspondent à cet état, puis le parcours
entier d'une machine vide à un lab noté.

Les commandes y sont des données, pas des messages. Le garde-fou i18n les
signalait ; j'ai voulu l'exempter, et mon propre test a montré que
l'exemption laissait passer « dsoxlab could not start the lab »
. Il avait
raison, je l'ai rendu intact et rangé les commandes là où elles doivent être.

L'assistant demande si l'on veut le bureau : 700 Mo, et autant de mémoire
en moins pour les machines de lab.

La documentation dit ce qui ne marche pas

KVM dans VirtualBox se comporte mal — une machine qui brûle un cœur à 100 %
sans allouer sa mémoire, puis un gel, sans que 16 Go et 8 vCPU n'y changent
rien
. La page le dit avant qu'on ne coche la case, donne les deux chemins
solides pour les labs vm, et annonce que le travail est en cours.

L'onglet Processeur est documenté en entier, avec une capture : un import
a laissé 1 vCPU et un Processing Cap à 1 %, auquel cas la machine n'est
pas lente, elle est inutilisable.

Éprouvé

assistant, 9 cas (mot de passe, bureau, /etc/environment, silence)  verts
etape / cause_probable, 4 cas, hors VM                              verts
accueil, 14 cas sur les fonctions de décision                       verts
registre, chaque dépôt confronté à l'API GitHub                     vert
image construite et démarrée SANS /dev/kvm : bureau installé        vert
ruff · mypy · 1305 tests · 18 e2e · actionlint · garde-fou de doc   verts

Type of change

  • Bug fix
  • New feature
  • Refactor
  • Documentation
  • Chore / tooling
  • Security / supply chain

Checklist

Always

  • ruff check src/dsoxlab tests tests_e2e fuzz scripts — propre
  • mypy src/dsoxlab — 88 fichiers, strict
  • pytest — 1305 passed
  • pytest tests_e2e — 18 passed
  • Moteur domain-agnostic — le registre des catalogues est une donnée
    packagée, pas de la logique ; aucun if nom == … ajouté
  • Aucun chemin personnel ni hôte en dur
  • Éprouvé sur deux dépôts, dont terraform-dsoxlab-training sans
    bloc infra: — 91 labs sur 91 fichiers, et 86 sur 86 côté Linux

When behavior changes

  • CHANGELOG.md et CHANGELOG.fr.md — 12 entrées de part et
    d'autre, trois sections identiques
  • Version portée à 0.3.4, uv lock rejoué

When a command or option is added, removed or changed

  • 23 clés ajoutées dans i18n/strings/en.py et fr.py
  • Vérifié sous DSOXLAB_LANG=en et DSOXLAB_LANG=fr
  • Aucune commande renommée ni supprimée : fullhelp reste exact
  • Les messages du journal restent en anglais

When .github/workflows/ is touched

N/A — aucun workflow modifié.

When the declarative contract changes

N/A — le contrat ne change pas.

🤖 Generated with Claude Code

… qui guide

Tout ce lot vient d'une session d'usage réel sur l'image 0.3.3 publiée le
matin même. Aucun de ces défauts n'a été trouvé en relisant du code, et
plusieurs étaient invisibles depuis ma machine de développement.

LES TROIS QUI RENDAIENT L'APPLIANCE INUTILISABLE

1. Le bureau ne pouvait pas s'installer sans virtualisation imbriquée.
   `apt-get update` vivait DANS la branche `if [ -e /dev/kvm ]`, alors que
   `90-nettoyage.sh` retire `/var/lib/apt/lists/*`. Sur une machine qui a la
   virtualisation imbriquée, la branche était prise et tout marchait : voilà
   pourquoi le défaut a survécu à tous mes essais. Sur une VirtualBox sortie
   de la boîte, l'index restait vide et `xfce4` était introuvable. Prouvé par
   deux VM QEMU sur l'image publiée, seule la virtualisation imbriquée
   changeant entre les deux.

2. La session graphique ne pouvait pas s'ouvrir. `chage -d 0 student` force
   le changement de mot de passe ; le greeter de LightDM ne sait pas mener ce
   dialogue. Le choix passe dans l'assistant, en console, avant que LightDM
   existe. Il est PROPOSÉ, pas imposé. Sans réponse, l'expiration est levée
   quand même : une machine dont la session ne s'ouvre pas est pire qu'une
   machine dont le mot de passe est connu — mais l'appliance le dit.

3. `dsoxlab` n'était pas dans le PATH d'un terminal du bureau. `uv` installe
   ses outils dans `~/.local/bin`, que `.profile` ajoute au PATH — mais
   `.profile` n'est lu que par un shell de LOGIN, et un terminal XFCE n'en est
   pas un. L'outil était installé et répondait « command not found » dans la
   seule fenêtre où on allait le taper. Trouvé par l'utilisateur.

LE DÉFAUT DE FOND : RIEN NE DISAIT POURQUOI

« configuration INCOMPLÈTE — bureau — elle recommencera au prochain
démarrage. » La cause existait, dans le journal et sur la console série ; la
fenêtre de la machine ne recevait que les titres d'étapes. Chaque étape écrit
maintenant dans `/var/log/dsoxlab/<étape>.log`, et un échec affiche la cause
NOMMÉE, les lignes d'erreur utiles et le chemin de la trace. Six causes
reconnues ; un message inconnu ne reçoit aucune cause inventée.

LES AUTRES

- l'attente du réseau validait `deb.debian.org` pendant que l'étape suivante
  appelait PyPI, et se contentait d'une résolution sans vérifier qu'une
  connexion passe ;
- `DSOXLAB_LANG` était écrit dans `~/.profile` : même cause que le PATH,
  l'interface restait anglaise malgré le choix de l'assistant. Il va dans
  `/etc/environment`, que PAM lit pour toutes les sessions ;
- le registre annonçait trois catalogues sur six et pointait `terraform` vers
  un dépôt renommé. Chaque entrée est désormais confrontée à l'API GitHub ;
- le message de fin ne disait rien d'actionnable ;
- un catalogue installé par URL restait proposé à l'installation.

CE QUE J'AI CASSÉ EN CORRIGEANT, ET RÉPARÉ

Le `TimeoutStartSec=3min` de l'assistant était calculé pour trois questions.
Avec le mot de passe et le bureau, le pire cas monte à 240 s : systemd
l'aurait tué en plein dialogue, donc avant son `chage -d -1`, laissant
exactement la machine inouvrable qu'il est là pour éviter. Il passe à 8 min,
calcul écrit en commentaire.

DEUX AJOUTS

`dsoxlab` tapé seul affichait l'aide de Typer : vingt-cinq commandes sans
indication du premier geste. Il affiche maintenant l'état de la machine et les
gestes QUI CORRESPONDENT à cet état, puis le parcours entier d'une machine
vide à un lab noté. Les commandes y sont des DONNÉES et non des messages —
le garde-fou i18n les signalait, j'ai voulu l'exempter, mon propre test a
montré que l'exemption laissait passer « dsoxlab could not start the lab ».
Il avait raison : une chaîne en dur dans un affichage est suspecte tant qu'on
n'a pas dit ce qu'elle est.

Et l'assistant demande si l'on veut le bureau : 700 Mo, et autant de mémoire
en moins pour les machines de lab.

LA DOCUMENTATION DIT CE QUI NE MARCHE PAS

KVM dans VirtualBox se comporte mal : une machine qui brûle un cœur sans
allouer sa mémoire, puis un gel, sans que 16 Go et 8 vCPU n'y changent rien.
La page le dit AVANT qu'on ne coche la case, donne les deux chemins solides
pour les labs `vm`, et annonce que le travail est en cours. L'onglet
Processeur est documenté en entier avec une capture — un import a laissé
1 vCPU et un Processing Cap à 1 %, auquel cas la machine n'est pas lente,
elle est inutilisable.

ÉPROUVÉ

  assistant, 9 cas (mot de passe, bureau, /etc/environment, silence)  verts
  etape / cause_probable, 4 cas, hors VM                              verts
  accueil, 14 cas sur les fonctions de décision                       verts
  registre, chaque dépôt confronté à l'API GitHub                     vert
  image construite et démarrée SANS /dev/kvm : bureau installé        vert
  ruff, mypy, 1305 tests, 18 e2e, actionlint, garde-fou de doc        verts

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@stephrobert
stephrobert merged commit a899f2c into main Oct 10, 2026
20 checks passed
@stephrobert
stephrobert deleted the fix/appliance-0.3.4 branch October 10, 2026 10:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant