Voir la source de Nfs

[[Category:serveur]]
[[Category:debian]]
[[Category:networking]]
[[Category:desktop]]
=Installation classique=

==Sur le serveur==

Installer le serveur nfs :
<pre>aptitude install nfs-kernel-server</pre>

Pour créer un partage, éditez le fichier <code>/etc/exports</code> :
<pre>/home/pfoo/data/ 192.168.10.0/255.255.255.0(ro,sync,no_subtree_check)</pre>

Note : Si l'un de vos clients doit pouvoir monter le partage nfs sans être root sur sa machine il faudra ajouter l'option <code>insecure</code> sur la ligne de l'exports.

Pour permettre la lecture et l'écriture, remplacez <code>ro</code> par <code>rw</code><br>
<code>192.168.10.0/255.255.255.0</code> signifie que le partage sera accessible pour les ips <code>192.168.10.X</code>

Rechargez nfs :
<pre>/etc/init.d/nfs-kernel-server reload</pre>

Attention, si vous souhaitez partager un volume ntfs en nfs, utilisez de préférence ntfs-3g pour monter le volume ntfs sur le serveur.

===Limiter l'accès===

Ajoutez les lignes suivantes dans <code>/etc/hosts.deny</code> :
<pre>
portmap: ALL
lockd: ALL
mountd: ALL
rquotad: ALL
statd: ALL
</pre>

Ajoutez les lignes suivantes dans <code>/etc/hosts.allow</code> :
<pre>
portmap: 192.168.10.
lockd: 192.168.10.
mountd: 192.168.10.
rquotad: 192.168.10.
statd: 192.168.10.
</pre>

==Sur le client==

Installer le client nfs :
<pre>aptitude install nfs-common</pre>

Ajoutez la ligne suivante dans <code>/etc/fstab</code> :
<pre>192.168.10.13:/home/pfoo/data/ /home/pfoo/mnt/ nfs defaults,vers=3,user,auto,noatime,intr 0 0</pre>

<code>192.168.10.13</code> est l'ip de votre serveur nfs.

il ne reste plus qu'a monter :
<pre>mount /home/pfoo/mnt/</pre>

=NFS et tunnel ssh=

==Sur le serveur==
Pour simplifier les choses, il va falloir forcer NFS à n'utiliser que des ports précis.

Modifiez la ligne suivante dans <code>/etc/default/nfs-common</code> : 
<pre>STATDOPTS="--port 2231"</pre>

Modifiez la ligne suivante dans <code>/etc/default/nfs-kernel-server</code> :
<pre>RPCMOUNTDOPTS="--port 2233"</pre>

Enfin, créez le fichier <code>/etc/modprobe.d/local.conf</code> contenant :
<pre>options lockd nlm_udpport=2232 nlm_tcpport=2232
options nfs callback_tcpport=2234</pre>

Créez un utilisateur "sleeper" qui servira a établir le tunnel ssh:
<pre>adduser --disabled-password sleeper</pre>

Et copiez la clé ssh publique de votre client dans /home/sleeper/.ssh/authorized_keys :
<pre>from="ip",command="/bin/sleep 600d" ssh-rsa .......</pre>

Créez enfin le partage nfs dans <code>/etc/exports</code>. En admettant que vous souhaitez partager le dossier /srv (remplacez IPNFS par l'ip de votre serveur) :
<pre>/srv IPNFS(rw,no_root_squash,sync,insecure)</pre>

Puis lancez l'export :
<pre>exportfs -a</pre>

==Sur le client==
Initialisez le tunnel ssh (remplacez IPNFS par l'ip de votre serveur nfs) :
<pre>
ssh -f -i /root/.ssh/id_rsa -c blowfish -L 61001:IPNFS:2049 -l sleeper IPNFS sleep 600d
ssh -f -i /root/.ssh/id_rsa -c blowfish -L 62001:IPNFS:2233 -l sleeper IPNFS sleep 600d 
</pre>

Ajoutez la ligne suivante dans /etc/fstab :
<pre>localhost:/srv /mnt nfs tcp,rsize=8192,wsize=8192,intr,rw,bg,nosuid,port=61001,mountport=62001,noauto</pre>

Et montez le partage :
<pre>mount /mnt</pre>

si vous souhaitez limiter la bande passante utilisable par le tunnel, utilisez trickle. Par exemple pour 5mbps :
<pre>
trickle -s -u 5000 -d 5000 ssh -f -i /root/.ssh/id_rsa -c blowfish -L 61001:IPNFS:2049 -l sleeper IPNFS sleep 600d
trickle -s -u 5000 -d 5000 ssh -f -i /root/.ssh/id_rsa -c blowfish -L 62001:IPNFS:2233 -l sleeper IPNFS sleep 600d 
</pre>

=Overview des permissions NFS=

Le contrôle d'accès de nfs3 est basé sur les uid/gid présentés lors de chaque requete nfs. Il est important de noter que les permissions appliquées sur un partage NFS sont celles du serveur.<br>
La manière classique de fonctionnement impose que les UID et les GID soient les même sur la machine cliente et sur la machine serveur nfs. Si c'est le cas, vous n'aurez aucun problème d'accès. Si vous souhaitez que l'accès soit permis en dehors du bon couple uid:gid, il faut s'intéresser aux options <code>root_squash no_root_squash all_squash no_all_squash anonuid anongid</code> de NFS.

Par défaut, si rien n'est précisé, le partage est considéré comme <code>root_squash</code> et <code>no_all_squash</code>.

Dans tous les exemples suivant, nous considérerons que le dossier /data appartient a l'uid:gid 1000/1000, sans aucun droit pour other (rwxr-x---) <br>
Prenons un exemple simple. Si votre /etc/exports NFS est configuré comme ceci :
<pre>
/data 192.168.1.0/255.255.255.0(rw,sync)
#ou son équivalent "par défaut"
/data 192.168.1.0/255.255.255.0(rw,sync,root_squash,no_all_squash)
</pre>
Il faudra que l'utilisateur qui doit accéder à la ressource NFS côté client ait lui aussi l'uid 1000 et le gid 1000 (dans une moindre mesure) et ce tout simplement pour respecter les permissions linux (jusque là c'est logique, non ?). Mais Dans le cas présent, même l'utilisateur root sur le client n'aura pas les droits sur le dossier ! Bizarre ? non, c'est lié à la directive root_squash qui, en gros, remap les accès fait par l'utilisateur root sur le client vers l'uid/gid squash (numéro 65534 si ça vous intéresse).<br>
Et pour qu'un autre utilisateur ait des droits, il suffit de suivre les permissions linux classiques. Mais attention, encore une fois, c'est sur le serveur qu'elles comptent. Si vous avez, sur le client nfs, un utilisateur d'uid 1001, membre du groupe de gid 1000 ... ça ne marchera pas, il faut aussi que l'utilisateur d'uid 1001 soit membre du groupe de gid 1000 sur le serveur nfs.

Si nous modifions la ligne comme suit :
<pre>/data 192.168.1.0/255.255.255.0(rw,sync,no_root_squash,no_all_squash)</pre>
Cela permettra à l'utilisateur root d'accéder aux fichiers. Si root créé un fichier dans /data (via le client nfs évidemment), le fichier appartiendra a root:root sur le serveur.

En résumé 
* all_squash et root_squash : force l'attribution de l'uid/gid squash aux clients
* no_all_squash et no_root_squash : conserve l'uid/gid original des clients
* par défaut, si rien n'est précisé : root_squash et no_all_squash.

Alors, pourquoi tout ce bordel puisqu'au final il faut quand même que les userid correspondent ? C'est la qu'interviennent les directives <code>anonuid</code> et <code>anongid</code>.
si on reprend, on a un dossier /data et des fichiers appartenant à l'uid 1000. Si on précise une ligne de ce type :
<pre>/data 192.168.1.0/255.255.255.0(rw,sync,root_squash,all_squash,anonuid=1000,anongid=1000)</pre>
Tous les utilisateurs (car all_squash) et l'utilisateur root (car root_squash) se retrouvent mappé vers l'uid squash, a savoir, l'uid 1000. Résultat, tous les utilisateurs (et root) auront les droits sur les fichiers de /data au travers de nfs.

=NFS4=