hum hum hum…

Y’a pas longtemps, j’ai peté ma “vieille” fonera. À force d’y coller des antennes au cul, j’ai fini par casser la soudure entre le connecteur d’antenne et la carte.

Par chance, j’ai recemment été convié à la Fiesta FON, ou l’on distribuait des fonera “classiques” (comprendre “pas fonera+”). Donc nickel bien, je remplace l’ancienne, ouvre la nouvelle, tout est ok. Sauf que non. Puisque désormais, evidemment, le portail FON ne me voit plus connecté :( Alors comme ça, pour voir, j’ai été jeter un oeil dans les divers scripts de la fonera, me disant qu’après tout, pour localiser du materiel, ils devaient probablement se baser soit sur le S/N, soit une ou plusieurs MAC. Et bin ouais. Si vous deviez, comme moi, changer voter fonera et que vous n’avez pas la patience d’attendre la réponse du support de FON, je vous conseille l’édition du fichier /bin/thinclient (oui, encore lui), et le hardocage des variables ETMAC et WLMAC, qui représentent respectivement l’adresse MAC de la carte ethernet et l’adresse MAC du lien WiFi public. Exemple:

J’ai refait mon LAN. Dans les grandes lignes, une Fonera flashée en DD-WRT bridge la connexion au net via une freebox. Le wrt est le routeur du LAN, il est connecté à un bete switch sur lequel est branché une Fonera “legacy”, qui me fournit l’acces WiFi de manière classique via son SSID “MyPlace”.

Jusque là, rien de particulier. Mais dans ce petit réseau, j’ai également des téléphones SIP dont un white, WiFi donc. Et comme vous le savez probablement, SIP et plus particulièrement RTP ne font pas bon ménage avec du NAT. Pour pallier ce problème, j’ai l’habitude d’utiliser des liens privés vers mes Asterisk en utilisant OpenVPN. J’ai testé par mal de packages avant de trouver une combinaison fonctionnelle sur Fonera/DD-WRT. En effet, les packages openvpn, libopenssl et liblzo disponibles ici: http://ipkg.k1k2.de/packages/ coredumpent simplement. Voici les emplacements de packages qui marchent:

Comme mentionné dans le post précedent, afin de pouvoir démarrer des kvm NetBSD, je me disais qu’une upgrade tranquille en Gutsy et son noyau 2.6.22 seraient du meilleur effet. Je n’ai de cesse de le répéter: naif. Je suis naif.

Je vois défiler l’apt-get dist-upgrade (du moins son pendant clicka-graphico-convi), et pressens moult emmerdes à la lecture de beaucoup trop d’unmet dependancies… mais bon, c’est démarré, c’est démarré, advienne que pourra.

J’en mourais d’envie: après avoir manipulé des machines VT-capable au boulot, je ne pouvais plus rentrer chez moi et ne pas démarrer un kvm ou un domU non modifié. Alors j’ai craqué. Après 4 heures passées rue Montgallet façon de Pretty-Woman, voici le setup que je me suis monté à moindres frais, afin de pouvoir, chez moi, gouter aux joies de la Virtualisation native :

. CPU: Intel Core 2 Duo E6300: 119€ . Carte Mère ASUS P5L 1394: 63€ . 2GB DDR2 Kingston: 58€

En echo à ce très bon post montrant une configuration réseau qui fonctionne pour qemu / kvm, je vous propose ma petite sauce. La finalité étant :

. Une VM NetBSD 3.1 sur le même LAN que le host . Son fonctionnement en background . Son administration potentielle via VNC en cas de crash

à la Xen quoi.

Le host est une debian x86, et evidemment le hardware supporte les instructions VT :

alors moi je dis: y.e.s.

Upgrade de Xen en 3.1 sur mon lappy boulot, juste pour voir, et YES, enfin ce !@#!@# de module b44 (BCM4401-B0) fonctionne out-of-the-box ! Il s’agit d’une debian testing, pour laquelle j’ai suivi ce tuto, excepté pour la partie mkinitrd qui pedalait dans le vide, je lui ai donc préféré mkinitramfs, utilisé de cette façon :

Décidemment, le “choix” de l’OS d’un domU n’est pas si large qu’il n’y parait… Nous avions statué l’archi suivante pour zone0 :

. dom0: debian stable amd64 + Xen 3.1 . domU services: OpenBSD 4.1 amd64 . domU shells: OpenBSD 4.1 amd64 . domU www1: NetBSD 3.1 x86 . domU www2: NetBSD 3.1 x86

Le choix de NetBSD x86 avait été dicté par le fait que l’installation même de la version 64 bits s’avérait impossible, cette dernière ne trouvant jamais le media cd0.

CINQ HEURES ! CINQ PUTAIN D’HEURES on vient de passer avec _mat et ofredj à essayer de débugger cette SALOPERIE de netfilter. Pour faire court, toujours dans les peripeties de zone0, je me disais ce matin “bon peinard, je sette les redirections de ports du dom0 vers les domUs et on part racker”: AH-AH. Et que jte PREROUTE, et que jte FORWARD et qu’on browse, qu’on lit des histoires de checksums erronés, de mode nat pour Xen, on essaye, on casse, on boit. Bref, la misère: impossible de faire un minable petit forwarding de port du dom0 vers un domU. En désespoir de cause, je tente ma chance avec IPVS, dont je connais la robustesse par le biais de mon boulot. Et bah… 10mn de lecture de man, 3mn de commandes, et ça marche. Là comme ça direct. Je vous l’accorde, c’est un peu le marteau pilon pour écraser une mouche, mais à bien y reflechir, les capacités de ce module kernel à faire du load balancing nous ouvrent potentiellement de nouveaux horizons… Un chouillat de conf pour faire envie

tu sais ce que c’est que ça lutin ?

ça, c’est le nombre de CDs / UNICes / Linux que j’ai du tester avant de tomber sur une configuration adéquate pour :

. Faire tourner un dom0 Xen en 64 bits . Faire tourner autre chose que du Linux en domU 64 bits

Le magic combo, c’est Debian Stable (Etch) amd64 + Xen 3.1

Pour le moment je fais tourner un domU OpenBSD amd64 et un domU NetBSD amd64 en hvm (CPU VT capable evidemment)

Bon c’est pas encore super brillant, j’imagine que ça fera hurler les puristes, mais au cas ou quelqu’un aurait besoin d’une toute petite classe de rien du tout pour manipuler des fichiers de conf “basiques” du type :

J’ai pondu un truc ici. Ça s’utilise comme ça :

et magie :

Améliorations bienvenues toussa.