NetBSD sans disque (ou La magie des lutins qui courent très vite dans les fils)

GNU/Linux Magazine HS n° 030 | mai 2007 | Emile (iMil) Heitor
Creative Commons
  • Actuellement 0 sur 5 étoiles
0
Merci d'avoir participé !
Vous avez déjà noté cette page, vous ne pouvez la noter qu'une fois !
Votre note a été changée, merci de votre participation !
(chapô) MAIS QU'EST-CE QUE TU FAIS !! Inconsciente que tu es, je sais bien que ce portable est vieux, qu'il n'a que 64 Megs de RAM (oui, c'est une constante chez moi), que sa Cirrus Logic ne doit pas être équipée de plus d'1 Meg... JE SAIS qu'il n'a pas de disque dur, mais regarde, là, sur le côté, une prise de la vie, le connecteur merveilleux : un rj45. Tu jettes pas cette box.

Des années de frustration

Ami lecteur, tu es comme moi, tu as dans ta cave, tes armoires, ton sous-sol ou autre endroit propice à stocker « des trucs qui vont servir un jour, j’te jure », un stock hallucinant de vieux matériel informatique. Et depuis bien des années, d’abord ta mère, puis maintenant ta femme et peut être tes enfants ricanent devant ton entêtement à vouloir garder ces reliques d’un ancien temps qui n’ont même pas de cartes 3d – *ricane* *ricane* fait ta petite famille –. Ami lecteur, l’heure de la vengeance a sonné. Bientôt, les moqueurs d’hier vont se transformer en adorateurs d’aujourd’hui, car grâce à toi, têtu mais conquérant, ton petit monde ne va plus rater une seconde de Derrick : de la salle de bains à la penderie, il y aura un browser, un lecteur de médias et, finalement, à peu près tout ce qu’ils veulent à part KillKill3d – Murder Edition.

Moins conflictuel, un autre scénario se prête parfaitement à notre expérience. Vous êtes jeune, vous êtes dans le coup, vous avez sans doute déjà manipulé des environnements de virtualisation. Et quel est l’élément le moins portable et le plus contraignant dans un environnement virtualisé ? Le disque. Cet article propose une solution intermédiaire, portable et radicale : pas de disque. Vous pourrez, sans le moindre souci, tester votre environnement virtualisé sous Xen, Qemu, VirtualBox, Parallels (sale) ou encore VMware (très sale) sans vous demander si qemu-img réalisera bien la conversion.

On vous le dit : IP, c’est la vie.

Une dernière note d’introduction. Le serveur utilisé pour cet article est une machine ayant les caractéristiques suivantes :

- AMD Sempron 2800+ ;

- 1Go de RAM ;

- Disque ATA classique de 80Go.

Plan de bataille

Vous le savez certainement, la plupart de nos machines, depuis 1999, sont capables de booter grâce à une méthode maintenant largement répandue, le boot PXE. Il est assez probable que vos machines à recycler soient capables de réaliser ce qui est également appelé un « Netboot » ou encore « LAN boot » dans certains BIOS. Si ce n’est pas le cas, ne passez pas encore à l’article suivant, nous verrons comme il est aisé de réaliser cette opération à l’aide d’un autre projet libre. Même constat concernant l’approche virtuelle.

Voici donc notre cible :

- faire démarrer notre vieille machine sur le réseau grâce à un Netboot ;

- faire charger à notre machine un noyau sur le réseau grâce à un serveur TFTP ou NFS ;

- monter les partitions usuelles et les utiliser comme un disque local ;

- boire.

Pour mener ces opérations à bien, nous aurons besoin :

- d’un serveur DHCP ;

- d’un serveur TFTP ;

- d’un serveur NFS ;

- des « sets » NetBSD ;

- d’une bouteille de Gin.

Et pour vous montrer que, non, GCU n’est pas un groupuscule extrémiste obtus (la négation s’applique au mot « obtus »), nos divers serveurs seront configurés et démarrés sur une machine munie d’une Debian GNU/Linux. OOooOOOooooOOoooh ! Bon ok, la démarche est strictement identique avec un BSD moderne.

Formez les bataillons

Ami lecteur, je te l’ai déjà dit, tu es comme moi, tu aimes voir des choses, nous allons donc tester chaque étape de notre périple plutôt que nous contenter d’un test final qui, de toutes façons, foirerait lamentablement et te ferait troubleshooter chaque étape de cet article.

Étape I, installation des outils

Afin de réaliser notre premier boot, nous allons installer nos trois serveurs :

# apt-get install dhcp3-server tftpd nfs-kernel-server netkit-inetd

Note

Sous NetBSD, FreeBSD et OpenBSD, ces outils sont disponibles dans le basesystem. Il suffit donc de les configurer et d’explicitement demander leur exécution dans /etc/rc.conf.

Étape II, configuration basique

Préparons tout d’abord le confortable foyer du futur client. Sur le serveur, exécutons les commandes suivantes :

# mkdir -p /home/netbsd/root/dev

# mkdir /home/netbsd/root/swap

# mkdir /home/netbsd/home

# mkdir /home/netbsd/usr

Créons dans la foulée le device console :

# mknod /home/netbsd/root/dev/console c 0 0

Éditons les quelques fichiers de configuration nécessaires :

/etc/inetd.conf

Le serveur TFTP est démarré par Inetd, le SuperServeur :

# /tftpboot sera le root directory du serveur TFTP

tftp    dgram   udp     wait    nobody /usr/sbin/tcpd /usr/sbin/in.tftpd /tftpboot

/etc/dhcp3/dhcpd.conf

ddns-update-style interim; # on sous-traite le Dynamic DNS chez ManPower

ignore client-updates; # ça va pas être possible avec vos baskets monsieur

# on traite les ips du subnet 192.168.201.0/24

subnet 192.168.201.0 netmask 255.255.255.0 {

        # on possède un DNS à cette adresse

        option domain-name-servers 192.168.201.254;

        # ainsi qu'une passerelle

        option routers 192.168.201.254;

        # déclaration de la machine à faire démarrer en réseau

        host pxehost {

                # qui sera identifiée par son adresse MAC

                hardware ethernet 00:0e:32:e4:80:23;

# on attribue à cette machine une IP fixe sur le range défini plus haut

                fixed-address 192.168.201.100;

  

                # l'âme du PXE boot est ici, l'emplacement de ce fichier est relatif au root du serveur TFTP

                filename "pxeboot_ia32.bin";

# l'IP du "prochain" serveur, comprendre TFTP ou NFS

                next-server 192.168.201.10;

                # le PATH vers le futur filesystem

                option root-path "/home/netbsd/root";

}

}

/etc/exports, liste des exports NFS

/home/netbsd/root pxehost(rw,no_root_squash)

/home/netbsd/swap pxehost(rw,no_root_squash)

/home/netbsd/usr pxehost(rw,no_root_squash)

/home/netbsd/home pxehost(rw,no_root_squash)

/etc/hosts, on y ajoute la correspondance entre le host et l’IP du client :

192.168.201.100    pxehost

Si vous avez suivi le GLMF Hors-série spécial BSD Acte I, la partie DHCP devrait vous rappeler quelque chose.

Nous devrions maintenant être en mesure de démarrer/redémarrer nos divers serveurs :

# /etc/init.d/inetd restart

# /etc/init.d/dhcp3-server restart

# /etc/init.d/nfs-kernel-server restart

Afin de s’assurer que notre serveur NFS est bien présent et exporte effectivement le futur filesystem de notre NetBSD diskless, exécutez :

showmount -e

Et vous devriez observer une sortie de type :

/home/netbsd/usr pxehost

/home/netbsd/home pxehost

/home/netbsd/swap pxehost

/home/netbsd/root pxehost

Notre système hôte dispose maintenant de l’outillage adéquat. Nous allons donc le peupler petit à petit. Et tout d’abord, permettons-lui de démarrer. Pour cela, nous avons besoin :

- d’un bootcode PXE

- d’un noyau

Pour obtenir ces deux fichiers, nous allons télécharger les sets kern et base :

# mkdir /home/netbsd/pkg

# cd /home/netbsd/pkg

# wget ftp://ftp.fr.netbsd.org/pub/NetBSD-daily/netbsd-4/200703090002Z/i386/binary/sets/kern-GENERIC.tgz

# wget ftp://ftp.fr.netbsd.org/pub/NetBSD-daily/netbsd-4/200703090002Z/i386/binary/sets/base.tgz

# # oui, on va monter du 4BETA, et quoi, ON A DU POIL OU BIEN ?!@#

Extraire les fichiers utiles :

# tar zxvfp ./kern-GENERIC.tgz

# tar -zf ./base.tgz -x ./usr/mdec/pxeboot_ia32.bin

Puis les copier au bon endroit :

# cp ./usr/mdec/pxeboot_ia32.bin /tftpboot

# cp netbsd /tftpboot

# cp netbsd /home/netbsd/root

« Ah tiens, y’a une typo ! ». Non, y’a pas de typo. Nous copions volontairement le noyau dans le root du serveur TFTP ET dans le root du futur filesystem, car, comme chez nous on aime bien avoir le choix, on pourra charger notre noyau via NFS ou TFTP. C’est gratos, c’est pour moi.

Everything is not proceeding as I had foreseen

Que nous voilà pleins d’émotion, nous allons faire démarrer notre brouette, éteinte depuis des années, probablement amputée de son disque à l’incroyable capacité de 10Go, fièrement munie de ses 64Megas Octets de RAM EDO qui vous avaient probablement coûté un bras à l’époque. Alors que le ventilateur crache quelques kilos de poussière, vous vous ruez sur le BIOS – non sans avoir lutté pour trouver un clavier AT –, et vous êtes pris de panique : pas l’ombre d’un menu « LAN », « PXE » ou encore « Netboot ». Rien. C’est en rouvrant la bête que vous vous souvenez que les trames Ethernet sont acheminées dans cette machine par... une NE2000 (PCI, s’il vous plaît).

Essuie tes larmes, ami lecteur. La communauté est grande, la communauté est bonne, et il existe une solution tout à fait élégante à ton problème. Et toi qui ricane, toi qui imagine que ton Xen 3.0.3 fraîchement apt-get’é ne souffrira pas des mêmes déboires, ne fais pas le fier, car tu vas devoir suivre strictement la même procédure. En réalité, et croyez bien que cela me désole, il n’y a guère que Qemu (dans sa dernière version, merci CMoi), VirtualBox et VMware qui sauront initier un boot réseau sans astuce.

La solution absolue se nomme « Etherboot » [http://www.etherboot.org/wiki/index.php]. Ce projet permet ni plus ni moins de générer, sous toutes sortes de formats, des disques de boot réseau. Pour ne rien gâcher, bien que la procédure pour créer ces images soit des plus aisées, le projet propose également, sur le site rom-o-matic.net, de générer automatiquement l’image dont vous avez besoin. Il ne reste qu’à la télécharger. Ils sont forts ces étudiants communistes.

Comme il est assez probable que le lecteur de disquettes qui équipait votre Pentium 100 ne doit plus servir que de cache dans votre tour ATA ou votre transportable de 15Kg, nous partirons du postulat que la noble machine possède un « lecteurdecédérom », achat qui vous a probablement valu de vous nourrir aux pâtes et aux œufs pendant plusieurs mois.

Repérez donc sur rom-o-matic l’image correspondant à votre carte réseau. Par exemple, dans notre cas, ns8390:rtl8029.

Pour une machine physique, gravez cette image à l’aide de votre logiciel de gravure favori.

Note

Si, EN PLUS, votre vieille machine ne possédait pas de lecteur CD-ROM, récupérez une image au format zdsk et suivez la procédure décrite sur la page de download de l’image pour générer une disquette de Netboot.

Pour une machine virtuelle, sauvegardez simplement l’image /quelque/part puis, par exemple, pour un domaine Xen, ajoutez l’entrée suivante dans le fichier de configuration du domaine :

disk = [ 'file:/quelque/part/eb-5.4.3-ns8390.liso,ioemu:hdc:cdrom,r' ]

boot = 'd'

Séquence émotion

ÇA Y EST ! Enfin, enfin, nous allons démarrer celle que nous finissions par appeler amicalement « pourriture de veau gavé au Tranxen ». L’image Etherboot ou l’interface PXE native doivent avoir pris la main, et vous devriez voir un écran de ce type :

Et là, j’ai envie de dire, pardon aux plus prudes, mais : c’est la teuf !

Soit en appuyant sur [N], soit en attendant quelques secondes, les premiers signes de vie de notre système distant devraient apparaître :

Et si tout se passe « bien », voici ce sur quoi nous devrions nous arrêter :

J’entends d’ici M. La Quenelle se gausser : « <kernel> OOO111!! OMG OMG!!!1! ROTFL NO INIT OOL \\rainbow ». Et il aura bien raison, car, effectivement, ni init, ni rien d’autre. Notre système est pour le moment totalement vierge.

Promised land

Maintenant que nous avons constaté notre victoire sur le démarrage réseau, nous pouvons éteindre Germaine pour nous concentrer sur notre serveur PXE/NFS. C’est à grand renfort de tar(1) et autres vi que nous allons monter un NetBSD fonctionnel de toutes pièces. Au début de cet article, nous avons préparé l’arborescence nécessaire pour accueillir l’ensemble du userland. Il nous reste à la peupler. Pour ce faire, nous allons tout d’abord télécharger l’ensemble des sets (nous devrions déjà posséder base) :

# pwd

/home/netbsd/pkg

# wget ftp://ftp.fr.netbsd.org/pub/NetBSD-daily/netbsd-4/200703090002Z/i386/binary/sets/comp.tgz

# wget ftp://ftp.fr.netbsd.org/pub/NetBSD-daily/netbsd-4/200703090002Z/i386/binary/sets/etc.tgz

# wget ftp://ftp.fr.netbsd.org/pub/NetBSD-daily/netbsd-4/200703090002Z/i386/binary/sets/games.tgz

# wget ftp://ftp.fr.netbsd.org/pub/NetBSD-daily/netbsd-4/200703090002Z/i386/binary/sets/man.tgz

# wget ftp://ftp.fr.netbsd.org/pub/NetBSD-daily/netbsd-4/200703090002Z/i386/binary/sets/misc.tgz

# wget ftp://ftp.fr.netbsd.org/pub/NetBSD-daily/netbsd-4/200703090002Z/i386/binary/sets/text.tgz

# wget ftp://ftp.fr.netbsd.org/pub/NetBSD-daily/netbsd-4/200703090002Z/i386/binary/sets/xbase.tgz

# wget ftp://ftp.fr.netbsd.org/pub/NetBSD-daily/netbsd-4/200703090002Z/i386/binary/sets/xcomp.tgz

# wget ftp://ftp.fr.netbsd.org/pub/NetBSD-daily/netbsd-4/200703090002Z/i386/binary/sets/xetc.tgz

# wget ftp://ftp.fr.netbsd.org/pub/NetBSD-daily/netbsd-4/200703090002Z/i386/binary/sets/xfont.tgz

# wget ftp://ftp.fr.netbsd.org/pub/NetBSD-daily/netbsd-4/200703090002Z/i386/binary/sets/xserver.tgz

Puis, décompressez le tout en nous assurant de conserver les bons droits :

# cd ../root

# for file in ../pkg/*tgz; do tar zxvfp $file;done

Puisque nous avons choisi de créer une partition usr, nous déplaçons le contenu de root/usr dans cette dernière :

# mv usr/* ../usr

Il nous reste à rendre tout ceci opérationnel. Tout d’abord, en créant du swap : 128 mégas devraient suffire :

# pwd

/home/netbsd

# dd if=/dev/zero of=./swap bs=4k count=32k

Puis, en créant une /etc/fstab :

pxeserver:/home/netbsd/swap   none swap sw,nfsmntpt=/swap

pxeserver:/home/netbsd/root   /     nfs   rw 0 0

pxeserver:/home/netbsd/usr    /usr nfs   rw 0 0

pxeserver:/home/netbsd/home   /home nfs   rw 0 0

Ainsi qu’un /etc/hosts :

192.168.201.254    pxeserver

192.168.201.100    pxehost

On configure l’interface réseau en créant un fichier /etc/ifconfig.<interface>, par exemple /etc/ifconfig.pcn0 :

inet pxehost netmask 255.255.255.0 broadcast 192.168.201.255

Et évidemment, on complète le fichier /etc/rc.conf :

# cette variable est initialement à NO, le système ne bootera pas si elle n'est pas placée à YES

rc_configured=YES

hostname="pxehost"

defaultroute="192.168.201.100"

nfs_client=YES

# rc ne doit pas reconfigurer le réseau, hérité du boot

auto_ifconfig=NO

net_interfaces=""

ET C'EST QUI TON PAPA ? HEIN ? C'EST QUI ?

Nous voici prêts pour le second et dernier boot à l’issue duquel notre système sera parfaitement opérationnel. Démarrez votre machine, virtuelle ou non, en mode single user. Pour cela, au décompte du bootloader, appuyez sur une touche, puis, à l’invite, tapez :

> boot netbsd -s

Note

Il semble qu’avec certains logiciels de virtualisation, Qemu, entre autres, le décompte soit « un peu » rapide pour avoir le temps de frapper une touche. Si tel était votre cas, remettez la variable rc_configured à NO dans le fichier rc.conf.

Vous devriez, après chargement du noyau, vous trouver devant une invite de ce type :

Après avoir appuyé sur [entrée], vous devriez être en possession d’un csh tout ce qu’il y a de moins convivial. Ce dernier devrait suffire le temps de créer l’ensemble des devices :

# cd /dev

# /bin/sh ./MAKEDEV all

Et maintenant, ^D !

Si tout s’est correctement déroulé, vous devriez admirer une mire de login.

VENGEAAAAAAAAAAAANCE !

Vous voici en possession de plusieurs dizaines de consoles NetBSD potentielles, dont probablement aucun des composants ne posera de problème de compatibilité, puisque fort ancien. Évidemment, il est temps d’épater la galerie, d’en mettre plein les mirettes, DE FAIRE SE PROSTERN... Il est temps de montrer des trucs que le GENS a envie de voir, et pour cela, vous n’avez besoin de rien de plus. Rien de plus que cet UNIX muni d’un serveur X et d’un client ssh dont je copie ici un extrait du man :

     -X Enables X11 forwarding. This can also be specified on a per-host

             basis in a configuration file.

             X11 forwarding should be enabled with caution. Users with the

             ability to bypass file permissions on the remote host (for the

             user's X authorization database) can access the local X11 display

             through the forwarded connection. An attacker may then be able

             to perform activities such as keystroke monitoring.

             For this reason, X11 forwarding is subjected to X11 SECURITY

             extension restrictions by default. Please refer to the ssh -Y

             option and the ForwardX11Trusted directive in ssh_config(5) for

more information.

Ce qui signifie qu’en activant l’option X11Forwarding sur un serveur depuis lequel vous voudrez exporter des sessions Gnome/KDE/Xfce/whatever, vous n’aurez, sur le terminal NetBSD diskless, besoin que d’un « simple » serveur X11. J’sais pas pour vous, mais moi ça me fait des trucs.

Une autre technique bien connue consistera à utiliser la variable d’environnement $DISPLAY et la commande xhost, démonstration :

- sur la machine dont vous voulez exporter les applications (inutile d’être sous X) :

DISPLAY=pxehost:0.0; export DISPLAY

- sur le client NetBSD diskless (X doit être lancé) :

xhost +pxeserver

Voici pour finir l’illustration de cette méthode, un export complet d’environnement depuis ma station tatooine vers l’environnement NetBSD/NFS kamino.

Sans déconner, c’est quand même plus groovy d’aller lire les derniers titres de Slashdot que de feuilleter Closer non ?

Références :

- http://www.netbsd.org/Documentation/network/netboot/

- http://ltsp.org/