Ce soir, voulant comprendre quel bug se produit au collège des missions (un de nos clients AbulÉduPRO) je me suis mis en tête de re-créer un TX à distance ... ce qui semble tout simplement impossible. Attention c'est un article assez technique et comme je n'ai pas trouvé d'informations à ce sujet sur l'internet je me suis dit que c'était important de laisser une trace de toutes ces réflexions et recherches !

L'idée est de pouvoir créer un comportement identique à celui d'un TX qui démarre sur un serveur AbulÉdu, à savoir:

• requête PXE/DHCP;
• téléchargement d'un noyau linux;
• lancement du noyau;
• vérification du comportement des scripts de lancement pour avoir le tant attendu message "/tmp/info/XDM_SERVER no such file or directory"

Le problème est que je ne suis pas sur le réseau local du client:

(RyXéo)   ==== (internet) ==== (eth1) : (Serveur du Client) : (eth0) ==== (reseau local) ==== (tx)

Voici donc les ruses que j'ai utilisé pour arriver à faire ce que je veux:

• lancer qemu sur le serveur via ma connexion SSH (-X pour expoter X et -C pour compresser):

ssh login@serveur.du.client -X -C

• créer une image qemu (10Mo)

qemu-img create pxe.qemu 10Mo

• télécharger la bootrom de la carte RTL8029 que qemu émule si bien en format ISO parceque qemu sait bien booter sur des cdroms stockés sous forme "d'images iso" (tout est sur une ligne et les "\" de fin de ligne sont pour indiquer que la ligne continue en dessous)

wget "http://www.rom-o-matic.net/5.4.2/build.php?version=5.4.2&F=&arch=\
i386&nic=ns8390%3Artl8029+--+%5B0x10ec%2C0x8029%5D&ofmt=ISO+\
bootable+image+without+legacy+floppy+emulation+%28.iso%29&A=Get+\
ROM" -O rtl8029.iso

• lancer qemu sur l'image iso qui elle même lancera la requête d'amorçage réseau:

sudo qemu -hda pxe.qemu -cdrom rtl8029.iso -boot d -net tap -net nic,macaddr=52:54:00:12:34:56

Et là on se heurte à un problème quasi insoluble: le lancement de qemu avec l'option "net tap" nous créé une interface "tap0" (côté serveur) qui comporte une ip 172.20.0.1 ... et cette plage d'ip là n'est pas sur 192.168.0.x d'abuledu et donc même si on fait des requêtes DHCP ça "coince" :(

Il faudrait que je prenne le temps de détailler le fonctionnement de qemu, il prendra deux IP, l'une pour l'adresse "externe" de la machine virtuelle et l'autre pour l'adresse "interne" bref un chouilla compliqué :)

Nouvelle ruse: et si je modifie /etc/qemu-ifup pour qu'il prenne l'ip 192.168.0.1 ça a une chance de marcher.

#!/bin/sh
sudo -p "Password for $0:" /sbin/ifconfig $1 192.168.0.1

Problèmes multiples:

• c'est l'ip d'eth0 du serveur abuledu et "il n'est pas possible d'avoir deux interfaces qui ont une même ip" (je schématise, et mise à jour suite à un échange de mails sur la liste tech de l'abul et une remarque de michel billaud, c'est possible de faire ce que je veux avec un bridge, donc promis la prochaine fois je teste ça);
• tap0 n'est disponible que lorsque qemu est vraiment lancé;

Ruse suivante:

• ifconfig eth0 down;
• lancer qemu;
• une fois qemu lancé, tap0 est "up" et avec l'adresse ip qui est normalement prise par eth0, je peux donc relancer le serveur dhcp, dns, nfs (etc) ils vont s'accrocher sur tap0 à la place d'eth0 et donc la requête DHCP qui est "dans le qemu" sera servie comme il faut ... waaa;
• modifier le fichier DHCP pour qu'à la mac adresse du qemu corresponde un "vrai TX" du collège;

Et voilà, j'ai un TX qui boote dans qemu ! J'ai réussi ma mission qui était de valider le démarrage d'un TX à distance, sans TX et ... je n'ai pas le bug que je voulais avoir !

Allez, en bonus j'ai même la vidéo du hold-up au format OGG grâce à istanbul!