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
1. Le lundi 5 juin 2017 à 7:02, par jeddy :
Bonjour,
je viens d'installer freebsd 10.3 et je cherche un moyen simple de faire un backup de mon système sur dvd.
Peut-être pourriez vous m'aider à écrire un script cron ou me donner les commandes à passer ? Je sais que le seul moyen d'apprendre est de faire des erreurs, mais je n'ai pas ce luxe ayant très peu de ressources.
Merci d'avance.
Poster un commentaire
Autour de cette page
Autour de cet article
Weblog
- …
- Mon prochain sac à main
- Usurper ou suivre ?
- Relooking
- Mon nouveau sac à main
- Clonage de FreeBSD en 2016
- Sueurs froides
- Blues professionnel
- Fin de série
- Every Day Carry en 2016
- …
Derniers commentaires
- Natacha dans Blogoversaire
- Jean Abou Samra dans Blogoversaire
- Jean Abou Samra dans Blogoversaire
- Natacha dans Blogoversaire
- Gro-Tsen dans Blogoversaire
- Balise dans Blogoversaire
- Gro-Tsen dans Mon deuxième carton
- Barakoma dans Requiescat
- joanna dans Évolution des commentaires
- Natacha dans Évolution des commentaires
Tags
- (Sans tag) (6)
- Appel au public (17)
- Autoexploration (60)
- BSD (6)
- Boulot (30)
- Création (12)
- En vrac (11)
- Évènement (58)
- Geek (47)
- Goûts (9)
- Humeur (18)
- Inventaire (9)
- Jeux (7)
- Jouets (36)
- Lecture (10)
- Réflexion (23)
- Site (22)
- Social (26)
- Société (14)
- Suite (15)
- Vision atypique (30)
- Vœux (8)
Archives
- 2024 (11)
- 2023 (14)
- 2022 (14)
- 2021 (15)
- 2020 (14)
- 2019 (12)
- 2018 (12)
- 2017 (13)
- 2016 (16)
- Décembre 2016 (2)
- Novembre 2016 (1)
- Octobre 2016 (1)
- Septembre 2016 (1)
- Août 2016 (1)
- Juillet 2016 (1)
- Juin 2016 (2)
- Mai 2016 (2)
- Avril 2016 (2)
- Mars 2016 (1)
- Février 2016 (1)
- Janvier 2016 (1)
- 2015 (12)
- 2014 (13)
- 2013 (15)
- 2012 (18)
- 2011 (18)
- 2010 (20)
- 2009 (45)