% tar -jx < *.bz

Beaucoup de technologies qui permettent de faire des tunnels IPv6 à travers un réseau IPv4 :

Quand on a un point de sortie, la technique idéale est 6in4, ou éventuellement IPsec en mode authentification (le chiffrement est peu intéressant, puisque couvrant uniquement la partie du trafic de la maison au point de sortie, et uniquement pour l'IPv6…).

Le serveur / point de sortie utilise lui-même des adresses IPv6. Le réseau côté maison a besoin d'au moins deux préfixes, pour le Wifi et pour le filaire. Or, OVH ne fournit aux kimsufi qu'un seul /64… Il va donc falloir découper en plusieurs morceaux. J'ai choisi /80, attribué comme suit :

Où :

• 2001:db8:a:b::/64 est le préfixe attribué au point de sortie ;
• le premier /80 est attribué aux différents services qui tournent sur la machine ;
• les /80 suivants pour la maison ;
• en vert le tunnel entre le routeur Wifi à la maison et le point de sortie ;

J'ai utilisé des adresses ULA pour les extrémités du tunnels, mais en fait il n'y en a pas vraiment besoin : une fois qu'on a commencé à découper notre /64, autant aller jusqu'au bout. Ça permet juste de bien reconnaître les adresses dans les fichiers de configuration et dans les tcpdump.

Il y a deux problèmes avec cette façon de faire. Le premier est évident : on utilise des préfixes qui font plus que /64. Cela nous fait essentiellement perdre les mécanismes d'auto-configuration sur les réseaux de la maison.

Le deuxième est un peu plus subtile. Le /64 fournit par OVH n'est pas vraiment routé jusqu'à nous. Si c'était le cas, tous les paquets à destination du /64 seraient livrés à 2001:db8:a:b::1 (par exemple), et notre routage interne avec les /80 lui serait transparent. À la place, le dernier routeur s'attend à être directement connecté à ce /64, et à pouvoir faire directement un NS et recevoir une réponse pour chaque adresse. Il va donc falloir mettre en place sur l'interface externe un proxy NDP, qui fera croire au routeur que toutes les adresses sont directement connectées.

Histoire d'avoir les ports déjà construits, on installe poudriere, la configuration se résume à pointer sur un FTP proche de chez nous. Ensuite on prépare un environnement pour 9.0 :

poudriere jail  -c -v 9.0-RELEASE -a amd64 -j poudre90
poudriere ports -c

On récupère la liste des ports installés, et tant qu'on y est on récupère aussi leur configuration pour que poudriere reconstruise les ports avec les bonnes options.

(pkg_version -o; jexecall pkg_version -o) >portlist
sort <portlist| uniq >portlistuniq
cut -d' ' -f1 <portlistuniq >portlist
cp -r /srv/jails/*/var/db/ports/* /usr/local/etc/poudriere.d/options
poudriere bulk -f portlist

Pendant que poudriere mouline, on installe FreeBSD 9.0 sur un système de fichiers à part.

zfs create zroot/slash90
zfs set mountpoint=/slash90 zroot/slash90
zfs create zroot/slash90/usr

cd /slash90
fetch http://ftp.fr.freebsd.org/pub/FreeBSD/releases/amd64/amd64/9.0-RELEASE/{base,kernel,src}.txz
tar -xpf base.txz
tar -xpf kernel.txz
tar -xpf src.txz

Pour les fichiers de configuration, on va copier la configuration depuis notre environnement actuel vers l'installation toute fraîche, puis lancer un coup de mergemaster(8) :

cd /slash90/etc
cp -a /etc/ .
chroot /slash90
mergaster -FUvi

On profite également d'être dans un chroot dans /slash90 pour installer les ports qu'on vient de construire.

La configuration réseau a un peu changé. Une configuration avec plusieurs addresses dans chaque famille ressemble à :

ifconfig_nfe0="inet 203.0.113.13/24"
defaultrouter="203.0.113.254"
ifconfig_nfe0_ipv6="inet6 2001:db8:1:8248::1/64 accept_rtadv"
rtsold_enable="YES" # ou ipv6_defaultrouter="fe80::f00:baa%nfe0"

ifconfig_nfe0_alias0="inet  198.51.100.43/32"
ifconfig_nfe0_alias1="inet6 2001:db8:1:8248::25"
ifconfig_nfe0_alias2="inet6 2001:db8:1:8248::53"

ipv6_network_interfaces n'est plus nécessaire.

On copie également /usr/local/etc dans /slash90.

Pour basculer d'un environnement vers l'autre, il suffit¹ de faire :

zfs set canmount=noauto zroot/slash82
zfs set canmount=noauto zroot/slash82/usr

vi /slash90/boot/loader.conf
# Ajouter : zfs_load="YES"
# et : vfs.root.mountfrom="zfs:zroot/slash90"
zfs unmount zroot/slash90
zfs unmount zroot/slash90/usr
zfs set mountpoint=/ zroot/slash90
zfs set mountpoint=/usr zroot/slash90/usr
zpool set bootfs=zroot/slash90 zroot

Dans mon cas, l'environnement actuel est installé dans zroot/slash82, avec /usr qui est dans zroot/slash82/usr. Si la racine du système est directement à la racine du pool ZFS, il y aura quelques subtilités, si on passe zroot en noauto il faudra penser à modifier les autres points de montage par exemple. De plus, chez moi /var est dans zroot/var, monté automatiquement par ZFS, donc il n'y a pas besoin de le déplacer.

Au premier essai, ma kimsufi n'a pas démarré. Un peu d'investigation via le le mode rescue-pro d'OVH (un simple netboot avec les disques accessibles) ne donne rien. Un zpool import -o altroot=/mnt plus tard, on refait la bascule dans l'autre sens (en utilisant zroot/slash82), et on retrouve une machine qui boote.

Le lendemain, je retente l'opération, cette fois en vKVM (une machine virtuelle qui démarre sur le disque dur du serveur), et là… le démarrage se passe correctement. Je ne sais pas pourquoi au premier essai, les choses se sont bloquées au boot.

Après un peu d'exploration, on voit qu'il y a certaines choses qui ont été « perdues » :

• ce qui est dans /root (un script de sauvegarde, par exemple) ;
• ce qui est dans /usr/local. J'ai pensé aux ports et à leur configuration, mais j'ai laissé de côté le RTM d'OVH, les dossiers de données de poudriere… ;
• /home (qui ne contenait guère que ~fred/.ssh/authorized_keys d'intéressant).

Il suffit de monter zroot/slash82 (qui est actuellement en canmount=noauto) pour avoir accès à ses données et les réinstaller.

On pourrait tout à fait adopter la même procédure : installer dans un système de fichiers à part, y compris les ports, rapatrier les configurations, et pointer ezjail vers la nouvelle installation. La mise à jour en place semble plus simple, et tellement moins risquée que pour la machine hôte…

ezjail-admin update -s 8.2-RELEASE -U

Attention, freebsd-update essaie de mettre à jour le noyau, il faut le relancer à la main une deuxième fois.

Malheureusement, il faut lancer à la main mergemaster pour chacune des jails (et tant qu'on y pense, mettre à jour le gabarit d'ezjail).

Pour les ports, grâce à la préparation faite plus haut, on a déjà des packages binaires à jour pour nos jails, et il suffit de lancer un jexecall portmaster -a pour tout mettre à jour.

Le passage à 9.0 n'a pas été aussi facile qu'attendu. En particulier, je ne sais pas pourquoi le premier démarrage n'a pas réussi du premier coup, et si c'est dû à l'utilisation de ZFS ou pas. De plus, la méthode que j'ai suivie n'était pas idéale —je suppose qu'en ayant de vraies procédures de backup-restore, je n'aurais pas oublié RTM ou les scripts qui traînent dans /root. D'un autre côté, le paramètre bootfs plus jouer un peu avec les points de montage permet de basculer facilement d'une installation à l'autre ; c'était une promesse de ZFS, et cette promesse est tenue. Au premier essai, c'est ce qui m'a permis de revenir sur une configuration fonctionnelle.

Je regrette de ne pas avoir adopté poudriere plus tôt.

Cette partie est largement une reprise du wiki de FreeBSD sur l'installation d'un système en ZFS.

Cependant :

• on ne boote pas sur l'ISO d'installation,
• on boote sur une racine qui est en NFS lecture seule.

Il va donc falloir ruser (un peu) pour récupérer les paquets d'installation.

On boote alors sur le rescue-pro, on a bien sûr pris soin de donner sa clef publique SSH pour ne pas avoir à attendre le mail avec les identifiants.

Je n'ai pas réussi à installer ZFS en utilisant une table de partition MBR, alors que ça a marché du premier coup avec du GPT. Il paraît que GPT est la voie du futur, alors hop.

On détruit avec gpart destroy le partitionnement en place, et on recrée un nouveau schéma :

gpart create -s gpt ad4
gpart add -s 64K -t freebsd-boot ad4
gpart add -s 2G -t freebsd-swap -l swap ad4
glabel label swap ad4p2
gpart add -t freebsd-zfs -l data ad4
glabel label data ad4p3
gpart show

Autre possibilité : ne pas faire de partition de swap, mais créer un volume ZFS de swap. D'après la page du Wiki FreeBSD citée plus haut, ça empêche de créer des dumps lors d'un crash. En l'absence d'autres arguments, je suis parti sur une partition de swap à part.

Récupérer les fichiers d'installation. On crée un volume en tmpfs, et on ignore couragement l'avertissement qui apparaît dans le dmesg :

mkdir /root/sets
mount -t tmpfs -o size=300000000 dummy /root/sets
dmesg | tail
=> WARNING: TMPFS is considered to be a highly experimental
   feature in FreeBSD.

cd sets
ftp ftp.fr.freebsd.org
cd pub/FreeBSD/releases/amd64/8.2-RELEASE
!mkdir base kernels
mget base/* kernels/*

Dans mon cas, j'installe juste un hôte minimal pour des jails. Pour un serveur traditionnel, vous voudrez certainement installer les autres sets, mais au pire cela se fait très bien une fois l'installation terminée.

On crée le volume ZFS :

mkdir /root/newinstall
zpool create -m /root/newinstall zroot /dev/gpt/data
zpool set bootfs=zroot zroot

On crée les sous-volumes ZFS :

zfs create zroot/usr
zfs create zroot/var

zfs list

On devrait voir zroot monté dans /root/newinstall, zroot/var dans /root/newinstall, etc.

Encore une fois, pour un serveur complet on voudra peut-être créer d'autres volumes ZFS pour une séparation plus fine, peut-être un /var/log compressé ou un /var/empty en RO… Voir l'article du wiki de FreeBSD pour une idée de partitionnement possible. /home avec des quotas (voire un volume par luser) est une très bonne idée de chose à ajouter si on prévoit d'avoir d'autres utilisateurs.

Par contre, mettre la racine (de notre serveur) dans la racine (de notre pool ZFS) n'est pas forcément une très bonne idée. Heureusement, on peut corriger cela plus tard.

On installe le monde de base plus le noyau GENERIC :

setenv DESTDIR /root/newinstall
cd /root/sets
cd base ; sh install.sh ; cd ..

cd kernels ; sh install.sh generic ; cd ..
cd /root/newinstall/boot
rm -fr kernel
mv GENERIC kernel

chroot /root/newinstall

echo /dev/label/swap none swap sw 0 0 > /etc/fstab
echo 'zfs_load="YES"' > /boot/loader.conf
echo 'vfs.root.mountfrom="zfs:zroot"' >> /boot/loader.conf

vi /etc/rc.conf

sshd_enable="YES"
ntpdate_enable="YES"
ntpdate_hosts="213.186.33.99"
fsck_y_enable="YES"
named_enable="YES"
ifconfig_nfe0="inet 198.51.100.43/24"
defaultrouter="94.23.42.254"
hostname="foo.example.net"
zfs_enable="YES"

Mettre un mot de passe pour root (passwd), et se créer un utilisateur (adduser et répondre aux questions). Noter que par défaut sshd refuse les connexions en tant que root, donc créer un utilisateur mortel et le placer dans le groupe wheel est certainement une bonne idée.

Quitter le chroot.

On va installer le bootloader ZFS-capable. Là j'ai eu une surprise : ZFS s'est mis à utiliser toute la RAM, ce qui est normal vue l'installation qu'on vient de réaliser, mais au détriment de notre partition tmpfs, ce qui est étonnant étant donné qu'on a donné une réservation. Donc, j'ai démonté / remonté mon pool ZFS, mon tmpfs a retrouvé une taille normale, et j'ai pu récupérer le bootloader pour l'installer :

zpool export zroot
zpool import zroot
cp /root/newinstall/boot/pmbr /root/sets
cp /root/newinstall/boot/gptzfsboot /root/sets

zpool export zroot
gpart bootcode -b /root/newinstall/boot/pmbr -p /root/newinstall/boot/gptzfsboot -i 1 ad4
zpool import zroot

Il est peut-être possible d'installer le bootloader sans démonter le pool, je n'ai pas essayé. Il doit aussi certainement être possible d'utiliser celui est dans le /boot de l'environnement fourni par OVH, je n'y ai pas pensé sur le moment…

Il semble que ZFS ait besoin d'un cache pour booter correctement. Je n'ai pas trouvé d'articles expliquant quelle est l'utilité du cache et ce qui se passe s'il n'est pas disponible au boot.

zpool set cachefile=/root/newinstall/boot/zfs/zpool.cache

On remet les points de montage au bon endroit :

zfs set mountpoint=legacy zroot
zfs set mountpoint=/usr zroot/usr
zfs set mountpoint=/var zroot/var
zpool set bootfs=zroot zroot
zfs unmount -a

Et là on croise les doigts et on reboote.

Ceci permet de faire plusieurs choses :

• appliquer une réservation d'espace pour la racine ;
• lorsqu'une nouvelle MàJ va arriver, il suffira de l'installer dans un nouveau dataset et de dire au bootloader de prendre l'autre dataset.

Let's roll.

On copie notre racine actuelle dans un autre volume :

zfs snapshot zroot@1 zfs
send zroot@1 | zfs receive zroot/slash
zfs destroy zroot@1

Même chose pour /usr :

zfs snapshot zroot/usr@1
zfs send zroot/usr@1 | zfs receive zroot/slash/usr
zfs destroy zroot/usr@1

Bien sûr, même chose pour les autres FS si vous avez partagé votre /usr en morceaux.

Il m'a été indiqué que renommer zroot/usr dans zroot/slash/usr (avec zfs rename) est plus rapide, et surtout évite d'oublier un volume si /usr a été fractionné.

On indique qu'on veut booter sur zroot/slash :

zpool set bootfs=zroot/slash
vi /slash/etc/loader.conf

Et on ajuste la valeur de vfs.root.mountfrom.

On veut aussi changer notre /usr :

zfs set canmount=noauto zroot/usr
zfs set mountpoint=/usr zroot/slash/usr

À ce moment, on a deux volumes montés sur /usr. Ça marche, mais c'est un peu bancal ; on va donc rebooter de suite. Quand la machine revient, on vérifie avec zfs list et mount que tout est bien monter là où on l'attend (l'un montre la configuration des points de montage, et l'autre montre les vrais montages). On voit que zroot/slash a un mountpoint qui vaut /slash, mais est monté à / en vrai. Je ne sais pas à quel point ça peut être gênant.

Pour vérifier que le volume zroot n'est plus directement utilisé, on va le vider puis vérifier que la machine revient au reboot :

zfs set mountpoint=/whatever zroot
chroot /whatever
rm -fr *
# oups, il y a des fichiers avec l'option schg...
^D
chflags -R noschg /whatever
rm -fr /whatever/*
zfs set mountpoint=none zroot
rmdir /whatever
zfs destroy zroot/usr
reboot

(Attention si vous avez d'autres volumes qui héritent leur point de montage depuis zroot !)

Notez que je n'ai pas déplacé /var, qui ne sera pas concerné par les mises à jours. C'est peut-être un choix discutable.

Ensuite, il nous reste toutes les actions habituelles d'une installation FreeBSD :

• configurer /etc/rc.conf pour activer les services que l'on veut ;
• installer des jails pour nos serveurs qui vont parler au publique ;
• ajouter l'arbre des ports pour installer des logiciels ;
• (optionnellement) installer RTM d'OVH : http://guide.ovh.com/RealTimeMonitoring ;

Et moultes autres activités :)

Il y a quelques cas où on n'a presque rien à faire pour bénéficier de la complétion sur un nouvel outil. Par exemple, si un outil utilise les conventions GNU, zsh peut parser la sortie de --help pour obtenir la liste des options existantes. Il suffit pour cela d'ajouter quelque chose comme :

compdef _gnu_generic foo

dans un fichier lu par zsh (.zshrc conviendra), et de relancer son shell pour pouvoir compléter les options de foo. On a même le droit à la documentation des options.

Un autre cas où l'on n'a presque rien à faire est lorsqu'on peut réutiliser une complétion existante. Si un outil attend comme argument uniquement des noms d'hôtes, on utilisera :

compdef _hosts foo

Maintenant, en tapant foo <TAB>, zsh proposera des complétions basées sur les noms d'hôtes, trouvés par `getent hosts` ou qui sont dans l'une des bases ssh_known_hosts entre autres.

Dans l'exemple au-dessus, _hosts est le nom d'une fonction zsh, dont la définition est (sur mon système) dans /usr/local/share/zsh/4.3.11/functions/Completion/Unix.

La documentation de zsh donne un autre exemple assez courant : le cas d'une commande qui accepte tous les fichiers qui ont une certaine extension.

compdef '_files -g "*.h"' foo

Ici, _files est encore une fonction, définie au même endroit que _hosts (et bon courage à celui qui voudra se plonger dans le code de cette fonction…). La documentation de cette fonction est visible dans le manuel de zsh, au nœud «  Completion Functions > Utility Functions  ».

Lorsqu'on a des besoins plus poussés, au hasard pour un outil tel qu'ezjail, on va devoir coder sa propre complétion. Une complétion n'est en soi qu'une fonction zsh qui est appelée par le shell lorsque l'utilisateur appuie sur TAB (ou C-d pour afficher les complétions).

Les fonctions de complétions sont installées par défaut dans /usr/local/share/zsh/site-functions/ (l'emplacement exact peut dépendre de votre OS). Par convention, le fichier dans lequel vous allez écrire votre fonction de complétion a le même nom que la commande concerné, avec un _ ajouté au début.

Lors du développement d'un fichier de complétion, il sera peut-être plus pratique de pouvoir éditer le fichier sans être root. Dans ce cas, il suffit de choisir un dossier local, par exemple ~/zsh. On placera le fichier de complétion dedans, et on l'ajoute au tableau $fpath (bien sûr, à placer avant l'appel à compinit) :

fpath=(~/zsh $fpath)

Notons que zsh refusera de charger des fonctions (donc des définitions de complétion) si le fichier appartient à un utilisateur autre que root ou l'utilisateur courant, ou s'il est modifiable par un autre utilisateur.

Le fichier de complétion commence avec un tag spécial sur la première ligne :

#compdef ezjail-admin

C'est un commentaire, qui indique à zsh que le fichier contient une complétion, et bien sûr quelle commande est concernée.

Ensuite, on définit une fonction de complétion, et on l'appelle :

_ezjail () {
    # code de complétion
}

_ezjail "$@"

A User's Guide to the Z-Shell, Peter Stephenson, Chapter 6: Completion, old and new. Il y a en particulier un tutorial bien fait.

The Z Shell Manual, 20. Completion System, et en particulier 20.6 Utility Functions. Vous en avez certainement une version accessible en local avec info zsh (ou C-h i m zsh depuis emacs). Le manuel est assez aride, je ne l'ai utilisé que comme référence.

zsh completion support for ezjail, de votre serviteur.

Quelques petits rappels pour les malheureux Linuxiens qui ne connaîtraient pas les jails de FreeBSD. Les jails de FreeBSD sont parfois comparées à des chroot sur stéroïdes ; maintenant que Linux a des choses telles qu'OpenVZ ou LXC, il faudrait plutôt utiliser cela comme comparaison.

Les jails pour FreeBSD ont été introduites dans FreeBSD 4.0 (mars 2000) par Poul-Henning Kamp (le développeur derrière UFS2 et pas mal de code tournant autour du stockage disque, l'auteur du malloc(3) de FreeBSD, du cache Varnish, et l'inventeur de l'expression bikeshedding). Une jail est définie par :

• un dossier racine ;
• un nom d'hôte ;
• optionnellement une ou plusieurs adresses IP ;
• une commande, qui est typiquement /etc/rc pour lancer un FreeBSD complet.

Depuis l'intérieur de la jail, il est impossible de sortir du dossier racine, contrairement à un chroot(2). Les processus tournant à l'intérieur de la jail ne peuvent utiliser que les adresses IP attribuées par l'administrateur pour se connecter ou accepter des connexions externes.

Le dossier attribué à une jail peut être tout petit (une dizaine de fichiers, comme le décrit Bapt dans ses NANO Jails), ou contenir un système FreeBSD complet (voire un système CentOS, en utilisant la couche d'émulation de Linux).

Pour des jails contenant un système FreeBSD complet, on voit qu'il peut rapidement y avoir quelques difficultés d'administration :

• une approche naïve conduirait à avoir autant d'installations de FreeBSD que de jails, ce qui est gourmand en espace disque (et en consommation mémoire, les bibliothèques dynamiques ne pouvant pas être partagées) ;
• lorsqu'une mise à jour est publiée, il faut réaliser autant de mises à jour que de jails ;
• même si créer une jail est facile et se fait en environ 6 lignes, cela pourrait être encore plus simple.

ezjail propose une solution à tout cela, et notamment aux deux premiers points en utilisant mount_nullfs(4) (l'équivalent du mount -o bind de Linux) pour fournir à toutes les jails une unique installation de FreeBSD en lecture seule ; cette installation est appelée la basejail. ezjail a un certain nombre d'autres fonctionnalités, que je ne déveloperai pas ici.