|
|
Association Francophone des Utilisateurs de Logiciels Libres French speaking Libre Software Users' Association Promouvoir les logiciels libres ainsi que l'utilisation de standards ouverts. |
|
|
Mise en fonction d'une salle informatique à l'écoleTable des matières
Objectifs généraux et contraintesObjectifs : mise en fonction d'une salle informatique permettant :
Cahier des charges : Au vu des moyens à disposition, la seule solution envisageable possède les caractéristiques suivantes :
Présentation générale du réseau intranetLa salle informatiqueLes câblages de la salle ont été réalisés par un électricien des services techniques de l'Université. Le système d'exploitationLe système d'exploitation choisi est un Unix libre et gratuit5 appelé Linux. L'avantage évident au premier abord est la gratuité du système. Cela n'est pas le plus important, le temps que l'on consacre à la mise en place ou à la maintenance pouvant augmenter ce coût. Plus déterminant, ce système est stable6. Le support technique existe grâce au news group et autres mailing-lists que l'on peut trouver sur le W3 (World Wide Web) mais aussi plus classiquement grâce à des sociétés apparues plus récemment du fait de l'ouverture du marché linux pour les entreprises. De plus, la pérénité de ce système semble maintenant acquise7. Linux est un Unix à part entière et son intégration dans un environnement UNIX plus général ne pose pas de problème (de compatibilité ou autre). Le serveur graphique8 est basé sur X119 et de nombreux window managers10 existent, des plus simples : twm ou fvwm aux plus intégrés : kde11 ou gnome12. Du point de vue de la sécurité, linux étant un Unix, les standards de sécurité sont élevés13 et les procédures de mise en place des outils liés à la sécurité sont bien connues. Pour les vieilles machines comme les i48614 que nous avons récupérés, linux a un intérêt déterminant par rapport à Windows. En effet, linux utilise les ressources matérielle des PC jusqu'à leurs limites et permet ainsi de travailler avec confort sur de vieilles machines comme les Intel 486DX récupérées. Enfin, les services réseau nécessaires à la mise en place d'une solution intranet existent, sont éprouvées et sont livrés en standard dans les distributions de linux. Dans la salle informatique, il n'y a pas d'imprimante installée pour le moment. Le serveur n'est généralement pas utilisé comme poste lors des TD/TP. Il peut cependant servir lors de démonstrations nécessitant des ressources processeur ou mémoire importantes. Nous avons 4 unités constitués chacune de 4 chaises, 3 tables et 2 PC clients. Les bureaux étant peu larges, l'utilisation de 3 bureaux par unité permet aux étudiants d'y poser leurs affaires, de partager le clavier, etc. Le câblage électrique et Ethernet passe dans une rigole en plastique placée sous les bureaux centraux du hub jusqu'au huitième poste. Les applications libresIl existe de nombreuses applications fonctionnant sous linux15, autant scientifiques que bureautiques16. Celles qui sont livrées en standard dans les distributions linux sont libres et gratuites, et n'engendrent aucun coût supplémentaire pour l'achat de logiciels. Plus précisément, une grande partie des applications libres sont sous licence GPL17, ce qui permet de les copier et les redistribuer sans aucun problème. L'utilisation de cette licence a permis d'homogénéiser d'un point de vue juridique le développement des logiciels libres (OSS ou Open Sources Software). La liste des applications installées et utilisées dans le cadre de l'enseignement en Sciences de la Terre est donnée dans l'annexe B. Les applications fonctionnant sous WindowsCertaines applications utiles pour des TP/TD de cristallographie tournaient sous Windows 3.1, il serait bien sûr intéressant de pouvoir les utiliser sur chacun des postes. Cela ne se fera pas pendant cette première phase (1998/99), cependant, on peut déjà citer deux possibilités à explorer :
Le serveur et les servicesLes postes sont indépendants du serveur du point de vue système (ce ne sont pas des terminaux), du point de vue service graphique également (X11 ainsi que le window manager est installé sur chacun des postes). La plupart des travaux utiliseront le processeur du poste client (le serveur n'est pas un serveur CPU). Le serveur est donc essentiellement un serveur NIS20, DNS21 et NFS22 (partage de fichiers : homes23 et applications24). Il est également prévu d'installer une imprimante partagée25 sur le serveur26. Le serveur est un AMD K6-3D à 350 MHz doté de 128 Mo de mémoire SDRAM, (voir l'annexe A pour plus de précisions). Cette configuration semble suffisante27 pour l'utilisation actuelle de la salle. En fait, la limitation matérielle est essentiellement la faible bande passante serveur-hub (à 10 Mb/s). En effet, la solution utilisée pour le réseau est une étoile avec un hub (ou concentrateur) 3COM 16 ports en 10 Mb/s. Remplacer le hub par un switch 100/10 Mb/s aurait été plus adapté28 car cet option garantissait une bande passante de 10 Mb/s à chaque poste client. Pour des questions de coût, cela n'a pu être réalisé. Cette partie du projet est cependant très facilement modifiable29 l'année prochaine (1999/00) si, à l'usage, le besoin s'en faisait sentir. La maintenancePour que la maintenance du réseau intranet et des applications soit simple (et par conséquent peu coûteuse en temps), il est important de standardiser les postes afin qu'ils possèdent des capacités comparables (processeur, mémoire, disques), ceci permet d'avoir les mêmes possibilités logicielles et la configuration réseau des postes devient également homogène30. Résumé des coûts matérielsLe PC utilisé comme serveur a été acheté chez un assembleur. Le montant de l'achat s'élève à 12 kF (tous les prix sont TTC). La partie matérielle réseau se limite à l'acquisition d'un hub pour 1.4 kF. Enfin, les différents achats de petit matériel d'occasion pour la mise à niveau des postes clients représentent environ 2 kF. En effet, dans notre cas, la première contrainte en terme de matériel est que l'on ne choisit pas ce que l'on récupère. Donc, l'objectif d'homogénéisation des postes au niveau matériel a engendré quelques surcoûts : acquisition de petits disques durs (~0.5 kF), de mémoire RAM (~0.4 kF), de cartes graphiques ISA (~0.6 kF), et d'autres composants (cartes mères,... pour ~0.5 kF). Investissement en tempsL'installation et la configuration de la solution envisagée nécessite un certain investissement en temps au moins lors de la conception/mise en place. Cependant, toutes les options prises l'ont été dans le but de simplifier la maintenance et de diminuer le coût en temps lors de l'exploitation. La stabilité inhérente au système UNIX ainsi que la sécurité engendrée devrait permettre un faible nombre d'interventions (entre autre les réparations31). D'ailleurs, pour le moment, aucun problème ou panne d'une des machines, d'un logiciel ou de la partie réseau n'est à signaler depuis l'entrée en fonction de la salle (mi-mars). La centralisation des comptes utilisateurs et des logiciels permet de simplifier là encore la maintenance (entre autre l'installation ou la mise à jour des logiciels). L'estimation de l'investissement en temps est difficile, cependant, en excluant le temps passé à récupérer ou à acheter du matériel ainsi que le temps passé à se documenter via internet sur les logiciels libres, il nous a fallu 16 demi-journées pour deux personnes. L'accès vers l'extérieurL'accès à internet est très important pour la formation des étudiants. En effet, cela leur permet, par la pratique, de se former à un outil qui devient incontournable. Savoir définir l'information dont on a besoin, la chercher et surtout savoir trouver celle-ci dans la multitude, le trop d'informations qui nous submerge32 est fondamental, non seulement dans la recherche ou toute autre activité professionnelle, mais aussi dans la vie de tous les jours. D'autre part, pour certains projets en Science de la Terre, il pourrait ainsi être possible de récupérer des données ou des informations sur d'autres sites universitaires, ou sur des sites liés à des observatoires, etc. Autre exemple, l'accès à des bases de données informatisées répertoriant les ouvrages à disposition dans telle bibliothèque33 est un outil très utile pour l'efficacité de la recherche d'information. Enfin, il serait très utile que les étudiants disposent d'une adresse Mel personnelle, ceci permet aux professeurs ou à l'administration de les joindre aisément. Dans tous les cas, l'utilisation d'Internet et du Mel développent l'autonomie de l'étudiant. Enfin, du point de vue de l'enseignement également, la connection de l'intranet permettrait de transferrer des données ou des images (par exemple issues du microscope) en temps réel. Notre réseau n'a actuellement aucun lien physique avec l'extérieur. Pour accéder à Internet, la solution la plus simple et la plus logique serait de relier ce sous-réseau au réseau informatique de l'université. Cependant, la politique informatique actuelle de l'université est très stricte en matière de sécurité. Il nous faut donc étudier avec ses services et en accord avec la charte informatique, les possibilités permettant de mettre en œuvre une solution si possible dès l'année prochaine (1999/00). Une solution simple, en accord avec la charte de l'université pourrait être d'installer une ligne téléphonique dans la salle informatique et d'équiper le serveur d'un modem. Cette solution peut s'avérer coûteuse, peu efficace (en terme de débit) et nous semble en désaccord avec une utilisation rationnelle des possibilités du réseau. En attendant une ouverture vers l'extérieur, nous installons les logiciels ou transferrons des données via un disque dur sur tiroir amovible installé sur le serveur. ConclusionsL'ensemble des objectifs fixés dans la première section a globalement été atteint, à l'exception la plus notable de l'installation d'une imprimante, qui se fera normalement dans le courant du mois de mai 99. En dehors de la recherche de documentation, de l'achat de pièces détachées, et de la rédaction de ce rapport, il a fallu environ 8 journées de travail à deux personnes, et au moins le double si on prend tout en compte (c'est à dire les prises de contact avec des entreprises susceptibles de nous donner des PC qu'elles considèrent obsolètes). Ce temps de travail s'est réparti sur environ 4 mois (décembre 98 à mars 99). Il est à noter que ce sont les PC desktop (Compaq et Digital), qui nous ont posé le plus de problèmes (voir l'annexe A). La salle est aujourd'hui en fonctionnement depuis plusieurs semaines (mi-mars). Plusieurs travaux pratiques ont été effectués avec 15 étudiants (deux par poste). Aucun problème notable n'est à signaler : ni panne matérielle, ni crash logiciel ou système. Le temps consacré à la salle depuis sa mise en service se limite à une dizaine d'heures pour l'installation de nouvelles applications exclusivement. Il est cependant trop tôt pour crier victoire, et ce n'est qu'au bout d'un an que nous saurons si la maintenance d'une telle salle est viable pour une petite équipe universitaire. Un second rapport, d'activité cette fois, devrait donc voir le jour au printemps 2000. Le développement prochain le plus évident et le plus important est l'ouverture du réseau à l'extérieur. La meilleure solution est l'ouverture au réseau de l'Université. Nous devons pour cela obtenir l'accord du service de sécurité informatique de l'Université. RemerciementsNous remercions Dmitri Pissarenko pour le don des PC de l'ENS, Bruno Cornaglia pour le don des PC Digital, et Ronan Hébert qui s'est occupé des contacts avec EDF (PC Compaq). Les membres du Centre De Calcul et du service réseau de l'Université de Cergy-Pontoise nous ont aidé par leurs conseils techniques et par la fourniture des cables réseau. Jean-Claude Guézou a été le régisseur financier du projet. Nous remercions enfin Sébastien Landrieux, Frédéric Flérit et Roland Martin pour le coup de main apporté lors de la mise à niveau hardware des PC clients et de la configuration du réseau. Configuration hardwareLe serveurLa configuration du serveur est détaillée ci-dessous. Elle correspond à un budget TTC de 12 kF34, en novembre 98. Le serveur dispose en outre d'un rack pour disque dur amovible qui permet le transfert de gros fichiers entre la salle informatique et le réseau de l'Université.
Homogénéisation des postes clientsLes PC récupérés se répartissaient en trois groupes :
Hormis la configuration de X11, l'homogénéisation des configurations hardware des PC n'a pas posé de grandes difficultés. En résumé, l'homogénéisation pour les processeurs se limite au fait que l'on n'a conservé que les i486 (DX2-50, 66 et 80), elle n'a pas posé de problème pour la mémoire RAM37 (16 Mo) ni pour les disques (capacité minimum de 400 Mo en un ou deux disques). En revanche, les PC Compaq ont posé des difficultés car le setup de la carte mère (BIOS/CMOS) est non standard, ce qui impose la création d'une partition supplémentaire38. En ce qui concerne la configuration de X1139, ce sont les circuits graphiques des PC desktop Compaq et Digital qui ont posé le plus de difficultés. Ceux-ci ne sont pas présents sous la forme de cartes graphiques enfichables sur slot mais sont intégrés à la carte mère. Il s'est avéré que les deux types de circuits graphiques, les QVISION 1024/I pour les Compaq et les S3 86C924 pour les Digital ne sont pas compatibles avec les serveurs graphiques X11 de XFree8640. En revanche, nous avons trouvé un vendeur de serveur X11 commerciaux : Accelerated-X41 qui proposait pour 100 US $ par machine42, un serveur X compatible avec les circuits graphiques des PC Compaq (QVISION 1024/I). En ce qui concerne les PC Digital, le circuit graphique S3 924 est géré par XFree86 mais à partir de 1 Mo de mémoire vidéo. Malheureusement, les circuits de nos deux PC Digital ne comprennent que 512 ko de mémoire. Donc, dans les deux cas, il a fallu neutraliser les circuits graphiques de la carte mère et les remplacer en installant une carte graphique ISA sur un slot libre. Ces cartes étant très anciennes, il a été très difficile d'en trouver 5 en bon état de marche. Donc, il est important de noter que, dans notre cas, la totalité des machines provenant d'entreprises sont des desktop et comportent des circuits graphiques non compatibles avec les serveurs X11 libres et gratuits. Ceci est probablement dû au fait que les développeurs de serveurs X11 libres s'attaquent en priorité au matériel qu'ils utilisent, c'est-à-dire au matériel des assembleurs43. Enfin, les écrans ne peuvent guère être homogénéisés. La configuration de X11 sur chacun des postes dépend des capacités de la carte graphique et de l'écran. On notera cependant qu'un effort a été fait pour que l'ensemble des écrans utilise la résolution 800x600 à une fréquence supérieure à 60 Hz, deux écrans n'atteignent pas cette résolution44 et étant de qualité médiocre, ils doivent être remplacés en priorité. Les cartes Ethernet comportent toutes une sortie RJ45 et sont enfichées sur un slot ISA. Ce sont des NE200045 sauf sur les deux PC Digital où ces cartes sont des Etherworks-3. Le matériel réseauLe hub (ou concentrateur) est de marque 3COM, il comporte 16 ports en 10 Mb/s (prises RJ45). Les câbles ont été fournis par le service informatique réseau de l'Université. L'imprimanteLes deux imprimantes laser récupérées ne fonctionnant pas, nous n'avons pour le moment aucune solution. On cherche de préférence (car robuste et peu coûteuse à l'exploitation) une imprimante laser de type HP laserjet II ou III. Configuration softwareLe systèmeLa distribution linux installée sur l'ensemble des machines est la RedHat 5.2 (version anglaise). Elle se présente sous la forme d'un CDROM d'installation bootable. L'installation de linux sur le serveur n'a pas posé de problème particulier. Pour les postes clients, l'installation s'est effectuée sans problème via NFS46. La faible place disque disponible sur les clients (moins de 320 Mo, 100 Mo étant réservé) n'a pas affecté l'installation du système, celui-ci n'étant pas très gros. Pour les applications fournies en standard, un choix s'est révélé nécessaire puisqu'une installation complète nécessite plus de 500 Mo. Le window managerNe pouvant utiliser les WM intégrés comme KDE ou Gnome47, nous avons laissé le choix par défaut de la distribution RedHat, c'est à dire fvwm. Ce window manager est complet, pratique (boutons, iconification, bureaux virtuels par exemple) et surtout peu gourmand en mémoire et CPU ce qui est important pour des clients de type i486 à 16 Mo de RAM. Le seul désavantage est la relative complexité de la configuration de fvwm. Nous avons d'ailleurs laissé la configuration par défaut. Chaque étudiant est cependant libre de configurer fvwm (fichier personnel situé dans son home) comme il l'entend. Les services réseauxNous avons déjà parlé des services DNS, NIS et NFS. Des détails sont donnés en annexe D sur la résolution des noms grâce au DNS et au NIS, en annexe E sur la centralisation de l'information grâce au service NIS et en particulier sur les comptes utilisateurs, ou encore en annexe C sur la configuration des systèmes de fichiers, entre autre sur les montages NFS. En ce qui concerne les applications réseau (browser web, ftp, telnet, ...), elles ne sont guère utiles dans le cadre d'un intranet excepté peut-être telnet pour les applications nécessitant de se loguer sur le serveur (voir ci-dessous l'exemple de Star Office). Les homeLes home sont des espaces disques contenant les répertoires par défaut des utilisateurs. Ils sont, nous l'avons déjà dit, partagés via NFS. La partition /home contenant les home des utilisateurs est physiquement sur le serveur NFS, c'est à dire erebus. Elle a une taille de 2.5 Go, ce qui est largement suffisant pour 15 étudiants en licence, environ 25 en DEUG et quelques professeurs. Un système de quota à cependant été mis en place avec une limite de 100 Mo par personne. Les applicationsSur le serveur, l'installation de la RedHat est complète. En revanche, sur les postes clients, les applications n'ont pas pu être toutes installées par manque de place sur les disques durs. Il a été nécessaire de faire un choix entre l'installation en local (accès plus rapide et non dépendant de l'encombrement du réseau) ou partagée et donc sur le serveur. Cette opération de sélection s'effectue simplement lors de l'installation, le logiciel d'installation de RedHat demande de choisir les packages48 un par un ou par groupes. Nous avons préféré, pour des raisons d'automatisation, installer le système à partir du logiciel d'installation de RedHat et les applications sur chaque poste grâce à un petit script49 en cshell. Pour une application donnée, le choix entre une installation locale et une installation sur le serveur accessible via NFS se fait d'après deux critères : une application est installée en local lorsqu'elle ne demande que très peu de place disque (par exemple, la calculatrice du bureau xcalc) ou lorsqu'elle est très utile au point d'être utilisée souvent et par de nombreuses autres applications (par exemple le visualisateur de Postscript ghostscript qui est utilisé par gv ou encore xv). Dans notre cas, le serveur NFS pour les applications est encore une fois la machine erebus. le répertoire de montage étant le classique /usr/local (le répertoire /opt étant un lien symbolique sur /usr/local). Les applications installées en localIl s'agit de programmes qui résident sur les diques durs de chaque poste, et qui sont exécutés par chaque poste. La liste n'est pas exhaustive :
Les utilitaires et applications bureautiquesUne application bureautique, comme un traitement de texte, a deux fonctions. Premièrement, elle sert à écrire un rapport, à mettre en forme un document, pour obtenir finalement une sortie sur papier qui pourra être diffusée. La deuxième fonction est liée à l'échange d'information ou de documents sous forme ``électronique'', c'est à dire sous forme de fichiers utilisant un certain format ou encore par Mel ou grâce au Web. Dans ce dernier cas (qui ne nous concerne pas pour le moment) du Mel ou du Web, les formats sont standards et ne posent pas de problème. Dans le cas d'un fichier échangé, prenons l'exemple d'un fichier au format Microsoft Word 97, il est nécessaire d'avoir une application comprenant ce format pour pouvoir lire ce fichier (par exemple Word 97 !). Cette deuxième fonction serait bien sûr facilitée par l'utilisation généralisée de formats standards (comme html pour le Web). Ceci n'étant pas, nous n'avons pas trouvé de solution satisfaisante pour l'instant. Les applications de bureautique sont toutes installées sur le serveur de logiciels, et sont exécutées sur chaque poste. Nous avons installé le ``traitement'' de texte LATEX (et TEX ) avec les différents utilitaires comme bibtex50 ou xdvi51 ou encore l'excellente interface graphique de LATEX que nous sommes en train d'utiliser pour écrire ce rapport : LYX52, On compte installer d'ici la mi-mai (début de l'écriture des rapports) :
Les applications scientifiquesActuellement, les applications scientifiques SciLab59, Seismic Un*x60 et GMT61 sont installées sur le serveur. Elles sont accessibles par les clients via NFS et peuvent tourner sur les postes clients. Systèmes de fichiers, partitionnement et fichier /etc/fstab (le NFS)Nous précisons dans cette annexe la configuration des systèmes de fichiers du serveur et d'un client. On pourra la considérer comme un exemple d'application des How-To du NFS (Network File System). Les fichiers peuvent résider physiquement sur les disques durs du serveur ou d'un poste client, sur des disquettes, ou sur CDROM. Les répertoires ou noms de fichiers sont indiqués par la fonte machine à écrire. Les commandes et noms de machines sont en caractères gras. Le serveur erebusLorsque l'on lance la commande df sur le serveur erebus, on obtient les informations suivantes (que nous avons reproduites sous forme de tableau) :
Le serveur dispose de deux disques durs d'environ 4.5 Go, le premier disque est en primary master62, ce qui se traduit en terme de device en /dev/hda et le second en secondary master, donc en /dev/hdc. Le premier disque comprend 3 partitions montées (visibles grâce à la commande df) :
Le second disque comprend quatre partitions (elles sont toutes montées) :
les postes clientsDans cette section, nous allons considérer le cas d'un client en particulier : puydedome. Lorsque l'on lance la commande df sur le poste client puydedome, on obtient :
La partition /dev/hda1 est la partition root, elle n'a pas besoin d'être très grosse (ici 43 Mo). puydedome est un Compaq, une partition est donc nécessaire pour le BIOS et la gestion des disques, elle n'apparaît pas dans ce tableau car elle n'est pas montée par le système linux, elle est en /dev/hda2 et prend 2 ou 3 Mo. La partition /dev/hda3 est réservée pour Windows si besoin était, elle fait environ 100 Mo, elle n'est pas utilisée pour le moment et n'est donc pas monté par le système linux. Elle n'apparaît donc pas. La partition /dev/hda4 est une partition étendue, c'est à dire virtuelle mais pouvant être découpée en morceaux, permettant ainsi de créer autant de partitions logiques que nécessaire, et qui apparaissent comme des partitions normales pour l'utilisateur. Cette partition n'apparaît donc pas ici. Elle est partagée en deux partitions étendues : la partition /dev/hda5 qui est la zone swap du système linux et la partition /dev/hda6 montée sur /usr comme on peut le voir dans le tableau. Cette partition fait 215 Mo et contient l'ensemble des applications nécessaires à Linux. Les trois autres lignes commencent par erebus qui est le nom du serveur, cela signifie que ces partitions ne sont pas sur le disque local mais montées à travers le réseau par NFS. Ces partitions sont vues et sont utilisables comme des partitions sur disques locaux, la différence pour l'utilisateur pouvant être l'accès plus lent aux fichiers lorsque le réseau est encombré ou lorsqu'il manipule des gros fichiers. Lorsque nous éditons le fichier /etc/fstab sur puydedome, nous avons accès au tableau suivant :
En plus des informations déjà données dans le paragraphe précédent, on peut remarquer des devices qui possèdent l'option noauto, ce qui signifie qu'ils ne sont pas montés au boot (lors du démarrage du système). L'option user permet à tout utilisateur de monter ces devices, ce qui est utile pour un lecteur de disquettes par exemple. C'est justement le cas des lignes 5 et 6 car /dev/fd0 signifie en linux ``le DEVice Floppy Disk 0'', c'est à dire en DOS ``a:''. Ce device peut être monté de deux manières différentes, sur le répertoire (point de montage) /floppy lorsque le système de fichiers (ou filesystem ou FS) est vfat, c'est à dire du DOS ou du Windows, ou bien sur le répertoire /flopext2 lorsque le système de fichiers est ext2, c'est à dire du linux. La ligne 7 montre comment monter un lecteur de CDROM à travers le réseau via NFS (comme indiqué dans la troisième colonne), là encore les options noauto et user sont utilisées. Nous avons pris comme exemple la machine puydedome. Malgré notre volonté d'homogénéisation des postes, le système de fichiers et le fichier /etc/fstab ne sont pas les mêmes sur tous les postes clients. Par exemple, les machines non Compaq n'ont pas besoin de partition spéciale. De plus, les disques ne sont pas les mêmes sur toutes les machines. Par exemple, deux des machines ont deux disques de 240 Mo et 265 Mo à la place d'un disque de 400 Mo ou 450 Mo. Les noms de machine et leur adresse IP (le DNS, le NIS hosts)Lorsque l'on téléphone à quelqu'un, soit on connaît son numéro par cœur, soit on consulte un annuaire. Il en est de même pour les ordinateurs, qui ont un nom, un alias, et un numéro (l'adresse IP). On pourrait ne désigner les ordinateurs que par leur adresse IP, mais on se heurterait immédiatement à la quasi-impossibilité de s'en souvenir. Nous développons ici le fonctionnement du DNS (Domain Name Service), sorte d'annuaire qui gère les noms, alias, et adresses IP des postes, et nous disons quelques mots sur la partie du NIS (Network Information Service) qui fait sensiblement la même chose. Pour la résolution de noms, on trouve dans le fichier /etc/resolv.conf des postes clients la ligne suivante :
Elle indique que le serveur pour la résolution des noms est 10.10.10.1, c'est à dire erebus. En effet, ce service (DNS) est installé sur erebus, c'est donc lui qui donne à l'ensemble des machines du réseau intranet l'équivalence entre l'adresse internet (ou adresse IP), le nom et l'alias (ou nom court) de la machine. Par exemple, pour puydedome l'adresse IP est ``10.10.10.8'', le nom est ``puydedome.STetud.u-cergy.fr'' et l'alias ``puydedome''. Les numéros utilisés ici font partie des adresses non routées, c'est à dire, qui ne sont pas joignables sur internet, les machines portant ce numéro n'existent pas pour les autres. Ceci n'était pas nécessaire puisque le réseau est purement intranet et n'est pas connecté physiquement au reste du monde, cependant, dans le cas ou il serait possible à terme de le connecter, nous avons préféré leur donner des numéros non routés. En fait, l'information sur puydedome apparaît déjà dans un fichier local nommé /etc/hosts (hosts signifie ici ``client'') et dont voici le contenu sous forme de table :
La première ligne indique à l'ordinateur comment discuter avec lui-même (loop-back), il ne faut surtout pas l'enlever. La seconde correspond à la définition de l'équivalence adresse-nom-alias dont nous avons déjà parlé. La différence est que sur le serveur de nom l'ensemble des machines est répertorié. On pourrait bien sur lister (sur toutes les machines) les équivalences dans les fichiers /etc/hosts mais cela multiplierait le nombre de modifications à faire et augmenterait le risque d'erreurs lors de la maintenance réseau. Une autre fonction du serveur de noms que l'on exploite pas ici puisqu'il n'y a pas de connexion vers l'extérieur est de normalement permettre d'accéder aux machines de l'extérieur et donc aux sites Web, etc (sans qu'elles soient répertoriées dans des fichiers locaux). Enfin, l'extension ``.STetud.u-cergy.fr'' est un nom de domaine qui correspond dans notre cas au domaine défini par le DNS (domainname) et par le NIS (nisdomain), on a choisi par simplification de faire coïncider ces domaines. L'équivalence adresse-nom-alias pour toutes les machines linux (c'est à dire toutes) est en fait également présente dans les tables NIS. Ce service permet de centraliser l'information sur les utilisateurs, les groupes et les machines64. Pour utiliser NIS, il est nécessaire de lancer le service sur les machines clientes (le démon ypbind) et d'avoir un serveur NIS, en l'occurence erebus une fois de plus. Le nom du serveur est présent dans le fichier /etc/yp.conf de chaque machine cliente, on y trouve la ligne suivante :
YP signifie yellow page et est utilisé comme synonyme de NIS. En ce qui concerne les informations sur les machines, cela signifie que NIS peut résoudre les équivalences adresse-nom-alias (pour les machines faisant partie du domaine NIS, une machine sous windows n'en ferait pas partie par exemple). Dans notre cas, le DNS et le NIS (hosts) sont redondants car premièrement, on n'a pas de connexion avec l'extérieur et deuxièmement, toutes les machines sont sous linux et font partie d'un seul domaine NIS. L'une ou l'autre de ces conditions pouvant être modifiée, nous avons préféré installer les deux services. Dernière précision, sur puydedome, dans le fichier /etc/nsswitch.conf qui a pour fonction de dire pour chaque classe d'information de quelle manière celle-ci est disponible et dans quel ordre, nous voyons à la ligne hosts (correspondant justement à l'équivalence adresse-nom-alias) :
ce qui signifie que la machine, lorsqu'elle se pose un problème de résolution de nom, doit d'abord voir dans son fichier /etc/hosts, puis si le problème n'est pas résolu, dans la table hosts du NIS (taper la commande ``ypcat hosts'' pour voir ce que la table contient), puis si le problème n'est toujours pas résolu, dans la base de données du serveur DNS (taper ``nslookup'' puis les noms ou les adresses à l'invite pour voir si elles sont résolues). La centralisation des comptes utilisateurs (le NIS utilisateurs et groupes, le NFS home)Tout utilisateur d'un poste sous Linux doit être déclaré à l'avance au système. Il est identifié par son nom (son loginname), son groupe d'utilisateur, et son mot de passe. Dans le cas d'un réseau de postes, il est évidemment souhaitable de centraliser les informations concernant les comptes des utilisateurs. Cela permet de créer ou d'éliminer un compte en une seule fois (plutot que de le faire sur chaque poste), et du point de vue de l'utilisateur, de disposer de son compte (par NIS) et de ses fichiers (NFS home) depuis n'importe quel poste. C'est le NIS (Network Information Service) qui s'occupe de la gestion de l'information. On peut voir par exemple l'ensemble des groupes d'utilisateurs en tapant la commande ``ypcat group'', et l'ensemble des utilisateurs en tapant ``ypcat passwd''. Lorsqu'un utilisateur ouvre une session de travail sur un poste, celui-ci vérifie la validité du mot de passe en consultant d'abord son propre fichier /etc/passwd, puis le fichier /etc/passwd du serveur NIS (ici erebus). C'est en fait ce deuxième fichier qui contient les mots de passe (codés, bien sûr) de tous les utilisateurs. L'appartenance à un groupe d'utilisateurs est obligatoire. Elle permet de moduler les droits des utilisateurs en ce qui concerne la lecture et l'écriture de tout fichier. Par exemple, nous avons actuellement dans notre salle trois groupes : un groupe pour les étudiants de DEUG, un groupe pour les étudiants de Licence, et un groupe pour les enseignants. Grace à la gestion des droits, il est possible à chaque utilisateur de définir de manière différente les droits de lecture, d'écriture et d'exécution de chacun de ses fichiers et ceci pour 3 classes d'utilisateurs : lui-même, les utilisateurs de son groupe, et les autres utilisateurs. Prenons un exemple, lorsque l'on tape la commande qui liste les fichiers du répertoire courant ``ls -l'', on voit apparaitre à gauche les information sur les droits relatifs aux fichiers listés, voici par exemple l'information donnée pour un fichier : -rwxr-xr-- 1 utilisateur groupe taille mois jour heure nom. Les dix caractères du début doivent être lus par séquences, 1+3+3+3, le premier caractère est utilisé pour les fichiers spéciaux (répertoires, liens, devices), les trois séquences de 3 caractères qui suivent, définissent les droits en lecture (``r'' pour readable) en écriture (``w'' pour writable) et en exécution (``x'' pour executable) pour les trois classes d'utilisateurs. Dans notre exemple, le fichier est en rwx pour l'utilisateur lui-même (première séquence de trois caractères), c'est à dire avec les droits en lecture, écriture et exécution. Il est en r-x pour les utilisateurs appartenant au même groupe que lui (deuxième séquence), c'est à dire avec des droits en lecture et exécution, mais pas de droit d'écriture. Il est en r-- pour les autres utilisateurs (hors de son groupe, troisième séquence), c'est à dire avec des droits en lecture seulement, l'exécution et l'écriture étant interdites. En utilisant ce système, il est ainsi très simple pour les enseignants d'interdire aux étudiants la lecture de leurs fichiers. Le NIS gère donc, d'une manière centralisée, l'identité de tout utilisateur sur tous les postes du réseau ainsi que ``l'adresse'' du répertoire où sont placée ses fichiers, mais il ne gère pas le système de fichiers lui-même ainsi que son accès par l'utilisateur. Dans notre cas, les fichiers des utilisateurs sont localisés sur un des disques durs du serveur erebus. Le partage de ces fichiers, c'est à dire leur accès de manière transparente depuis tous les postes, et géré par le NFS home (/home est le répertoire qui contient tous les fichiers de tous les utilisateurs). Des précisions sur la configuration des systèmes de fichiers (en particulier de la partition /home montée via NFS sur les postes clients) sont donnés en annexe C. Cette double centralisation, information et système de fichiers, permet, de faciliter la maintenance des comptes des utilisateurs, de rendre les postes complètement interchangeables pour l'utilisateur, et de ne pas utiliser l'espace disque très limité des postes clients. Notes
|
|
Sauf mention explicite contraire le contenu de ce site est Copyright AFUL sous licence Creative Commons Paternité - Partage des Conditions Initiales à l'Identique 
|
