Rapport de TER : Outils de déploiement d`images disque

Transcription

Rapport de TER : Outils de déploiement d'images disque
Pierre FOURNIER, Youness MOGHLI
11 mars 2005
Résumé
Le sujet de ce TER est de rechercher, étudier et comparer les outils de déploiement d'images logicielles et de les
mettre en oeuvre dans le cadre de l'installation d'un parc de machines sous Linux/Windows. Après un bref
historique des outils disponibles, nous exposerons les choix possibles, ainsi que ceux retenus. Nous expliquerons les
différents procédés utilisés tout au long d’un déploiement, puis un exemple d’installation et d’utilisation d’un système
de déploiement en chaîne sera abordé.
Mots-clés : Images système, Déploiement, PXE, TFTP, DHCP, NFS, Boot
Table des Matières
1
INTRODUCTION ................................................................................................................................................. 2
1.1 INTERET DES OUTILS DE DEPLOIEMENT D’IMAGES ....................................................................................................................2
1.2 HISTORIQUE .......................................................................................................................................................................................2
2
ETUDE ET COMPARAISON DES OUTILS EXISTANTS ................................................................................. 2
2.1 LES CARACTERISTIQUES ...................................................................................................................................................................2
2.1.1 Symantec Norton Ghost ....................................................................................................................................................2
2.1.2 CCCSS ............................................................................................................................................................................2
2.1.3 Ka-Deploy .........................................................................................................................................................................3
2.1.4 UDP Cast........................................................................................................................................................................3
2.2 NOTRE CHOIX ....................................................................................................................................................................................3
3
FONCTIONNEMENT DES ELEMENTS DU DEPLOIEMENT ..................................................................... 3
3.1
3.2
3.3
3.4
4
PXE......................................................................................................................................................................................................4
DHCP ..................................................................................................................................................................................................4
TFTP....................................................................................................................................................................................................4
NFS ......................................................................................................................................................................................................5
MISE EN PLACE DU SYSTEME DE DEPLOIEMENT .................................................................................... 5
4.1 CONFIGURATION DE L’UNITE SERVEUR ........................................................................................................................................5
4.1.1 Module serveur de Ka-Deploy ............................................................................................................................................5
4.1.2 DHCP .............................................................................................................................................................................5
4.1.3 TFTP ...............................................................................................................................................................................5
4.1.4 NFS .................................................................................................................................................................................6
4.1.5 Configuration de PXELinux............................................................................................................................................6
4.2 CONFIGURATION DU PC SOURCE ....................................................................................................................................................6
4.3 CONFIGURATION DES MACHINES DESTINATION.........................................................................................................................6
5
CONCLUSION....................................................................................................................................................... 6
6
REMERCIEMENTS .............................................................................................................................................. 6
7
REFERENCES BIBLIOGRAPHIQUES............................................................................................................... 7
REFERENCES ............................................................................................................................................................... 7
1ère année du Master Informatique de l’Université Claude Bernard Lyon1
1 Introduction
Le but de ce TER est de rechercher et comparer les
différents systèmes de déploiement d’images logicielles, afin
d’en équiper l’UFR à long terme.
Une première phase consistera à étudier les outils existants
et à les comparer. La deuxième phase sera la mise en place
effective du système de déploiement et l'installation du noeud
de référence.
1.1
Intérêt des outils de déploiement
d’images
Le déploiement d’images disque a été créé à l’origine afin
de pouvoir faire des sauvegardes d’un système d’exploitation
entièrement configuré, ce qui permettait, en cas de perte du
système (virus, installation d’un logiciel corrompu, mauvaise
manipulation…), de réinstaller en quelques minutes un système
opérationnel.
Pourtant ce système, bien que satisfaisant pour des
sauvegardes d’un système d’exploitation ou la copie conforme
d’un ordinateur sur un autre, se montre très contraignant et
fastidieux lorsqu’il s’agit d’installer un parc entier de machines.
En effet, les outils de déploiement d’images sont aussi utilisés
dans ce cas. Cette méthode impose d’exécuter un logiciel
spécifique sur chaque machine de destination afin d’extraire
l’image. Enfin un dernier inconvénient est que pour mettre à
jour son parc de la même façon, il faut recréer une image du
système à jour, puis la redéployer sur tous les clients.
Nous verrons qu’il existe justement deux types de logiciels
de déploiement d’images, chaque type étant plus adapté pour
un domaine d’utilisation : la copie personnelle d’un système ou
l’installation en chaîne de plusieurs machines identiques.
L’optique de ce TER étant de mettre en place un système
d’installation automatisée d’un parc informatique, nous
mettrons l’accent sur les programmes dédiés à cette utilisation.
1.2 Historique
Au commencement, le moyen universel pour copier un
système d’exploitation était de faire une copie brute par xcopy
d’une partition disque à une autre. Ce système était lent et
brutal.
Il y a quelques années, l’unique moyen disponible pour
installer un parc informatique en série était d’utiliser le logiciel
de Symantec, Norton Ghost. Le principe est de créer une
image complète d’une partition disque, de stocker cette image
sur un support (CD-ROM, disque dur, réseau…), puis de
réinstaller cette partition soit sur la même machine, soit sur une
autre. Puis un concurrent est apparu, DriveImage développé
par la société PowerQuest. DriveImage était une alternative
intéressante à Ghost du fait de son algorithme de compression
plus puissant et la possibilité de faire des images de partition
linux (Ghost dans ses premières versions ne reconnaissait que
les partitions FAT et NTFS). Or en décembre 2003, Symantec
Corporation a racheté PowerQuest, et ainsi les deux logiciels
Ghost et DriveImage ont fusionné en un programme
compatible avec les deux formats.
Plus récemment, une nouvelle famille d’outils a vu le jour,
grâce à l’émergence de la norme PXE, permettant de booter
une machine en réseau. Ces outils offrent la possibilité
Rapport de TER de Pierre FOURNIER, Youness MOGHLI
2004-2005
d’exécuter un système d’exploitation entièrement par réseau, ce
qui libère de la contrainte du support, et pourrait permettre
une installation entièrement automatisée, limitant au maximum
l’intervention humaine …
2 Etude et comparaison des outils
existants
2.1 Les caractéristiques
Avant de commencer la pratique et la manipulation des
machines, nous avons effectué une session de recherche et de
documentation sur les différents outils disponibles et utilisables
actuellement. Voici une liste de logiciels que nous avons
retenus :
2.1.1 Symantec Norton Ghost
Comme annoncé dans l’historique, Norton Ghost est le
logiciel historique de création d’images système. Il reste l’outil
le plus utilisé dans ce domaine.
Le principe de fonctionnement de Ghost est en deux
phases distinctes : la création de l’image (créer une image d’une
partition disque avec le programme, puis de la stocker sur un
support) et le déploiement de l’image (lancer sur la machine
destination le programme d’extraction d’image à partir d’un
CD ou de disquettes de boot spécifiques, puis extraire l’image).
Ses caractéristiques sont les suivantes :
− C’est un logiciel commercial
− Actuellement en version 9
− Compatible avec les formats FAT, NTFS, EXT
− Outils d’administration sous Windows
− Documentation et aide abondante
2.1.2 CCCSS
Ce programme ayant été évoqué dans le sujet du TER,
nous le citons dans ce rapport. CCCSS est l’acronyme de
Centralized Cloning Configuration Synchronisation Security
system. Cet outil serait utilisé pour configurer et synchroniser
un parc de stations sous Linux/Debian (bien que des versions
plus récentes pourraient gérer d’autres distributions).
Le manque d’informations à son sujet nous fait penser que
ce programme en est encore à ses balbutiements ou a été arrêté
[Pon04], nous n’avons donc pas approfondi cette possibilité, et
préféré s’intéresser aux outils utilisant la norme PXE…
2
2.1.3 Ka-Deploy
2004-2005
2.1.4 UDP Cast
Deuxième outil trouvé utilisant pxelinux, UDP Cast est un
outil permettant l’envoi de données simultanément à plusieurs
destinations. Il est donc possible de déployer un système
d’exploitation de cette manière.
Contrairement à Ka-Deploy qui ne fonctionne qu’avec un
boot sur le réseau (PXE), UDP Cast peut s’utiliser de plusieurs
façons : disquette, CD-ROM, réseau.
Enfin, différence appréciable par rapport à Ka-Deploy, le
site Internet d’UDP Cast est assez complet quand à la
documentation pour l’installation [Udp05a] [Udp05b], il reste
par contre relativement pauvre au niveau de la documentation
du fonctionnement.
2.2 Notre choix
FIG. 1 – Déploiement en chaîne
Ka-Deploy fait partie de la famille des outils utilisant
pxelinux. Nous parlons de famille car nous avons trouvé au
moins trois outils utilisant un schéma d’installation, de
configuration et de fonctionnement similaires.
Son principe de fonctionnement est le suivant : le
déploiement du système ne se fait pas à partir d’une image,
mais à partir d’une machine que nous appellerons source. Une
machine serveur permet d’administrer le déroulement du
déploiement, et d’informer les clients de l’emplacement de la
source. Les pc clients se connectent donc par réseau à la
machine source afin de récupérer le système. L’idée la plus
intéressante de Ka-Deploy et son principe d’installation en
chaîne : au lieu d’avoir plusieurs machines se connectant à la
même source, créant ainsi une baisse de débit conséquente, le
premier client se connecte à la source, puis le deuxième client
se connecte au premier … Cette topologie en chaîne est la plus
performante en terme de débit (voir la figure 1) [Aug01].
Ainsi, il est possible d’installer un système de plusieurs Go
sur 200 machines en moins de 15 minutes [Der02].
Nous avons choisi de ne pas utiliser Ghost (ou un clone de
Ghost) pour différentes raisons. En effet, le but d’un TER est
justement de faire une phase de recherche et de
documentation, or l’utilisation de Ghost ne nécessite ni
recherche ni documentation. De plus, le sujet était justement
de trouver un nouveau système de déploiement utilisable dans
l’UFR et de remplacer l’ancien système d’installation en série
(en l’occurrence Ghost avec une image sur CD-ROM).
Notre choix s’est donc tourné vers les outils utilisant la
technologie PXE. En effet, ils ont été conçus dans l’optique de
servir au déploiement à grande échelle, et le fait qu’ils soient
récents et encore en développement pour la plupart en fait un
sujet d’étude complexe et intéressant. De plus l’idée du boot
entièrement réseau permet d’éviter d’avoir à transporter un
CD-ROM ou une disquette partout.
Parmi les deux outils PXE étudiés, nous avons commencé
par étudier Ka-Deploy car ce programme semblait avancé dans
sa conception : développement en cours de la version 2,
plusieurs
anciennes
version
correctement
stables.
Parallèlement, UDP Cast n’étant pas dédié uniquement au
déploiement d’images, il nous semblait plus judicieux de
l’écarter.
Les parties suivantes prennent donc comme exemple KaDeploy, mais tous les outils fonctionnant avec pxelinux.0 se
comportent de la même manière et demandent le même type
de configuration.
3 Fonctionnement des éléments
du déploiement
Les éléments suivants sont utilisés lors de l’utilisation
d’outils de déploiement de type pxelinux, la compréhension de
leurs mécanismes est donc primordiale si on souhaite installer
correctement ce type de système.
FIG. 2 – Temps de diffusion sur 200 nœuds avec différentes
topologies
Les problèmes majeurs de Ka-Deploy sont que les clients
doivent être identiques au niveau du matériel, et surtout que sa
mise en œuvre est très fastidieuse…
3
3.1 PXE
2004-2005
3.2 DHCP
Un serveur DHCP (Dynamic Host Configuration Protocol)
permet d’administrer automatiquement la configuration réseau
IP des clients. Ce protocole est très utile lorsque le réseau est
« mouvant », que beaucoup de machines se rajoutent ou
partent, et permet de garder une architecture cohérente.
DHCP fonctionne sur le modèle client-serveur : un
serveur, qui détient la politique d'attribution des configurations
IP, envoie une configuration donnée pour une durée donnée à
un client donné (typiquement, une machine qui vient de
démarrer). Le serveur va servir de base pour toutes les requêtes
DHCP (il les reçoit et y répond), aussi doit-il avoir une
configuration IP fixe. Dans un réseau, on peut donc n'avoir
qu'une seule machine avec adresse IP fixe : le serveur DHCP.
Le protocole DHCP s'appuie entièrement sur BOOTP : il
en reprend le mécanisme de base (ordre des requêtes, mais
aussi le format des messages). DHCP est une extension de
BOOTP.
FIG. 3 – Schéma d’échange d’informations client – serveur
Le boot PXE est un acronyme pour Preboot Execution
Environment (Environnement d'Exécution Avant le boot).
PXE est une technologie qui est utilisée pour démarrer un PC
à distance à travers un réseau.
Sous linux, PXE est géré avec Pxelinux, un dérivé de
Syslinux [Sys05]. Son installation se fait en copiant le fichier
pxelinux.0 (un binaire linux) dans le répertoire du TFTP, puis
en créant le répertoire pxelinux.cfg/ dans lequel seront placés
les fichiers de configuration spécifiques.
Supposons un client qui aurait une carte Ethernet avec
comme adresse mac 88:99:AA:BB:CC:DD. Au boot, si le
serveur DHCP lui attribue l’adresse IP 192.0.2.91, le client
cherchera le fichier de configuration sur le serveur TFTP dans
l’ordre suivant :
/tftpboot/pxelinux.cfg/01-88-99-aa-bb-cc-dd
/tftpboot/pxelinux.cfg/C000025B
/tftpboot/pxelinux.cfg/C000025
/tftpboot/pxelinux.cfg/C
/tftpboot/pxelinux.cfg/default
Le client cherche d’abord le fichier de configuration ayant
le nom de son adresse MAC, puis son adresse IP (en
hexadécimal), puis décrémente son adresse jusqu'à finalement
chercher le fichier « default ».
Donc suivant l’utilisation que l’on veut en faire, soit on
détermine des fichiers de configuration spécifiques à chaque
client, soit on fait un fichier de configuration par défaut. C’est
cette dernière option qui sera gardée, l’intérêt de la
manipulation étant de pouvoir installer automatiquement un
grand nombre de machines (sans forcement connaître leur
adresse MAC).
FIG. 4 – Format de trame DHCP
L’intérêt du serveur DHCP dans notre cas est de pouvoir
attribuer une adresse IP aux clients sans qu’un système
d’exploitation soit chargé, et surtout sans avoir à définir
manuellement les adresses IP et MAC pour une installation à
grande échelle.
3.3 TFTP
Un serveur TFTP, ou Trivial File Transfert Protocol,
remplit le même rôle qu’un serveur FTP : le transfert de
fichiers par réseau. La différence majeure consiste à la non
sécurisation de ce protocole : il utilise le protocole non sécurisé
UDP, n’effectue donc pas de contrôle de bonne réception du
client. De plus il ne possède pas de système d’authentification.
[Sol92]
L’intérêt d’un tel système aussi peu sécurisé est qu’il soit
utilisable dans un environnement « fiable », et surtout de
permettre de limiter les informations à donner par un
utilisateur : il est donc possible d’automatiser le téléchargement
du système d’exploitation minimal de cette façon.
Lors de l’utilisation d’un serveur TFTP, il faut donc faire
très attention à ne mettre aucune donnée sensible, et à bien
isoler le répertoire, chacun pouvant lire et écrire a volonté
dessus.
4
3.4 NFS
NFS (Network File System) permet de partager des fichiers
entre différentes machines, comme s’ils se trouvaient sur le
disque local. Linux peut être utilisé comme serveur et client
NFS. Le client exporte des systèmes de fichier alors que les
clients montent ces systèmes.
Dans notre cas, la machine serveur va exporter un système
de fichiers, à savoir un système minimal, alors que les clients
vont monter ce système pour pouvoir booter dessus par la
suite.
4 Mise en place du système de
déploiement
Afin de faire les différents tests et essais pour mettre en
place le système de déploiement avec Ka-Deploy, l’université
nous a fourni le matériel suivant :
− Une machine type TP de réseau, Windows 2000 et
Debian installés et configurés. Cette machine sera le
nœud source du déploiement (la configuration que l’on
cherche à déployer sur les autres machines).
− Une machine de type TP de réseau avec la configuration
d’usine (Windows XP). Ce sera le nœud client.
− Une machine basée sur un Athlon 900, en libre
utilisation, ce sera la machine qui jouera le rôle de
serveur.
L’idée est d’arriver à faire le déploiement sur un client,
l’installation en chaîne devrait se faire de la même façon, il
suffira de changer le nombre de clients attendus par le nœud
source.
2004-2005
4.1.1 Module serveur de Ka-Deploy
Il faut commencer par télécharger les packages de KaDeploy. Malheureusement, la version 2 n’est à ce jour toujours
pas disponible, nous avons donc travaillé avec la version 0.91.
Les
fichiers
sont
à
prendre
sur
http://sourceforge.net/projects/ka-tools/ :
ka-deploy-server-host-0.91-1.i386.rpm
Ces packages sont au format RPM (celui de la distribution
Red-Hat), que Debian ne reconnaît pas par défaut. Plutôt que
d’essayer de convertir le package, il faut installer l’outil « alien »
qui permet l’installation de packages de distributions
différentes :
# apt-get install alien
# alien –i ka-deploy-server-host0.91-1.i386.rpm
4.1.2 DHCP
Nous avons installé un démon DHCP et ses dépendances.
Nous avons choisi dhcp3 parce qu’il offre plus de
fonctionnalités, en particulier le « dynamic-bootp » :
# apt-get install dhcp3-server
Lorsque l’installation demande sur quelle interface activer
le serveur DHCP mettre « eth0 » ou le nom de l’interface si il y
a plusieurs cartes réseau.
La configuration du serveur DHCP se fait en éditant le
fichier /etc/dhpc3/dhcpd.conf
4.1 Configuration de l’unité serveur
Pour des raisons pratiques, nous avons installé tous les
serveurs nécessaires au bon fonctionnement du déploiement
avec Ka-Deploy sur une même machine serveur principal. Mais
il est tout à fait possible d’utiliser Ka-Deploy dans un parc
comprenant des serveurs DHCP, NFS et TFTP séparés.
Afin de pouvoir redémarrer avec une configuration la plus
saine possible, nous avons commencé la session de
manipulation par une réinstallation de Debian sur la machine
destinée à faire serveur. Nous avons fait une installation
minimale des packages d’origine, pour bien comprendre et
assimiler les différentes étapes d’installation et de configuration
des différents modules rentrant en jeu.
Nous avons configuré le réseau de telle façon que l’on
puisse
profiter
de
la
connexion
Internet
de
l’UFR (indispensable pour installer les packages les plus
récents) :
Passerelle : 134.214.88.1
Serveur DNS : 134.214.88.10
Enfin, la dernière phase de configuration générale est de
modifier la liste des serveurs sur lesquels l’outil Debian apt-get
trouvera les packages à installer :
/etc/apt/source.list
Dans l’exemple ci-dessus, la plage d’IP est volontairement
petite, afin d’être sûr de ne pas entrer en conflit avec les autres
machines de l’UFR.
L’option « dynamic-bootp » doit être indiquée mise pour
indiquer que le DHCP doit répondre aux requêtes bootp en
donnant une adresse de cette plage d’IP.
Les lignes « filename ka/pxelinux.0 » et « next-server
134.214.90.101 » indiquent que les clients, après avoir récupéré
leur adresse IP, doivent télécharger le fichier « ka/pxelinux.0 »
sur le serveur 134.214.90.101.
Après modification du fichier de configuration, penser à
redémarrer le serveur :
# /etc/init.d/dhcp3-server restart
On note que qu’il arrive au restart de dhcp3 de ne pas
fonctionner correctement, dans ce cas, faire :
# /etc/init.d/dhcp3-server stop
# /etc/init.d/dhcp3-server start
4.1.3 TFTP
Commençons par installer le serveur TFTP :
# apt-get install ftfpd-hpa
5
Il faut déterminer quel sera le répertoire racine du serveur
TFTP, et quels seront les paramètres. Dans notre cas le
repertoire racine est /tftpboot/.
La configuration du serveur TFTP se fait en éditant le
fichier /etc/inetd.conf
4.1.4 NFS
La première phase consiste en l’installation du démon
NFS :
# apt-get install nfs-user-server nsfcommon
Il faut en plus installer les fichiers spécifiques à NFS de KaDeploy qu’on a téléchargé préalablement sur Sourceforge :
# alien –I ka-nfsroot-0.91-1.i386.rpm
On détermine quels sont les répertoires à exporter en
modifiant le fichier /etc/exports :
Les options « ro » et « no_root_squash » sont
respectivement pour dire que le répertoire est en lecture seule
(impossible de modifier les données) et que n’importe quel
utilisateur aura accès à ce répertoire.
4.1.5 Configuration de PXELinux
Alors que le fichier pxelinux.0 est un exécutable, il faut
paramétrer le répertoire pxelinux.cfg/ pour que les clients se
connectent correctement.
La configuration générique pour plusieurs machines sans
avoir à relever les adresses MAC est de créer un fichier
pxelinux.cfg/default, tous les clients regarderont ce fichier :
4.3 Configuration
destination
2004-2005
des
machines
La seule configuration que nécessitent les nœuds clients est
de modifier le BIOS afin que la carte réseau fonctionne en
mode PXE. Il faut ensuite choisir l’interface réseau comme
premier périphérique de boot.
5 Conclusion
Bien que toutes nos manipulations aient été effectuées avec
Ka-Deploy, nous pensons mettre en œuvre UDP Cast avant la
soutenance, car il semble être plus développé graphiquement et
ainsi voir les différences entre deux outils utilisant le même
noyau.
Nous avons vu que de par son principe de logiciel libre, et
la puissance de son fonctionnement, Ka-Deploy (ou les
logiciels de type pxelinux) est certainement l’alternative la plus
intéressante aujourd’hui pour installer un nombre conséquent
de machines.
Pourtant, un système qui demande autant d’investissement
dans la recherche de documentation et dans l’installation peutil vraiment être considéré comme la meilleure possibilité ? Le
fait qu’il soit toujours en développement permet d’espérer des
versions suivantes utilisables plus facilement.
Enfin, le développement de la norme PXE et son
implémentation dans la plupart des nouvelles machines va
permettre une multiplication de ce type de logiciels, dont
certain deviendront sûrement des références...
6 Remerciements
Nous tenons à remercier Olivier Gluck pour nous avoir
proposé ce sujet et pour nous avoir encadré dans la réalisation
de ce TER. Nous remercions également les administrateurs du
bâtiment Nautibus pour nous avoir fourni l’environnement de
travail nécessaire au bon déroulement de notre projet. Enfin
nous remercions toutes les personnes qui nous ont aidé
indirectement grâce à leurs explications sur leurs sites Internet
(donc plusieurs sont en référence).
4.2 Configuration du pc source
Télécharger puis installer depuis Sourceforge le fichier :
# alien –i ka-deploy-source-node-0.911.i386.rpm
Pour mettre cette machine en mode écoute et attente des
clients, il faut lancer le script en tant que Root :
# ka-d.sh –n xx
Où xx est le nombre de clients attendus. Une fois tous les
clients connectés le colonage démarre.
6
2004-2005
7 Références bibliographiques
L’outil Ka-Deploy étant un logiciel libre et encore en
développement, l’intégralité de notre documentation s’est faite
sur Internet. La plupart des références qui suivent sont donc
les adresses Internet des différents sites qui nous ont aidé pour
la réalisation de ce TER.
Références
[Aug01]
P. Augerat, « Outils d’exploitation d’une grappe
de grande taille », support de présentation p. 8
[Der02]
S. Derr, « The Ka tools and OSCAR », support
de presentation p. 21
[Ka01]
Site officiel de Ka-Deploy
http://ka-tools.sourceforge.net/
[Pon04]
D. Ponsard
https://lipforge.ens-lyon.fr/projects/cccss/
[Sol92]
K. Sollins , « protocole TFTP révision 2 »
http://abcdrfc.free.fr/rfc-vf/rfc1350.html
[Sys05]
Site officiel de Syslinux – Pxelinux
http://syslinux.zytor.com/pxe.php
[Udp05a]
Site d’UDP Cast
http://udpcast.linux.lu/
[Udp05b]
UDP Cast en français
http://www.refer.ne/article.php3?id_article=1
4
7

Rapport de TER : Outils de déploiement d`images disque

Transcription

Documents pareils

Retours d`expériences de la Télévision Mobile Personnelle

Booter en PXE – Lancer le client GHOSt

Installation et configuration d`un serveur PXE Ghost Cast sur

Document à télécharger : ftmi-deploiement-reseau

Pour quel changement pédagogique favorisant le développement

Clonezilla live par serveur PXE : Lexique

Configuration de partage de connexion Internet (ICS)

Linux terminal server

Techniques de boot réseau