Castellano Chinese Deutsch English Français Nederlands

par Fahad Saeed, Fahad Ali Arshad and Salman Javed <researchers_uet(at)yahoo.com> L´auteur: Les auteurs sont étudiants en licence au Department of Electrical Engineering, UET, Lahore, au Pakistan. Leurs intérêts de recherche incluent l'informatique distribuée & parallèle, les OS et bases de données distribuées, les réseaux sans fil ad-hoc et de senseurs. Traduit en Français par: Jean-Etienne Poirrier (homepage) Sommaire: Introduction Motivation Les modèles de réseaux Les réseaux ad-hoc Notre scenario Buts de l'étude Hypothèses Topologie et travail de notre réseau Implémentation Configurations des terminaux Environment de travail Procédures de sauvegarde rdiff-backup cron Note méthode Administration Partage de clés SSH FILEWORM COMMANDWORM Synchronization du temps Remerciements Références Talkback form for this article

Etude et implémentation d'un réseau sans fil ad-hoc 802.11 basé sur Linux Résumé: L'étude et le développement d'un réseau sans fil ad hoc pour un laboratoire d'informatique est décrit. _________________ _________________ _________________

Introduction

L'objectif de ce laboratoire est de permettre aux étudiants d'utiliser n'importe quelle machine de leur choix mais d'être toujours capable de travailler avec leurs fichiers personnels, comme ce serait le cas dans une configuration standard. Cependant, tout ceci est réalisé sans l'utilisation d'un serveur de fichiers central ni de système d'information sur le réseau. L'objectif de ce travail est de montrer qu'un réseau ad-hoc peut être utilisé pour un laboratoire conventionnel dans lequel les noeuds peuvent être mobiles ou non. En éliminant les serveurs centraux de fichiers, nous éliminons les seuls points de problème et rendont le système très fiable. L'utilisation du réseau sans fil élimine également le coût et les ruptures liés au câblage, hubs, switches, sockets et les problèmes qui y sont associés. Nous décrivons comment l'administration et les mises à jour de logiciel sont réalisées par l'utilisation d'une propagation semblable à celle d'un ver.

Motivation

Est-ce qu'il existe un besoin réel de serveurs ? Est-ce qu'un réseau d'ordinateurs dans un laboratoire ne peut pas fonctionner sans coordination centralisée ? Est-ce qu'un réseau ad-hoc peut fournir tous les services qu'un client demande ? Avec l'augmentation de la puissance de calcul, les réseaux deviennent intelligents. Les noeuds terminaux intelligents peuvent collaborer dans un environnement distribué pour faire tourner des application de manière plus efficace que le modèle traditionnel client/serveur.

Dans cet article, nous allons démontrer comment Linux peut être utilisé pour développer un réseau sans fil 802.11 ad-hoc pour un grand laboratoire d'informatique. A la place du modèle traditionnel client/serveur, nous avons développé un laboratoire autonome sans fil qui fonctionne sans aucun serveur. Ce concept enlève la plupart des redoutés points isolés d'échec dans le réseau. Nous allons inclure des détails sur la manière dont des scripts Linux soignés (Perl et Bash), de la programmation et configuration peuvent être utilisés pour développer un réseau distribué avec des fonctionnalités similaires au modèle client/serveur. Un des soucis principaux dans un laboratoire en mode ad-hoc, c'est le problème de l'administration. Dans une topologie distribuée, il n'y a pas un seul point de contrôle, ce qui rend la vie difficile à l'administrateur. Nous allons montrer comment les scripts Linux peuvent être utilisés pour s'atteler à diverses tâches administratives.

Les modèles de réseaux

Les applications se basant sur un réseau peuvent s'exécuter sur une seule machine ou être distribuées sur plusieurs machines. L'informatique client/serveur est un exemple d'arrangement distribué dans lequel une partie d'une application (le front end) s'exécute sur la station de travail pour fournir une interface à l'utilisateur alors qu'une autre part (le back end) s'exécute sur un serveur pour effectuer le travail effectif comme la recherche dans une base de données, le traitement de programmes, de fichiers, etc.

Les réseaux ad-hoc

Un réseau ad-hoc est une collection de noeuds autonomes ou terminaux qui communiquent entre eux en maintenant leur connectivité d'une manière décentralisée. Chaque noeud du réseau agit comme un serveur lorsqu'il fournit des services à d'autres noeuds et comme un client lorsqu'il reçoit des services des autres. Chaque noed est, en soi, une entité qui peut entrer ou quitter un réseau ad-hoc sans perturber le comportement du réseau. Chaque noeud est un hôte et un routeur en même temps. Les noeuds collaborent et contrôlent le réseau d'une manière distribuée.

Les réseaux sans fil ad-hoc sont formés lorsqu'une collection ad-hoc d'appareils équipés de capacités de communication se trouve à proximité l'un de l'autre. De manière claire, chaque paire de ces appareils dont la distance est inférieure à leur gamme de transmission peuvent communiquer directement entre eux. De plus, si quelques appareils se portent volontaires de manière occasionnelle pour agir comme répétiteur, il est possible de former un réseau ad-hoc avec plusieurs hops. Un élément distinctif important de ces réseaux par rapport aux réseaux “standards” est qu'ils ne reposent sur aucune infrastructure pré-existante ou contrôle centralisé. Ils opèrent dans un environnement dynamique avec les noeuds sans fil mobiles disponibles. Ces noeuds communiquent en utilisant des interfaces radio et peuvent être sujets à du bruit, une diminution d'intensité du signal et les interférences.

La différence fondamentale entre le modèle client/serveur et le modèle ad-hoc est que, dans le modèle ad-hoc, les processus interactifs peuvent être client, serveur ou les deux. Alors que dans un modèle client/serveur, un processus assume le rôle de fournisseur de service alors que l'autre assume le rôle de consommateur de ce service. Dans l'architecture client/serveur, une partie du traitement est également toujours réalisée par le serveur qui est le point central de contrôle. Si le serveur tombe en panne, tout le réseau tombe en panne.

Notre scenario

Nous avons mis en place un laboratoire sans fil ad-hoc au Electrical Engineering Department UET Lahore. Son but principal est de fournir un environnement fonctionnel aux étudiants de manière à ce qu'ils puissent travailler sur leurs devoirs/projets de programmation. Il n'y a pas de serveur NIS central qui maintient les comptes des utilisateurs et pourtant, un étudiant n'est pas confiné à une seule machine.

Dans ce réseau ad-hoc, les données sont importées vers la machine locale via NFS et le traitement est réalisé localement. Le traffic réseau est considérablement réduit puisque les noeuds (les clients) n'ont pas besoin de transférer toutes les données brutes vers un centre de traitement centralisé (le serveur), comme dans le modèle traditionnel client/serveur. Ce réseau ad-hoc peut fournir tous les services qui sont requis pour le travail dans ce laboratoire.

Buts de l'étude

• Aucun point d'échec qui pourrait rendre le laboratoire inopérant.
• Développement d'un réseau autonome avec une architecture distribuée.
• Maintenance du plus petit nombre possible de fichiers de configuration statiques.
• Identification de l'utilisateur et cryptage pour toutes les communications de données.
• Elimination des pertes de données par utilisation de procédures de backup à distance efficaces.
• Accomplissement d'une administration sans troubles.

Hypothèses

Nos hypothèses sont typiquement celles des systèmes à exécution à distance et ne sont pas exagérément restrictives ou extensives.

• Noms de répertoires et fichiers uniformes : nous supposons que tous les fichiers partagés sont accessibles sur tous les noeuds en utilisant les mêmes noms de répertoire et que la plupart des fichiers locaux sur chaque noeud sont également accessibles sous les même noms de répertoires (par exemple, /bin/ls).
• OS et configurations de logiciels compatibles : nous supposons que tous les noeuds dans ce réseau ad-hoc font tourner des versions compatibles de systèmes d'exploitation et possèdent des configurations de logiciels compatibles.
• Identifiant d'utilisateur unique : nous supposons que chaque utilisateur possède un identifiant d'utilisateur unique et que chaque noeud dans le réseau possède au-moins un compte home (chaque noeud est home d'au-moins un utilisateur).
• Base de données des comptes : nous supposons que le fichier de base de données contient l'identifiant d'utilisateur et l'adresse IP statique du noeud correspondant. La même base de données est disponible sur tous les noeuds.
• Adresses IP : il est supposé que les adresses IP sont statiques et qu'elles sont comprises dans la plage 192.168.0.***.
• Interface sans fil : il est supposé que les interfaces sans fil de chaque noeud sont allumées et travaillent en mode ad-hoc.
• Sauvegarde : le schéma d'adressage IP est tel que si l'IP de la machine home est 192.168.0.1, la machine de sauvegarde est 192.168.0.2.

Topologie et travail de notre réseau

• Chaque machine agit autant comme un serveur NFS que comme client NFS.
• Spécifications des clients : Pentium III, 733 MHz, Fedora Core 3, D-Link DWL-G520 (rev 01) NICs.
• Chaque étudiant a un compte sur une seule machine et nous appelons cette machine la machine "home" de cet étudiant, comme montré à la figure 1. Chaque machine maintient un fichier de base de données avec chaque identifiant d'utilisateur et l'adresse IP statique de la machine home. Tout le travail (par exemple, compilation Java et assemblage de programmes) est réalisé localement sur la machine home. Si l'étudiant se connecte à partir d'une machine autre que sa machine home, le répertoire home de l'étudiant est monté à distance, comme illustré à la figure 2. Une copie de sauvegarde automatique du répertoire home est gardée sur une seconde machine distante. Si le premier home tombe en panne, le second home est monté. L'utilisation d'autofs assure que le montage des systèmes de fichier appropriés à la demande.

Implémentation

Configurations des terminaux

Sur chaque terminal, nous avons créé quatre comptes utilisateur pour l'utilisateur home, le backup, l'administrateur et l'étudiant. De plus, trois répertoires sont créés, à savoir : /home/script, /home/script1 et /home/localwork. /home/script contient les scripts scriptm4, database, testlogin, unmount et back. /home/script1 contient remote1, remote2, et loggedip, comme indiqué à la figure 3. Le répertoire /home/localwork est celui où les fichiers distants sont montés. Nous expliquons tout cela en considérant l'exemple d'un utilisateur home u02026 (avec adresse IP 192.168.0.26) impliquant que le compte de sauvegarde de son terminal est u02025.

Editez le /home/student/.bash_profile du compte étudiant ainsi :

cd /home/script
bash /home/script/scriptm4

Le script scriptm4 est lancé lorsque le compte utilisateur student est loggé.

Maintenant, editez le /home/student/.bash_logout

bash /home/script/unmount
clear

Le script unmount se lance au logout.

Le /home/u02026/.bash_profile ressemble à ceci :

bash /home/script1/remote1
exit

Et /home/u02025/.bash_profile ressemble à çà :

bash /home/script1/remote2
exit

L'utilitaire rdiff-backup est utilisé pour les procédures de sauvegarde. Nous avons ajouter un job cron pour cette sauvegarde en éditant /var/spool/cron/u02026

0 13 * * * rdiff-backup /home/u02026 192.168.0.27::/home/u02026
0 13 * * * rdiff-backup 192.168.0.27::/home/u02026 /home/u02026

Cette édition de fichiers de configuration sur un grand nombre de terminaux est laborieuse. Aussi, nous avons développé un script (autoset1) qui automatise les tâches de configuration.

Ce script est lancé une fois en tant que root et il est placé dans /home/auto en même temps que tous les scripts mentionnés ci-dessus. Il demande de manière interactive les diverses informations (comme le nom de l'utilisateur home, celui de sauvegarde, le temps pour le job cron, etc.) qui doivent être configurées à partir du terminal. A part les arrangements mentionnés ci-dessus, un sous-script Perl ipinrc détermine les adresses IP des terminaux voisins qui seront utilisés plus tard pour la génération de clés, le partage et les autres tâches administratives.

Environment de travail

Avec les configurations initiales définies sur tous les terminaux, nous allons maintenant expliquer comment les noeuds ad-hoc vont utiliser les scripts pour définir un environnement de travail pour l'utilisateur.

Tout étudiant qui souhaite travailler se connecte avec le compte “student” qui est un compte ouvert. Cette connection à “student” initialise le script scriptm4 qui demande à l'utilisateur d'entrer sont identifiant d'utilisateur qui lui a été assigné. Le sous-script testlogin vérifie cet identifiant dans le fichier de base de données.

Le listing suivant montre un exemple de fichier de base de données présent sur chaque terminal.

L'adresse IP correspondant à un identifiant utilisateur valide est extraite du fichier de base de données. Ce script identifie alors l'utilisateur en faisant un ssg vers la machine home (ssh userid@user_home_ip). Un mot de passe utilisateur valide permettra alors à l'utilisateur de se connecter à sont compte home. A son tour, cela lance le script remote1 présent dans .bash_profile du compte home sur la machine distante/home.

Un sous-script nommé loggedip se lance à partir de remote1. Il extrait l'adresse IP de la machine qui s'est connectée avec succès la dernière fois.

Après cela, le script remote1 édite /etc/exports pour exporter le répertoire home à l'adresse IP où l'utilisateur se trouve. Et la connexion ssh est terminée en rendant le contrôle au script scriptm4 sur la machine locale.

Finalement, avec les permissions d'export correctes sur la machine distante, le répertoire home est monté via NFS et une console s'ouvre pour que l'utilisateur puisse commencer son travail. L'utilisateur est complètement inconscient de ces processus en tâche de fond et l'entièreté du processus est transparent à l'utilisateur.

Au logout, le script unmount est invoqué. Il s'assure que tous les montages NFS sont démontés.

Procédures de sauvegarde

Chaque machine maintient une copie de sauvegarde du répertoire home de l'utilisateur sur une machine voisine appelée terminal de sauvegarde. La procédure de sauvegarde distribuée utilise cron et les utilitaires rdiff-backup.

rdiff-backup

rdiff-backup sauvegarde un répertoire dans un autre, éventuellement à travers le réseau. Le répertoire cible finit par être une copie du répertoire source, mais des "reverse diffs" supplémentaires sont stockés dans un sous-répertoire spécial de ce répertoire cible, de manière à ce que vous puissiez quand même récupérer des fichiers perdus il y a un certain temps. L'idée est de combiner les meilleurs fonctionnalités d'un miroir et d'une sauvegarde incrémentale. Rdiff-backup préserve également les sous-répertoires, liens en durs, fichiers dev, permissions, propriétés uid/gid et les temps de modification. Rdiff-backup peut également de manière efficace du point de vue de la bande passant, comme rsync. Ainsi, vous pouvez utiliser rdiff-backup et ssh pour savegarder de manière sécurisée n'importe quel répertoire dans un endroit distant, et seulement la différence sera transmise. Finalement, rdiff-backup est facile à utiliser et utilise des paramètres par défaut sensibles.

cron

cron est un planificateur de tâches puissant sous Linux. Il permet l'exécution de commandes à des moments spécifiés par l'utilisateur. Le fichier de configuration /var/spool/cron/user spécifie le moment auquel la commande requise doit être exécutée. Les utilisateurs peuvent configurer ce fichier en utilisant la commande crontab. Il y a d'habitude sept champs pour chaque entrée.

Ces champs sont :

minute heure jourdumois mois jourdelasemaine utilisateur commande
e.g.
0 13 * * * rdiff-backup 192.168.0.27::/home/u02026 /home/u02026

Note méthode

La procédure de sauvegarde est lancée aux moments où le laboratoire n'est pas utilisé. Les moments des différents cronjobs sont déterminés pour être uniques afin que les procédures de sauvegarde soient efficaces du point de vue de l'utilisation de la bande passante. Pour réaliser cela, les terminaux sont sauvegardés de manière à ce que seulement un ou deux terminaux sont en train d'effectuer la procédure de sauvegarde simultanément.

Une copie automatiquement sauvegardée du répertoire home est gardé sur une seconde machine distante. Si le premier home défaille, le second home est monté. L'utilisation d'autofs assure que le montage/démontage des systèmes de fichiers appropriés à la demande.

Administration

Un des problèmes principaux du développement d'un laboratoire en mode ad-hoc est le problème d'administration. Dans une topologie distribuée, il n'y a pas un seul point de contrôle. Il était donc besoin de développer une manière élégante d'assister l'administrateur dans ses importantes tâches administratives comme le transfert d'un seul fichier à tous les noeuds, l'exécution d'une commande sur tous les noeuds, etc.

Nous avons conçu notre schéma de distribution de manière à pouvoir effectuer les tâches administratives. Sur chaque terminal, un compte administrateur a été créé, comme mentionné précédemment.

Partage de clés SSH

SSH est le remplaçant d'utilitaires standard non cryptés comme telnet, rlogin et rsh. Il permet à l'utilisateur d'exécuter à distance des commandes. De nombreuses méthodes d'identification existent pour SSH comme rhosts-RSA-Authentication, RSA Authentication, l'identification par mot de passe utilisant /etc/passwd. L'identification RSA ne requière pas que l'utilisateur entre un mot de passe mais la session est quand même cryptée. La cryptographie à clé publique RSA est utilisée durant le handshake entre le client et le serveur pour identifier la machine client.

Chaque compte administrateur sur un terminal partage la clé ssh avec le compte administrateur de ses voisins, comme montré sur la figure 4. La génération de clés et le partage avec les terminaux voisins doit être faite une fois, après que les terminaux aient été préparés comme mentionné ci-dessus. Ce script keygen2 génère une clé ssh pour un terminal, effectue les modifications nécessaires au répertoire .ssh de l'utilisateur-administrateur et partage la clé avec les terminaux voisins. Cela permet au compte administrateur d'accéder aux comptes administrateur de ses voisins sans mot de passe tout en fournissant une communication cryptée nécessaire au réseau sans fil. Ce concept d'accès au terminaux voisins sans mot de passe est essentiel au fonctionnement des scripts fileworm et commandworm présentés ci-dessous.

FILEWORM

Dans notre scénario, l'instructeur a souvent besoin de transférer un fichier sur le réseau afin que les étudiants puissent travailler dessus. Cela aurait pu être réalisé de diverses manières comme, par exemple, le transfert du fichier sur chacun des noeuds, un à un, à partir d'un seul terminal, en utilisant la bande passante de manière inefficace.

Nous avons développé une méthode qui transfère le fichier en un minimum de temps et avec une utilisation optimale de la bande passante. Cela fonctionne comme un vers et duplique le fichier à travers le réseau. Le transfert du fichier peut être initié de n'importe quel noeud dans le réseau ad-hoc. Le noeud initial transfère le fichier à ses noeuds voisins et, à leur tour, ces noeuds le transfère à leurs noeuds voisins. Avant de transférer le fichier, on vérifie la présence de ce fichier dans un répertoire particuliers sur les noeuds voisins. La présence du fichier sur les noeuds qui initient le scipt fileworm n'est pas vérifiée. Si le fichier n'est pas présent [sur le noeud voisin], il est transféré. Sinon, aucune action n'est prise. Ce processus continue jusqu'à ce que le fichier soit transféré à tous les terminaux, comme indiqué sur la figure 5.

COMMANDWORM

Il exécute une seule commande sur tous les noeuds. Il fonctionne sur le même principe que fileworm. Mais, à la place de transférer des fichiers, il exécute des commandes sur tous les noeuds, par exemple éteindre tous les noeuds à partir d'un terminal. Le noeud initial exécute la commande sur ses voisins qui, à leur tour, vont exécuter la commande sur leurs voisins. Cela continue jusqu'à ce que la commande soit exécutée sur tous les noeuds.

Synchronization du temps

Avec des fichiers partagés sur un grand nombre de stations de travail, il devient impératif que les horloges des machines soient synchronisées de manière à ce que les indications de temps sur les fichiers soient globalement comparables. La synchronisation du temps aide à maintenir les logs, à implémenter les procédures de backup, etc. Nous configurons simplement toutes les machines pour qu'elles règlent leur temps sur une seule référence.

Remerciements

Ce travail a été réalisé sous la supervision du professeur Shahid Bokhari au Computer Communications Laboratory du Department of Electrical Engineering, UET, à Lahore, au Pakistan. Ce laboratoire a été mis en place avec une bourse du Gouvernement du Punjab. Le réseau sans fil de ce laboratoire a été rendu possible par le support généreux des anciens de 86EE et 93EE.

Références

• Shahid H Bokhari and Rafeequr Rehman, “Linux and the Developing World”, IEEE Software, Vol. 16, No. 1, Feb. 1999, pp. 58-64
• S. H. Bokhari, “The Linux Operating System”, Computer, Vol. 28, No. 8, Aug 1995, pp. 74-79
• http://www.linuxjournal.com/article/4139
• http://www.linuxjournal.com/article/4880
• http://www.linuxjournal.com/article/4413
• http://www.linuxjournal.com/article/7630
• http://www.linuxjournal.com/article/6909
• http://www.linuxjournal.com/article/3290
• http://www.nongnu.org/rdiff-backup/
• http://www.seattle-sage.org/1999/06/ssh.pdf

Talkback form for this article

2006-08-15, generated by lfparser version 2.54