Emile “iMil” Heitor ’s home

C’est remarquable cette propension des petits lutins bleus de la nuit à aller bousiller les seules machines qui ne sont pas backupées, ils savent tout, ils voient tout, et ce sont de sacrés petits pervers de merde.

Hier matin, alors que je m’apprétais à faire le tour de mes mails avant de partir au boulot, je constate avec effroi que “je ne sors plus”. Comportement plus qu’étrange, ma passerelle récupère bien l’IP publique Free via DHCP, le ping passe quelques secondes, puis s’arrête, plus rien. Inévitablement, je commence à blâmer Free -bien qu’objectivement, je n’ai pas recontré de problèmes majeurs depuis des mois-, puis par acquis de conscience, teste le lien sur une machine differente. Ça passe.

Mon ancienne passerelle était un peu bancale, il faut l’avouer; il s’agissait d’une Sun Netra X1 gracieusement léguée par monsieur ange pendant Solutions Linux 2008, qui faisait tourner un OpenBSD 4.1 qui paniquait environ tous les trois mois.

Il ne m’en fallait pas plus pour plancher sur une nouvelle gateway, sous NetBSD cette fois. M’est alors apparu l’idée de faire fonctionner cette passerelle dans un domU, après tout, en bridgeant l’interface qui reçoit le réseau Free à une interface Xen, et de la même manière, en bridgeant l’interface raccordée à mon LAN, cela devrait fonctionner sans accroc: et bien c’est le cas.

Voici les fichiers impliqués dans ce mic-mac:

Sur le dom0, je déclare mes interfaces comme suit :

$ cat /etc/ifconfig.fxp0 # LAN
inet 192.168.0.10 netmask 255.255.255.0
$ cat /etc/ifconfig.fxp1 # Free
up

Puis je déclare des bridges sur ces interfaces :

$ cat /etc/ifconfig.bridge0 # LAN
create
!brconfig $int add fxp0 up
$ cat /etc/ifconfig.bridge1 # Free
create
!brconfig $int add fxp1 up

Ce qui nous donne, dans la configuration du domU :

$ cat /usr/pkg/etc/xen/exar
#kernel = "/home/imil/xen/netbsd-5.0.2-INSTALL_XEN3_DOMU.gz"
kernel = "/home/imil/xen/netbsd-5.0.2-XEN3_DOMU-pf.gz"
memory = 256
name = "exar"
vcpus = 1
disk = [ 'file:/home/imil/xen/exar.img,0x03,w' ]
disk += [ 'file:/home/imil/iso/amd64cd-5.0.2.iso,0x04,r' ]
vif = [ 'bridge=bridge0' ]
vif += [ 'bridge=bridge1' ]
bootdev = "/dev/xbd0a"

Notez le nom du noyau qui sert à faire booter cette VM, netbsd-5.0.2-XEN3_DOMU-pf.gz. En effet, un modload /usr/lkm/pf.o fait misérablement crasher le domU, il est donc nécessaire de se fendre d’une recompilation du noyau domU en incluant à la configuration :

pseudo-device   pf                      # PF packet filter
pseudo-device   pflog                   # PF log if

Sur le domU-passerelle, on constate la présence des deux interfaces :

$ ifconfig -a
xennet0: flags=8863 mtu 1500
        capabilities=2800
        enabled=0
[...]
xennet1: flags=8863 mtu 1500
        capabilities=2800
        enabled=0
[...]

Leur configuration est triviale :

exar$ cat /etc/ifconfig.xennet0 # LAN
inet 192.168.0.254 netmask 255.255.255.0
exar$ cat /etc/ifconfig.xennet1 # Free
up
!dhclient $int

Et voila !

On active le NAT gràce à pf :

ext_if="xennet1"
int_if="xennet0"

nat on $ext_if from !($ext_if) -> ($ext_if:0)

Et me voila à nouveau en mesure de raconter ma vie trépidante sur l’Intarwebz.

On peut lire sur GCU que nous avons passé une partie du week end, après un bafr bien arrosé, à mettre à jour Zone0.GCU-Squad.org, machine qui héberge le site, et moult services du groupe.

Il faut l’avouer, cette mise à jour fut une promenade de santé en comparaison de sa cauchemardesque installation voila deux ans. Je me propose tout de même de vous raconter les quelques manipulations qui furent nécessaires à sa migration vers 2009.

Rappelez-vous, Zone0 c’était :

• Un quad-core VT-capable
• Une debian etch
• Un noyau Linux 2.6.18 patché en raison d’un bug du driver du controlleur RAID 3ware
• En conséquence du point précedent, un Xen 3.1 roulé sous les aisselles en provenance de Xen.org

Contre toute attente, un simple :%s/etch/lenny/g suivi d’un apt-get update && apt-get dist-upgrade a rectifié la situation bancale d’un Xen et d’un noyau non-issus de debian, ce qui rendait tout upgrade très périlleux.

Il est à noter qu’en raison du passage de lvm1 à lvm2, il a été nécessaire de se refendre d’un apt-get dist-upgrade, alors seulement l’installation d’un nouveau noyau utilisera les nouveaux hooks de lvm2 pour générer un initrd correct. Le noyau installé est en l’occurrence linux-image-2.6.26-2-xen-amd64.

Un reboot plus tard, le dom0 2.6.26 était controllé par Xen 3.2.

Pour être tout à fait honnête, nous avons planché quelques minutes sur un problème lié à l’ancienne installation. En effet, les domUs hvm ne démarraient pas, et nous constations que qemu-dm, l’executable en charge de virtualiser les péripheriques, était en état defunct. La raison était en réalité simplissime, les configurations de nos domUs faisaient appel aux fichiers /usr/lib/xen/boot/hvmloader et /usr/lib/xen/bin/qemu-dm, or c’étaient les anciens binaires qui se trouvaient là, ceux installés par la version 3.2 issue du package debian se trouvent dans /usr/lib/xen-default (qui est un lien logique vers /usr/lib/xen-3.2-1). Rien de bien méchant.

Une fois rebootée, c’en était fini pour notre session au datacenter, et il me revenait de mettre à jour les deux domUs NetBSD. Double (quadruple donc) mise à jour, puisqu’en plus de migrer les deux systèmes vers NetBSD 5.0.1, en raison de l’incroyable gain de performance que j’avais constaté entre le mode HVM et Paravirtualisé de Xen, j’avais prévu de profiter de cet upgrade massif pour basculer les domUs NetBSD en mode paravirtualisé.

Là encore, rien de terrifiant, dans la configuration des domUs, j’ai simplement remplacé :

kernel = '/usr/lib/xen-3.2-1/boot/hvmloader'
builder = 'hvm'
device_model = '/usr/lib/xen-3.2-1/bin/qemu-dm'

par

kernel = '/home/xen/NetBSD/5.0.1/netbsd-XEN3PAE_DOMU.gz'

Après avoir booté les domUs sur ce kernel domU modifié, il n’a s’agit que d’une procédure d’upgrade des plus classiques, suivie de la mise à jour des packages à l’aide de pkg_comp (recréé pour correspondre au système réel) puis pkg_chk.

Les machines, virtuelles et réelles, semblent bien se comporter, et je suis désormais complètement convaincu par la supériorité du mode paravirtualisé, les temps de réponse sont simplement sidérants.

Pkgin utilisable, je me suis engagé à l’intégrer dans PackageKit afin que NetBSD dispose rapidement d’une interface graphique permettant de manipuler des packages.

Je ne souhaitais pas polluer ma machine de développement avec une myriade de librairies et utilitaires graphiques, aussi ai-je installé un domU NetBSD 5.0 prévu à cet effet.
Afin de simuler l’utilisation d’une station de travail sans pour autant installer plusieurs téras de logiciels, j’ai choisi xfce4. Son installation est désormais simplissime (quoi, j’ai le droit de me brosser un peu) :

$ sudo pkgin in xfce4

Il faudra placer les variables suivantes dans le fichier /etc/rc.conf du domU

rpcbind=YES
famd=YES
dbus=YES
hal=YES

pour démarrer l’usine à gaz la machinerie fam,dbus,hal.

Vous connaissez probablement le drapeau -X de ssh(1) permettant de faire transiter du traffic X11 à travers la session ssh. Il conviendra de placer la variable suivante dans le fichier /etc/ssh/sshd_conf du serveur (du domU dans notre cas) afin d’autoriser sshd(8) à forwarder le protocole X11 :

X11Forwarding yes

Moyennant quoi, on se connecte au domU de cette façon :

$ ssh -X mondomu

Nous afficherons alors une session X11 à l’aide du server Xnest(1). Il suffira de renseigner le fichier ~/.xinitrc comme pour un serveur X classique :

xfce4-session

Et de démarrer son environnement de cette façon :

$ xinit -- /usr/X11R7/bin/Xnest

Afin d’obtenir ce résultat :

Pour tester “en vrai” mon fameux pkg_dry (work in progress, pas du tout utilisable, pas d’affolement), je devais posséder une VM NetBSD 5 “poubelle”. Seulement, depuis quelques temps déjà, je sais que cette version panic‘e sur KVM, VirtualBox et Xen HVM. Aussi me suis-je décidé à Xenifier ma machine de developpement NetBSD qui n’a pas d’instructions VT, afin d’y faire tourner un domU en paravirtualisation.

Voici la compilation des documents utiles :

• Le HOWTO officiell NetBSD/xen (pas à jour)
• Le HOWTO du wiki NetBSD
• Un post sur port-xen qui donne quelques informations supplémentaires

Ce qu’il faut savoir :

• Il n’est plus nécessaire d’utiliser grub pour démarrer le noyau Xen, le bootloader standard fonctionne parfaitement
• En ajout à la doc du wiki NetBSD, j’ai du spécifier le bootdev dans mon /boot.cfg, le cas écheant, le noyau tentait de booter sur sd0a
• De la même manière, dans la conf de mon domU, j’ai du ajouter la directive bootdev = "/dev/xbd0a"
• J’utilise des images et non de vrais disques, la ligne correspondante dans la conf du domU est: disk = [ 'file:/home/imil/xen/slave-1.img,0x03,w', 'file:/home/imil/iso/netbsd-i386.iso,0x04,r' ]

À noter que je suis extremement impressionné par la rapidité d’un domU paravirtualisé, n’ayant jusqu’à présent utilisé que des guests HVM.

Ce midi, le domU GCU était injoignable. Une connexion VNC nous permet de voir que le noyau vomissait depuis quelques minutes une floppée de :

rtk0: unable to allocate Tx cluster

Une rapide recherche nous amène sur ce post qui, comme on pouvait le soupçonner, explique que les cartes de type rtl8139 sont moisies, mais que dans l’urgence, l’ajout de la directive :

options		NMBCLUSTERS=4096

à la conf kernel permet de résoudre le problème.

"re0: watchdog timeout"

Voila tout ce que nous obtenions lorsque nous choisissions le driver NIC rtl8139 pour un domU NetBSD ou OpenBSD.
Finalement, c’est une réponse de Manuel Bouyer sur port-xen qui donne la solution: Désactiver re* ! C’est alors rtk* qui prend la main, et là, point de timeout, de latences ou autres dysfonctionnement, “juste ça marche”.