30/12/2012

201212301200 freebsd xen domU rescue

Un domU à la sauce FreeBSD

J'ai à ma disposition un ordinateur portable Dell Latitude D810 généreusement doté de 2 Go de ram, d'un disque accueuillant de 40 Go, le tout propulsé par un unique mais véloce Pentium Mobile se déplaçant à la vitesse supersonique de 1.73 GHz. Tout ça à la portée du premier quidam venu c'est fou, non ?

Devant cette débauche de puissance, on ne peut que s'incliner. Et installer un NetBSD 6.0 i386 parce que les serviettes oranges ça roxe. Quelles sont les origines de cette roxitude ? Une déscendance directe avec Unix (le vrai, le seul et l'unique, sorti des entrailles d'un PDP 11 il y a plus de 40 ans) ? 20 ans d'histoire (sans compter sa longue gestion au sein du CSRG, hébergé par l'University of Berkeley, California) ? Une accointance particulière avec le projet Xen ? Son récent support de LVM ? Une communauté française particulièrement impliquée (de par ses contributions de qualité et de ses rassemblements de haut niveau) ?

Nul doute que nous sommes en présence d'un OS du bien. Il est aisé de trouver moultes documentations relatives à son installation (dans le cas contraire n'hésitez pas à vous procurer le Gnu Linux Magazine France n°115) et l'ajout de Xen (version 4.1) est trivial. Mais un OS du bien c'est bien, deux c'est mieux. Je me propose donc de détailler les différentes étapes menant à l'obtention d'un domU FreeBSD 9.0.

Les caractéristiques de la machine et une volonté de parcourir des chemins peu fréquentés expliquent les choix suivants:

pas de ZFS (car gourmand en ram et nous devons partager 2 Go entre Xen, le dom0 et nos domU)
un espace disque limité par rapport aux capacités actuelles (mais on peut en faire des cochonneries avec 40 Go :)
tenter de mimer OpenBSD (et son bsd.rd) et NetBSD (et son netbsd-INSTALL_XEN3PAE_DOMU.gz)
pas de NFS (j'aime pô)
laisser le dom0 le plus propre possible (pas de packages en plus et mollo sur l'espace disque)
apprendre des trucs (pleins)

Le projet FreeBSD ne proposant pas de kernel xenifié tout prêt, il va falloir passer par les sources. Une machine (même virtuelle) avec un FreeBSD i386 (le kernel compilé depuis une machine X86_64 n'était pas reconnu comme PAE, pré-requis indispensable à l'utilisation de Xen 4.1), la bible sous les yeux, les sources en version 9.0 fraichement récupérés et nous voilà prêt à compiler 2 kernels:

freebsd_XEN_DOMU
freebsd-INSTALL_XEN_DOMU

Point de compilation sans configuration et un peu de lecture. Inutile de compiler l'ensemble des modules, les divers périphériques disponibles dans un domU sont tous identifiés et intégrés dans le kernel. Seul bémol: la présence des options de debug. On peut, sans être trop téméraire, s'en passer aisément (tout comme de nfs dont je ne suis pas un fervent adepte):

# cat /usr/src/sys/i386/conf/XEN_PROD
include XEN

ident           XEN_PROD

makeoptions     DEBUG=
makeoptions     MODULES_OVERRIDE=

nooptions       SCTP                    # Stream Control Transmission Protocol
nooptions       NFSCL                   # New Network Filesystem Client
nooptions       NFSD                    # New Network Filesystem Server
nooptions       NFSLOCKD                # Network Lock Manager
nooptions       NFS_ROOT                # NFS usable as /, requires NFSCL

# Debugging for use in -current
nooptions       KDB                     # Enable kernel debugger support.
nooptions       DDB                     # Support DDB.
nooptions       GDB                     # Support remote GDB.
nooptions       DEADLKRES               # Enable the deadlock resolver
nooptions       INVARIANTS              # Enable calls of extra sanity checking
nooptions       INVARIANT_SUPPORT       # Extra sanity checks of internal structures, required by INVARIANTS
nooptions       WITNESS                 # Enable checks to detect deadlocks and cycles
nooptions       WITNESS_SKIPSPIN        # Don't run witness on spinlocks for speed
# cd /usr/src
# make buildkernel KERNCONF=XEN_PROD
# ls -l /usr/obj/usr/src/sys/XEN_PROD/kernel
-rwxr-xr-x  1 root  wheel  3962117 Dec 28 17:27 /usr/obj/usr/src/sys/XEN_PROD/kernel

J'ai dit mollo sur l'espace disque. Je n'utiliserais donc pas les supports habituels (oui môssieur, même les 130 Mo du bootonly sont encore trop pour moi :)

FreeBSD-9.0-RELEASE-i386-bootonly.iso    131 582 KB
FreeBSD-9.0-RELEASE-i386-disc1.iso       513 882 KB
FreeBSD-9.0-RELEASE-i386-dvd1.iso      2 191 632 KB
FreeBSD-9.0-RELEASE-i386-memstick.img    547 752 KB

Pour comprendre la suite des évènements, passons en revue les étapes de l'installation d'un OS du bien:

boot du kernel
obtention d'un shell
préparation du support de destination
installation du système
configuration

Les étapes 2 à 5 sont souvent dévolues à un programme d'installation (le vénérable sysinstall ou le récent bsdinstall). Afin de mimer OpenBSD ou NetBSD, je souhaite construire un kernel contenant de quoi installer ma boule de geisha. Ce kernel contiendra un ramdisk, idéalement peuplé du programme d'installation. Mais là où le bât blesse, c'est que la page de manuel de sysinstall est claire:

 This product is currently at the end of its life cycle and will eventually be replaced.

bsdinstall est quant à lui un script shell faisant appel à d'autres scripts ou programmes:

# ls -l /usr/libexec/bsdinstall/
total 200
-r-xr-xr-x  1 root  wheel   1570 Jan  3  2012 adduser
-r-xr-xr-x  1 root  wheel   7356 Jan  3  2012 auto
-r-xr-xr-x  2 root  wheel  39888 Jan  3  2012 autopart
-r-xr-xr-x  1 root  wheel   2591 Jan  3  2012 checksum
-r-xr-xr-x  1 root  wheel   1680 Jan  3  2012 config
-r-xr-xr-x  1 root  wheel   8436 Jan  3  2012 distextract
-r-xr-xr-x  1 root  wheel   8452 Jan  3  2012 distfetch
-r-xr-xr-x  1 root  wheel   3446 Jan  3  2012 docsinstall
-r-xr-xr-x  1 root  wheel   2053 Jan  3  2012 hostname
-r-xr-xr-x  1 root  wheel   3851 Jan  3  2012 jail
-r-xr-xr-x  1 root  wheel   1747 Jan  3  2012 keymap
-r-xr-xr-x  1 root  wheel   8663 Jan  3  2012 mirrorselect
-r-xr-xr-x  1 root  wheel   2225 Jan  3  2012 mount
-r-xr-xr-x  1 root  wheel   6253 Jan  3  2012 netconfig
-r-xr-xr-x  1 root  wheel   3496 Jan  3  2012 netconfig_ipv4
-r-xr-xr-x  1 root  wheel   4543 Jan  3  2012 netconfig_ipv6
-r-xr-xr-x  2 root  wheel  39888 Jan  3  2012 partedit
-r-xr-xr-x  1 root  wheel   1635 Jan  3  2012 rootpass
-r-xr-xr-x  1 root  wheel   2895 Jan  3  2012 services
-r-xr-xr-x  1 root  wheel   1477 Jan  3  2012 time
-r-xr-xr-x  1 root  wheel   1810 Jan  3  2012 umount
-r-xr-xr-x  1 root  wheel   4700 Jan  3  2012 wlanconfig

Il serait assez laborieux de faire la liste de tous les binaires (et de leurs dépendances respectives) utilisés, car même s'ils sont tous compris dans "base", je ne vais pas faire rentrer la moitié de "base" dans un kernel.

Mes précédentes aventures m'ont fait découvrir le "rescue" et j'ai décidé d'approfondir cette piste. Un rapide coup d'oeil à "/rescue" nous apprend 2 choses:

les outils ne manquent pas (gestion des disques durs, systèmes de fichier, configuration réseau, compression / décompression, restauration)
le tout dans moins de 5 Mo

Les plus perspicaces auront remarqué l'absence de fetch, ftp ou nc. Aucun outil pour récupérer un fichier (au hasard base.txz). Casse la tienne comme dit si bien mon ami Béru, on va phalanger ça.

Après lecture de librescue/Makefile et rescue/Makefile, je configure la compilation de "rescue" de la sorte:

# cat /root/etc/src_xen_install.conf
WITHOUT_RCMDS="yes"
WITHOUT_TCSH="yes"
WITHOUT_ATM="yes"
#WITHOUT_INET6_SUPPORT="yes"
WITHOUT_IPFILTER="yes"
WITHOUT_IPX="yes"
WITHOUT_ZFS="yes"
WITHOUT_NIS="yes"
WITHOUT_HESIOD="yes"
#WITHOUT_OPENSSL="yes"

Au résultat:

# cd /usr/src/rescue/
# make SRCCONF=/root/etc/src_xen_install.conf obj
# make SRCCONF=/root/etc/src_xen_install.conf
# ls -l /usr/obj/usr/src/rescue/rescue/rescue
-rwxr-xr-x  1 root  wheel  3778132 Dec 29 08:53 /usr/obj/usr/src/rescue/rescue/rescue

Pour rajouter un binaire à notre "rescue", il faut malheureusement éditer rescue/Makefile. Inutile de sortir la tronçonneuse pour alléger la partie CRUNCH_PROGS_bin=, le gain ne serait que de quelques centaines de Ko. Si certains esprits chafouins avaient l'idée saugrenue d'objecter que fetch serait plus approprié, je leur souhaite bon courage avec la lib ssl.

# diff -u rescue/Makefile.orig rescue/Makefile
--- rescue/Makefile.orig        2012-12-29 09:01:22.000000000 +0100
+++ rescue/Makefile     2012-12-29 12:50:24.000000000 +0100
@@ -206,6 +206,7 @@
 CRUNCH_PROGS_usr.bin+= id
 CRUNCH_ALIAS_id= groups whoami
 
+CRUNCH_PROGS_usr.bin+= ftp
 ##################################################################
 # Programs from stock /usr/sbin
 #

Au résultat:

# ls -l /usr/obj/usr/src/rescue/rescue/rescue
-rwxr-xr-x  1 root  wheel  3897468 Dec 29 12:52 /usr/obj/usr/src/rescue/rescue/rescue

Le "rescue" est prêt, reste à l'intégrer à notre kernel:

# dd if=/dev/zero of=/tmp/mfs_image bs=1M count=5
5+0 records in
5+0 records out
5242880 bytes transferred in 0.017344 secs (302287859 bytes/sec)
# mdconfig -a -t vnode -f /tmp/mfs_image -u 0
# gpart create -s gpt md0
md0 created
# gpart add -t freebsd-ufs md0
md0p1 added
# newfs -O1 -o space -m 0 md0p1
/dev/md0p1: 5.0MB (10168 sectors) block size 32768, fragment size 4096
        using 2 cylinder groups of 4.00MB, 128 blks, 256 inodes.
super-block backups (for fsck -b #) at:
 64, 8256
# mount /dev/md0p1 /mnt
# mkdir /mnt/{rescue,dev,disk}
# cd /usr/src/rescue/
# make SRCCONF=/root/etc/src_xen_install.conf DESTDIR=/mnt DONTSTRIP=1 install
# cat /usr/src/sys/i386/conf/XEN_INSTALL 
include XEN_PROD

ident           XEN_INSTALL

options         MD_ROOT                 # MD is a potential root device
options         MD_ROOT_SIZE=5120 # 5M
makeoptions     MFS_IMAGE=/tmp/mfs_image
options         ROOTDEVNAME=\"ufs:/dev/md0p1\"
# umount /mnt
# mdconfig -d -u 0
# cd /usr/src
# make buildkernel KERNCONF=XEN_INSTALL
[ snip des trucs ]
>>> Kernel build for XEN_INSTALL completed on Sat Dec 29 13:40:32 CET 2012
--------------------------------------------------------------
# ls -l /usr/obj/usr/src/sys/XEN_INSTALL/kernel
-rwxr-xr-x  1 root  wheel  9205179 Dec 29 13:40 /usr/obj/usr/src/sys/XEN_INSTALL/kernel

Il est temps d'immortaliser tout ce travail:

$ md5 freebsd*
MD5 (freebsd-INSTALL_XEN_DOMU) = e763357ad52622ba5f5b2dcba9c5d373
MD5 (freebsd_XEN_DOMU) = 77d01b45d09e23a05962119f07765505
$ sha256  freebsd*
SHA256 (freebsd-INSTALL_XEN_DOMU) = 9a2f935cbc6acebdd1a165d9b390822a303ad6db41db7c11ae5862e8e78ff9dd
SHA256 (freebsd_XEN_DOMU) = d4fd2a4061ebe507e760ec4241354dbfaeafd97457faa17eba1b57b874e7e024

Une fois tout ce beau monde copié sur notre dom0, on peut passer à la configuration du domU freebsd. Je rappelle que LVM est désormais disponible sur nos serviettes oranges, autant en profiter (vg00 est mon volume group principal):

# lvm lvcreate --size 10G -n lv_freebsd vg00
  Logical volume "lv_freebsd" created
# lvm lvdisplay /dev/vg00/lv_freebsd
  --- Logical volume ---
  LV Name                /dev/vg00/lv_freebsd
  VG Name                vg00
  LV UUID                E2ReS2-e9mh-D1KB-EHXg-PcKz-QYbt-rRLIw6
  LV Write Access        read/write
  LV Status              available
  # open                 0
  LV Size                10.00 GiB
  Current LE             2560
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     0
  Block device           169:2

La configuration du domU pour l'installation:

# cat /root/etc/freebsd.cfg 
kernel      = '/root/xen/freebsd-INSTALL_XEN_DOMU'
memory      = '256'
disk        = [ 'phy:/dev/mapper/vg00-lv_freebsd,hda,w' ]
name        = 'xenfree.bsdsx.fr'
vif         = [ 'mac=00:16:3e:00:00:51,bridge=bridge0', 'mac=00:16:3e:00:01:51,bridge=bridge1' ]
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'
extra       = 'console=hvc0,boot_verbose,kern.hz=100,vfs.root.mountfrom=ufs:/dev/md0p1'

2 mots concernant le réseau:

J'utilise xen en mode brouteur et pleins d'interfaces, une adaptation à votre propre utilisation est sans doute nécessaire.

Même si tout semble prévu, il n'est pas possible, depuis le rescue, d'utiliser dhclient. Cette possibilité nous aurait permis d'avoir un accès réseau "complet" (passerelle, serveurs de noms ...) et de pouvoir récupérer base.txz depuis les sites officiels. Il faudra donc se contenter de configurer manuellement une interface réseau (xn0) et utiliser des adresses ip en lieu et place de nom d'hôte. Je vais donc servir base.txz en utilisant les outils disponibles sur le dom0 (inetd et /usr/libexec/httpd):

$ grep ^http /etc/inetd.conf 
http            stream  tcp     nowait:600      _httpd  /usr/libexec/httpd      httpd /var/www
$ ls -l /var/www/freebsd/9.0/
total 105792
-rw-r--r--  1 root  wheel  54107736 Dec 17 21:47 base.txz
# pkill -HUP inetd

Dernière recommandation: ne pas tenir compte du message suivant:

[XEN] hypervisor wallclock nudged; nudging TOD.

Il est temps de rentrer dans le vif du sujet:

# xm create /home/dsx/etc/freebsd.cfg -c
Using config file "/home/dsx/etc/freebsd.cfg".
Started domain xenfree.bsdsx.fr (id=23)
                                       WARNING: loader(8) metadata is missing!
Copyright (c) 1992-2012 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 9.0-RELEASE-p5 #5: Sat Dec 29 16:45:44 CET 2012
    dsx@dsxbsd001:/usr/obj/usr/src/sys/XEN_INSTALL i386
Xen reported: 1729.021 MHz processor.
Timecounter "ixen" frequency 1953125 Hz quality 0
CPU: Intel(R) Pentium(R) M processor 1.73GHz (1729.02-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x6d8  Family = 6  Model = d  Stepping = 8
  Features=0xafe1fbff
  Features2=0x180
  AMD Features=0x100000
real memory  = 268435456 (256 MB)
avail memory = 251011072 (239 MB)
[XEN] IPI cpu=0 irq=128 vector=RESCHEDULE_VECTOR (0)
[XEN] IPI cpu=0 irq=129 vector=CALL_FUNCTION_VECTOR (1)
[XEN] xen_rtc_probe: probing Hypervisor RTC clock
rtc0:  on motherboard
[XEN] xen_rtc_attach: attaching Hypervisor RTC clock
xenstore0:  on motherboard
xc0:  on motherboard
Event timer "ixen" quality 600
Timecounters tick every 10.000 msec
[XEN] hypervisor wallclock nudged; nudging TOD.
xenbusb_front0:  on xenstore0
xn0:  at device/vif/0 on xenbusb_front0
xn0: Ethernet address: 00:16:3e:00:00:51
xn1:  at device/vif/1 on xenbusb_front0
xn1: Ethernet address: 00:16:3e:00:01:51
xenbusb_back0:  on xenstore0
xctrl0:  on xenstore0
xbd0: 10240MB  at device/vbd/768 on xenbusb_front0
xbd0: attaching as ad0
xn0: backend features:
xn1: backend features:
Timecounter "TSC" frequency 1729021000 Hz quality 800
Trying to mount root from ufs:/dev/md0p1 []...
rtc0: [XEN] xen_rtc_gettime
rtc0: [XEN] xen_rtc_gettime: wallclock 1355568504 sec; 833095242 nsec
rtc0: [XEN] xen_rtc_gettime: uptime 1291968 sec; 51658017 nsec
rtc0: [XEN] xen_rtc_gettime: TOD 1356860472 sec; 884753259 nsec
Dec 30 09:41:13 init: login_getclass: unknown class 'daemon'
cannot open /etc/rc: No such file or directory
Enter full pathname of shell or RETURN for /rescue/sh: [XEN] hypervisor wallclock nudged; nudging TOD.

Cannot read termcap database;
using dumb terminal settings.

# gpart create -s gpt ad0
ad0 created
# gpart add -t freebsd-swap -s 1G  ad0
ad0p1 added
# gpart add -t freebsd-ufs  ad0
ad0p2 added
# newfs ad0p2
/dev/ad0p2: 9216.0MB (18874296 sectors) block size 32768, fragment size 4096
        using 13 cylinder groups of 740.00MB, 23680 blks, 47360 inodes.
super-block backups (for fsck -b #) at:
 192, 1515712, 3031232, 4546752, 6062272, 7577792, 9093312, 10608832, 12124352,
 13639872, 15155392, 16670912, 18186432
newfs: Cannot retrieve operator gid, using gid 0.
# mount /dev/ad0p2 /disk
# ifconfig xn0 up
xn0: link state changed to DOWN
xn0: link state changed to UP
# ifconfig xn0 inet 10.30.12.51 netmask 255.255.255.0
# ping -c 2 10.30.12.1
PING 10.30.12.1 (10.30.12.1): 56 data bytes
64 bytes from 10.30.12.1: icmp_seq=0 ttl=255 time=0.442 ms
64 bytes from 10.30.12.1: icmp_seq=1 ttl=255 time=0.146 ms

--- 10.30.12.1 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.146/0.294/0.442/0.148 ms
# cd /disk
# ftp -4 http://10.30.12.1/freebsd/9.0/base.txz
ftp: Can't lookup `10.30.12.1:http': servname not supported for ai_socktype
# ftp -4 http://10.30.12.1:80/freebsd/9.0/base.txz
Requesting http://10.30.12.1:80/freebsd/9.0/base.txz
54107736 bytes retrieved in 00:04 (11.12 MiB/s)
# md5 base.txz 
MD5 (base.txz) = 38d2dca70b768f6992e1cf11af663f0b
# tar xzpf base.txz
# echo '# Device               Mountpoint      FStype  Options         Dump    Pass#' > /disk/etc/fstab
# echo '/dev/ad0p1             none            swap    sw              0       0' >> /disk/etc/fstab 
# echo '/dev/ad0p2             /               ufs     rw              1       1' >> /disk/etc/fstab
# sed -i '' '/^ttyv/d' /disk/etc/ttys
# echo 'xc0     "/usr/libexec/getty Pc"         vt100   on  secure' >> /disk/etc/ttys

Le premier ftp est juste là pour montrer que sans /etc/services, il faut connaitre les numéros de port par coeur :) Arrivé à ce stade, on peut se caresser le pubis. Le plus dur est fait, il nous reste l'étape 5 (configuration). On peut:

récupérer des fichiers de configuration depuis le réseau
faire un chroot /disk (mais attention, le terminal n'est pas configuré, vi ne va pas aimer)
redémarrer le système: root ne possède pas de mot de passe

Je préfère personnellement la dernière solution, même si elle implique un reboot supplémentaire.

Le fichier de configuration final:

#kernel      = '/home/dsx/xen/freebsd-INSTALL_XEN_DOMU'
kernel      = '/home/dsx/xen/freebsd_XEN_DOMU'
memory      = '256'
disk        = [ 'phy:/dev/mapper/vg00-lv_freebsd,hda,w' ]
name        = 'xenfree.bsdsx.fr'
vif         = [ 'mac=00:16:3e:00:00:51,bridge=bridge0', 'mac=00:16:3e:00:01:51,bridge=bridge1' ]
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'
#extra       = 'console=hvc0,boot_verbose,kern.hz=100,vfs.root.mountfrom=ufs:/dev/md0p1'
extra       = 'console=hvc0,boot_verbose,kern.hz=100,vfs.root.mountfrom=ufs:/dev/ad0p2'

Pour conclure:

L'automatisation de l'installation peut se faire depuis un fichier /etc/rc que l'on aura pris soin de placer dans le ramdisk (attention à bien tout tester). Pour ma part, j'ai appris plein de trucs, donc mission accomplie :) Et cerise sur le gâteau, FreeBSD 9.1 est disponible !

Ps: les kernels sont disponibles ici.

Lien vers ce billet

20/04/2010

[ openwrt xen route ipv6 ]

201004202206 openwrt xen route ipv6

OpenWRT, Xen et ipv6

Dans un précédent billet, je décrivais ma configuration xen. Il ne me manquait qu'une seule chose: l'ipv6. Je dois bien avouer que ça ne s'est pas fait en un jour.

J'ai commencé par configurer mon routeur:

root@fonera# route -A inet6 add 2001:470:ca75:100::/64 gw 2001:470:ca75:20:224:1ff:fe0f:f84c

Où 2001:470:ca75:100::/64 est le réseau dédié aux hosts xen et 2001:470:ca75:20:224:1ff:fe0f:f84c l'ipv6 du dongle wifi du portable. Qui dit routage dit forwarding:

root@d531# grep forwarding= /etc/sysctl.conf
net.ipv6.conf.all.forwarding=1

Et pour éviter un message désagréable au boot:

root@d531# echo 'ipv6' >> /etc/modules

J'ai cru avoir une bonne idée en utilisant eth0 (qui me sert très peu) mais c'est vraiment une très mauvaise idée:

root@d531# tail -n 8 /etc/network/interfaces
auto eth0
iface eth0 inet static
    address 192.168.1.116
    netmask 255.255.255.0
iface eth0 inet6 static
    address 2001:470:ca75:100::1
    netmask 64

root@d531# ifconfig eth0 | grep inet6
      adr inet6: 2001:470:ca75:100::1/64 Scope:Global

root@d531# ping6 -c 1 -W 1 2001:470:ca75:100::1
PING 2001:470:ca75:100::1(2001:470:ca75:100::1) 56 data bytes

--- 2001:470:ca75:100::1 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

L'absence d'adresse lien-local ne doit pas être innocente dans cette affaire. Une (lllooonnnggggguuuuueeee) série de ping, reboot, man, google, ifup/ifdown plus tard, une idée me traverse la tête: pourquoi ne pas utiliser une interface virtuelle ?

root@d531# tail -n 8 /etc/network/interfaces
auto dummy0
iface dummy0 inet static
  address 10.0.0.1
  netmask 255.255.255.0
iface dummy0 inet6 static
  address 2001:470:ca75:100::1
  netmask 64

root@d531# ifconfig dummy0 | grep inet6
      adr inet6: 2001:470:ca75:100::1/64 Scope:Global
      adr inet6: fe80::9082:a4ff:fe06:92bc/64 Scope:Lien

root@d531# ping6 -c 1 -W 1 2001:470:ca75:100::1
PING 2001:470:ca75:100::1(2001:470:ca75:100::1) 56 data bytes
64 bytes from 2001:470:ca75:100::1: icmp_seq=1 ttl=64 time=0.030 ms

--- 2001:470:ca75:100::1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.030/0.030/0.030/0.000 ms

root@linuto# ping6 -n -c 1 2001:470:ca75:100::1
PING6(56=40+8+8 bytes) 2001:470:ca75:10:214:bff:fe80:337b --> 2001:470:ca75:100::1
16 bytes from 2001:470:ca75:100::1, icmp_seq=0 hlim=63 time=7.855 ms

--- 2001:470:ca75:100::1 ping6 statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 7.855/7.855/7.855/nan ms

It works! Passons à la configuration de xen. Le script vif-route ne prend pas en compte l'ipv6. Heureusement, je ne suis pas seul: http://notes.benv.junerules.com/all/software/xen-and-routed-ipv6/.

J'en profite pour proposer une version perless ici. On précise à xen qu'on utilise une autre interface qu'eth0:

root@d531# grep '\-route' /etc/xen/xend-config.sxp
(network-script 'network-route netdev=dummy0')
(vif-script     'vif-route netdev=dummy0')

Un dernier reboot pour vérifier que le tout survit à un redémarrage et c'est parti:

root@d531# grep vif /etc/xen/openwrt.bsdsx.fr.cfg 
vif         = [ 'ip=10.0.0.33 2001:470:ca75:100::33,mac=00:16:3E:6D:BB:94' ]

root@d531# xm create -c openwrt.bsdsx.fr.cfg
[ snip boot ]
root@OpenWrt:/# ifconfig br-lan|grep inet6
      inet6 addr: 2001:470:ca75:100::33/64 Scope:Global
      inet6 addr: fe80::ac65:afff:fed8:dcc4/64 Scope:Link

Et ça marche ?

root@linutop# traceroute6 -n  2001:470:ca75:100::33
traceroute6 to 2001:470:ca75:100::33 (2001:470:ca75:100::33) from 2001:470:ca75:10:214:bff:fe80:337b, 64 hops max, 12 byte packets
 1  2001:470:ca75:10::1  1.761 ms  1.73 ms  1.324 ms
 2  2001:470:ca75:20:224:1ff:fe0f:f84c  4.317 ms  9.467 ms  10.127 ms
 3  *^C

Hum, pas trop. Un coup de tcpdump plus tard et je me rends compte qu'il manque une route par défaut sur l'invité:

root@OpenWrt:/# ip -6 ro add default via 2001:470:ca75:100::1
root@OpenWrt:/# ping6 -c 1 www.kame.net
PING www.kame.net (2001:200:0:8002:203:47ff:fea5:3085): 56 data bytes
64 bytes from 2001:200:0:8002:203:47ff:fea5:3085: seq=0 ttl=52 time=314.763 ms

--- www.kame.net ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 314.763/314.763/314.763 ms

Un dernier tour sur http://wiki.openwrt.org/doc/uci/network pour enregistrer la route:

root@OpenWrt:/# tail -n 4 /etc/config/network 
config 'route6'
    option 'interface' 'lan'
    option 'target' 'default'
    option 'gateway' '2001:470:ca75:100::1'

Et voilà, c'est bon, servez chaud. Bon appétit.

Lien vers ce billet

03/04/2010

[ openwrt xen ]

201004032216 openwrt xen

OpenWRT et Xen

Depuis quelques temps, ce billet me trottait dans la tête. Petit récapitulatif:

le dom0 est une debian lenny 64 bits qui accède au réseau grâce au wifi
mon routeur est une fonera sous openwrt
j'ai envie de faire le foufou avec openwrt et des configs ultralight

Une recherche avec xen bridge wifi et me voila à configurer mes domU en mode routeur:

d531:~> grep script /etc/xen/xend-config.sxp | grep -v "^#"
(network-script network-route)
(vif-script     vif-route)

Mon interface eth0 ne me sert (presque) à rien:

d531:~> /sbin/ifconfig eth0 | grep 'inet adr'
      inet adr:10.0.0.1  Bcast:10.255.255.255  Masque:255.0.0.0

Afin que mes domU puissent accéder au nain ternet, j'ajoute une route sur mon routeur:

root@fonusb# route add -net 10.0.0.0 netmask 255.255.255.0 gw 172.16.10.116
root@fonusb# tail -n 5 /etc/config/network
config 'route' 'xen'
    option 'interface' 'wpa'
    option 'target' '10.0.0.0'
    option 'netmask' '255.255.255.0'
    option 'gateway' '172.16.10.116'

Où 10.0.0.0 est le réseau de mes domU, 172.16.10.116 l'ip de mon dom0 et wpa le nom logique de mon interface. Voir ici pour la configuration d'une route sous openwrt.

Concernant openwrt, mes tentatives de compilation sur ma machine 64 bits se sont soldées par un cuisant échec. J'ai opté pour une solution simple: un chroot 32 bits. La documentation ne manque pas, je ne vais pas détailler l'opération.

Une fois dans mon chroot et l'installation des paquets nécessaires, on peut commencer à jouer:

bsdsx@chroot> svn co svn://svn.openwrt.org/openwrt/trunk/
bsdsx@chroot> cd trunk
bsdsx@chroot> ./script/feeds update
bsdsx@chroot> make prereq

Et c'est parti pour une partie de coche-mi coche-moi:

Target System
  [x] x86
Subtarget
  [x] Xen Paravirt Guest
Global build settings
  [ ] Compile the kernel with Debug Filesystem enabled
Kernel modules
  Xen paravirtualized guest support
      [x] kmod-xen-evtchn
      [ ] kmod-xen-fbdev
      [x] kmod-xen-fs
      [x] kmod-xen-kbddev
      [x] kmod-xen-netdev

Une fois le make terminé, on installe le tout:

dsx@d531> sudo cp /usr/local/src/x86_32/home/bsdsx/src/svn/openwrt/trunk/bin/x86/openwrt-x86-ext2.fs /usr/local/xen/
dsx@d531> sudo cp /usr/local/src/x86_32/home/bsdsx/src/svn/openwrt/trunk/bin/x86/openwrt-x86-vmlinuz /usr/local/xen/

La configuration du domU:

dsx@d531:/etc/xen> cat /etc/xen/openwrt.bsdsx.fr.cfg 
kernel      = '/usr/local/xen/openwrt-x86-vmlinuz'
memory      = '32'
root        = '/dev/xvda1 rw'
disk        = [ 'file:/usr/local/xen/openwrt-x86-ext2.fs,xvda1,w', ]
name        = 'openwrt.bsdsx.fr'
vif         = [ 'ip=10.0.0.33,mac=00:16:3E:6D:BB:94' ]
gateway     = '10.0.0.1'
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'
extra       = 'console=hvc0 xencons=tty'

Et c'est parti (attention c'est rapide !):

dsx@d531> sudo xm create -c openwrt.bsdsx.fr.cfg
[ snip boot ]
root@OpenWrt:/# cat /proc/version 
Linux version 2.6.32.10 (dsx@d531.bsdsx.fr) (gcc version 4.1.2) #5 SMP Sat Apr 3 08:56:39 UTC 2010
root@OpenWrt:/# tail -n 7 /etc/config/network 
config interface lan
    option ifname   eth0
    option proto    static
    option ipaddr   10.0.0.33
    option netmask  255.255.255.0
    option gateway  10.0.0.1
    option dns      172.16.10.254

On retrouve dans la configuration:

10.0.0.1 l'ip de eth0 du dom0
172.16.10.254 l'ip du routeur où tourne un dnsmasq

Et ça marche ?

root@OpenWrt:/# ping -c 1 www.google.fr
PING www.google.fr (209.85.229.147): 56 data bytes
64 bytes from 209.85.229.147: seq=0 ttl=53 time=34.268 ms

--- www.google.fr ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 34.268/34.268/34.268 ms

Lien vers ce billet

08/10/2009

[ netbsd xen install ]

200910081111 netbsd xen install

Netbsd 5.0.1 et Xen

Le contexte:

HP ProLiant DL140
2 Xeon HT (32 bits)
4 Go de RAM
80 Go IDE (récup)
5 adresses IP
le tout derrière un squid

A la différence de nombreux tutos où on ne voit que les commandes qui marchent, je vais essayer de partager mes erreurs et mes réflexions.

Installation

Je ne vais pas recopier http://www.netbsd.org/docs/guide/en/chap-exinst.html mais une lecture attentive ne fera pas de mal.

Mes adaptations:

Figure 3.5. MBR partitions

J'ai choisi 'b: Use the entire disk'

Concernant les partition, un / et un swap suffiront pour l'instant.

Par contre, / sera formaté en ffsv2 et mounté avec l'option log (Figure 3.15. Disklabel partition editing)

Figure 3.6. Full or custom installation

Full, on sait jamais. Pour être honnête, vu le nombre de réinstallation que j'ai fait, j'ai parfois (souvent :) sélectionné Custom avec les sets pré-sélectionnés.

NetBSD est toujours aussi simple/rapide à installer.

Configuration

Un reboot plus tard et voila le dmesg.

/etc/rc.conf:
hostname=netbsd.domain.tld
ifconfig_bge0="inet 10.50.0.40 netmask 255.255.255.0"
defaultroute="10.50.0.100"
sshd=YES

/etc/ssh/sshd_config:
PermitRootLogin yes

netbsd# /etc/rc.d/network restart
netbsd# /etc/rc.d/sshd restart

Packages

Tant que je suis en mode découverte, pourquoi ne pas essayer pkgin ?

netbsd# export ftp_proxy=http://proxy.domain.tld:3128/
netbsd# export http_proxy=http://proxy.domain.tld:3128/
netbsd# pkg_info
netbsd# pkg_add -v ftp://ftp.fr.netbsd.org/pub/pkgsrc/packages/NetBSD/i386/5.0.1_2009Q2/All/pkgin-0.2.5.tgz
pkg_add: Can't process ftp://ftp.fr.netbsd.org:21/pub/pkgsrc/packages/NetBSD/i386/5.0.1_2009Q2/All/sqlite3*: Protocol error
pkg_add: no pkg found for 'sqlite3>=3.2.7nb1', sorry.
pkg_add: Can't install dependency sqlite3>=3.2.7nb1
pkg_add: 1 package addition failed

On va lui donner un coup de main:

netbsd# pkg_add -v ftp://ftp.fr.netbsd.org/pub/pkgsrc/packages/NetBSD/i386/5.0.1_2009Q2/All/sqlite3-3.6.14.2.tgz
bin/sqlite3
include/sqlite3.h
include/sqlite3ext.h
lib/libsqlite3.la
lib/libsqlite3.a
lib/libsqlite3.so
lib/libsqlite3.so.0
lib/libsqlite3.so.0.8.6
lib/pkgconfig/sqlite3.pc
man/man1/sqlite3.1
Package sqlite3-3.6.14.2 registered in /var/db/pkg/sqlite3-3.6.14.2
netbsd# pkg_add -v ftp://ftp.fr.netbsd.org/pub/pkgsrc/packages/NetBSD/i386/5.0.1_2009Q2/All/pkgin-0.2.5.tgz
Running install with PRE-INSTALL for pkgin-0.2.5.
bin/pkgin
man/man1/pkgin.1
share/examples/pkgin/repositories.conf.example
Executing '/bin/mkdir -p '/usr/pkg'/etc/pkgin'
Running install with PRE-INSTALL for pkgin-0.2.5.
pkgin-0.2.5: copying /usr/pkg/share/examples/pkgin/repositories.conf.example to /usr/pkg/etc/pkgin/repositories.conf
Package pkgin-0.2.5 registered in /var/db/pkg/pkgin-0.2.5
#========================================================================
$NetBSD: MESSAGE,v 1.1.1.1 2009/06/08 13:58:26 imil Exp $

First steps before using pkgin.

. Modify /usr/pkg/etc/pkgin/repositories.conf to suit your platform
. Initialize the database :

        # pkgin update

#========================================================================
netbsd# vi /usr/pkg/etc/pkgin/repositories.conf
netbsd# pkgin update
processing local summary...
updating database: 100%
downloading pkg_summary.bz2: 100%
processing remote summary (ftp://ftp.fr.netbsd.org/pub/pkgsrc/packages/NetBSD/i386/5.0.1_2009Q2/All/)...
updating database: 100%

Installation de Xen

On garde sous les yeux:

Et on y va:

netbsd# pkgin install xentools33
calculating dependencies for xentools33...
nothing to upgrade.
8 packages to be installed: ncurses-5.7nb1 readline-6.0 libffi-3.0.8nb2 python25-2.5.4nb1 py25-xml-0.8.4nb2 py25-readline-0nb4 py25-curses-0nb4 xentools33-3.3.1nb6 (14M to download, 59M to install)
proceed ? [y/N] y
...
netbsd# cp /usr/pkg/share/examples/rc.d/* /etc/rc.d/
netbsd# chmod 755 /etc/rc.d/xen*
netbsd# cd /dev && sh MAKEDEV xen

netbsd# pkgin install xenkernel33
calculating dependencies for xenkernel33...
nothing to upgrade.
1 packages to be installed: xenkernel33-3.3.1nb1 (828K to download, 828K to install)
proceed ? [y/N] y
...

netbsd# cp /usr/pkg/xen3-kernel/xen.gz /

On récupère depuis ftp://ftp.fr.netbsd.org/pub/NetBSD/NetBSD-5.0.1/i386/binary/kernel/

Tout le monde est là:

netbsd# ls /
.cshrc       cdrom       libexec                     proc        usr
.profile     dev         mnt                         rescue      var
altroot      etc         netbsd                      root        xen.gz
bin          kern        netbsd-INSTALL_XEN3_DOMU.gz sbin
boot         lib         netbsd-XEN3_DOM0.gz         stand
boot.cfg     libdata     netbsd-XEN3_DOMU.gz         tmp

netbsd# cat /boot.cfg
menu=Boot normally:boot netbsd
menu=Boot single user:boot netbsd -s
menu=Disable ACPI:boot netbsd -2
menu=Disable ACPI and SMP:boot netbsd -12
menu=Boot Xen dom0:load /netbsd-XEN3_DOM0.gz console=pc;multiboot /xen.gz dom0_mem=256M -s
menu=Drop to boot prompt:prompt
default=1
timeout=5

netbsd# reboot

On choisit manuellement la cinquième entrée et chocapik:

Mismatch between XEN and DOM0 kernel

On va lire [http://archive.netbsd.se/?ml=port-xen&a=2008-08&t=8360302], puis [http://www.netbsd.org/ports/xen/] et on se dit qu'on va attendre: "A new kernel XEN3PAE_DOM0 should show up in the next HEAD autobuild."

et c'est (re)parti:

netbsd# pkgin remove xenkernel33
netbsd# pkgin remove xentools33
netbsd# pkgin install xenkernel3
netbsd# pkgin install xentools3
netbsd# cp /usr/pkg/xen3-kernel/xen.gz /
netbsd# reboot

On choisit la cinquième entrée du menu de boot et hop un dmesg

netbsd# cp /usr/pkg/share/examples/rc.d/* /etc/rc.d/
netbsd# chmod 755 /etc/rc.d/xen*
netbsd# echo "xend=YES" >> /etc/rc.conf
netbsd# echo "xenbackendd=YES" >> /etc/rc.conf
netbsd# echo "xendomains=YES" >> /etc/rc.conf
netbsd# xend start
netbsd# xenbackendd

netbsd# cat /etc/ifconfig.bridge0
create
!brconfig $int add bge0 up

On modifie le script /usr/pkg/etc/xen/scripts/vif-bridge

netbsd# grep xbridge= /usr/pkg/etc/xen/scripts/vif-bridge
        #xbridge=$(xenstore-read "$xpath/bridge")
        xbridge=bridge0

Configuration des domU

netbsd# mkdir -p /home/xen
netbsd# dd if=/dev/zero of=/home/xen/netbsd-001.img bs=1m count=2k
netbsd# grep -v "^#" /usr/pkg/etc/xen/netbsd-001
kernel = "/netbsd-INSTALL_XEN3_DOMU.gz"
memory = 128
name = "netbsd-001"
vif = [ 'bridge=bridge0' ]
disk = [ 'file:/home/xen/netbsd-001.img,xbd0a,w', 'file:/home/xen/i386cd-5.0.1.iso,xbd1d,r' ]
root = "/dev/xbd0a"

Roulement de tambour:

netbsd# xm create -c /usr/pkg/etc/xen/netbsd-001
Error: Device 0 (vif) could not be connected. Hotplug scripts not working

On active le bridge0 sinon les domU ne se lance pas:

netbsd# /etc/rc.d/network restart

On installe tranquillou, minimal, depuis le cd qui est en _xbd1d_ et pas _cd0a_, et on finit par un


netbsd-001# halt -p

ctrl+] pour quitter la console du domU. On bascule sur le kernel normal:

netbsd# grep ^kernel /usr/pkg/etc/xen/netbsd-001
kernel = "netbsd-XEN3_DOMU.gz"

On boote le domU et voilà-t-y pas qu'il demande sur quoi booter :( On modifie /usr/pkg/etc/xen/netbsd-001

netbsd# grep ^root /usr/pkg/etc/xen/netbsd-001
root = "xbd0a"

Si au prochain reboot du dom0 pas de xen, on n'oublie pas de modifier l'entrée par défaut de /boot.cfg:

netbsd# grep ^default /boot.cfg
default=5

Poufinage domU

On a donc une image d'un domU non configurée. Pourquoi ne pas en profiter ?

netbsd# dd if=/home/xen/netbsd-001.img of=/home/xen/_netbsd.img

On pourra rapidement (re)faire un domU:

netbsd# dd if=/home/xen/_netbsd.img of=/home/xen/netbsd-002.img
netbsd# sed -e 's/001/002/' /usr/pkg/etc/xen/netbsd-001 > /usr/pkg/etc/xen/netbsd-002

Reste à commenter les lignes screen de /etc/wscons.conf et garder uniquement la console on dans /etc/ttys. Un peu de configuration:

netbsd-001# tail /etc/rc.conf
ifconfig_bge0="inet 10.50.0.41 netmask 255.255.255.0"
defaultroute="10.50.0.100"
hostname="netbsd-001.domain.tld"
sshd=YES
powerd=YES

netbsd-001# cat /etc/resolv.conf
domain domain.tld
search domain.tld
nameserver 192.168.0.2
nameserver 192.168.0.1
nameserver 192.168.0.3

Pour démarrer automatiquement notre domU:

netbsd# echo 'xendomains="netbsd-001"' >> /etc/rc.conf

A venir

Un seul disque n'est pas suffisant pour une mise en production. Je vais donc rajouter un disque et refaire une installation sur du raid 1 (mirroir).

Les fichiers utilisés comme device pour les domU je n'aime pas car on superpose les couches:

disque -> partition -> file system -> partition -> file system
           dom0         dom0           domU         domU

On ne dispose pas encore de LVM ni de ZFS (mais c'est en cours). Vu la quantité de RAM et le nombre d'IP disponibles, je vais pouvoir affecter une (des) partitions à mes 4 domU:

disque -> partition -> file system
           dom0         dom0

       -> partition -> file system
           domU         domU
       -> partition -> file system
           domU         domU
       -> partition -> file system
           domU         domU
       -> partition -> file system
           domU         domU

Le dom0 doit être un peu mieux configuré: sshd, pf, ntp, cache dns, centralisation des logs, un petit smartmontool, du symon (ou munin) et deux trois trucs qui facilitent la vie. En attendant un controleur SATA et deux disques de plus grosse capacité, amusez-vous bien avec NetBSD et Xen !

Lien vers ce billet