Clonage de FreeBSD en 2016

Il y a presque six ans, j'ai publié Clonage de FreBSD, qui rassemble mes notes sur la fabrication d'un disque bootable à partir d'un FreeBSD existant, en branchant le futur disque système cible comme une unité de stockage externe sur le système hôte.

Depuis je me suis servie moult fois de ces notes, dont un fois pas plus tard qu'il y a deux semaines, pour l'arrivée de Tsuiraku. J'ai vu au fil du temps mes pratiques s'écarter de mes vieilles notes, À tel point qu'il m'a semblé utile cette fois-ci de refaire un billet avec la dernière version de la procédure et mes commentaires sur l'évolution depuis mon billet précédent.

Ce billet ne suppose pas la lecture du billet d'il y a six ans, par contre des notions de gestion ou d'administration système FreeBSD seront nécessaires.

Rappel du contexte

J'ai donc machine cible, en l'occurrence Tsuiraku, qui existe matériellement mais qui n'a pas encore de système d'exploitation.

J'ai aussi une machine hôte, en l'occurrence Yulai, qui fonctionne sous FreeBSD, qui a accès à internet et sur laquelle est branché le disque système de la machine cible, en tant que stockage externe, qui se trouve être /dev/da0.

Une particularité de Tsuiraku est d'être refroidi passivement. Pour faciliter la circulation d'air, j'utilise une clef USB comme disque système, au lieu d'utiliser l'emplacement 2.5" au dessus du processeur.

(Re)partitionnement du disque

Il y a six ans, je créais le pool directement sur le disque, en suivant des recommandations venues de Solaris, ce qui revient à sauter cette étape. Non seulement ce n'est pas utile pour FreeBSD, mais parfois ça pose des problèmes au niveau de la swap et/ou du bootloader.

# gpart delete -i 1 da0
# gpart destroy da0

La clef USB cible était livrée pré-formattée, donc il a fallu détruire la partition existante avant re répartir sur des bases saines.

# gpart create -s gpt da0
# gpart add -s 64K -t freebsd-boot da0
# gpart add -s 4G -t freebsd-swap -l swap1 da0
# gpart add -t freebsd-zfs -l disk1 da0

Il y a six ans je copiais sauvagement le booloader à coups de dd, mais comme j'utilise maintenant gpart, autant le faire à ce stade avec les autres commandes gpart:

# gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0

Notons cependant que cette commande installe le bootloader de l'hôte. Dans mon cas ce n'est pas un problème, car l'hôte et la cible sont tous les deux des 10.3-RELEASE, mais une différence significative pourrait justifier de télécharger les tarballs avant ce stade pour utiliser un bootloader cohérent avec le reste du système.

Chiffrement du disque

Philosophiquement, je suis de plus en plus partisane du chiffrement généralisé de mes supports de stockage, si possible avec un bouton « panique » qui coupe le courant et/ou détruit la clef, et/ou un jeux de mots de passe qui détruisent la clef au lieu de déchiffrer, et/ou des zones chiffrées niables

En pratique, c'est une image expérimentale pour une machine dont j'ignore les performances de chiffrement, donc autant expérimenter sur un système en clair.

D'autre part, je peux imaginer plusieurs scénarios où je serais contente de voir cette machine redémarrer complètement après une coupure de courant, sans intervention physique de ma part. J'imagine que ça se résoudrait avec le système d'exploitation en clair et le home chiffré, mais ça rend beaucoup plus difficile de s'assurer que des informations importantes ne se retrouvent pas dans la zone en clair.

Bref, j'ai couardement laissé tomber le chiffrement dans cette procédure, mais j'écris ce paragraphe pour me rappeler de ce problème à chaque fois que je verrai ces notes. Je mettrai à jour cette section quand j'aurai une solution satisfaisante.

Création du système de fichiers

J'ai pas mal changé le partitionnement. J'ai cherché l'intérêt de découper base, et faute de le trouver j'ai tout simplement arrêté. Je suis donc repartie de mes besoins et mes usages pour justifier mes découpages.

# zfs create ztsuiraku/root
# zfs create ztsuiraku/root/usr.local
# zfs create ztsuiraku/root/usr.local/db
# zfs create ztsuiraku/root/var
# zfs create ztsuiraku/root/var/log
# zfs create ztsuiraku/home
# zfs create ztsuiraku/home/nat
# zfs create ztsuiraku/reserve

D'abord, je veux séparer le système d'exploitation de mes données perso', pour pouvoir changer le premier sans toucher au second, et sauvegarder le second sans gaspiller des ressources sur le premier. D'où root et home.

home est découpé par politique de sauvegarde et d'utilisation, soit en première approximation par utilisateur.

root contient essentiellement le système de base, et je laisse tout ensemble pour les systèmes de courte espérance de vie, par exemple ma 11.0-BETA1.

Sinon son premier découpage est les répertoires demandant une politique spéciale, comme nosetuid ou un quota. En gros, /tmp, /var/tmp et /var/log. Je n'ai pas mis les tmp ici à cause du support clef USB, ils seront en mfs à la place.

Je sépare aussi les ports du système de base, avec root/usr.local qui sera monté sur /usr/local et root/usr.local/db monté sur /var/db/pkg. L'idée est de pouvoir snapshot et rollback des ports, par exemple lors de l'expérimentation de nouvelles options ou d'une nouvelle version à proposer. On m'a confirmé que ça ne suffit pas forcément, les ports peuvent faire à peu près n'importe quoi n'importe où, mais c'est ce qu'on peut faire de mieux sans snapshot tout root (ce qui reste possible avec cette construction).

J'ai re-séparé /var pour essayer une politique particulière décrite plus bas.

Enfin, ZFS a de gros problèmes quand le pool est presque plein. Il parait que c'est le cas avec tous les systèmes de fichiers qui essayent d'éviter intelligemment la fragmentation, mais j'ai cru comprendre que c'est encore pire avec ZFS. Pour éviter de trop remplir le pool, j'ajoute un FS vide auquel 10% du pool sont réservés.

J'imagine que j'aurais pu créer les fs directement avec les options ci-dessous, mais je préfère les lignes plus courtes et les explications séparées.

# zfs set compression=on ztsuiraku/home
# zfs set compression=on ztsuiraku/root
# zfs set compression=gzip-9 ztsuiraku/root/var/log

La compression, c'est bien et ce n'est pas cher. Enfin, j'espère. Je ne sais pas trop ce que ça donne sur un Celeron basse puissance, mais j'espère que c'est encore valable, surtout avec un système sur USB.

Je ne sais pas à quel point gzip-9 l'emporte sur simplement on quand on est certain d'avoir majoritairement du texte, comme c'est le cas pour /var/log.

# zfs set sync=disabled ztsuiraku/root/var

Il parait que désactiver la synchronisation sur /var aide les performances des systèmes sur clef USB. Ça me semble quand même plutôt dangereux, mais en même temps je ne sais as ce qui utilise vraiment /var, donc je suppose que je vais le découvrir à l'usage.

# zfs set reservation=3G ztsuiraku/reserve

La réserve pour empêcher le pool de dépasser 90% d'utilisation. Je me demande si je pourrais garantir la non-utilisation du FS en ajoutant un quota nul ou très faible, mais pour en vérifier l'efficacité il faudrait une expérimentation trop pénible à mettre en œuvre. Déjà que je n'ai jamais été en situation de vérifier que la réservation fonctionne bien…

Installation et configuration de FreeBSD

Il y a six ans, il était de compilation, en plus d'installation et de configuration. Ça ne m'amuse plus vraiment de compiler, et les paquets binaires aussi bien que les mises à jour binaires ont fait leurs preuves depuis.

Donc je ne compile plus, je télécharge directement les binaires.

# fetch ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/10.3-RELEASE/base.txz
# fetch ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/10.3-RELEASE/doc.txz
# fetch ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/10.3-RELEASE/kernel.txz
# fetch ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/10.3-RELEASE/lib32.txz

# tar -xvC /ztsuiraku/root -f base.txz
# tar -xvC /ztsuiraku/root -f doc.txz
# tar -xvC /ztsuiraku/root -f kernel.txz
# tar -xvC /ztsuiraku/root -f lib32.txz

Il faudrait sans doute que j'ajoute entre le téléchargement et l'extraction une étape de vérification des archives. Je pense sincèrement que ce n'est pas de la paranoïa que de faire cette vérification avec ce que l'on sait du monde actuel. Par contre ça demande de réfléchir fort à comment vérifier utilement, donc un modèle d'attaquant et tout et tout. La flemme l'emporte, et je mets un paragraphe pour me rappeler de le faire à chaque fois que je relirai ces notes, au lieu de le faire tout de suite.

Pour la configuration, il y a six ans je n'avais mis que la liste des fichiers à modifier, mais j'ai trouvé pénible de réinventer à chaque fois leur contenu, donc cette fois que vais le mettre avec.

# cat >/ztsuiraku/root/boot/loader.conf <<-EOF
vfs.root.mountfrom="zfs:ztsuiraku/root"
zfs_load="YES"
kern.hz=100
EOF

Du full ZFS classique, avec un kern.hz pour une utilisation interactive et basse consommation.

# cat >/ztsuiraku/root/etc/rc.conf <<-EOF
hostname="tsuiraku"

ifconfig_DEFAULT="DHCP"

devfs_system_ruleset="localrules"

kld_list="aesni coretemp"
ntpd_enable="YES"
ntpdate_enable="YES"
sendmail_enable="NONE"
sshd_enable="YES"
tmpmfs="YES"
tmpsize="1g"
zfs_enable="YES"
EOF

Pour celui-là, j'ai un peu triché, parce que je n'avais aucune idée du type d'interface réseau dans la machine avant le premier boot, donc en fait la ligne ifconfig_re0 a été ajoutée dans un deuxième temps.

Correction : on peut arranger ce problème de divination en mettant ifconfig_DEFAULT au lieu de ifconfig_re0, et j'ai mis à jour le code ci-dessus dans ce sens. Mille mercis à Olivier de me l'avoir soufflé et de m'avoir rappelé qu'il faut charger aesni explicitement (même si en fait le Celeron J1800 de Tsuiraku n'a pas le support).

En plus des mes trucs habituels, il y a le tmpmfs que j'ai évoqué plus haut. J'ai mis 1g plus ou moins au hasard, je verrai à la longue si c'est trop peu (et peut-être si c'est trop, quoique ça risque d'être moins facile à percevoir).

Ajout : J'ai désactivé sendmail dans le rc.conf ci-dessus, mais je n'ai jamais tenu compte des conséquences de l'absence de MTA sur mes machines de bureau, surtout par rapport à periodic.

# mkdir /ztsuiraku/root/var/log/periodic
# cat >/ztsuiraku/root/etc/periodic.conf <<-EOF
daily_output=/var/log/periodic/daily-$(date +%F).log
weekly_output=/var/log/periodic/weekly-$(date +%F).log
monthly_output=/var/log/periodic/monthly-$(date +%F).log
daily_status_security_inline="YES"

daily_clean_hoststat_enable="NO"
daily_status_mail_rejects_enable="NO"
daily_status_include_submit_mailq="NO"
daily_submit_queuerun="NO"

daily_scrub_zfs_enable="YES"
daily_status_smart_devices="AUTO"
EOF

Le premier bloc élimine toutes les sorties par e-mail, et concentre tout dans /var/log/periodic. Le deuxième bloc recopie bêtement les recommandations pour ceux qui n'utilisent pas sendmail comme MTA. Il faudra d'ailleurs que je vérifie comment ça évolue avec l'arrivée de DMA dans base. Le dernier bloc contient mes ajustements personnels : un scrub et un test SMART périodiques. Même si en vrai, la clef USB de Tsuiraku n'a pas l'air de supporter SMART, donc je n'ai pas mis la dernière ligne, et j'hésite à augmenter l'intervalle entre deux scrubs, mais il me semble que c'est surtout de la lecture, donc ça ne devrait pas trop user la clef. Fin d'ajout

# cat >/ztsuiraku/root/etc/devfs.rules <<-EOF
[localrules=5]
add path 'da*' mode 0660 group operator
EOF

# cat >>/ztsuiraku/root/etc/sysctl.conf <<-EOF
vfs.usermount=1
hw.acpi.cpu.cx_lowest=C3
dev.cpu.0.cx_lowest=C3
dev.cpu.1.cx_lowest=C3
EOF

Le usermount standard, et l'activation des gros C-states pour continuer dans le thème basse consommation.

# cat >/ztsuiraku/root/etc/fstab <<-EOF
/dev/da0p1                      none            swap    sw 0 0
ztsuiraku/root/var              /var            zfs     rw 0 0
ztsuiraku/root/var/log          /var/log        zfs     rw 0 0
ztsuiraku/root/usr.local        /usr/local      zfs     rw 0 0
ztsuiraku/root/usr.local/db     /var/pkg/db     zfs     rw 0 0
EOF

C'est parfois un peu fastidieux de mettre tous les systèmes de fichiers dans /etc/fstab, mais je n'ai pas trouvé d'autre façon de changer facilement de système de base. Comme /etc/fstab est dans /, il suffit de changer le bootfs du pool pour passer sur une autre base. Avec tout ce que j'ai jonglé entre la 10.3-RELEASE, les 11.0-BETA et les CFT, je suis plutôt contente d'avoir fait comme ça.

Ajout :

# cat >/etc/syslog.conf <<-EOF
*.err;kern.warning;auth.notice;mail.crit                /dev/console
*.*     @172.22.0.2
EOF

Dans le cas particulier de Tsuiraku, qui sera éventuellement amené à se reproduire donc je le note ici, je préfère envoyer les logs système sur le réseau local plutôt que de les écrire sur la clef, donc j'ai piqué le syslog.conf d'un nanoBSD. Fin d'ajout

# mv -i /ztsuiraku/root/var/tmp{,-no}
# ln -s /tmp /ztsuiraku/root/var/tmp

Je n'ai jamais vraiment compris la différence entre /tmp et /var/tmp. Plutôt que de faire deux mfs, j'ai juste fait un lien symbolique, en gardant de côté le /var/tmp que les tarballs ont peuplé, des fois qu'en fait il soit vraiment utile. Là c'est de l'expérimental pur, je consignerai par ici mes éventuelles mauvaises expériences.

# chroot /ztsuiraku/root /bin/sh
passwd
tzsetup

Il y a peut-être une façon plus propre d'initialiser le mot de passe root et le fuseau horaire, ou peut-être simplement le faire après le premier boot. Pour l'instant je n'ai pas encore essayé autrement, c'est pareil qu'il y a six ans.

Rendre le disque dur bootable

J'ai déjà mis le bootloader dans une section précédente, donc je passe directement à la suite.

# zpool export ztsuiraku
# zpool import ztsuiraku
# cp -i /boot/zfs/zpool.cache /ztsuiraku/root/boot/zfs/

En vrai je n'ai pas fait l'export suivi de l'import, et j'ai été obligée de remettre à la main le mountfrom au boot suivant. Je ne sais pas s'il y a un lien de cause à effet, ou si j'ai eu une lenteur d'énumération de l'USB (da0 est apparu après le prompt) pour une autre raison. Dans le doute, je laisse l'export/import dans ces notes.

# zpool export ztsuiraku
# zpool import -R /zt ztsuiraku
# zfs set mountpoint=legacy ztsuiraku/root
# zfs set mountpoint=none ztsuiraku/reserve
# zfs set mountpoint=/home ztsuiraku/home
# zpool set bootfs=ztsuiraku/root ztsuiraku

Retour vers la cible

À ce stade, le disque est prêt, au petit détail près qu'il faut réussir à le débrancher de l'hôte pour le remettre dans la machine. Je n'ai toujours pas trouvé de solution satisfaisante.

Exporter le pool empêcher de démarrer dessus, arracher violemment pose de gros problème de cohérences des FS.

On m'avait suggéré de démonter tous les FS, et d'arracher ensuite, ce qui casse le pool du point de vue de l'hôte. Ça marche bien dans la machine cible, mais l'hôte se retrouve avec un pool fantôme, et tous mes essais pour le faire disparaitre ont soit été vains, soit aboutis à une commande qui ne termine pas (parfois même entrainant toutes les commandes zfs avec elle).

Reste éteindre complètement l'hôte avant de transplanter le stockage. C'est pénible, mais c'est propre.

Epilogue

Comme pour le contenu des fichiers à configurer, j'ai plusieurs fois regretté ne pas avoir dans mes notes les première commandes à faire sur la cible.

# pkg install tmux zsh vim-lite fossil smartmontools

Les outils de base.

# pw useradd -n nat -u 1001 -G wheel,operator -s =zsh

La commande que j'ai le plus de mal à retrouver, et que je ne semble pas capable d'assimiler (faute de m'en servir suffisamment souvent ?).

# pkg install pekwm rxvt-unicode xorg-server xinit xrdb xmodmap xauth xrandr setxkbmap conky xf86-input-{keyboard,mouse} xf86-video-intel

Le minimum pour avoir une interface graphique à mon goût.

Commentaires

Pas de commentaire pour le moment.

Poster un commentaire

Mise en forme historique : pour mettre en valeur un mot ou un groupe de mot, tapez une étoile de part et d'autre, sans mettre d'espace entre l'étoile et le mot, comme ceci : *mise en valeur*. Pour insérer un lien, mettez le entre crochets, comme ceci : [http://instinctive.eu/].

Mise en forme markdown : voir le guide détaillé, en résumé c'est le Markdown traditionnel, sans HTML ni titres, mais avec les tables PHP-Markdown-Extra.

Attention : les balises HTML entrées dans les commentaires seront affichées telles quelles, et non pas interprétées.

Autour de cette page

 

Autour de cet article

  • Publié le 29 juillet 2016 à 21h27
  • Dernière modification le 15 août 2016 à 11h29
  • État de la bête : archiviste ès geekeries
  • Pas de commentaire
  • Tag : BSD
  • Tag : Geek
  • Tag : Suite

Derniers commentaires

Tags

Archives

Site-level navigation and features

 

Instinctive.eu

Contact

Sections

Validation

Copyright © 2008-2016 Natacha Kerensikova

Butterfly images are copyright © 2008 Shoofly