Créer un partage NFS

De $1

 

Introduction

Système de partage de fichiers réseau sous Linux

 


http://g.eckenschwiller.free.fr/Tutoriels/Configuration/serveur_NFS.php

 

Les options de NFS permettent de gérer ces droits, par l'intermédiaire des identifiants de l'utilisateur qui veut accéder au partage. Selon le cas :

  • les identifiants du demandeur sont conservés. et les droits sont définis en fonction de la qualité du demandeur (propriétaire, appartient au groupe, fait partie du reste du monde)
  • les identifiants sont transformés en identifiants d'un utilisateur nommé nobody et qui n'a que des droits très limités (reste du monde)

Si un demandeur est, par exemple, l'utilisateurToto et que cet utilisateur existe à la fois sur la machine client et sur le serveur, rien ne dit que les identifiants de cet utilisateur Toto soient les mêmes sur les deux machines. Il faudra y remédier au besoin, faute de quoi il ne sera pas reconnu correctement et pourrait avoir les droits d'un autre utilisateur.

Si le demandeur distant est un superutilisateur, vous savez qu'il a des droits illimités. De ce fait, il sera traité séparément, afin de définir s'il peut les utiliser sur le serveur.

Les options se placent immédiatement après le nom du client, sans espace et entre parentaises (voir l'exemple ci-dessus).
Voici les options relatives aux identifiants et aux droits qui en résultent :

  • concernant les utilisateurs normaux
    • no_all_squashC'est l'option utilisée par défaut, il n'est donc pas nécessaire de l'indiquer.
      Les utilisateurs ordinaires conservent leur identifiant.
      Intérêt : chaque utilisateur n'accède qu'à ses documents et à ceux auxquels il est autorisé.
      Il faut cependant que les UID et GID soient identiques sur les deux machines.
    • all_squash
      Les requêtes de tous les utilisateur sont transformées en requêtes de l'utilisateur anonyme (nobody).
      Intérêt : les clients ne peuvent rien modifier. Ceci est conseillé pour un serveur public.
  • concernant le superutilisateur
    • root_squashC'est l'option utilisée par défaut, il n'est donc pas nécessaire de l'indiquer.
      Les requêtes du superutilisateur sont transformées en requêtes de l'utilisateur anonyme, donc avec des droits très réduits.
      Intérêt : un superutilisateur distant ne peut pas utiliser ses droits étendus sur le serveur. Cette option est fortement recommandée et indispensable pour un serveur public.
    • no_root_squash
      Le superutilisateur garde tous ses droits.
      Intérêt : Elle est utile pour les stations sans disque.

Remarque : vous avez vu qu'avec l'option no_all_squash, il faut que les UID et GID de l'utilisateur soient identiques sur les deux machines. Il existait deux méthodes permettant leur conversion lorsque cela est nécessaire. Elles ont été abandonnées, sans doute par manque de sécurité. Maintenant, il faut bien veiller à avoir les mêmes identifiants ou bien utiliser une méthode centralisée d'authentification.

 

 

  • Accès synchrone/asynchrone
    Les spécifications de NFS disent qu'une requête d'écriture de NFS doit être terminée (lorsque les données sont effectivement écrites sur le disque) avant de procéder à une nouvelle requête. Ceci réduit les performances à l'écriture, mais augmente le sécurité (en cas de redémarrage brutal d'un serveur après plantage par exemple).
    Il s'agit de l'accès synchrone et c'est le comportement par défaut.
    Les écritures asynchrones sont plus rapides.
    Une des optionssyncouasyncdoit être spécifiée.
  • Connexion sécurisée ou non
    L'option 'sécurisée réclame que les requêtes proviennent d'un port de numéro inférieur à 1024. Elle est en service par défaut.
    C'est une des optionssecure(par défaut) ouinsecurequi doit être spécifiée.
  • Partage en lecture seule ou non
    C'est une des optionsro=lecture seule (par défaut) ourw lecture/écriture qui doit être spécifiée.
  • Vérification des sous-répertoires
    Généralement, pour un répertoire personnel, vous n'utiliserez pas le contrôle des sous-répertoires.
    C'est une des optionssubtree_checkouno_subtree_checkqui doit être spécifiée.

 

 


http://www.troubleshooters.com/linux/nfs.htm

 

General Options

Many options can go in the parentheses. If more than one, they are delimited by commas. Here are the common options:
Option
What it does
Comment
ro Read Only The share cannot be written. This is the default.
rw Read Write The share can be written.
secure Ports under 1024 Requires that requests originate on a port less  than IPPORT_RESERVED (1024). This is the default.
insecure Negation of secure  
async Reply before disk write Replies to requests before the data is written to disk. This improves performance, but results in lost data if the server goes down.
sync Reply only after disk write Replies to the NFS request only after all data has been written to disk. This is much safer than async, and is the default in all nfs-utils versions after 1.0.0.
no_wdelay Write disk as soon as possible NFS has an optimization algorithm that delays disk writes if NFS deduces a likelihood of a related write request soon arriving. This saves disk writes and can speed performance.
BUT...
If NFS deduced wrongly, this behavior causes delay in every request, in which case this delay should be eliminated. That's what the no_wdelay option does -- it eliminates the delay. In general, no_wdelay is recommended when most NFS requests are small and unrelated.
wdelay Negation of no_wdelay This is the default.
nohide Reveal nested directories Normally, if a server exports two filesystems one of which is mounted on the other, then  the  client  will  have  to mount  both filesystems explicitly to get access to them.  If it just mounts the parent, it will see an empty  directory  at  the place where the other filesystem is mounted.  That filesystem is "hidden".

Setting the nohide option on a filesystem causes it  not  to  be hidden,  and  an appropriately authorised client will be able to move from the parent to that  filesystem  without  noticing  the change.

However,  some  NFS clients do not cope well with this situation as, for instance, it is then possible for two files in  the  one apparent filesystem to have the same inode number.

The  nohide  option  is  currently only effective on single host exports.  It does not work reliably with  netgroup,  subnet,  or wildcard exports.

This option can be very useful in some situations, but it should be used with due care, and only after confirming that the client system copes with the situation effectively.
hide Negation of nohide This is the default
subtree_check Verify requested file is in exported tree This is the default. Every file request is checked to make sure that the requested file is in an exported subdirectory. If this option is turned off, the only verification is that the file is in an exported filesystem.
no_subtree_check Negation of subtree_check Occasionally, subtree checking can produce problems when a requested file is renamed while the client has the file open. If many such situations are anticipated, it might be better to set no_subtree_check. One such situation might be the export of the /home filesystem. Most other situations are best handed with subtree_check.
secure_locks Require authorization for lock requests This is the default. Require authorization of all locking requests.
insecure_locks Negation of secure_locks Some NFS clients don't send credentials with lock requests, and hence work incorrectly with secure_locks., in which case you can only lock world-readable files. If you have such clients, either replace them with better ones, or use the insecure_locks option.
auth_nlm Synonym for secure_locks  
no_auth_nlm Synonym for secure_locks  

 

 

 

 

 howto05_small.pngVous en pensez quoi ?


 

 

 

 
 
Images (0)
 
Commentaires (0)
Vous devez être connecté pour poster un commentaire.