TP7: NFS et NIS

Le but de ce TP sera dans un premier temps de tester le fonctionnement du système NFS (Network File System) sur vos machines virtuelles. Vous simulerez un réseau sur machines virtuelles en lançant deux machines ayant des adresses IP différentes, et vous utiliserez NFS pour pouvoir accéder aux fichiers de l’une des machines virtuelles à partir de l’autre. Dans un second temps vous testerez NIS (Network Information Service, également appelé Yellow Pages), qui permet (tout comme LDAP) de déployer une base de données distribuée sur un réseau, et est surtout utilisé pour partager des informations contenues dans des fichiers de configuration, comme /etc/passwd. Nous l’utiliserons conjointement avec NFS, afin de réaliser un système avec authentification centralisée et serveur de home directories.

Exercice 1 Préparez deux machines virtuelles. Vérifiez qu’elles sont bien connectées au réseau, donnez-leur les hostnames client et serveur. Installez le package nfs-common sur les deux machines, et nfs-kernel-server sur le serveur. Ce fichier, situé sur le serveur NFS, contrôle quels sont les répertoires à rendre accessibles au public au travers de NFS, à qui on les rend accessibles, et avec quelles permissions. Sa syntaxe est la suivante : chaque ligne contient un répertoire à exporter, suivi d’une liste de clients (séparés par des blancs) pouvant monter ce répertoire. Chaque client peut être suivi – ro : lecture seule.– rw : lecture/écriture.– rw=liste : lecture/écriture à une liste d’hôtes, lecture seule aux autres.– root_squash : associe l’UID 0 et le GID 0 (i.e. le compte root) distants aux valeurs spé- cifiées par anonuid et anongid. Explication : le comportement normal de NFS consiste à utiliser l’uid et le gid de la requète client pour gérer les droits d’accès au fichier sur le serveur. Toutefois, il n’est en général pas désirable que l’utilisateur root de la machine cliente soit aussi traitée en tant que root sur la machine serveur. C’est pour cette raison que le uid 0 est en général mappé vers le uid anonyme anonuid. Ce mécanisme est appelé le root squashing et est le comportement par défaut. Voici un exemple de fichier exports :/ master(rw) trusty(rw,no_root_squash)/projects proj*.local.domain(rw)/home/joe 192.168.139.0/24(rw,all_squash,anonuid=150,anongid=100) /pub (ro,all_squash) Après toute modification au fichier exports, il convient d’exécuter la commande /usr/sbin/exportfs sur le serveur afin de réaliser l’exportation à proprement parler (voir man pour plus de détails). Appelée avec l’option -a, cette commande réalise l’export de tous les répertoires listés dans /etc/exports.

L’accés aux données distantes par le client se fait en deux temps : montage (grâce à mount) du file system distant dans l’arborescence du client, puis accès aux fichiers. Le mount suit la syntaxe mount hostname:directory directory_d_accrochage.Pour démonter un file system umount directory_d_accrochage Lors du montage d’un file system distant, plusieurs options peuvent être spécifiées (à l’aide de l’option -o de mount). Le tableau ci-dessous en apporte un récapitualtif (voir man mount et man nfs) :de temps, continuer à essayer indéfiniment. C’est l’option par défaut. Ceci est utile par exemple en cas de crash du serveur : les clients seront tous simplements bloqués jusqu’à ce que le serveur soit à nouveau opérationnel puis pourront à nouveau accéder aux fichiers distants de manière transparente, sans avoir dû gérer d’erreur. Les processus ainsi bloqués sont non-interruptibles, sauf si l’option intr (voir ci-dessous) est spécifiée.Exercice 3 Sur le client, tentez de monter le répertoire home partagé par le serveur dans /mnt/home_du_serveur. Faites en sorte que les droits d’accès et les propriétaires de fichiers soient préservés (nécessite peut-être de modifier le serveur). Faites des tests : création de fichiers par les utilisateurs notroot et root, changement des droits avec chmod. Regardez les résultats tant sur le client que sur le serveur.

NIS utilise un modèle client-serveur. Un serveur NIS est une machine contenant les bases de données distribuées construites à partir des fichiers de configuration. Il y a toujours exacte- ment un serveur maître, et éventuellement plusieurs serveurs additionnels, appelés esclaves, qui contiennent des duplications des bases de données du serveur maître.Si par exemple le fichier /etc/passwd est géré par NIS, les consultations de ce fichier dans les clients ne se feront pas sur le fichier local lui-même, mais plutôt par une requête envoyée sur le réseau vers le serveur NIS. Ainsi, toutes les machines du réseau pourront travailler avec le même fichier passwd présent une seule fois sur le serveur. Bien sûr, le serveur devra reconstruire sa base de données distribuée à chaque modification du fichier passwd (et propager ce changement vers les éventuels serveurs esclaves). Dans le cadre de ce TP, nous nous limiterons à un seul serveur NIS.