Fast Diskless Deployment Framework - Mathrice

Fast Diskless DeploymentFrameworkMars 2006Zouhir.Hafidi@math.univ­lille1.frPhilippe.Depouilly@math.u­bordeaux1.fr1

Petite mise au point• Un PC diskless est un PC :– sans disqueou– dont les disques ne sont pas utilisés pour lesystème (on dira alors que c’est du diskless++)Mars 2006Zouhir.Hafidi@math.univ­lille1.frPhilippe.Depouilly@math.u­bordeaux1.fr2

Classification des postes detravail• Critère : puissance de traitement locale oudistante– Rien en local : TX, boîtiers constructeurs, PC diskless(typiquement vieux PC recyclés avec LTSP)– Une infime partie en local (en général un navigateur) :boîtiers constructeurs, PC diskless Thinstation/LTSP/...– Tout en local : Poste lourd (PC standard), PCdiskless/PC diskless++, PC stateless (cached clients)Mars 2006Zouhir.Hafidi@math.univ­lille1.frPhilippe.Depouilly@math.u­bordeaux1.fr3

Avantages du diskless « tout enlocal »• Pour l’utilisateur :Mars 2006– en apparence, fonctionnement identique à un poste lourdavec moins de bruit et zéro admin– Meilleure prise en charge des périphériques locaux que lesclients légers (son, graveur, etc.)• Pour l’administrateur :– Gestion centralisée, portabilité, sécurité– Pas besoin de Terminal Servers (pas de XDMCP)– Pleine exploitation des ressources matérielles locales(puissance CPU, Zouhir.Hafidi@math.univ­lille1.frRAM)Philippe.Depouilly@math.u­bordeaux1.fr4

Inconvénients du diskless « touten local »• Nécessite des configurations matérielles« assez » récentes et « assez »généreuses notamment la RAM• Dépendance vis­à­vis du réseauMars 2006Zouhir.Hafidi@math.univ­lille1.frPhilippe.Depouilly@math.u­bordeaux1.fr5

Principe de fonctionnement dudiskless « tout en local »• Ce qui se fait le plus souvent :– Chargement du noyau via le réseau– Montage de la racine en lecture seule (readonlyroot) via un protocole réseau (NFS, AFS, GFS,etc.)Mars 2006Zouhir.Hafidi@math.univ­lille1.frPhilippe.Depouilly@math.u­bordeaux1.fr6

Cahier de charges• Eviter le plus possible d’utiliser des outils qui ne fontpas partie de la distribution standard• Faciliter les updates :– Eviter de patcher le kernel– s’interdire de modifier tout fichier faisant partie d’un package• Adapter la solution à différentes situations (labo,enseignement, conférence, calcul sur cluster, ...)• Pouvoir porter la solution à d’autres distributionsMars 2006Zouhir.Hafidi@math.univ­lille1.frPhilippe.Depouilly@math.u­bordeaux1.fr7

Problématique du readonly root• Certains scripts de démarrage/arrêt du système nesont pas adaptés au readonly root• Certains fichiers (typiquement de config) reflètentle matériel sur lequel le système a été installé àl’origine et qui n’est pas forcément le mêmepartout• Durant sa durée de vie, un système doit pouvoirécrire : Où écrire ? Quoi ? Comment ?Mars 2006Zouhir.Hafidi@math.univ­lille1.frPhilippe.Depouilly@math.u­bordeaux1.fr8

Problème des scripts dedémarrage/arrêt• Au premier abord on se dit que le plussimple est de les modifier/patcher dans lereadonly root– Problème : ceci complique les updatesMars 2006Zouhir.Hafidi@math.univ­lille1.frPhilippe.Depouilly@math.u­bordeaux1.fr9

Problème des fichiers de config• Chaque client diskless doit pouvoir utiliserses propres fichiers de config– Utiliser un système tel que clusternfs• Problème : non adapté aux filers– Générer à la volée les fichiers de configMars 2006Zouhir.Hafidi@math.univ­lille1.frPhilippe.Depouilly@math.u­bordeaux1.fr10

Problème de l’accès en écriture• Où écrire ?– Ramdisk– Tmpfs– Montage réseau en rw– Clé USB– Disque localMars 2006Zouhir.Hafidi@math.univ­lille1.frPhilippe.Depouilly@math.u­bordeaux1.fr11

Problème de l’accès en écriture(suite)• Quoi ?– /var (/var/log, /var/run, /var/lock, etc.)– /etc (/etc/mtab)– /dev– /tmpMars 2006Zouhir.Hafidi@math.univ­lille1.frPhilippe.Depouilly@math.u­bordeaux1.fr12

Problème de l’accès en écriture(suite)• Comment ?– Avec de la cuisine :• Mettre des liens symboliques dans le readonly rootqui pointent sur des zones « writable » lors del’initialisation du système• Des tar.gz dépliés en mémoire• mount ­­bind• ?Mars 2006Zouhir.Hafidi@math.univ­lille1.frPhilippe.Depouilly@math.u­bordeaux1.fr13

Problème de l’accès en écriture(suite)• Comment (suite) ? (si on regarde du côté desLive CDs)– Avec un sysème d’overlay « recouvrement » :• Au niveau block device : cowloop, Device mappersnapshots• Au niveau filesystem (en général du Copy­On­Write): cowlinks, mini_fo, ovlfs, translucency, MapFS,unionfsMars 2006Zouhir.Hafidi@math.univ­lille1.frPhilippe.Depouilly@math.u­bordeaux1.fr14

Solution retenue• Utilisation de unionfs :Mars 2006– Overlay = partie « writable » sur tmpfs + / en ro• Tout ce qui doit être modifié/patché le sera aumoment de l’initialisation du diskless• Les fichiers de config seront générés à la volée aumoment de l’initialisation du diskless (autodétection,paramétrage)• Les clients diskless sont paramétrés via les fichiers deconfig PXEZouhir.Hafidi@math.univ­lille1.frPhilippe.Depouilly@math.u­bordeaux1.fr15

Implémentation• Le diskless boote par PXE• Un noyau (standard) + initrd (fabriqué) sont chargés• Le initrd effectue les opérations suivantes :– Chargement des modules nécessaires pour le réseau– Configuration du réseau par DHCP– Montage nfs ro du / (/mnt/nfs)– Montage d’une zône tmpfs (/memory)– Création d’un overlay unionfs (/union = /memory + /mnt/nfs)Mars 2006Zouhir.Hafidi@math.univ­lille1.frPhilippe.Depouilly@math.u­bordeaux1.fr16

Implémentation (suite)– Si nécessaire faire certaines modifications avant de passer lamain à init– Récupération de certains fichiers comme /etc/resolv.conf– pivot_root• Init lit /etc/inittab et appelle rc.sysinit• rc.sysinit fait appel à rc.readonly qui prépare le terrainavant de rentrer dans le runlevel désiré (ajout, patch, ...)• Exécution des scripts rcX.d/ (démarrage des services)• Finir le processus de démarrage en exécutant rc.localMars 2006Zouhir.Hafidi@math.univ­lille1.frPhilippe.Depouilly@math.u­bordeaux1.fr17

Déploiement du diskless « tout enlocal »1.Préparer une machine qui servira commepoint de départ :– Installer la distribution– Configurer le poste comme si c’était un postelourd (authentification, impression, logicieladditionnel, etc.)– Tout mettre à jourMars 2006Zouhir.Hafidi@math.univ­lille1.frPhilippe.Depouilly@math.u­bordeaux1.fr18

Déploiement du diskless « tout enlocal » (suite)2.Préparer le readonly root selon les cas :– Readonly root = / de la machine initiale• Mauvaise solution surtout si vous avez un filer– Readonly root = une copie du / faite sur la mêmemachine ou sur une autre machine (ex. un filer)Un script permet de le faireMars 2006Zouhir.Hafidi@math.univ­lille1.frPhilippe.Depouilly@math.u­bordeaux1.fr19

Déploiement du diskless « tout enlocal » (suite)3.Créer l’image initrd nécessaire àl’initialisation du diskless pour une versiondonnée du kernelUn script permet de le faireMars 2006Zouhir.Hafidi@math.univ­lille1.frPhilippe.Depouilly@math.u­bordeaux1.fr20

Déploiement du diskless « tout enlocal » (suite)4.Booter le client diskless :– Au préalable :• Copier le kernel et l’image initrd sur votre serveurtftp• Créer un fichier de config PXE pour le client• Configurer votre serveur DHCP pour répondre auxrequêtes PXE des clients diskless– Power OnMars 2006Zouhir.Hafidi@math.univ­lille1.frPhilippe.Depouilly@math.u­bordeaux1.fr21

Paramétrage des clients diskless• Il est possible d’utiliser les paramètressuivants dans les fichiers de config PXE :– NFSROOT, ETHERNET– RUNLEVEL, ONSERVICES, OFFSERVICES– LANG, KEYBOARD, MOUSE, EMULTHREE– XDRIVER, HSYNC, VSYNC, DEPTH, RESOLUTION,DESKTOP– GUEST, PASSWD (utiles pour des conférences)– ROOT (utile dans l’enseignement d’admin réseau par ex.)Mars 2006Zouhir.Hafidi@math.univ­lille1.frPhilippe.Depouilly@math.u­bordeaux1.fr22

Le diskless++• Possibilité d’utiliser des disques locaux :– Utile par exemple dans un cluster de calcul oujuste pour récupérer des données– Par défaut :• Les partitions swap sont automatiquement détectéeset utilisées (sinon utiliser le paramètre NOSWAP)• Les autres partitions sont automatiquement montées(sinon utiliser le paramètre NOHDD)Mars 2006Zouhir.Hafidi@math.univ­lille1.frPhilippe.Depouilly@math.u­bordeaux1.fr23

Portage sur les différentes distros• FaDDeF repose sur 5 briques :– le module noyau unionfs– le script de création de l'image initrd– le script disklessrc exécuté par initrd– Busybox– les scripts déposés sur le serveur diskless avecune empreinte minimaleMars 2006Zouhir.Hafidi@math.univ­lille1.frPhilippe.Depouilly@math.u­bordeaux1.fr24

Portage sur les différentes distros• unionfs se compile sur les noyaux > 2.6.9• script d'installation pour les distribution FC,RH, Mandriva• En cours pour Debian, Ubuntu et OpenSuse­10Mars 2006Zouhir.Hafidi@math.univ­lille1.frPhilippe.Depouilly@math.u­bordeaux1.fr25

Portage sur les différentes distros• Le script de création de initrd fabrique unfichier image ext2• Il crée les dossiers pour accueillir :– Busybox, les /dev de base, les modules des cartesréseaux, le script disklessrc• Porté sur Ubuntu/Debian, FC4, Mandriva etOpenSuseMars 2006Zouhir.Hafidi@math.univ­lille1.frPhilippe.Depouilly@math.u­bordeaux1.fr26

Portage sur les différentes distros• Busybox :– Binaire statique et autonome– Une soixantaine de programmes (modprobe,udhcpc, hostname, shell, cut, grep, etc.)– Plateforme indépendant : un binaire pour toutesles distributionsMars 2006Zouhir.Hafidi@math.univ­lille1.frPhilippe.Depouilly@math.u­bordeaux1.fr27

Portage sur les différentes distros• Le script disklessrc repose sur Busybox, ilest donc à 95% générique• Avant de laisser la place à /sbin/init il a < 5choses à faire : modifier inittab, fstab, mtab,positionner des infos sur la carte réseau• Quelques lignes shells selon les distributions(< 5)Mars 2006Zouhir.Hafidi@math.univ­lille1.frPhilippe.Depouilly@math.u­bordeaux1.fr28

Portage sur les différentes distros• La version actuelle cumule ces actions debase pour toutes les distributions• La version suivante permettra de déposer unscript dans /initrd qui sera exécuté avant/sbin/init• A noter : le montage NFS du serveur se faitsur TCP pour plus de robustesseMars 2006Zouhir.Hafidi@math.univ­lille1.frPhilippe.Depouilly@math.u­bordeaux1.fr29

Portage sur les différentes distros• Les scripts déposés sur le serveur disklesspermettent d'adapter le comportement pourun client diskless, sont portés pour FC4 etMandriva, en cours pour Ubuntu/Debian etOpenSuseMars 2006Zouhir.Hafidi@math.univ­lille1.frPhilippe.Depouilly@math.u­bordeaux1.fr30

Portage sur les différentes distros• Une commande pour fabriquer l'image initrd: updateDiskless /racine 2.6.x­y.z /depot :• dépose un fichier initrd et une copie devmlinuz de 2.6.x­y.z• Il suffit de copier ces fichier dans le dossierdu serveur tftp et adapterpxelinux.cfg/defaultMars 2006Zouhir.Hafidi@math.univ­lille1.frPhilippe.Depouilly@math.u­bordeaux1.fr31

Portage sur les différentes distros• Une commande pour copier les fichiersscripts sur le serveur diskless :mkreadonlyroot /racine• Ces scripts s'adaptent très facilement et sontpeu nombreux (< 10) et très lisiblesMars 2006Zouhir.Hafidi@math.univ­lille1.frPhilippe.Depouilly@math.u­bordeaux1.fr32

Portage sur les différentes distros• Les portages sont en cours• Ils doivent permettre une configuration d'unserveur diskless en moins d'une heure(chrono) pour plusieurs distributions(actuellement Fedora, Mandriva, RedHat,Ubuntu, Debian et selon un sondageMathrice, on y ajoute OpenSuse)Mars 2006Zouhir.Hafidi@math.univ­lille1.frPhilippe.Depouilly@math.u­bordeaux1.fr33

Conclusion• Philosophie indépendante de toute distro• Implémentation technique spécifique àchaque distro sur certains aspects• Avantages certains du diskless « tout enlocal »• Elément à « surveiller » : unionfsMars 2006Zouhir.Hafidi@math.univ­lille1.frPhilippe.Depouilly@math.u­bordeaux1.fr34

Ressources• Scripts pour configurer le diskless :– https://svn.math.cnrs.fr/faddef– http://wiki.math.cnrs.fr• Liens :– http://www.am­utils.org/project­unionfs.html– http://www.linux­live.org/– http://linux.web.psi.ch/livecd/Mars 2006Zouhir.Hafidi@math.univ­lille1.frPhilippe.Depouilly@math.u­bordeaux1.fr35