« Nfs » : différence entre les versions
(9 versions intermédiaires par le même utilisateur non affichées) | |||
Ligne 2 : | Ligne 2 : | ||
[[Category:debian]] | [[Category:debian]] | ||
[[Category:networking]] | [[Category:networking]] | ||
[[ | [[Category:desktop]] | ||
=Installation classique= | =Installation classique= | ||
Ligne 11 : | Ligne 11 : | ||
Pour créer un partage, éditez le fichier <code>/etc/exports</code> : | 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 | <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 | 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> | 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> | <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> | ||
Ligne 64 : | Ligne 64 : | ||
<pre>STATDOPTS="--port 2231"</pre> | <pre>STATDOPTS="--port 2231"</pre> | ||
Modifiez la ligne suivante dans <code | Modifiez la ligne suivante dans <code>/etc/default/nfs-kernel-server</code> : | ||
<pre>RPCMOUNTDOPTS="--port 2233"</pre> | <pre>RPCMOUNTDOPTS="--port 2233"</pre> | ||
Ligne 117 : | Ligne 117 : | ||
</pre> | </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> | 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. | 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 : | Si nous modifions la ligne comme suit : | ||
Ligne 126 : | Ligne 126 : | ||
* all_squash et root_squash : force l'attribution de l'uid/gid squash aux clients | * 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 | * 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>. | 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>. | ||
Ligne 131 : | Ligne 132 : | ||
<pre>/data 192.168.1.0/255.255.255.0(rw,sync,root_squash,all_squash,anonuid=1000,anongid=1000)</pre> | <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. | 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= |
Dernière version du 12 juin 2016 à 22:31
Installation classique
Sur le serveur
Installer le serveur nfs :
aptitude install nfs-kernel-server
Pour créer un partage, éditez le fichier /etc/exports
:
/home/pfoo/data/ 192.168.10.0/255.255.255.0(ro,sync,no_subtree_check)
Note : Si l'un de vos clients doit pouvoir monter le partage nfs sans être root sur sa machine il faudra ajouter l'option insecure
sur la ligne de l'exports.
Pour permettre la lecture et l'écriture, remplacez ro
par rw
192.168.10.0/255.255.255.0
signifie que le partage sera accessible pour les ips 192.168.10.X
Rechargez nfs :
/etc/init.d/nfs-kernel-server reload
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 /etc/hosts.deny
:
portmap: ALL lockd: ALL mountd: ALL rquotad: ALL statd: ALL
Ajoutez les lignes suivantes dans /etc/hosts.allow
:
portmap: 192.168.10. lockd: 192.168.10. mountd: 192.168.10. rquotad: 192.168.10. statd: 192.168.10.
Sur le client
Installer le client nfs :
aptitude install nfs-common
Ajoutez la ligne suivante dans /etc/fstab
:
192.168.10.13:/home/pfoo/data/ /home/pfoo/mnt/ nfs defaults,vers=3,user,auto,noatime,intr 0 0
192.168.10.13
est l'ip de votre serveur nfs.
il ne reste plus qu'a monter :
mount /home/pfoo/mnt/
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 /etc/default/nfs-common
:
STATDOPTS="--port 2231"
Modifiez la ligne suivante dans /etc/default/nfs-kernel-server
:
RPCMOUNTDOPTS="--port 2233"
Enfin, créez le fichier /etc/modprobe.d/local.conf
contenant :
options lockd nlm_udpport=2232 nlm_tcpport=2232 options nfs callback_tcpport=2234
Créez un utilisateur "sleeper" qui servira a établir le tunnel ssh:
adduser --disabled-password sleeper
Et copiez la clé ssh publique de votre client dans /home/sleeper/.ssh/authorized_keys :
from="ip",command="/bin/sleep 600d" ssh-rsa .......
Créez enfin le partage nfs dans /etc/exports
. En admettant que vous souhaitez partager le dossier /srv (remplacez IPNFS par l'ip de votre serveur) :
/srv IPNFS(rw,no_root_squash,sync,insecure)
Puis lancez l'export :
exportfs -a
Sur le client
Initialisez le tunnel ssh (remplacez IPNFS par l'ip de votre serveur nfs) :
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
Ajoutez la ligne suivante dans /etc/fstab :
localhost:/srv /mnt nfs tcp,rsize=8192,wsize=8192,intr,rw,bg,nosuid,port=61001,mountport=62001,noauto
Et montez le partage :
mount /mnt
si vous souhaitez limiter la bande passante utilisable par le tunnel, utilisez trickle. Par exemple pour 5mbps :
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
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.
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 root_squash no_root_squash all_squash no_all_squash anonuid anongid
de NFS.
Par défaut, si rien n'est précisé, le partage est considéré comme root_squash
et no_all_squash
.
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---)
Prenons un exemple simple. Si votre /etc/exports NFS est configuré comme ceci :
/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)
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).
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 :
/data 192.168.1.0/255.255.255.0(rw,sync,no_root_squash,no_all_squash)
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 anonuid
et anongid
.
si on reprend, on a un dossier /data et des fichiers appartenant à l'uid 1000. Si on précise une ligne de ce type :
/data 192.168.1.0/255.255.255.0(rw,sync,root_squash,all_squash,anonuid=1000,anongid=1000)
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.