Tester le fonctionnement du système NFS sur vos machines virtuelles

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 ﬁchiers 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 ﬁchiers de conﬁguration, comme /etc/passwd. Nous l’utiliserons conjointement avec NFS, aﬁn de réaliser un système avec authentiﬁcation centralisée et serveur de home directories.

Exercice 1 Préparez deux machines virtuelles. Vériﬁez 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 ﬁchier, 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é- ciﬁé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 ﬁchier 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 ﬁchier 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 modiﬁcation au ﬁchier exports, il convient d’exécuter la commande /usr/sbin/exportfs sur le serveur aﬁn 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 ﬁle system distant dans l’arborescence du client, puis accès aux ﬁchiers. Le mount suit la syntaxe mount hostname:directory directory_d_accrochage.Pour démonter un ﬁle system umount directory_d_accrochage Lors du montage d’un ﬁle system distant, plusieurs options peuvent être spéciﬁé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éﬁniment. 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 ﬁchiers 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éciﬁé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 ﬁchiers soient préservés (nécessite peut-être de modiﬁer le serveur). Faites des tests : création de ﬁchiers 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 ﬁchiers de conﬁguration. 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 ﬁchier /etc/passwd est géré par NIS, les consultations de ce ﬁchier dans les clients ne se feront pas sur le ﬁchier 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 ﬁchier passwd présent une seule fois sur le serveur. Bien sûr, le serveur devra reconstruire sa base de données distribuée à chaque modiﬁcation du ﬁchier passwd (et propager ce changement vers les éventuels serveurs esclaves). Dans le cadre de ce TP, nous nous limiterons à un seul serveur NIS.