Le blog firefox!

Network File System ou NFS

2007-01-19T14:05:00.000-08:00

Network File System (NFS)

Introduction

Le système de fichiers réseau, ou NFS (Network File System), créé à l’origine par Sun Microsystems, permet aux hôtes de monter des partitions sur un système distant et de les utiliser exactement comme des systèmes de fichier locaux. Ceci permet à l'administrateur système de stocker des ressources dans un emplacement central du réseau, fournissant ainsi aux utilisateurs légitimes un accès permanent. NFS est un système client/serveur. Le client utilise les répertoires distants comme s’ils faisaient partie de son système de fichiers local, car ils sont mis à disposition par le serveur. La liaison d’un répertoire distant au système de fichiers local se nomme montage de répertoire, tandis que le partage d’un répertoire se nomme exportation d’un répertoire.

D’autres systèmes présentent les mêmes fonctionnalités que NFS. Samba (http://www.samba.org) permet le partage de fichier avec des clients Windows sans gérer les permissions sur les fichiers ; Andrew File System, à l’origine développé par IBM (http://www.openafs.org) et qui est devenu open-source, permet un mécanisme de partage de fichiers avec des fonctionnalités additionnelles pour la sécurité et la performance. Coda File System (http://www.coda.cs.cmu.edu/) combine le partage de fichiers avec un aspect particulier sur les clients déconnectés.
L’avantage de NFS aujourd’hui est qu’il est mature, standard, bien compris et supporté à travers plusieurs plateformes.

A. Versions de NFS et leurs différences

Trois versions de NFS existent et deux sont actuellement en vigueur. La version 2 de NFS (NFSv2), utilisée depuis plusieurs années, est largement supportée par divers systèmes d'exploitation. La version 3 de NFS (NFSv3), apporte d'autres fonctions, y compris un traitement de fichiers de taille variable et un meilleur rapportage d'erreurs. Et la version 4 (NFSv4) qui au moment de l’écriture de ce document est développement actif sous le noyau 2.6.x. Son implémentation est toujours très fluide et changeante, et il n’est pas recommandé pour une utilisation en production(http://www.nfsv4.org/). Cette partie traitera donc des différences entre les versions 2 et 3 de NFS.
 Les clients utilisant la version 2 n’ont accès qu’à des fichiers de 2Go de données au maximum alors que ceux utilisant la version 3 supportent des fichiers de plus grande capacité. Néanmoins la taille maximale dépend du système de fichiers local du serveur NFS
 NFS version 2 limite la taille maximale d’une opération de lecture écriture à 8ko. NFS version 3 sur UDP supporte en théorie plus de 56ko (la taille maximale d’un datagramme UDP est de 64ko, donc avec le NFS, RPC, et l’en-tête UDP, le maximum pour une lecture écriture sur UDP est d’environ 60ko). Pour la version 3 sur TCP, la limite dépend de l’implémentation. La majeure partie des implémentations ne supporte pas plus de 32ko.
 NFS version 3 introduit le concept de Weak Cache Consistency ou faible consistance du cache. Ce dernier permet aux clients de la version 3 de détecter plus rapidement les modifications apportées sur les fichiers par d’autres clients. Ceci se fait par le retour d’informations d’attributs spéciaux dans une réponse du serveur pour une opération de lecture écriture. Le client peut alors utiliser l’information pour décider si la donnée et l’attribut sont corrects.
 Les clients de la version 2 interprètent les informations sur un fichier eux-mêmes pour déterminer si un utilisateur a accès sur ce fichier. Les clients de la version 3 peuvent utiliser une nouvelle opération (appelée ACCESS) pour demander au serveur de décider des droits d’accès. Ceci permet à un client n’utilisant pas les listes de contrôle d’accès (ACL) d’interagir correctement avec un serveur le supportant.
 NFS version 2 requiert qu’un serveur sauvegarde toutes ces données pour une opération d’écriture sur disque avant de répondre au client que l’opération d’écriture est terminée. Ceci peut s’avérer coûteux parce que fractionnant les requêtes d’écriture en petits paquets (8ko ou moins) qui doivent chacun être écrits sur disque avant que le prochain paquet ne puisse à son tour être écrit. Les disques fonctionnent mieux s’ils peuvent écrire une grande quantité de données à la fois.
 NFS version 3 introduit le concept d’écriture asynchrone sécurisé. Un client de la version 3 peut spécifier que le serveur est autorisé à répondre avant qu’il est sauvegardé la donnée demandée sur disque, permettant au serveur de gagner sur de petites opérations d’écriture au profit d’une écriture complète sur disque de toute l’information. Un client de la version 3 peut aussi spécifier que la donnée doit être écrite sur disque avant que le serveur réponde, tout comme une écriture avec la version 2. Le client spécifie le type de lecture en réglant le champ stable_how dans les arguments de chaque opération d’écriture à UNSTABLE pour demander une écriture asynchrone sécurisée, et FILE_SYNC pour une écriture avec NFS version 2.

Le serveur indique si la donnée demandée est continuellement stockée en réglant le champ correspondant en réponse à chaque opération d’écriture NFS. Un serveur peut répondre à une demande d’écriture UNSTABLE par une réponse UNSTABLE ou un FILE_SYNC, ceci dépend ou non que la donnée demandée réside sur un support de stockage permanent. Un server NFS devant répondre à une requête FILE_SYNC uniquement par un FILE_SYNC.

Les clients s’assurent que les données écrites en utilisant l’écriture asynchrone sécurisée l’ont été sur un support de stockage permanent en utilisant une nouvelle opération disponible avec la version 3 appelée COMMIT. Les serveurs n’envoient pas de réponse à un COMMIT tant que toutes les données demandées par une requête ne soient écrites sur un support permanent. Les clients de la version 3 doivent protéger les données en mémoire tampons qui sont écrites par une écriture asynchrone sécurisée mais pas encore « commité ». Si le serveur redémarre avant que le client n’est envoyé le COMMIT approprié, le serveur peut répondre à l’éventuel demande de COMMIT de manière à forcer le client de renvoyer l’original opération d’écriture. Les clients de la version 3 utilisent le COMMIT en envoyant des écritures asynchrones sécurisées au serveur durant un appel système de type close ou fsync.

NFS est un service RPC (Remote Procedure Call: Appel de procédures distantes). Les RPC sont une API développée par SUN et mis depuis dans le domaine public. Elles permettent l'écriture d'applications du type client/serveur qui consiste à demander l'exécution d'une procédure distante avec retour du résultat. Les services RPC sont gérés via un annuaire nommé le portmapper. Un programme client qui envoie une requête NFS s'adresse au portmapper qui est un démon accessible sur le port 111 en TCP ou UDP (voir le fichier /etc/services pour une description des ports standards). Lorsque ce client s'adresse au portmapper, il lui demande où se trouve le serveur NFS et portmapper lui indique alors le port correspondant à ce service (port 2049 par défaut pour NFS).

B. Fonctionnement du Remote Procedure Call (RPC)
Le modèle d’appel de procédure à distance (RPC) est similaire à celui de l’appel de procédure local (LPC). Dans le cas du local, l’appelant places des arguments à une procédure dans un lieu bien placé (comme les registres de résultats). Il transferts ensuite le contrôle à la procédure, et éventuellement en reçoit un en retour. De là, les résultats de la procédure sont extraient depuis le lieu bien placé, et celui qui appelle (le client) continue l’exécution.
L’appel de procédure à distance est similaire, dans ce fil de contrôle deux traitements tourne logiquement: l’un est le traitement du client et l’autre celui du serveur.
Le traitement du client envoie un message d’appel au traitement serveur et attend un message de réponse. Le message d’appel contient des paramètres de procédure, avec d’autres contenus. Le message de réponse contient les résultats de procédure, avec d’autres contenus. Une fois que le message de réponse est reçu, les résultats de la procédure sont extraient, l’exécution du client est recommencé.
Du côté du serveur, un traitement est dormant attendant l’arrivé d’un message d’appel. Quand un arrive, le traitement serveur extrait les paramètres de procédure, calcule les résultats, envoie une réponse, et puis attend le prochain message d’appel.

Dans ce modèle, seulement un des deux traitements est actif à n’importe quel temps donné. Ce modèle est seulement un exemple. Le protocole RPC ne fait aucune restriction sur le modèle de simultanéité implémenté, et d’autres sont possibles. Par exemple, une implémentation peut choisir d’avoir des appels RPC asynchrones, comme ça le client peut faire du travail utile pendant qu’il attend la réponse du serveur. Une autre possibilité est que le serveur crée une tâche pour traiter une requête entrante, comme ça le serveur est libre de recevoir d’autres requêtes.
Les différents types de RPC
Nous retrouvons trois types de RPC: le RPC sans réponse, avec réponse et avec réponses multiples.
1. Le RPC sans réponse
Le RPC sans réponse demande un échange synchrone. Le programme appelant reste en attente de la réponse du serveur. La conversation est très simple, le message d’appel contient tous les éléments nécessaires au serveur: nom de la procédure, paramètres associés à cette procédure et données d’identification de l’appelant. Cette identification permet de vérifier si le niveau d’autorisation demandé pour l’exécution de cette procédure est respecté par l’utilisateur. Une fois que le traitement est terminé, le serveur transmet la réponse attendue par le programme client en un seul flot.
Le principal avantage des RPC est la simplicité (apparente) de mise en oeuvre. Les inconvénients sont :
• Caractère exclusivement synchrone de l’échange
• Fiabilité médiocre (repose sur une exécution et une seule; si elle échoue, il n’y a pas de reprise)
• Pas de synchronisation entre le client et le serveur au cours de l’échange
• Pas de gestion du flux de retour (la réponse arrive en une fois quel qu’en soit le volume)
Dans ce type de RPC il est très difficile de savoir si une panne se produit avant que le client ait reçu son exécution, le client ne sait pas si le serveur a réalisé la procédure : il sait seulement si la procédure a été exécutée zéro ou une fois.
2 Le RPC avec réponse
Nous retrouvons un deuxième type de RPC pour palier a ces problèmes, les appels avec réponse. Il fait un compte rendu d’exécution sur deux cas, le cas de réussite et celui d’échec de l’exécution de la procédure.
3 Le RPC avec réponses multiples
Le troisième type de RPC est celui avec réponses multiples (appelé Broadcast RPC). Il entraîne plusieurs comptes rendus pendant l’échange. Par exemple, la procédure peut envoyer des résultats à des intervalles réguliers. Ils sont idéals pour des calculs exécutés à intervalle fixe.

Transports et sémantiques
Le protocole RPC est indépendant des protocoles de transport. Le protocole s’occupe seulement des spécifications et des interprétations des messages.
Le RPC n’essaye pas d’implémenter n’importe quel genre de fiabilité et l’application doit être averti du type de protocole de transport sous RPC. S’il sait qu’il tourne sur un transport fiable comme le TCP/IP, alors la plupart du travail est déjà fait pour lui. S’il tourne sur un transport non fiable comme le UDP/IP, il doit implémenter sa propre politique de retransmission et d’arrêt car la couche de RPC ne fournit pas ce service.

Vu qu’il est indépendant du transport, le protocole RPC n’attache pas de sémantiques spécifiques aux procédures à distance ou leur exécution. la sémantique peut être impliquée par (mais devrait être explicitement indiquée par) le protocole fondamental de transport.
Par exemple, considérez le RPC fonctionnant sur un transport incertain tel qu'UDP/IP. Si une application retransmet des messages de RPC après des arrêts courts, la seule chose elle peut impliquer si elle ne reçoit aucune réponse est que la procédure a été exécutée zéro fois ou plus. S'il reçoit une réponse, alors il peut impliquer que la procédure a été exécutée au moins une fois.
Un serveur peut souhaiter se rappeler des requêtes précédemment accordées d'un client et ne le lui raccorde pas afin d'assurer des sémantiques d’exécuter-au-plus-une-fois d’un certain degré. Un serveur peut faire ceci en prenant l'identification de transaction qui est empaquetée avec chaque requête de RPC. Une application du client peut aussi choisir de réutiliser son identification précédente de transaction en retransmettant une requête.

S’il utilise un transport fiable tel que le TCP/IP, l'application rajoute dans un message de réponse que la procédure a été exécutée exactement une fois, mais s'il ne reçoit aucun message de réponse, il ne peut pas supposer que la procédure à distance n'a pas été exécuté. Si un protocole connecté comme le TCP est employé, une application a besoin toujours d'arrêts et de reconnexion pour manipuler des crashes de serveur. Il existe d'autres possibilités pour des transports.
Authentification
Le protocole RPC fournit les champs nécessaires pour un client pour s'identifier à un service et vice-versa. Des mécanismes de sécurité et de contrôle d'accès peuvent être établis sur l'authentification de message. Plusieurs différents protocoles d'authentification peuvent être soutenus. Un champ dans l'en-tête de RPC indique quel protocole est employé.
Il existe plusieurs types de protocoles d’authentification dont les plus connus sont ceux fournis par l’ONC/RPC, il s’agit des authentifications suivantes:
• Null authentification: Souvent les appels sont de façon que l’appelant ne sait qui il est ou le serveur ne s’en préoccupe pas.
• UNIX Authentification: identifiant le client comme client utilisant le système UNIX.
• DES Authentification: servant a régler le problème de naming (identification client) et de vérification de qualification du client.
Il existe d’autres types d’authentification et il est aussi possible d’en créer.
Reconnaissance des programmes et des procédures et notion de port mapper
Le message d'appel de RPC a trois champs non signés : numéro du programme distant, numéro de version du programme distant, et numéro de la procédure distante. Les trois champs identifient uniquement la procédure à appeler. Des numéros de programme sont administrés par une autorité centrale (comme SUN). Une fois qu’il y a un numéro de programme, il peut mettre en application son programme distant (la première exécution aurait très probablement le numéro de version de 1). Vu que la plupart des nouveaux protocoles se transforment en de meilleurs et plus stables (évolution des programmes, nouvelles fonctions dans les programmes, etc.), un champ de version du message d'appel identifie la version du protocole que le visiteur emploie. Les numéros de version définissent les vieux et nouveaux protocoles par le même processus de serveur possible.
Le numéro de la procédure identifie la procédure à appeler. Ces numéros sont documentés dans les spécifications du protocole du programme spécifique. Par exemple, des spécifications du protocole du service d'archivage peuvent déclarer que la procédure numéro 5 est "lire" et la procédure numéro 12 est "écrire".
Comme les protocoles à distance de programme peuvent changer au-dessus de plusieurs versions, le protocole réel de message RPC pourrait également changer, le message d'appel a également dans lui le numéro de version du RPC. Pour information les numéros de programme sont donnés en groupe d’hexadécimal 2000000.

Le port mapper maintient une base de données renseignant les associations. Lorsqu’un client désire contacter un programme RPC sur une machine, il s’adresse au préalable au port mapper de la machine afin de connaître le port de communication associé. Le port mapper s’exécute toujours sur le port de communication 111.

Le RPC est un protocole très important au sein de l’informatique, il est utilisé pour tout appel de procédure sur le réseau que cela soit internet ou intranet, toute demande fait sur le net est un appel de procédure (téléchargement, passage d'une page à l'autre) ainsi que les interactions entre programme telles que les programmes de messagerie (Live Messenger par exemple).
Son développement dans l’avenir sera d’une grande utilité ainsi que l’étude par ceux qui souhaitent le connaître.

C. Installation NFS

I. Sur le serveur NFS

1. Compiler sans outil de gestion des paquetages

Télécharger le package nfs utils sur: http://sourceforge.net/projects/nfs
Pour compiler sans utiliser un système de gestion des paquetages, il suffit d’extraire le contenu téléchargé avec :

tar –xzvf nfs-utils-1.0.1.tar.gz

Se rendre dans le dossier nfs-utils-1.0.1 et lancer les commandes:

# ./configure
# make

Pour installer les binaires et la documentation, exécuter la commande:

# make install

Vous aurez à installer les deux scripts de service NFS. Sous RedHat ils se trouvent dans /etc/redhat.

2. Compiler avec RPM

Sous RedHat vous pouvez utiliser

# rpm -ta nfs-utils-1.0.1.tar.gz

Pour construire les sources et binaires RPMs.

II. Paramétrer un serveur NFS

Le paramétrage du serveur NFS se fera en deux étapes : paramétrage des fichiers de configuration et démarrage des services NFS.

1) Paramétrage des fichiers de configuration
On note trois principaux fichiers de configuration qu’il vous faudra éditer pour installer le serveur NFS : /etc/exports, /etc/hosts.allow, /etc/hosts.deny. A proprement parler, vous n’avez besoin d’éditer que le fichier /etc/exports pour que NFS fonctionne, mais vous serez confrontez à un paramétrage non sécurisé.

 /etc/exports
Le fichier /etc/exports permet non seulement de contrôler quels systèmes de fichiers sont exportés vers des hôtes distants mais permet également de spécifier des options. Les lignes vierges ne sont pas prises en compte, des commentaires peuvent être insérés grâce au symbole dièse (#) et un retour à la ligne peut être introduit grâce à une barre oblique inverse (\). Chaque fichier exporté doit avoir sa ligne propre. Les hôtes autorisés placés après un système de fichiers exporté doivent être séparés par des espaces. Les options pour chacun des hôtes doivent être placées entre parenthèses directement après l'identificateur d'hôte, sans espace entre l'hôte et la première parenthèse.
Dans sa forme la plus simple, /etc/exports requiert seulement le répertoire exporté et l'hôte autorisé à l'exploiter:
/test-nfs/fichier-serveur ssn-xp.gbsystems.net
/unautre/dossier/exporte 192.168.100.50
Après la réexportation de /etc/exports grâce à la commande /sbin/service nfs restart, l'hôte ssn-xp.gbsystems.net pourra monter /test-nfs/fichier-serveur et 192.168.100.50 peut monter /unautre/dossier/exporte. Parce qu'aucune option n'est spécifiée dans cet exemple, plusieurs préférences par défaut de NFS entrent en vigueur:
• ro — Lecture-seule. Les hôtes qui montent ce système de fichiers ne pourront pas le modifier. Pour autoriser les hôtes à apporter des modifications au système de fichiers, l'option rw (Lecture-seule) doit être spécifiée.
• async — Permet au serveur d'écrire des données sur le disque lorsqu'il le juge opportun. Bien que cela ne soit pas important si l'hôte reçoit des données en lecture-seule, s'il apporte des modifications à un système de fichiers en lecture-écriture et que le serveur plante, des données peuvent être perdues. En spécifiant l'option sync, toutes les opérations d'écriture doivent être confiées au disque avant que la requête d'écriture par le client ne soit effectivement achevée. Cela peut diminuer les performances.
• wdelay — Cette option entraîne un retard des opération décriture sur le disque par NFS, s'il suspecte qu'une autre requête d'écriture est imminente. Ce faisant, les performances peuvent être améliorées grâce à une réduction du nombre d'accès au disque par des commandes d'écriture séparées, réduisant ainsi le temps d'écriture. L'option no_wdelay quant à elle, désactive cette fonction mais n'est disponible que lors de l'utilisation de l'option sync.
• root_squash — Retire au super-utilisateur en connexion distante tous les privilèges de son status en lui assignant l'ID d'utilisateur 'personne'. Ce faisant, le pouvoir du super-utilisateur distant est réduit au niveau d'utilisateur le plus bas, lui empêchant d'agir comme comme s'il était le super-utilisateur sur le système local. Sinon, l'option no_root_squash annule cette fonction de réduction des privilèges du super-utilisateur. Afin de limiter le champs d'action de chaque utilisateur distant, y compris le super-utilisateur, utilisez l'option all_squash. Pour spécifier l'utilisateur et ID de groupe à utiliser avec des utilisateurs distants d'un hôte particulier, utilisez respectivement les options anonuid et anongid. Dans ce cas, vous pouvez créer un compte d'utilisateur spécial pour que les utilisateurs NFS distants partagent et spécifient, (anonuid=,anongid=), où correspond au numéro de l'ID d'utilisateur et représente le numéro de l'ID de groupe.
Pour outrepasser ces réglages par défaut, vous devez spécifier une option qui les remplace. Par exemple, si vous ne spécifiez pas rw, cette exportation sera partagée seulement en lecture(ro). Ce remplacement des réglages par défaut doit être explicitement spécifié pour chaque système de fichier exporté. De plus, d'autres options sont disponibles là où il n'existe pas de valeur par défaut. Elles permettent d'annuler la vérification de sous-arborescence, l'accès à des ports non-sûrs et les verrouillages non-sûrs de fichiers (nécessaires pour certaines implémentations anciennes de client NFS). Consultez la page de manuel relative à exports pour plus de détails sur ces options moins souvent utilisées.
Lors de la précision des noms d'hôtes, utilisez les méthodes suivantes:
• hôte simple (single host) — Où un hôte particulier est spécifié avec un nom de domaine, d'hôte ou une adresse IP pleinement qualifiés.
• caractères génériques (wildcards) — Où les caractères * ou ? sont utilisés pour prendre en compte un groupement de noms de domaines ou adresses IP pleinement qualifiés ou ceux qui correspondent à une particulière chaîne de lettres.
Soyez toutefois prudents si vous utilisez des caractères génériques pour des noms de domaines pleinement qualifiés, car ils sont souvent plus exacts que ce que vous escomptiez. Par exemple, si vous utilisez *.gbsystems.net comme caractère générique, systeme.gbsystems.net sera autorisé à accéder au système de fichiers exporté, mais sammy.systeme.gbsystems.net lui, ne le sera pas. Pour retenir les deux noms de domaine, ainsi que sam.developpement.gbsystems.net vous devrez utiliser *. gbsystems.net *.*. gbsystems.net
• réseaux IP (IP networks) — Autorise la mise en correspondance d'hôtes selon leur adresse IP dans un réseau plus grand. Par exemple, 192.168.100.0/28 autorisera les 16 premières adresses IP, de 192.168.100.0 à 192.168.100.15, à accéder au système de fichiers exporté, mais pas 192.168.100.16 ou une adresse IP supérieure.
• groupes réseau (netgroups) — Attribue un nom de groupe à un groupe réseau NIS, écrit ainsi: @. Cette option attribue au serveur NIS la charge du contrôle d'accès pour ce système de fichier exporté, où les utilisateurs peuvent être ajoutés et supprimés dans un groupe NIS sans affecter /etc/exports.
Avertissement !!!
Le format du fichier /etc/exports est très précis, particulièrement en ce qui concerne l'utilisation des caractères d'espace. Rappelez-vous bien de toujours séparer les systèmes de fichiers exportés des hôtes, et les hôtes entre eux à l'aide d'un caractère d'espace. Toutefois, aucun autre caractère d'espace ne doit se trouver dans le fichier à moins qu'ils ne soient utilisés pour des lignes de commentaire.
Par exemple, les deux lignes suivantes n'ont pas la même signification:
/home sammy.gbsystems.net(rw)
/home sammy.gbsystems.net (rw)

La première ligne autorise seulement les utilisateurs de sammy.gbsystems.net à avoir un accès en lecture-écriture au répertoire /home. La deuxième ligne elle, autorise les utilisateurs de sammy.gbsystems.net à monter le répertoire en lecture-seule (valeur par défaut), mais tout autre utilisateur peut le monter en lecture-écriture.
 /etc/hosts.allow et /etc/hosts.deny
Ces deux fichiers spécifiques spécifient quels ordinateurs du réseau peuvent utiliser des services du serveur. Chaque ligne de ces fichiers contient une entrée signalant le service et une liste de machines. Quand le serveur reçoit une requête d’une machine, il l’exécute de la sorte :
1. vérifie en premier hosts.allow pour voir si la machine respecte les règles écrites. Si c’est le cas, la machine est autorisée
2. Si la machine ne respecte pas une entrée de hosts.allow, le serveur vérifie dans hosts.deny pour voir si le client respecte ce qui est écrit. Si c’est le cas, la machine se voit refusé l’accès.
3. Si le client ne correspond pas aux régles écrites dans chaque fichier, alors l’accès lui est autorisé.
De plus aux contrôle d’accès des services couverts par inetd (tels que telnet, FTP), ce fichier peut aussi contrôler l’accès à NFS en restreignant les connexions aux démons qui fournissent les services NFS. Les restrictions se font par service.
Le premier démon dont on doit restreindre l’accès est portmapper. Ce démon permet essentiellement aux clients de trouver les services NFS du système. Restreindre l’accès au portmapper est le meilleur moyen de défense contre un pirate du système via NFS parcequ’aucun client non autorisé ne pourra savoir où trouver les démons NFS. Néanmoins il y a deux choses à savoir. Premièrement, restreindre portmapper ne suffit pas si l’intrus sait d’une raison où d’un autre comment trouver les démons. Deuxièmement, si vous utilisez NIS, restreindre portmapper va aussi restreindre les requêtes de NIS.
En général c’est une bonne idée qu’avec NFS (de même que la plupart des services internet) d’explicitement refuser l’accès aux adresses IP que vous ne voulez pas autoriser.
La première étape pour le faire est d’ajouter l’entrée suivante dans /etc/hosts.deny :
portmap :ALL
On fait pareil pour chaque démon NFS (qui seront détaillés plus tard) dans le même fichier :
lockd:ALL
mountd:ALL
rquotad:ALL
statd:ALL

Nous allons maintenant ajouter une entrée dans hosts.allow pour donner aux hôtes voulus l’accès.(Si on laisse les lignes ci-dessus dans hosts.deny alors personne ne pourra accéder à NFS.) Les entrées dans hosts.allow suivent le format :
service: host [ou réseau/masque] , host [ ou réseau/masque]
Ici host représente l’adresse IP d’un potentiel client, il peut être possible avec certaines versions d’utiliser le nom DNS de l’hôte, mais ceci est fortement déconseillé.
Supposons que vous ayez la configuration ci-dessus et que vous veuillez autoriser l’accès à gbsrhl001 et gbsrhl002 et que les adresses IP de ces deux machines soient respectivement 192.168.100.20 et 192.168.100.21. Vous pouvez ajouter ces entrées suivantes dans /etc/hosts.allow :
portmap: 192.168.100.20 , 192.168.100.21

Pour de récentes versions de nfs-utils, vous pouvez ajouter les entrées suivantes :

lockd: 192.168.100.20 , 192.168.100.21
rquotad: 192.168.100.20 , 192.168.100.21
mountd: 192.168.100.20 , 192.168.100.21
statd: 192.168.100.20 , 192.168.100.21

Si votre intention est d’éxécuter NFS sur un grand nombre de machines d’un réseau local, /etc/hosts.allow autorise aussi des entrées du type réseau/masque tout comme pour /etc/exports.

2) Démarrer les services

Le serveur NFS doit maintenant être configuré et vous pourrez le faire tourner. Mais avant de faire démarrer il faut que le protocole TCP/IP fonctionne correctement sur votre machine. Si vous utilisez telnet, FTP et autres, TCP fonctionne correctement.
Ceci dit, la grande partie des nouvelles distributions linux intègre NFS dans leur noyau, sans quoi NFS ne fonctionnera pas.

 Démarrer le portmapper

NFS dépend du démon portmapper, aussi appelé portmap ou rpc.portmap. Il doit être démarrer en premier. Il se trouve dans /sbin ou quelquefois dans /usr/sbin. Les distributions récentes démarre ce démon dans les scripts de démarrage, mais il est préférable de vérifier son état avant de commencer à travailler avec NFS, il suffit de taper :
ps aux | grep portmap

 Les Démons

Le serveur NFS fonctionne avec cinq démons : rpc.nfsd qui effectue la grande partie du travail ; rpc.lockd et rpc.statd qui s’occupent du verrouillage des fichiers ; rpc.mountd pour les requêtes de montage, et rpc.rquotad pour le quota des fichiers utilisateurs sur les volumes exportés. A partir du noyau 2.2.18, lockd est appelé par nfsd sur sa demande, donc ne vous souciez pas de le démarrer par vous-mêmes. statd aura besoin d’être démarrer séparément. Les distributions récentes ont des scripts de démarrage pour ces démons.
Ces démons sont tous compris dans le paquetage nfs-utils, et peuvent aussi se trouver dans les dossiers /sbin et /usr/sbin.

S’ils ne sont pas inclut dans les scripts de démarrage de votre distribution, vous devrez les ajouter suivant cette ordre :
rpc.portmap
rpc.mountd, rpc.nfsd
rpc.statd, rpc.lockd (si nécessaire), et
rpc.rquotad

 Vérifier que NFS fonctionne
Puisque portmap fournit la coordination entre les services RPC et les numéros des ports utilisés pour communiquer avec eux, il est utile de pouvoir visualiser les services RPC en cours à l'aide de portmap lors de la résolution de problèmes. La commande rpcinfo montre chaque service basé sur RPC avec son numéro de port, numéro de programme RPC, version, et type de protocole IP (TCP ou UDP).
Pour s'assurer que les bons services NFS basés sur RPC sont activés pour portmap, utilisez la commande rpcinfo -p:
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100011 1 udp 749 rquotad
100011 2 udp 749 rquotad
100005 1 udp 759 mountd
100005 1 tcp 761 mountd
100005 2 udp 764 mountd
100005 2 tcp 766 mountd
100005 3 udp 769 mountd
100005 3 tcp 771 mountd
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
300019 1 tcp 830 amd
300019 1 udp 831 amd
100024 1 udp 944 status
100024 1 tcp 946 status
100021 1 udp 1042 nlockmgr
100021 3 udp 1042 nlockmgr
100021 4 udp 1042 nlockmgr
100021 1 tcp 1629 nlockmgr
100021 3 tcp 1629 nlockmgr
100021 4 tcp 1629 nlockmgr

L'option -p vérifie le mappeur de ports sur l'hôte spécifié, ou par défaut sur l'hôte local en l'absence de spécification. D'autres options sont décrites dans la page de manuel rpcinfo.
Les résultats ci-dessus montrent des services NFS en activité(version 2 et 3, , rpc.statd version 1, network lock manager pour rpc.lockd versions 1, 3 et 4). Si l'un des services NFS services ne démarre pas correctement, portmap sera incapable d'orienter les requêtes RPC de clients pour ce service, vers le port adéquat. Souvent, le redémarrage de NFS en étant connecté en tant que super-utilisateur (ou root) (/sbin/service nfs restart) permettra à ces services de s'enregistrer correctement auprès de portmap et de commencer à fonctionner.

Si des changements sont apportés au fichier /etc/exports, ces derniers ne prendront pas effet automatiquement. Vous devrez exécuter la commande exportfs –ra pour forcer nfsd à relire /etc/exports.
La commande exportfs permet au super-utilisateur d'exporter ou désexporter sélectivement des répertoires sans redémarrer le service NFS. Lorsque exportfs a passé les options appropriées, les systèmes de fichiers à exporter sont écrits dans /var/lib/nfs/xtab. Puisque rpc.mountd se réfère au fichier xtab lorsqu'il décide des privilèges d'accès à un système de fichier, les changements apportés à la liste des systèmes de fichiers exportés prennent effet immédiatement.
Diverses options sont disponibles lorsque l'on utilise exportfs:
• -r — provoque l'exportation de tous les répertoires listés dans /etc/exports par la construction d'une nouvelle liste d'exportation dans /etc/lib/nfs/xtab. Cette option rafraîchit effectivement la liste d'exportations par tout changement apporté à /etc/exports.
• -a — provoque l'exportation ou la désexportation de tous les répertoires, selon les autres options d' exportfs.
• -o options — permet à l'utilisateur de spécifier les répertoires à exporter qui ne sont pas listés dans /etc/exports. Ces partages de systèmes de fichiers supplémentaires doivent être écrits de la même manière qu'ils sont spécifiés dans /etc/exports. Cette option sert à tester un système de fichiers exporté avant de l'ajouter de façon permanente à la liste des systèmes de fichiers à exporter.
• -i — ne prend pas en compte /etc/exports; seules les options données par la ligne de commande sont utilisées pour définir des systèmes de fichiers exportés.
• -u — désexporte des répertoires de leur montage par des utilisateurs distants. La commande exportfs -ua suspend effectivement le partage de fichier NFS tout en laissant actifs les divers démons NFS. Pour permettre au partage NFS de continuer, tapez exportfs -r.
• -v — opération prolixe selon laquelle les systèmes de fichiers à exporter ou désexporter sont affichés avec de plus amples détails, lors de l'exécution de la commande exportfs.
Si aucune option n'est transmise à la commande exportfs, elle affiche une liste des systèmes de fichiers exportés en cours.
Les changements apportés à /etc/exports peuvent aussi se lire en rechargeant le service NFS à l'aide de la commande service nfs reload. Ce faisant, les démons NFS demeurent actifs tout en réexportant le fichier /etc/exports.

III. Les fichiers de configuration de clients NFS

Tout partage NFS proposé par un serveur peut être monté à l'aide de diverses méthodes. Le partage peut bien sûr être monté manuellement, en utilisant la commande mount. Pour ce faire, le super-utilisateur doit taper la commande mount chaque fois que le système redémarre. Parmi les deux méthodes de configuration de montage NFS figurent: la modification de /etc/fstab ou l'utilisation du service autofs.
1. /etc/fstab
L'insertion d'une ligne correctement formatée dans le fichier /etc/fstab revient à monter manuellement le système de fichiers exporté. Le fichier /etc/fstab est lu par le script /etc/rc.d/init.d/netfs au démarrage du système et tout partage spécifié dans ce dernier sera monté.
Une ligne /etc/fstab courante pour monter une exportation NFS ressemblera à ceci:
: nfs 0 0
L'option correspond au nom d'hôte, l'adresse IP ou le nom de domaine pleinement qualifié du serveur exportant le système de fichiers.
L'option correspond au chemin vers le répertoire exporté.
L'option spécifie l'endroit dans le système de fichier local où monter le répertoire exporté. Ce point de montage doit être déterminé avant que /etc/fstab ne soit lu, sinon le montage échouera.
L'option nfs spécifie le type de système de fichiers en cours de montage.
La zone spécifie les options de montage pour le système de fichiers. Par exemple, si la zone d'options stipule rw,suid, le système de fichier exporté sera monté en lecture-écriture (read-write) les ID d'utilisateur et de groupe fixées par le serveur seront utilisées. Notez que les parenthèses ne doivent pas être utilisées ici.
2. autofs
Un inconvénient lors de l'utilisation de /etc/fstab est que, indépendamment de la fréquence d'utilisation de ce système de fichiers monté, votre système doit allouer des ressources pour conserver ce montage en place. Ceci n'est pas un problème pour un ou deux montages, mais si votre système maintient le montage de douzaines de systèmes à la fois, les performances générales du système peuvent en pâtir. Une alternative à /etc/fstab consiste à utiliser l'utilitaire basé sur le noyau nommé automount, qui lui montera et démontera les systèmes de fichiers NFS automatiquement, économisant ainsi des ressources.
Le script autofs, situé dans le répertoire /etc/rc.d/init.d/, sert à contrôler automount par le biais du fichier de configuration primaire /etc/auto.master. Alors qu'automount peut être spécifié dans une ligne de commande, il est plus commode de spécifier les points de montage, nom d'hôte, répertoire exporté et options dans un ensemble de fichiers, plutôt que de les taper tous à la main. En exécutant autofs en tant qu'un service démarrant et arrêtant les niveaux d'exécution spécifiés, les configurations de montage des divers fichiers peuvent être automatiquement implémentées.
Les fichiers de configuration autofs sont organisés selon une relation parent-enfant. Un fichier de configuration principal (/etc/auto.master) se réfère à des points de montage sur votre système qui sont liés à un type de correspondance (map type) particulier, qui prend la forme d'autres fichiers de configuration, programmes, chemins NIS et autres méthodes de montage moins courantes. Le fichier auto.master contient des lignes se référant à chacun de ces points de montage, organisées de la manière suivante:

L'élément de cette ligne indique l'emplacement du montage sur le système de fichiers local. L'option fait référence à la manière dont le point de montage sera monté. La méthode la plus courante pour monter automatiquement des exportations NFS consiste à utiliser un fichier en tant que type de chemin (map-type) pour un point de montage particulier. Le fichier de chemin (map file), généralement nommé auto., où est le point de montage désigné dans auto.master, contient des lignes similaires à celles reproduites ci-dessous:

:
L'élément réfère au répertoire dans le point de montage où le système de fichiers exporté devrait être monté. Tout comme une commande mount standard, l'hôte exportant le système de fichiers ainsi que le système de fichiers exporté doivent être spécifiés dans la section :. Pour spécifier des options particulières pour le montage du système de fichiers exporté, placez-les dans la section , en les séparant bien par des virgules. Pour des montages NFS utilisant autofs, placez -fstype=nfs dans la section .
Bien que les fichiers de configuration autofs puissent être utilisés pour divers montages pour divers types de périphériques et systèmes de fichiers, ils se révèlent particulièrement utiles lors de la créaton de montages NFS. Par exemple, des organisations stockent le répertoire /home/ d'utilisateur sur un serveur central via le partage NFS. Ensuite, elles configurent le fichier auto.master sur chacune des stations de travail pour renvoyer à un fichier auto.home contenant les spécifications du montage du répertoire /home/ via NFS. Cela permet à l'utilisateur d'accéder à ses données personnelles et aux fichiers de configuration dans son répertoire /home/ en se connectant sur n'importe quel ordinateur du réseau interne. Le fichier auto.master dans cette situation ressemblerait à l'extrait suivant:
/home /etc/auto.home

Ceci installe le point de montage /home/ sur le système de fichier local à configurer avec le fichier /etc/auto.home, qui pourrait ressembler à l'extrait suivant:
* -fstype=nfs,soft,intr,rsize=8192,wsize=8192,nosuid server.example.com:/home
Cette ligne déclare que tout répertoire auquel un utilisateur tente d'accéder dans le répertoire /home/ local (en raison de l'astérisque) devrait entraîner un montage NFS sur le système server.domain.com au sein de son système de fichiers /home/ exporté. Les options de montage spécifient que chaque montage NFS de répertoire /home/ devrait utiliser une suite particulière de paramètres.
3. Options courantes de montage NFS
Au-delà du montage d'un système de fichiers sur un hôte distant via NFS, un certain nombre d'autres options peuvent être spécifiées au moment du montage, pour le rendre plus commode à utiliser. Ces options peuvent être utilisées avec les commandes manuelles mount, les paramètres /etc/fstab et autofs et d'autres méthodes de montage.
Ci-dessous figurent les options les plus courantes pour les montages NFS:
• hard ou soft — Spécifie si le programme utilisant un fichier via une connexion NFS doit s'arrêter et attendre (hard) que le serveur revienne en ligne si l'hôte servant le système de fichiers exporté est indisponible, ou s'il doit rapporter une erreur (soft).
Si l'option hard est spécifiée, l'utilisateur ne peut pas terminer le processus attendant la communication NFS pour recommencer, à moins que l'option intr ne soit également spécifiée.
Si l'option soft, est spécifiée, l'utilisateur peut ajouter une option timeo= où spécifie la durée d'attente en secondes avant de rapporter l'erreur.
• intr — Autorise l'interruption des requêtes NFS si le serveur est en panne ou ne peut pas être atteint.
• nolock — Peut être nécessaire afin de pouvoir se connecter à d'anciens serveurs NFS. Pour effectuer le verrouillage, utilisez l'option lock.
• noexec — Interdit l'exécution de binaires sur le système de fichiers monté. Cette option est utile si votre système Red Hat Linux est en train de monter un système de fichiers non-Linux via NFS, contenant des binaires incompatibles.
• nosuid — Interdit aux bits identifieur-d'utilisateur-fixé ou identifieur-de-groupe-fixé de prendre effet.
• rsize=8192 et wsize=8192 — Peuvent accélérer la communication NFS pour la lecture (rsize) et l'écriture (wsize) en déterminant une taille de blocs de données supérieure, exprimée en bits, pour les transférer en une fois. Soyez prudent si vous changez ces valeurs; des noyaux Linux ou des cartes de réseau anciens pourraient ne pas fonctionner correctement avec des tailles de blocs supérieures.
• nfsvers=2 or nfsvers=3 — Spécifie la version du protocole NFS à utiliser.
La page de manuel relative à mount énumère davantage d'options, y compris les options pour monter des systèmes de fichiers non-NFS.
D. Sécuriser NFS
NFS fonctionne bien pour le partage de systèmes de fichiers entiers avec un grand nombre d'hôtes connus et d'une manière largement transparente. Beaucoup d'utilisateurs accédant aux fichiers grâce à un montage NFS ne se rendent pas compte que le système de fichiers qu'ils sont en train d'utiliser ne se trouve pas vraiment sur leur système local. De ce fait, et avec l'habitude d'utilisation, divers problèmes potentiels de sécurité peuvent surgir.
Les points suivants doivent être considérés lorsque des systèmes de fichiers NFS sont exportés sur un serveur où lorsqu'ils sont montés sur un client. Ce faisant, les risques de sécurité NFS seront minimisés et les données stockées sur le serveur seront mieux protégées.
1. Accès des hôtes
NFS contrôle qui peut monter un système de fichiers exporté en se basant sur l'hôte qui effectue la requête de montage et non pas sur l'utilisateur qui exploitera effectivement le système de fichiers. Les hôtes doivent se voir accorder des droits explicites pour pouvoir monter le système de fichiers exporté. Le contrôle d'accès n'est possible pour les utilisateurs, que par les permissions de fichier et de répertoire. En d'autres termes, une fois qu'un système de fichiers est exporté via NFS, tout hôte distant connecté au serveur NFS peut avoir accès aux données partagées. Afin de limiter les risques potentiels, les administrateurs système peuvent restreindre l'accès à une lecture-seule ou peuvent réduire les utilisateurs à une ID d'utilisateur et de groupe commune. Ceci étant, de telles solutions peuvent empêcher l'utilisation du partage NFS de la manière originellement prévue.
De plus, si un agresseur prend le contrôle du serveur DNS utilisé par le système effectuant l'exportation du système de fichiers NFS, le système associé avec un nom d'hôte particulier ou un nom de domaine pleinement qualifié peut renvoyer vers un ordinateur non-légitime. À ce stade, l'ordinateur non-autorisé devient le système ayant l'autorisation de monter le partage NFS, puisqu'aucun nom d'utilisateur ou mot de passe n'est échangé pour fournir une sécurité supplémentaire au montage NFS. Les serveurs NIS compromis courent le même risque, si des groupes réseau NIS sont utilisés pour permettre à certains hôtes de monter un partage NFS. En utilisant des adresses IP situées dans /etc/exports, ce genre d'attaque devient plus difficile.
Les caractères génériques doivent être utilisés avec parcimonie lorsque la persmission d'exporter des partages NFS est attribuée car le champs d'action de ces caractères génériques peut s'étendre à un plus grand nombre de systèmes que prévus.
Pour de plus amples informatons sur la sécurisation de NFS, reportez-vous au chapitre intitulé Sécurité du serveur du Guide de sécurité de Red Hat Linux.

2. Permissions de fichiers
Une fois que le système de fichier NFS est monté en lecture-écriture par un hôte distant, la seule protection dont dispose chacun des fichiers partagés réside dans ses permissions. Si deux utilisateurs partageant la même valeur d'ID d'utilisateur montent le même système de fichier NFS, ils pourront modifier les fichiers mutuellement. De plus, toute personne connectée en tant que super-utilisateur (ou root) sur le système client peut utiliser la commande su - pour devenir un utilisateur ayant accès à des fichiers particuliers via un partage NFS. Pour de plus amples informations sur les conflits entre NFS et les ID d'utilisateur, reportez-vous au chapitre intitulé Gestion de comptes et groupes du Guide d'administration système de Red Hat Linux.
Le comportement par défaut lors de l'exportation d'un système de fichiers via NFS consiste à utiliser la fonction de réduction du super-utilisateur (ou 'root squashing'). Cette dernière permet d'assigner à l'ID d'utilisateur d'une personne quelconque accédant au partage NFS en tant que super-utilisateur (ou root) sur son ordinateur local, une valeur du compte personne (nobody) du serveur. Il est vivement conseillé de ne jamais désactiver la fonction de 'root squashing'.
Si l'exportation d'un partage NFS ne doit se faire qu'en lecture-seule, songez à utiliser l'option all_squash, qui attribue à tout utilisateur accédant au système de fichiers exporté, l'ID d'utilisateur personne (nobody).

E. Utiliser Linux NFS avec d’autres systèmes d’exploitation

Le texte ci-dessous est un extrait tiré de la nfs-howto dont nous reproduisons textuellement et dans sa version originale la partie relative à l’utilisation de NFS avec d’autres OS. Nous avons ajouter une petite partie pour son utilisation avec Windows.
Every operating system, Linux included, has quirks and deviations in the behavior of its NFS implementation -- sometimes because the protocols are vague, sometimes because they leave gaping security holes. Linux will work properly with all major vendors' NFS implementations, as far as we know. However, there may be extra steps involved to make sure the two OSes are communicating clearly with one another. This section details those steps.
In general, it is highly ill-advised to attempt to use a Linux machine with a kernel before 2.2.18 as an NFS server for non-Linux clients. Implementations with older kernels may work fine as clients; however if you are using one of these kernels and get stuck, the first piece of advice we would give is to upgrade your kernel and see if the problems go away. The user-space NFS implementations also do not work well with non-Linux clients.
Following is a list of known issues for using Linux together with major operating systems.

1. AIX
1.1. Linux Clients and AIX Servers
The format for the /etc/exports file for our example in Section 3, “Setting Up an NFS Server” is:
/usr slave1.foo.com:slave2.foo.com,access=slave1.foo.com:slave2.foo.com
/home slave1.foo.com:slave2.foo.com,rw=slave1.foo.com:slave2.foo.com

1.2. AIX clients and Linux Servers
AIX uses the file /etc/filesystems instead of /etc/fstab. A sample entry, based on the example in Section 4, “Setting up an NFS Client”, looks like this:
/mnt/home:
dev = "/home"
vfs = nfs
nodename = master.foo.com
mount = true
options = bg,hard,intr,rsize=1024,wsize=1024,vers=2,proto=udp
account = false
1. Version 4.3.2 of AIX, and possibly earlier versions as well, requires that file systems be exported with the insecure option, which causes NFS to listen to requests from insecure ports (i.e., ports above 1024, to which non-root users can bind). Older versions of AIX do not seem to require this.
2. AIX clients will default to mounting version 3 NFS over TCP. If your Linux server does not support this, then you may need to specify vers=2 and/or proto=udp in your mount options.
3. Using netmasks in /etc/exports seems to sometimes cause clients to lose mounts when another client is reset. This can be fixed by listing out hosts explicitly.
4. Apparently automount in AIX 4.3.2 is rather broken.
2. BSD
2.1. BSD servers and Linux clients
BSD kernels tend to work better with larger block sizes.
2.2. Linux servers and BSD clients
Some versions of BSD may make requests to the server from insecure ports, in which case you will need to export your volumes with the insecure option. See the man page for exports(5) for more details.

3. Tru64 Unix
3.1. Tru64 Unix Servers and Linux Clients
In general, Tru64 Unix servers work quite smoothly with Linux clients. The format for the /etc/exports file for our example in Section 4, “Setting up an NFS Client” is:
/usr slave1.foo.com:slave2.foo.com -access=slave1.foo.com:slave2.foo.com /home slave1.foo.com:slave2.foo.com \ -rw=slave1.foo.com:slave2.foo.com -root=slave1.foo.com:slave2.foo.com
(The root option is listed in the last entry for informational purposes only; its use is not recommended unless necessary.)
Tru64 checks the /etc/exports file every time there is a mount request so you do not need to run the exportfs command; in fact on many versions of Tru64 Unix the command does not exist.)
3.2. Linux Servers and Tru64 Unix Clients
There are two issues to watch out for here. First, Tru64 Unix mounts using Version 3 NFS by default. You will see mount errors if your Linux server does not support Version 3 NFS. Second, in Tru64 Unix 4.x, NFS locking requests are made by daemon. You will therefore need to specify the insecure_locks option on all volumes you export to a Tru64 Unix 4.x client; see the exports man pages for details.
4. HP-UX
4.1. HP-UX Servers and Linux Clients
A sample /etc/exports entry on HP-UX looks like this:
/usr -ro,access=slave1.foo.com:slave2.foo.com
/home -rw=slave1.foo.com:slave2.fo.com:root=slave1.foo.com:slave2.foo.com
(The root option is listed in the last entry for informational purposes only; its use is not recommended unless necessary.)
4.2. Linux Servers and HP-UX Clients
HP-UX diskless clients will require at least a kernel version 2.2.19 (or patched 2.2.18) for device files to export correctly. Also, any exports to an HP-UX client will need to be exported with the insecure_locks option.

5. IRIX
5.1. IRIX Servers and Linux Clients
A sample /etc/exports entry on IRIX looks like this:
/usr -ro,access=slave1.foo.com:slave2.foo.com
/home -rw=slave1.foo.com:slave2.fo.com:root=slave1.foo.com:slave2.foo.com
(The root option is listed in the last entry for informational purposes only; its use is not recommended unless necessary.)
There are reportedly problems when using the nohide option on exports to linux 2.2-based systems. This problem is fixed in the 2.4 kernel. As a workaround, you can export and mount lower-down file systems separately.
As of Kernel 2.4.17, there continue to be several minor interoperability issues that may require a kernel upgrade. In particular:
• Make sure that Trond Myklebust's seekdir (or dir) kernel patch is applied. The latest version (for 2.4.17) is located at:
http://www.fys.uio.no/~trondmy/src/2.4.17/linux-2.4.17-seekdir.dif
• IRIX servers do not always use the same fsid attribute field across reboots, which results in inode number mismatch errors on a Linux client if the mounted IRIX server reboots. A patch is available from:
http://www.geocrawler.com/lists/3/SourceForge/789/0/7777454/
• Linux kernels v2.4.9 and above have problems reading large directories (hundreds of files) from exported IRIX XFS file systems that were made with naming version=1. The reason for the problem can be found at:
http://www.geocrawler.com/archives/3/789/2001/9/100/6531172/.
The naming version can be found by using (on the IRIX server):
xfs_growfs -n mount_point
The workaround is to export these file systems using the -32bitclients option in the /etc/exports file. The fix is to convert the file system to naming version=2. Unfortunately the only way to do this is by a backup/mkfs/restore.
mkfs_xfson IRIX 6.5.14 (and above) creates naming version=2XFS file systems by default. On IRIX 6.5.5 to 6.5.13, use:
mkfs_xfs -n version=2 device
Versions of IRIX prior to 6.5.5 do not support naming version=2 XFS file systems.
5.2. IRIX clients and Linux servers
Irix versions up to 6.5.12 have problems mounting file systems exported from Linux boxes - the mount point "gets lost," e.g.,:
# mount linux:/disk1 /mnt
# cd /mnt/xyz/abc
# pwd
/xyz/abc
This is known IRIX bug (SGI bug 815265 - IRIX not liking file handles of less than 32 bytes), which is fixed in IRIX 6.5.13. If it is not possible to upgrade to IRIX 6.5.13, then the unofficial workaround is to force the Linux nfsd to always use 32 byte file handles. A number of patches exist - see:
• http://www.geocrawler.com/archives/3/789/2001/8/50/6371896/
• http://oss.sgi.com/projects/xfs/mail_archive/0110/msg00006.html
6. Solaris
6.1. Solaris Servers with Linux Clients
Solaris has a slightly different format on the server end from other operating systems. Instead of /etc/exports, the configuration file is /etc/dfs/dfstab. Entries are of the form of a share command, where the syntax for the example in Section 4, “Setting up an NFS Client” would look like:
share -o rw=slave1,slave2 -d "Master Usr" /usr
and instead of running exportfs after editing, you run shareall.
Solaris servers are especially sensitive to packet size. If you are using a Linux client with a Solaris server, be sure to set rsize and wsize to 32768 at mount time.
Finally, there is an issue with root squashing on Solaris: root gets mapped to the user noone, which is not the same as the user nobody. If you are having trouble with file permissions as root on the client machine, be sure to check that the mapping works as you expect.
6.2. Solaris Clients with Linux Servers
Solaris clients will regularly produce the following message:
svc: unknown program 100227 (me 100003)
This happens because Solaris clients, when they mount, try to obtain ACL information - which Linux obviously does not have. The messages can safely be ignored.
There are two known issues with diskless Solaris clients: First, a kernel version of at least 2.2.19 is needed to get /dev/null to export correctly. Second, the packet size may need to be set extremely small (i.e., 1024) on diskless sparc clients because the clients do not know how to assemble packets in reverse order. This can be done from /etc/bootparams on the clients.
7. SunOS
SunOS only has NFS Version 2 over UDP.
On the server end, SunOS uses the most traditional format for its /etc/exports file. The example in Section 4, “Setting up an NFS Client” would look like:
/usr -access=slave1.foo.com,slave2.foo.com
/home -rw=slave1.foo.com,slave2.foo.com, root=slave1.foo.com,slave2.foo.com
Again, the root option is listed for informational purposes and is not recommended unless necessary.
7.1. SunOS Clients
Be advised that SunOS makes all NFS locking requests as daemon, and therefore you will need to add the insecure_locks option to any volumes you export to a SunOS machine. See the exports man page for details.
8.Windows
Pour l’utilisation de NFS avec windows il suffit de télécharger des softs du genre ProNFS pour pouvoir interagir avec d’autres OS et partager ainsi dossier et fichier. Ce dernier édité par Labtam est téléchargeable ici.
F. Ressources supplémentaires
L'administration d'un serveur NFS peut se transformer en un véritable défi. Maintes options, y compris un certains nombre passé sous silence dans ce chapitre, sont disponibles pour l'exportation ou le montage de partages NFS. Pour de plus amples informations, consultez les sources d'information mentionnées ci-dessous.
1. Documentation installée
• /usr/share/doc/nfs-utils-/ — Remplacez par le numéro de version du paquetage NFS. Ce répertoire contient de nombreuses informations sur l'implémentation de NFS sous Linux, y compris diverses configurations NFS et leur impact sur les performances de transfert de fichiers.
• man mount — Contient une vue complète des options de montage pour les configurations aussi bien de serveur que de client NFS.
• man fstab — Donne des détails quant au format du fichier /etc/fstab utilisé pour monter les systèmes de fichiers lors du démarrage du système.
• man nfs — Fournit des détails non seulement sur l'exportation de systèmes de fichiers spécifique à NFS, mais également sur les options de montage.
• man exports — Montre les options couramment utilisées dans le fichier /etc/exports lors de l'exportation de systèmes de fichiers NFS.
2. Livres sur le sujet
• Managing NFS and NIS de Hal Stern, Mike Eisler, et Ricardo Labiaga; O'Reilly & Associates — Constitue un excellent guide de référence pour les nombreuses exportations NFS et options de montage disponibles.
• NFS Illustrated de Brent Callaghan; Addison-Wesley Publishing Company — Fournit des comparaisons de NFS avec d'autres systèmes de fichiers réseau et montre, en détail, comment se déroule une communication NFS.

Sources :
http://nfs.sourceforge.net/nfs-howto
http://www.nfsv4.org/
http://sourceforge.net/projects/nfs
http://supinfo-projects.com/fr/2003/rpc
http://www.europe.redhat.com/documentation/rhl9/rhl-rg-fr-9/ch-nfs.php3
http://www.time-travellers.org/shane/papers/NFS_considered_harmful.html
http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/ref-guide/ch-nfs.html
http://www.ac-creteil.fr/reseaux/systemes/linux/nfs-linux.html
http://tldp.org/LDP/nag/node140.html
http://www.unet.univie.ac.at/aix/aixbman/commadmn/nfs_intro.htm

Prétendu trou de sécurité de Firefox : regardons de plus près

2005-12-13T04:44:00.000-08:00

Lu sur le blog de Tristan Nitot sur l'eventul trou de sécurité de notre browser préféré ;)

Certains sites annoncent a tort que Firefox 1.5 a un trou de sécurité critique. Je les invite à vérifier leurs sources et à lire ce qui suit, qui est publié par Mozilla. Je pense qu'un rectificatif de leur part s'impose.

Long-title temporary startup unresponsiveness

Web pages with extremely long titles (the posted proof of concept used 2.5 million characters) can cause Mozilla Firefox and the Mozilla Suite to appear to "hang" on startup when reading the browsing history data. The browser will eventually continue normally although this can take up to several minutes on a slower computer. The unresponsive starts will continue until the item with the long title is removed from the history file or eventually expires.

We have investigated this issue and can find no basis for claims that variants of this denial-of-service attack can cause an exploitable crash, and no evidence for this claim has been offered. There does not appear to be any risk to users or their computers beyond the temporary unresponsiveness at startup.

En voici la traduction :

Manque de réaction temporaire au démarrage pour les titres longs''

Les pages Web avec des titres extrèmement longs (le test publié utilisait 2,5 millions de caractères) peut faire que Firefox et la suite Mozilla semblent ne plus fonctionner au démarrage alors qu'ils sont en train de lire l'historique de navigation. Le navigateur finira par fonctionner normallement, même si cela peut prendre plusieurs minutes sur un ordinateur lent. La lenteur au démarrage persistera tant que le titre long n'aura pas été retiré du fichier de l'historique, ou tant qu'il n'aura pas expiré.

Nous avons mené des recherches sur ce problème et nous pensons qu'il n'y a pas de raison d'affirmer que des variantes de cette attaque par déni de service peut provoquer un plantage qui pourrait être exploité, et nous n'avons pas eu la preuve de cette affirmation. Il ne semble pas y avoir de risque pour les utilisateurs au delà du manque de réactivité au démarrage.

Personnelemnt j'ai eu à tester le code et ma machine à ramer je l'avoue en me marquant une adresse de site assez longue, j'ai même du avoir recours au gestionnaire de tâches pour l'arrêter, mais aprés redémarrage de firefox, plus de blem ;)
Donc continuons à avoir confiance pour freiner l'emprise IE!

Un code pour faire planter son Firefox???

2005-12-13T04:39:00.000-08:00

Voici un article que j'ai lu pour vous sur pcastuces: annonçant une faille sur notre navigateur favori!

Alors que le navigateur frappé d’un panda roux et connu pour être plus sûr que son homologue de Redmond, une faille vient d’être découvert touchant ainsi tout spécialement le logiciel de la fondation Mozilla.

Certes, ce n’est pas une faille de sécurité et personne ne devrait prendre le contrôle de votre machine pour l’instant, même si certains le prédisent, mais ce genre d’incident est assez rare sur Firefox pour qu’on en parle. Le code, que vous trouverez en bas de cette actualité a pour but de créer un sujet pour page Web extrêmement long qui apparaîtra en parti sur l’onglet de la page visionné. Sur le moment, rien ne se passe, mais une fois Firefox fermé, il sera impossible de le lancer à nouveau sans qu’il crash. Bref, le panda n'apprécie vraiment pas les titres trop long.

Sachez que pour résoudre le problème, il vous suffit d’effacer le fichier « history.dat » présent dans le répertoire Documents and Settings(user)Application DataMozillaFirefox(votre profile).

Exemple de code pouvant bloquer Firefox :

script type="text/javascript"

function ex() {
var buffer = "";
for (var i = 0; i < 5000; i++) {
buffer += "A";
}
var buffer2 = buffer;
for (i = 0; i < 500; i++) {
buffer2 += buffer;
}
document.title = buffer2;
}

/script

Pour information, sachez que cette faille touche aussi les linuxiens.

Visitez le site qui bloquera votre Firefox (il faut cliquer sur "Proof of Concept")

La "Google Toolbar" dope Firefox !

2005-12-05T05:59:00.000-08:00

Lu sur caloga.com de la période du 1er au 15 décembre 2005:

La presse spécialisée dans son ensemble a salué l'arrivée du navigateur Firefox, et fait un éloge unanime de ce logiciel dont le succès fut explosif : en moins de 13 mois, plus de 110 millions de téléchargements, 11% de part de marché mondiale, 14% aux Etats-Unis, 15% en Europe ! La réussite de Firefox tient à la fois à ses qualités propres (tout le monde reconnaît son avance technologique) et aux failles de sécurité de son principal adversaire, Internet Explorer 6.

Mais la véritable révolution apportée par Firefox, peu remarquée par les observateurs, se trouve sans doute ailleurs. Depuis quelques jours, le navigateur peut être téléchargé directement dans une version qui intègre la barre d'outils de Google (ou "Google Toolbar"). Nous avons le plaisir de vous proposer le lien de téléchargement vers cette version nommée "Firefox incluant la barre d'outils Google", aujourd'hui réservée aux utilisateurs de Windows.

Cette fonctionnalité supplémentaire s'avère bien sûr séduisante pour les internautes. Elle traduit également une alliance stratégique de fait entre Google et un des acteurs majeurs du logiciel libre, la Mozilla Organization. Microsoft se doit de réagir avec un sans-faute sur la sortie prochaine d'Internet Explorer 7. Mais force est de constater que Firefox vient de prendre un temps d'avance dans la partie d'échecs qui l'oppose à IE.

Installation firefox

2005-11-21T08:26:00.000-08:00

On choisit la version de notre système d'exploitation pour télécharger le programme adéquat. Suivant le lien donné ci dessous, le choix se fait sur la partie située à droite de la fenêtre et ressemble à ceci:

Une fois notre OS choisit la fenêtre de téléchargement apparait et on procéde à l'installation comme pour tout autre logiciel téléchargeable sur la toile. Pour cela nous allons lancer le fichier Firefox Setup 1.0.7 enregistré sur le disque dur. On double clique dessus et on obtient ceci:

On clique de nouveau sur suivant puis on choisit le bouton radio "J'accepte les termes de l'accord de licence", puis suivant, on laisse les paramétres standards qui ne différencient pas trop des paramètres personnalisés, de nouveau on clique sur suivant pour démarrer l'installation.

On obtient une fenêtre avec une barre de progression de l'installation se présentant comme suis:

Une fois cette ètape terminée, notre installation s'est bien déroulé et on obtient une derniére fenêtre nous permettant de lancer firefox:

En cliquant sur Terminer firefox se lance et nous demande si on veut le mettre comme navigateur par défaut car il a noté la présence d'un autre navigateur outre que lui. Définir firefox comme navigateur par défaut inclut que toutes les pages web seront directement affichées par lui comme le faisait IE avant lui. Il transférera en même temps nos favoris, historiques et autres d'internet explorer avec lui.
Voilà nous venons d'installer firefox, notons au passage que sa page de démarrage s'ouvre sur le célébre moteur de recherche google .
Félicitations, maintenant découvrons le ;)

Firefox ou le navigateur en devenir ???

2005-11-21T08:03:00.000-08:00

Firefox (version 1.0.7 à ce jour) est le navigateur de nouvelle génération de la fondation Mozilla. Firefox est une alternative légère et gratuite au géant qui domine le marché des navigateurs Internet : Internet Explorer. Firefox permet de surfer plus vite, plus sûrement et plus efficacement qu'avec n'importe quel autre navigateur. Il dispose en outre de diverses autres fonctionnalités paramétrables selon l'utilisateur.
Téléchargeable sur ce lien: firefox à vous de le découvrir et l'exploiter pleinement !
J'attends vos commentaires ;)