Ou comment monter un jail en 2 – 2. On commence par topper une ISO de FreeBSD sur le host (système de base). Supposons que nous voulions installer un jail nommé “jigar” dans /jail/dtc. On va y mettre deux chose : le système de base FreeBi et les pages de man (une fois loggué dans le jail, c’est pratique de les avoir sous la main). Commencons par monter l’ISO :
mdconfig -a -t vnode -f ./FreeBSD-8.1-RELEASE-amd64-disc1.iso
Qui doit renvoyer un device (chez moi md0)
mount -t cd9660 /dev/md0 /mnt/iso
Mon shell root par défaut est sh (j’aime pô csh, je sais pas m’en servir ^^). On doit se placer dans le “set” a installer (base et manpages pour nous) :
cd /mnt/iso/8.1-RELEASE/base
DESTDIR=/jail/dtc ./install.sh
cd /mnt/iso/8.1-RELEASE/manpages
DESTDIR=/jail/dtc ./install.sh
Après c’est du classique, configurons le rc.conf du host :
#Alias avec l'ip du jail sur l'interface
ifconfig_igb0_alias0="inet <ip_host>"
syslogd_flags="-s -s"
sendmail_enable="NO"
inetd_flags="-wW -a <ip_host>"
rpcbind_enable="NO"
jail_enable="YES"
jail_list="jigar"
jail_set_hostname_allow="NO"
jail_socket_unixiproute_only="YES"
jail_procfs_enable="NO"
jail_devfs_enable="YES"
jail_exec_start="/bin/sh /etc/rc"
jail_devfs_ruleset="devfsrules_jail"
jail_nausica_flags="-n jigar"
jail_nausica_rootdir="/jail/dtc"
jail_nausica_hostname="jigar.garnett.fr"
jail_nausica_ip="ip_jigar"
Celui de “jigar” (/jail/dtc/etc/rc.conf) :
hostname="jigar.garnett.fr"
network_interfaces=""
keymap="fr.iso.acc"
sshd_enable="YES"
syslogd_flags="-s -s"
rpcbind_enable="NO"
Quelques post-actions :
touch /jail/dtc/etc/fstab
cp /etc/resolv.conf /jail/dtc/etc/
cp /jail/dtc/usr/share/zoneinfo/Europe/Paris /jail/dtc/etc/localtime
chroot /jail/nausica /bin/sh
#passwd
#exit
Et voila, c’est prêt !
Juste un post pour indiquer la mise en ligne ce jour d’un article soumis sous “creative commons” à Linux Magazine. Je trouve ce principe particulièrement intéressant de publier l’article sur le web librement accessible quelques mois après sa parution. Il est disponible ici.
Voila un petit mois que je n’ai rien posté sur ce blog. J’avais un peu la tête sous l’eau. J’ai donc passé mes serveurs FreeBSD hébergeant des jail en 8.0. Seulement, je me suis loupé dans la procédure d’upgrade. J’ai upgradé un jail en 8.0 puis en rappelant la commande freebsd-update j’ai omis le -b pour lui donner comme racine un jail donc il a mis à jour le système de base. Je n’ai pas voulu interrompre la procédure donc je l’ai laissé finir.
Le problème lorsque l’on utilise freebsd-update pour mettre à jour ses jails c’est qu’il se base sur la version renvoyée par uname. Si l’on met à jour le système de base avant les jails, alors freebsd-update lancé sur le jail considère que le système est déjà à jour. Pour s’en sortir, deux options :
1) Création d’un faux uname
On move /usr/bin/uname vers /usr/bin/uname.org et on se fait un petit script du style :
#!/bin/sh
/usr/bin/uname.org $* | sed s/"8.0-RELEASE"/"7.2-RELEASE-p4"/g
Ok c’est encore plus crade que du porno thaïlandais …
2) Copie d’un jail “master”
Directement inspiré d’un post trouvé ici. Cette méthode propose de disposer d’un master jail à répliquer. J’étais un peu dans cette configuration avec comme “master jail” celui que j’avais upgradé avant ma boulette. Les installations des différents jails étant assez homogènes (ferme de serveur FreeBSD / Apache / Trac / SVN) il me suffisait de répliquer ce jail et de recoller les data de /usr/local/[svn|www]-trac qui contiennent respectivement les instances subversion et Trac associées. Pour copier un jail, ne surtout pas faire un bête cp mais plutôt :
# cd /jail/masterjail
# tar -cpf - . | tar -C /jail/newjail -xpf –
Pour conserver les permissions, la nature du fichier (surtout les liens) etc. Quand on combine tar et ssh on obtient même un “master jail” deployable de façon sécurisée sur tous les serveurs partageant son architecture (uname -m). A noter que cette manipulation a quand même nécessité la recompilation du port www/apache22 sur le newjail.
Sous FreeBSD, je cherchais comment utiliser le nom du jail à la place du JID dans la commande jexec. A priori d’après le man c’est possible :
-n jailname
The name of the jail, if given upon creation of the jail. This
is not the hostname of the jail.Bingo, j’essaye :
jexec -n monjail '' ls
Ca pète le message d’erreur suivant :
jexec: Cannot identify jail.
je vérifie vingt fois le nom de mon jail et retente çamarchepas. Je décide donc de mater dans le man de jail (RTFM rulez) et je trouve ça :
-n jailname Assign and administrative name to the jail that can be used
for management or auditing purposes. The system will not
enforce the name to be unique.Une fois la ligne jail_monjail_flags=”-n monjail” ajoutée dans le rc.conf et le service jail relancé çamarchemieux.
Ajourd’hui passage des jails de 7.1 en 7.2. Je pensais pouvoir faire une mise à jour binaire par freebsd-update (ce que je fais d’habitude). Seulement pour le changement de version : samarchepa, freebsd-update ne met rien à jour dans les Jails. Du moins je ne connais pas de moyens d’y arriver. Du coup, j’ai opté pour la mise à jour recompilation.
Sur le système hôte :
# cd /usr/src
# make buildworld DESTDIR=/monjail
# mergemaster -p -D /monjail
Petite note sur mergemaster : la partie récente est a droite (r) tandis que la partie gauche c’est l’existant (l). Cette première commande initialise le /var/db/mergemaster.mtree du jail avec les fichiers “importants” (-p). Ce fichier va être utilisé par la suite pour installer automatiquement les fichiers de configuration du système de base qui n’ont pas étés modifiés par l’administrateur.
Si on le fait pas, mergemaster renvoi le message suivant au moment de l’auto-update :
Unable to find mtree database. Skipping auto-upgrade.
Ensuite on arrête le jail, on installe les mises à jour (programmes et fichiers de configuration) et enfin on redémarre :
# /etc/rc.d/jail stop monjail
# make installworld DESTDIR=/monjail
# mergemaster -i -U -D /monjail
# /etc/rc.d/jail start monjail
A executer dans le jail (soit par SSH, soit par jexec) :
# /usr/sbin/pwd_mkdb -d /etc -p /etc/master.passwd
# /usr/bin/cap_mkdb /etc/login.conf
Il n y a plus qu’à vérifier que tout est reparti.