NFS ( Système de fichiers réseau) est principalement conçu pour être partagé des dossiers et Dossiers compris entre / Unix systèmes de Microsystèmes solaires dans 1980. Il vous permet de monter des systèmes de fichiers locaux sur le réseau et des hôtes distants pour interagir avec eux comme s'ils étaient montés localement sur le même système. En utilisant NFS, nous pouvons configurer le partage de fichiers entre Unix dans linux système et linux pour le système Unix.

Avantages de NFS

1. NFS crée un accès local à fichiers supprimés.
2. Il utilise l'architecture standard client/serveur pour échanger des fichiers entre toutes les machines en fonction de * RIEN.
3. En utilisant NFS pas besoin que les deux machines fonctionnent sur le même SE.
4. En utilisant NFS nous pouvons personnaliser la solution stockage centralisé.
5. Les utilisateurs reçoivent leur Les données quel que soit leur emplacement physique.
6. Automatique mettre à jour pour les nouveaux fichiers.
7. Suite une nouvelle version NFS prend en charge le montage ACL, pseudo sous racine.
8. Peut être protégé pare-feu et KerberosName.

Services NFS

Un service Système V lancé. Forfait serveur NFS comprend trois outils inclus dans les forfaits portmap et nfs-utils.

1. portmap: affiche les appels passés depuis d'autres machines vers le bon service RPC(pas nécessaire avec NFSv4).
2. nfs: convertit les requêtes distantes partage de fichiers aux requêtes sur le système de fichiers local.
3. rpc.mountd: ce service est chargé de montage et démonter systèmes de fichiers.

Fichiers de configuration importants pour NFS

1. /etc/exports: son fichier de configuration principal NFS, tous exportés des dossiers et catalogues, qui sont définis dans ce fichier et sur serveur NFS de destination.
2. /etc/fstab: À monter Répertoire NFS sur votre système sans redémarre, nous devons écrire à /etc/fstab.
3. /etc/sysconfig/nfs: Fichier de configuration NFS pour contrôler quel port RPC et autres prestations auditions.

Configurer et monter NFS sur un serveur Linux

Pour configurer une monture NFS, nous aurons besoin d'au moins deux voitures linux/Unix. Ici, dans ce tutoriel, nous allons utiliser deux serveurs.

1. Serveur NFS: nfsserver.example.ru avec IP - 192.168.0.55
2. Client NFS: nfsclient.example.ru avec IP - 192.168.0.60

Installation du serveur NFS et du client NFS

Nous devons installer des packages NFS sur notre Serveur NFS et aussi en voiture Client NFS. Nous pouvons le définir avec " " ( chapeau rouge Linux) et le package d'installation " apt-get” (DebianName et ubuntu).

# yum install nfs-utils nfs-utils-lib # yum install portmap (non requis avec NFSv4) # apt-get install nfs-utils nfs-utils-lib

Courez maintenant prestations de service sur les deux machines.

# /etc/init.d/portmap start # /etc/init.d/nfs start # chkconfig --level 35 portmap on # chkconfig --level 35 nfs on

Après avoir installé les packages et démarré les services sur les deux machines, nous devons configurer les deux machines pour partager des fichiers.

Configurer un serveur NFS

Configurons d'abord le serveur NFS.

Mise en place d'un répertoire d'export

# mkdir /nfsshare

Maintenant, nous devons écrire à " /etc/exports" et redémarrage services pour rendre notre répertoire partagé sur le réseau.

# vi /etc/exports /nfsshare 192.168.0.60(rw,sync,no_root_squash)

Dans l'exemple ci-dessus, il y a un répertoire sous / intitulé " partage nfs", actuellement partagé avec l'IP du client" 192.168.0.60 ” avec privilèges la lecture et enregistrements (RW), vous pouvez aussi utiliser nom d'hôte client à la place IP dans l'exemple ci-dessus.

Options NFS

Quelques autres options que nous pouvons utiliser dans les fichiers " /etc/exports” pour le partage de fichiers est la suivante.

1. ro: Avec cette option, nous pouvons fournir accès en lecture seule aux fichiers partagés, c'est-à-dire client ne pourra que lire.
2. rw: Cette option permet client vers serveur accès pour les deux la lecture et enregistrements au sein de l'annuaire général.
3. synchroniser: La synchronisation accuse réception des requêtes vers le répertoire partagé uniquement après changements ont été commis.
4. no_subtree_check: Cette option empêche la vérification sous-arbre. Lorsque le répertoire partagé est un sous-répertoire d'un système de fichiers plus grand, NFS effectue une analyse de chaque répertoire au-dessus de lui pour vérifier ses autorisations et ses détails. Désactiver la validation sous-arbre peut améliorer la fiabilité NFS, mais réduire Sécurité.
5. no_root_squash: Cette phrase permet racine, connecter vers un dossier spécifique.

Pour plus d'options avec " /etc/exports», il est recommandé de lire pages guides pour exportation.

Configuration d'un client NFS

Après réglage NFS-serveur, nous avons besoin monter ce répertoire partagé ou cette partition sur client serveur.

Montage de répertoires partagés sur un client NFS

Maintenant sur Client NFS, nous avons besoin monter ce répertoire pour y accéder localement. Pour ce faire, nous devons d'abord savoir quelles ressources sont disponibles sur le serveur distant ou NFS.

# showmount -e 192.168.0.55 Exporter la liste pour 192.168.0.55 : /nfsshare 192.168.0.60

Monter un répertoire accessible sur NFS

Afin de monter général NFS répertoire, nous pouvons utiliser la commande mount suivante.

# mount -t nfs 192.168.0.55:/nfsshare /mnt/nfsshare

La commande ci-dessus définira le répertoire partagé sur " /mnt/nfsshare” sur le serveur client. Vous pouvez le tester avec la commande suivante.

# monter | grep nfs sunrpc sur /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) nfsd sur /proc/fs/nfsd type nfsd (rw) 192.168.0.55:/nfsshare sur /mnt type nfs (rw,addr=192.168.0.55)

La commande mount ci-dessus se monte sur Répertoire partagé NFS au Client NFS temporairement pour monter un répertoire NFS en permanence sur votre système indépendamment des redémarrages, nous devons faire une entrée dans " /etc/fstab“.

#vi /etc/fstab

Ajoutez ce qui suit nouvelle ligne comme indiqué ci-dessous.

192.168.0.55:/nfsshare /mnt nfs par défaut 0 0

Test du comportement d'une installation NFS

Nous pouvons tester notre installation d'un serveur NFS en créant fichier d'essai côté serveur et vérifier son existence sur Client NFS côté ou vice versa.

nfsserver côté serveur

Nous avons créé un nouveau fichier texte nommé " nfstest.txt” dans ce répertoire partagé.

# cat > /nfsshare/nfstest.txt Ceci est un fichier de test pour tester le fonctionnement de la configuration du serveur NFS.

nfsclient côté client

Accédez au répertoire partagé à serveur client et vous trouverez le fichier partagé sans aucune mise à jour manuelle ou service de rechargement.

# ll /mnt/nfsshare total 4 -rw-r--r-- 1 root root 61 Sep 21 21:44 nfstest.txt [courriel protégé]~]# cat /mnt/nfsshare/nfstest.txt Ceci est un fichier de test pour tester le fonctionnement de la configuration du serveur NFS.

Suppression d'un montage NFS

Si tu veux démonter ce répertoire partagé du serveur une fois que vous avez terminé avec le partage de fichiers, vous pouvez simplement démonter ce répertoire particulier avec la commande " démonter“. Voir cet exemple ci-dessous.

[courriel protégé]~]# démonter /mnt/nfsshare

Vous pouvez voir que le montage a été supprimé sur le système de fichiers.

# df -h -F nfs

Vous verrez que ces répertoires partagés ne sont plus disponibles.

Commandes importantes pour NFS

Quelques commandes plus importantes pour NFS .

1. showmount -e: Spectacles disponibles objets partagés sur ordinateur local
2. showmount -e : Liste des disponibles objets partagés au télécommande serveur
3. showmount -d: Liste de tous sous-répertoires
4. exportfs -v: Affiche une liste des partages des dossiers et options sur le serveur
5. exportfs -a: Exporter tous les objets disponibles listés dans /etc/exports, ou nom
6. exportfs -u: Réexporte tous les objets disponibles listés dans /etc/exports, ou nom
7. exportfs -r: Mettre à jour la liste des serveurs après modification /etc/exports

C'est a propos de Montage NFS pour le moment, si vous êtes intéressé, vous pouvez lire le guide sur . Laisser votre

#image.jpg Passez un bon moment, lecteurs et invités de mon blog. Il y a eu une très longue pause entre les messages, mais je suis de retour au combat). Dans l'article d'aujourd'hui, je vais regarder fonctionnement du protocole NFS, aussi bien que configuration du serveur NFS et du client NFS sous Linux.

Présentation de NFS

NFS (Système de fichiers réseau- système de fichiers réseau) à mon avis - solution parfaite dans réseau local, où vous avez besoin d'un échange de données rapide (plus rapide que SAMBA et moins gourmand en ressources par rapport aux systèmes de fichiers distants avec cryptage - sshfs, SFTP, etc...) et la sécurité des informations transmises n'est pas au premier plan. Protocole NFS vous permet de monter des systèmes de fichiers distants sur le réseau dans une arborescence de répertoires locaux comme s'il s'agissait d'un système de fichiers sur disque.

Ainsi, les applications locales peuvent fonctionner avec le système de fichiers distant comme avec le système local. Mais il faut être prudent (!) avec configuration de NFS, car avec une certaine configuration, vous pouvez suspendre le système d'exploitation client en attendant des E/S sans fin.

Protocole NFS basé sur le travail Protocole RPC, ce qui dépasse encore ma compréhension)) donc le contenu de l'article sera un peu vague ... Avant de pouvoir utiliser NFS, que ce soit un serveur ou un client, vous devez vous assurer que votre noyau prend en charge le fichier NFS système. Vérifiez si le noyau prend en charge système de fichiers NFS peut être fait en recherchant les lignes correspondantes dans le fichier /proc/filesystems :

ARCHIV ~ # grep nfs /proc/filesystems nodev nfs nodev nfs4 nodev nfsd

S'il n'y a pas de lignes indiquées dans le fichier /proc/filesystems, vous devez installer les packages décrits ci-dessous. Cela permettra très probablement d'installer des modules de noyau dépendants pour prendre en charge les systèmes de fichiers appropriés.

Si, après l'installation des packages, le support NFS n'est pas affiché dans le fichier désigné, il sera alors nécessaire de recompiler le noyau pour activer cette fonctionnalité.

Histoire Système de fichiers réseau

Protocole NFS développé par Sun Microsystems et a quatre versions dans son histoire. NFSv1 a été développé en 1989 et était expérimental, fonctionnant sur le protocole UDP. La première version est décrite dans la RFC 1094.

NFSv2 est sorti la même année 1989, était décrit par la même RFC1094 et était également basé sur le protocole UDP, tout en permettant la lecture d'au moins 2 Go à partir d'un fichier. NFSv3 a été finalisé en 1995 et décrit dans la RFC 1813.

Les principales innovations de la troisième version étaient la prise en charge des fichiers volumineux, l'ajout de la prise en charge du protocole TCP et des gros paquets TCP, ce qui a considérablement accéléré les performances de la technologie. NFSv4 a été finalisé en 2000 et décrit dans la RFC 3010, révisé en 2030 et décrit dans la RFC 3530.

La 4e version comprenait des améliorations de performances, la prise en charge de divers outils d'authentification (en particulier, Kerberos et LIPKEY avec l'implémentation du protocole RPCSEC GSS) et des listes de contrôle d'accès (types POSIX et Windows). La version NFS v4.1 a été approuvée par l'IESG en 2010 et a reçu la RFC 5661.

La principale innovation de la version 4.1 est la spécification pNFS - Parallel NFS, un mécanisme d'accès parallèle d'un client NFS aux données de plusieurs serveurs NFS distribués. La présence d'un tel mécanisme dans un exemple de système de fichiers réseau aidera à construire des systèmes de stockage et d'information "cloud" ("cloud") distribués.

Serveur NFS

Depuis que nous avons NFS- c'est réseau système de fichiers, vous devez configurer réseau sous linux. (Vous pouvez aussi lire l'article les grands concepts des réseaux). Ensuite, vous devez installer le package approprié. Sur Debian, il s'agit des packages nfs-kernel-server et nfs-common, sur RedHat, il s'agit du package nfs-utils.

Et aussi, il est nécessaire d'autoriser le lancement du démon à des niveaux d'exécution appropriés (la commande dans RedHat est /sbin/chkconfig nfs on, dans Debian - /usr/sbin/update-rc.d nfs-kernel-server defaults).

Les packages installés dans Debian sont exécutés dans l'ordre suivant :

ARCHIV ~ # ls -la /etc/rc2.d/ | grep nfs lrwxrwxrwx Racine racine unique 20 octobre 18 15:02 S15nfs-common -> ../init.d/nfs-common lrwxrwxrwx Racine racine unique 20 sept 20 octobre deux 01:23 S16nfs-kernel-server -> ../init .d/nfs-kernel-server

En d'autres termes, première exécution nfs-commun, plus tard le serveur lui-même nfs-kernel-server.

Dans RedHat, la situation est similaire, à la seule exception que le 1er script est appelé nfslock, et le serveur s'appelle simplement nfs. Pro nfs-commun Le site debian nous dit littéralement ceci : fichiers communs pour le client et le serveur NFS, ce paquet doit être installé sur la machine qui fonctionnera comme client ou serveur NFS.

Le package comprend des programmes : lockd, statd, showmount, nfsstat, gssd et idmapd. Après avoir examiné le contenu du script de démarrage /etc/init.d/nfs-common, vous pouvez suivre la séquence de travail suivante : le script vérifie la présence du fichier binaire exécutable /sbin/rpc.statd, vérifie la présence dans les fichiers /etc/default/nfs-common, /etc/fstab et /etc/exports traits nécessitant l'exécution d'imps idmapd et gssd, démarre le démon /sbin/rpc.statd, puis avant de démarrer /usr/sbin/rpc.idmapd et /usr/sbin/rpc.gssd vérifie ces exécutables fichiers binaires, puis pour le démon /usr/sbin/rpc.idmapd vérifie la présence des modules du noyau sunrpc, nfs et nfsd, ainsi que la prise en charge du système de fichiers rpc_pipefs dans le noyau (en d'autres termes, sa présence dans le /proc/ filesystems file), si tout est réussi, il démarre /usr/sbin/rpc.idmapd. De plus, pour un démon /usr/sbin/rpc.gssd vérifie le module de noyau rpcsec_gss_krb5 et démarre l'imp.

Si vous visualisez le contenu Script de démarrage du serveur NFS sous Debian (/etc/init.d/nfs-kernel-server), on peut tracer la séquence suivante : au démarrage, le script vérifie l'existence du fichier /etc/exports, la présence du module noyau nfsd, le présence du support du système de fichiers NFS dans le noyau Linux (autrement dit dans le fichier /proc/filesystems), si tout est en place, alors le démon démarre /usr/sbin/rpc.nfsd, puis vérifie si le paramètre NEED_SVCGSSD est défini (défini dans le fichier d'options du serveur /etc/default/nfs-kernel-server) et, s'il est défini, démarre le démon /usr/sbin/rpc.svcgssd, dernier lance le démon /usr/sbin/rpc.mountd. Ce script montre que Le fonctionnement d'un serveur NFS consiste en démons rpc.nfsd, rpc.mountd et si l'authentification Kerberos est utilisée, alors aussi démon rcp.svcgssd. Le démon rpc.rquotad et nfslogd fonctionnent toujours dans le chapeau rouge (Dans Debian, pour une raison quelconque, je n'ai pas trouvé d'informations sur ce démon et les raisons de son absence, apparemment supprimées ...).

A partir de là, il devient clair que le serveur Network File System se compose des processus suivants (lecture - démons) situés dans les répertoires /sbin et /usr/sbin :

• rpc.statd- Bes surveillant l'état du réseau (alias Network Status Monitor, alias NSM). Il vous permet d'annuler correctement le verrouillage après un crash / redémarrage. Il utilise le programme /usr/sbin/sm-notify pour signaler les violations. Bes statd fonctionne à la fois sur les serveurs et sur les clients. Auparavant, ce serveur était nécessaire pour que rpc.lockd fonctionne, mais maintenant le noyau est responsable des verrous (note : si je ne me trompe pas #image.jpg). (Programme RPC 100 mille 20 un et 100 mille 20 quatre - dans les nouvelles versions)
• rpc.lockd- Bes lockd lockd (également appelé gestionnaire de verrouillage NFS (NLM)) gère les demandes de verrouillage de fichiers. Le blocage Bes fonctionne à la fois sur les serveurs et sur les clients. Les clients demandent un verrou de fichier et les serveurs l'accordent. (obsolète et non utilisé comme démon dans les nouvelles distributions. Ses fonctions dans les distributions modernes (avec un noyau antérieur à 2.2.18) sont assurées par le noyau, plus précisément par le module noyau (lockd).) (programme RPC 100024)
• rpc.nfsd- Le démon principal du serveur NFS est nfsd (dans les nouvelles versions, il est parfois appelé nfsd4). Cet imp sert les requêtes des clients NFS. L'option RPCNFSDCOUNT dans le fichier /etc/default/nfs-kernel-server sur Debian et NFSDCOUNT dans le fichier /etc/sysconfig/nfs sur RedHat détermine le nombre d'imps à démarrer (la valeur par défaut est 8). (Programme RPC 100003)
• rpc.mountd- NFS mountd mount gère les demandes des clients pour monter des répertoires. Bes mountd fonctionne sur les serveurs NFS. (programme RPC 100005)
• rpc.idmapd- L'idmapd pour NFSv4 bes sur le serveur convertit l'uid/gid local des utilisateurs au format nom@domaine, et le service sur le client convertit les noms des utilisateurs/groupes sous la forme nom@domaine en identifiants locaux d'utilisateurs et de groupes ( selon le fichier de configuration /etc/idmapd.conf, voir man idmapd.conf pour plus de détails):.
• De plus, les imps étaient utilisés dans les anciennes versions de NFS : nfslogd- Le démon de journalisation NFS capture l'activité des systèmes de fichiers exportés, fonctionne sur les serveurs NFS et coté- le serveur de quotas distant fournit des informations sur les quotas d'utilisateurs dans les systèmes de fichiers distants, peut fonctionner à la fois sur les serveurs et sur les clients (programme RPC 100011)

Dans NFSv4, lors de l'utilisation de Kerberos, des démons sont également lancés :

• rpc.gssd- Bes NFSv4 fournit des méthodes d'authentification via GSS-API (authentification Kerberos). Fonctionne sur client et serveur.
• rpc.svcgssd- Le serveur NFSv4 fournit une authentification client côté serveur.

portmap et protocole RPC (Sun RPC)

Outre les packages ci-dessus, NFSv2 et v3 nécessitent forfait supplémentaire portmap(dans les distributions plus récentes, remplacé par renommé en rpcbind). Forfait actuel généralement installé automatiquement avec NFS comme dépendant et implémente le travail du serveur RPC, en d'autres termes, est responsable de l'attribution dynamique des ports pour certains services enregistrés dans le serveur RPC.

Littéralement, selon la documentation, il s'agit d'un serveur qui convertit les numéros de programme RPC (Remote Procedure Call) en numéros de port TCP/UDP. portmap opère sur plusieurs entités : appels ou requêtes RPC, ports TCP/UDP, version de protocole (tcp ou udp), numéros de programme et versions de programme. Le portmap bes est démarré par le script /etc/init.d/portmap avant le démarrage des services NFS.

En bref, le travail d'un serveur RPC (Remote Procedure Call) est de traiter les appels RPC (procédures dites RPC) des processus locaux et distants.

À l'aide d'appels RPC, les services s'enregistrent ou se retirent du mappeur de port (alias port mapper, alias portmap, alias portmapper, alias, dans les nouvelles versions, rpcbind), et les clients utilisant des appels RPC acheminant les requêtes vers portmapper obtiennent les bonnes informations. Les noms conviviaux des services de programme et leurs numéros correspondants sont définis dans le fichier /etc/rpc.

Lorsqu'un service a envoyé une requête correspondante et s'est enregistré sur le serveur RPC dans le mappeur de ports, le serveur RPC attribue au service TCP et UDP les ports sur lesquels le service a démarré et stocke dans le noyau les informations pertinentes sur le service en cours d'exécution (sur le nom), le numéro de service unique (en accord avec /etc/rpc), le protocole et le port sur lequel le service s'exécute et la version du service, et fournit les informations indiquées aux clients sur demande. Le convertisseur de port lui-même a un numéro de programme (100000), un numéro de version de 2, le port TCP 100 onze et le port UDP 111.

Ci-dessus, lors de la spécification de la composition des démons du serveur NFS, j'ai indiqué les principaux numéros de programme RPC. Je vous ai probablement un peu confondu avec ce paragraphe, je vais donc dire la phrase principale, qui devrait clarifier: la fonction principale du mappeur de port est de lui retourner (le client) le port sur lequel le programme demandé s'exécute. Par conséquent, si un client doit contacter RPC avec un numéro de programme spécifique, il doit d'abord contacter le processus portmap sur la machine serveur et rechercher le numéro de port pour communiquer avec le service RPC dont il a besoin.

Le fonctionnement du serveur RPC peut être représenté par les étapes suivantes :

L'utilitaire rpcinfo est utilisé pour obtenir des informations d'un serveur RPC. Avec -p traits d'hôte, le programme répertorie tous les programmes RPC enregistrés sur l'hôte hôte. Sans spécifier d'hôte, le programme affichera les services sur localhost. Exemple:

ARCHIV ~ # rpcinfo -p programme vers proto port 100k Deux tcp 100 onze portmapper 100k Deux udp 100 onze portmapper 100k 20 quatre Un udp 50 neufk quatre cent 50 un statut 100k 20 quatre Un tcp Sixtyk huit cent 70 deux statut 100k 20 un Un udp 40 fourk trois cents 10 nlockmgr 100k 20 un trois udp 40 fourk trois cents 10 nlockmgr 100k 20 un quatre udp 40 fourk trois cents 10 nlockmgr 100k 20 un un tcp 40 fourk huitième 50 un nlockmgr 100 mille 20 un trois tcp 40 quatre mille huit cents 50 un nlockmgr 100 mille 20 un Quatre tcp 40 quatre mille huit cents 50 un nlockmgr 100 mille trois Deux tcp Deux mille 40 neuf nfs 100 mille trois Trois tcp Deux mille 40 neuf nfs 100 mille trois Quatre tcp Deux mille 40 neuf nfs 100 mille trois Deux udp Deux mille 40 neuf nfs 100 mille trois Trois udp Deux mille 40 neuf nfs 100 mille trois Quatre udp Deux mille 40 neuf nfs 100 mille 5 Un udp 50 mille trois cents 6 mountd 100 mille 5 Un tcp 40 mille quatre cents 5 mountd 100 mille 5 Deux udp 50 mille trois cents 6 mountd 100 mille 5 Deux tcp 40 mille quatre cents 5 mountd 100 mille 5 Trois udp 50 mille trois cents 6 mountd 100 mille 5 Trois tcp 40 mille quatre cents 5 mountd

Comme vous pouvez le voir, rpcinfo répertorie (en colonnes de gauche à droite) le numéro, la version, le protocole, le port et le nom du programme enregistré.

Avec rpcinfo, vous pouvez supprimer l'enregistrement d'un programme ou obtenir des informations sur un service RPC particulier (plus d'options dans man rpcinfo). Comme vous pouvez le voir, les démons portmapper de la version Deux sont enregistrés sur les ports udp et tcp, la version rpc.statd Un sur les ports udp et tcp, les versions 1,3,4 du gestionnaire de verrouillage NFS, la version démon du serveur nfs 2,3,4, comme ainsi que les versions sans monture 1,2,3.

Le serveur NFS (plus précisément le démon rpc.nfsd) reçoit des requêtes du client sous forme de datagrammes UDP sur le port 2049. Malgré le fait que NFS fonctionne avec un convertisseur de port, ce qui permet au serveur d'utiliser des ports attribués dynamiquement, le port UDP 2000 40 neuf est codé en dur sur NFS dans la plupart des implémentations.

Fonctionnement du protocole de système de fichiers réseau

Montage NFS à distance

Le processus de montage d'un système de fichiers NFS distant peut être représenté comme suit :

Description du protocole NFS lors du montage d'un répertoire distant :

1. Un serveur RPC est démarré sur le serveur et le client (généralement au démarrage), maintenu par le processus portmapper et enregistré sur les ports tcp/111 et udp/111.
2. Les services sont démarrés (rpc.nfsd, rpc.statd, etc.), qui sont enregistrés sur le serveur RPC et enregistrés sur random ports réseau(si un port statique n'est pas défini dans les paramètres de service).
3. la commande mount sur l'ordinateur client envoie au noyau une requête pour monter le répertoire réseau indiquant le type de système de fichiers, l'hôte et pratiquement le répertoire, le noyau envoie une requête RPC au processus portmap sur le serveur NFS sur le udp/111 port (si le client n'a pas la fonction de travailler via tcp )
4. Le noyau du serveur NFS interroge le RPC sur la présence de l'imp rpc.mountd et renvoie au noyau client le port réseau sur lequel l'imp s'exécute.
5. mount envoie une requête RPC au port sur lequel rpc.mountd est en cours d'exécution. Actuellement, le serveur NFS peut valider un client en fonction de son adresse IP et de son numéro de port pour voir si ce client peut monter le système de fichiers désigné.
6. Le mount imp renvoie une description du système de fichiers demandé.
7. La commande mount du client émet un appel système mount pour associer le descripteur de fichier obtenu à l'étape 5 à un point de montage local sur l'hôte du client. Le descripteur de fichier est stocké dans le code client NFS et, à partir de ce moment, tout accès par les processus utilisateur aux fichiers du système de fichiers du serveur utilisera le descripteur de fichier comme point de départ.

Echange de données entre client NFS et serveur

L'accès ordinaire à un système de fichiers distant peut être décrit par le schéma suivant :

Description du processus d'accès à un fichier situé sur un serveur NFS :

Configurer un serveur NFS

Réglage du serveur il s'agit essentiellement de spécifier les répertoires locaux autorisés à être montés par des systèmes distants dans le fichier /etc/exports. Cette action s'appelle exportation de la hiérarchie des répertoires. Les principales sources d'informations sur les répertoires exportés sont les fichiers suivants :

• /etc/exports- le fichier de configuration principal qui stocke la configuration des répertoires exportés. Utilisé lors du démarrage de NFS et de l'utilisation de l'utilitaire exportfs.
• /var/lib/nfs/xtab- contient une liste de répertoires montés par des clients distants. Utilisé par le démon rpc.mountd lorsqu'un client essaie de monter une hiérarchie (une entrée de montage est créée).
• /var/lib/nfs/etab- une liste des répertoires pouvant être montés par des systèmes distants, indiquant toutes les fonctionnalités des répertoires exportés.
• /var/lib/nfs/rmtab- liste des répertoires qui ne sont pas non exportés pour le moment.
• /proc/fs/nfsd- un système de fichiers spécial (noyau 2.6) pour gérer un serveur NFS.
• exportations- liste des hiérarchies actives exportées et des clients vers lesquels ils ont été exportés, ainsi que des propriétés. Le noyau obtient ces informations à partir de /var/lib/nfs/xtab.
• fils- contient le nombre de fils (peut également être modifié)
• en utilisant filehandle vous pouvez obtenir un pointeur vers un fichier
• et etc...
• /proc/net/rpc- contient des statistiques "brutes" (brutes), qui peuvent être obtenues à l'aide de nfsstat, ainsi que divers caches.
• /var/run/portmap_mapping- des informations sur les services enregistrés dans RPC

Note: En général, il y a beaucoup d'interprétations et de formulations du but des fichiers xtab, etab, rmtab sur Internet, je ne sais pas qui croire #image.jpg Même sur http://nfs.sourceforge.net/ le l'interprétation n'est pas univoque.

Configuration du fichier /etc/exports

Normalement, le fichier /etc/exports est le seul fichier qui doit être modifié pour la fonction de serveur NFS. Ce fichier contrôle les propriétés suivantes :

• Quels clients peut accéder aux fichiers sur le serveur
• Quelles hiérarchies ? les répertoires sur le serveur sont accessibles par chaque client
• Comment les noms de clients personnalisés seront affiché aux noms d'utilisateur locaux

Peu importe quelle ligne du fichier d'exportation a le format suivant :

point d'exportation client1(fonctions) [client2(fonctions) ...]

Où export_point chemin absolu hiérarchie de répertoires exportée, client1 - n nom d'un ou plusieurs clients ou adresses IP, séparés par des espaces, autorisés à monter export_point. Les fonctions décrire les règles de montage pour le client indiqué avant les options.

Voici l'ordinaire exporte l'exemple de configuration du fichier :

ARCHIV ~ # cat /etc/exports /archiv1 fichiers(rw,sync) 10.0.0.1(ro,sync) 10.0.230.1/24(ro,sync)

À cet exemple les fichiers ordinateurs et 10.0.0.1 sont autorisés à accéder au point d'exportation /archiv1, tandis que l'hôte de fichiers est en lecture/écriture, et l'hôte 10.0.0.1 et le sous-réseau 10.0.230.1/24 ont un accès en lecture seule.

Les descriptions d'hôte dans /etc/exports sont autorisées au format suivant :

• Les noms de nœuds individuels sont décrits comme des fichiers ou files.DOMAIN.local.
• La description du masque de domaine est faite au format suivant : *DOMAIN.local inclut tous les nœuds du domaine DOMAIN.local.
• Les sous-réseaux sont spécifiés sous forme de paires adresse IP/masque. Par exemple : 10.0.0.0/255.255.255.0 inclut tous les hôtes dont les adresses commencent par 10.0.0.
• Spécifier le nom du groupe réseau @myclients qui a accès à la ressource (lors de l'utilisation d'un serveur NIS)

Fonctions générales d'exportation des hiérarchies de catalogue

Le fichier d'exportation utilise les éléments suivants fonctions générales (Tout d'abord, les fonctions utilisées par défaut dans la plupart des systèmes sont indiquées, celles qui ne sont pas par défaut entre parenthèses) :

• auth_nlm (no_auth_nlm) ou alors verrous_sécurisés (verrous_non sécurisés)- spécifie que le serveur doit rechercher l'authentification des demandes de verrouillage (en utilisant le protocole NFS Lock Manager).
• cacher (cacher)- si le serveur exporte deux hiérarchies de répertoires, l'une imbriquée (montée) dans l'autre. Le client doit, bien sûr, monter la deuxième hiérarchie (enfant), sinon le point de montage de la hiérarchie enfant ressemblera à un répertoire vide. La fonction nohide donne une deuxième hiérarchie de répertoires sans montage trivial. (remarque : je cette option impossible de le faire fonctionner...)
• ro(rw)- Autorise uniquement les requêtes de lecture (écriture). (En fin de compte, s'il peut être lu/écrit ou non est déterminé en fonction des autorisations du système de fichiers, tandis que le serveur n'est pas en mesure de faire la distinction entre une demande de lecture de fichier et une demande d'exécution, il permet donc la lecture si l'utilisateur a lu ou exécuté autorisations.)
• sécurisé (non sécurisé)- demande que les requêtes NFS proviennent de ports sécurisés (< 1024), чтобы программа без droits root impossible de monter la hiérarchie des répertoires.
• sous-arbre_vérification (pas de_sous-arbre_vérification)- Si un sous-répertoire du système de fichiers est exporté, mais pas le système de fichiers entier, le serveur vérifie si le fichier demandé se trouve dans le sous-répertoire exporté. La désactivation de la vérification réduit la sécurité mais augmente la vitesse de transfert des données.
• synchronisation (asynchrone)- spécifie que le serveur ne doit répondre aux requêtes qu'après que les configurations effectuées par ces requêtes ont été écrites sur le disque. La fonction async indique au serveur de ne pas attendre que les informations soient écrites sur le disque, ce qui augmente les performances mais réduit la fiabilité. en cas de rupture de connexion ou de panne d'équipement, des informations peuvent être perdues.
• wdelay (no_wdelay)- ordonne au serveur de retarder l'exécution des demandes d'écriture si une demande d'écriture ultérieure est en attente, en écrivant les données dans des blocs plus grands. Cela améliore les performances lors de l'envoi de grandes files d'attente de commandes d'écriture. no_wdelay spécifie de ne pas retarder l'exécution de la commande d'écriture, ce qui peut être utile si le serveur reçoit un nombre illimité de commandes sans rapport.

Exportez les liens symboliques et les fichiers de périphérique. Lors de l'exportation d'une hiérarchie de répertoires contenant des liens symboliques, l'objet lien doit être disponible pour le système client (distant), en d'autres termes, l'une des règles suivantes doit être vraie :

• l'objet lien doit exister sur le système de fichiers client
• vous devez exporter et monter l'objet lien

Le fichier de périphérique fait référence à l'interface du noyau Linux. Lorsque vous exportez un fichier de périphérique, cette interface est exportée. Si le système client n'a pas de périphérique du même type, le périphérique exporté ne fonctionnera pas.

Sur le système client, lors du montage d'objets NFS, l'option nodev peut être utilisée afin que les fichiers de périphérique dans les répertoires montés ne soient pas utilisés.

Les fonctions par défaut sur différents systèmes peuvent varier, elles peuvent être trouvées dans le fichier /var/lib/nfs/etab. Après avoir décrit le répertoire exporté dans /etc/exports et redémarré le serveur NFS, toutes les fonctions manquantes (lire : fonctions par défaut) seront reflétées dans le fichier /var/lib/nfs/etab.

Fonctions d'affichage (correspondant) des ID utilisateur

Pour une meilleure compréhension de ce qui suit, je vous conseille de lire l'article Gestion des utilisateurs Linux. Chaque utilisateur Linux a son propre UID et GID maître, qui sont décrits dans les fichiers /etc/passwd et /etc/group.

Le serveur NFS suppose que le système d'exploitation de l'hôte distant a authentifié les utilisateurs et leur a attribué l'UID et le GID corrects. L'exportation de fichiers donne aux utilisateurs du système client le même accès à ces fichiers que s'ils se connectaient directement au serveur. Ainsi, lorsqu'un client NFS envoie une requête à un serveur, le serveur utilise l'UID et le GID pour identifier l'utilisateur sur le système local, ce qui peut entraîner certains problèmes :

Les fonctions suivantes définissent les règles d'affichage des utilisateurs distants dans les utilisateurs locaux :

Exemple d'utilisation d'un fichier de mappage utilisateur :

ARCHIV ~ # cat /etc/file_maps_users # Mappage des utilisateurs # remote local comment uid 0-50 Mille deux # mappage des utilisateurs avec l'UID distant 0-50 à l'UID local Mille deux gid 0-50 Mille deux # mappage des utilisateurs avec /span GID distant 0-50 vers GID local 1002

Gestion du serveur NFS

Le serveur NFS est géré à l'aide des utilitaires suivants :

• nfsstat
• showmsecure (non sécurisé)out
• exportfs

nfsstat : statistiques NFS et RPC

L'utilitaire nfsstat permet de visualiser les statistiques des serveurs RPC et NFS. Les fonctions de commande peuvent être visualisées dans man nfsstat.

showmount : affiche des informations sur l'état de NFS

utilitaire showmount interroge le rpc.mountd imp sur l'hôte distant pour les systèmes de fichiers montés. Par défaut, une liste triée de clients est renvoyée. Clés:

• --tous- une liste de clients et de points de montage est donnée, indiquant où le client a monté le répertoire. Ces informations peuvent ne pas être fiables.
• --répertoires- liste des points de montage
• --exportations- une liste des systèmes de fichiers exportés est donnée sur la base des croyances de nfsd

L'exécution de showmount sans arguments imprimera sur la console des informations sur les systèmes autorisés à monter local collectes. Par exemple, l'hôte ARCHIV nous fournit une liste de répertoires exportés avec les adresses IP des hôtes autorisés à monter les collections désignées :

FICHIERS ~ # showmount --exports archive Liste d'exportation pour l'archive : /archiv-big 10.0.0.2 /archiv-small 10.0.0.2

Si vous spécifiez un nom d'hôte / IP dans l'argument, des informations sur cet hôte seront affichées :

ARCHIV ~ # fichiers showmount clnt_create: RPC: Programme non enregistré # ce message nous indique que le démon NFSd ne s'exécute pas sur l'hôte FILES

exportfs : gestion des répertoires exportés

Cette commande sert des collections exportées, des données dans un fichier /etc/exports, il serait plus précis d'écrire ne sert pas, mais se synchronise avec le fichier /var/lib/nfs/xtab et supprime ceux qui n'existent pas de xtab. exportfs est effectué au démarrage du démon nfsd avec l'argument -r. L'utilitaire exportfs en mode noyau 2.6 communique avec le démon rpc.mountd via les fichiers du répertoire /var/lib/nfs/ et ne communique pas directement avec le noyau. Sans traits, donne une liste des systèmes de fichiers actuellement exportés.

propriétés exportfs :

• [client:dirname] - ajoute ou supprime le système de fichiers spécifié pour le client spécifié)
• -v - afficher plus d'informations
• -r - réexporte toutes les collections (sync /etc/exports et /var/lib/nfs/xtab)
• -u - supprimer de la liste d'exportation
• -a - ajouter ou supprimer tous les systèmes de fichiers
• -o - fonctions séparées par des virgules (similaire aux options utilisées dans /etc/exports ; ainsi, vous pouvez modifier les fonctions des systèmes de fichiers déjà montés)
• -i - ne pas utiliser /etc/exports lors de l'ajout, uniquement les propriétés de la ligne de commande actuelle
• -f - réinitialise la liste des systèmes exportés dans le noyau 2.6 ;

Client NFS

Avant d'accéder à un fichier sur un système de fichiers distant, le ou les clients doivent le monter et recevoir du serveur pointeur vers celui-ci. Montage NFS peut être fait en utilisant commandes de montage ou avec l'aide de l'un des monteurs automatiques (amd, autofs, automount, supermount, superpupermount). Le processus de montage est parfaitement démontré dans l'illustration ci-dessus.

Au Clients NFS aucun démon n'a besoin de courir, fonctions clients crée le module noyau kernel/fs/nfs/nfs.ko, qui est utilisé lors du montage d'un système de fichiers distant. Les collections exportées depuis le serveur peuvent être installées sur le client des manières suivantes :

• manuellement à l'aide de la commande mount
• automatiquement au démarrage, lors du montage des systèmes de fichiers décrits dans /etc/fstab
• automatiquement en utilisant le démon autofs

Je ne considérerai pas la 3ème méthode avec autofs dans cet article, en raison de sa grande quantité d'informations. Peut-être que dans de futurs articles, il y aura une description séparée.

Montage du système de fichiers réseau avec la commande mount

Un exemple d'utilisation de la commande mount est présenté dans les commandes de gestion des périphériques post-blocage. Ici, je vais regarder un exemple de la commande mount pour monter un système de fichiers NFS :

FICHIERS ~ # mount -t nfs archiv:/archiv-small /archivs/archiv-small FICHIERS ~ # mount -t nfs -o ro archiv:/archiv-big /archivs/archiv-big FICHIERS ~ # mount ..... .. archiv:/archiv-small sur /archivs/archiv-small type nfs (rw,addr=10.0.0.6) archiv:/archiv-big sur /archivs/archiv-big type nfs (ro,addr=10.0.0.6)

La 1ère commande monte le répertoire exporté /archiv-small sur le serveur d'archivage au point de montage local /archivs/archiv-small avec les options par défaut (c'est-à-dire lecture/écriture).

Même si commande de montage dans les distributions récentes, il peut penser au type de système de fichiers utilisé sans spécifier le type, mais spécifier l'option -t nfs est préférable. La 2e commande monte le répertoire /archiv-big exporté sur le serveur d'archivage dans le répertoire local /archivs/archiv-big avec l'option de lecture seule (ro). commande de montage sans traits nous montre clairement le résultat de la monture. Outre la fonction de lecture seule (ro), il peut être possible de spécifier d'autres fonctions principales lors du montage de NFS:

• nosuid- Cette fonction désactive l'exécution des programmes setuid à partir d'un répertoire monté.
• nœudv(pas de périphérique - pas un périphérique) - Cette fonction interdit l'utilisation de fichiers spéciaux de caractères et de blocs en tant que périphériques.
• verrouiller (sans verrou)- Active le verrouillage NFS (par défaut). nolock désactive le verrouillage NFS (ne démarre pas le démon lockd) et est à l'aise avec les anciens serveurs qui ne prennent pas en charge le verrouillage NFS.
• mounthost=nom- Le nom de l'hôte exécutant NFS sans montage est mountd.
• mountport=n - Le port utilisé par le mountd imp.
• port=n- port utilisé pour se connecter au serveur NFS (la valeur par défaut est 2049 si le démon rpc.nfsd n'est pas enregistré sur le serveur RPC). Si n=0 (par défaut), alors NFS envoie une demande au portmap sur le serveur pour trouver le port.
• taille=n(taille de bloc de lecture - taille de bloc de lecture) - Le nombre d'octets lus en une seule fois à partir du serveur NFS. La valeur par défaut est 4096.
• taillew=n(taille du bloc d'écriture - la taille du bloc d'écriture) - Le nombre d'octets écrits en une seule fois sur le serveur NFS. La valeur par défaut est 4096.
• TCP ou alors UDP- Pour monter NFS, utilisez respectivement TCP ou UDP.
• bg- Si vous perdez l'accès au serveur, répétez les vérifications en arrière-plan afin de ne pas bloquer le processus de démarrage du système.
• fg- Si vous perdez l'accès au serveur, répétez les sondes en mode prioritaire. Cette option peut bloquer le processus de démarrage du système par des tentatives de montage. Pour cette raison, le paramètre fg est principalement utilisé à des fins de débogage.

Fonctionnalités affectant la mise en cache des attributs sur les montages NFS

Attributs de fichier, stockés dans des inods (inodes), tels que l'heure de modification, la taille, les liens physiques, le propriétaire, changent généralement occasionnellement pour les fichiers normaux et encore moins souvent pour les répertoires. De nombreux programmes, tels que ls, accèdent aux fichiers en lecture seule et ne modifient pas les attributs ou le contenu des fichiers, mais gaspillent les ressources système dans des opérations réseau coûteuses.

Pour éviter une surcharge inutile de ressources, vous pouvez attributs de données de cache. Le noyau utilise l'heure de modification d'un fichier pour savoir si le cache est obsolète en comparant l'heure de modification dans le cache et l'heure de modification du fichier lui-même. Le cache d'attributs est périodiquement mis à jour en fonction de ces paramètres :

• ac (noac)(cache attrebute - mise en cache des attributs) - Active la mise en cache des attributs (par défaut). Bien que la fonctionnalité noac ralentisse le serveur, elle évite le vieillissement des attributs lorsque plusieurs clients écrivent activement des informations dans une hiérarchie commune.
• acdirmax=n(maximum du fichier de répertoire de cache d'attributs) - Le nombre maximal de secondes que NFS attend avant de mettre à jour les attributs de répertoire (la valeur par défaut est de soixante secondes)
• acdirmin=n(fichier de répertoire de cache d'attribut minimum - mise en cache d'attribut minimum pour le fichier de répertoire) - Petit nombre de secondes que NFS attend avant de mettre à jour les attributs de répertoire (30 secondes par défaut)
• accregmax=n(attribute cache regular file maximum - maximum de mise en cache d'attributs pour un fichier normal) - Le nombre maximal de secondes que NFS attend avant de mettre à jour les attributs d'un fichier normal (la valeur par défaut est de soixante secondes)
• aregmin=n(minimum de fichier régulier de cache d'attribut) - Un petit nombre de secondes que NFS attend avant de mettre à jour les attributs d'un fichier régulier (la valeur par défaut est de trois secondes)
• actimeo=n(délai d'expiration du cache d'attribut) - Remplace les valeurs de toutes les options ci-dessus. Si actimeo n'est pas défini, les valeurs ci-dessus sont par défaut.

Fonctions de gestion des erreurs NFS

Les fonctions suivantes contrôlent ce que NFS fait lorsqu'il n'y a pas de réponse du serveur ou lorsque des erreurs d'E/S se produisent :

• fg (bg)(avant-plan - avant-plan, arrière-plan - arrière-plan) - Créer des sondes de montage NFS en échec au premier plan/arrière-plan.
• dur doux)- imprime le message "serveur ne répond pas" à la console lorsque le timeout est atteint et continue les mount probes. Avec cette fonction doux- à l'expiration du délai, signale une erreur d'E/S au programme qui a appelé l'opération. (il est conseillé de ne pas utiliser l'option logicielle)
• nointr(intr)(pas d'interruption - ne pas interrompre) - N'autorise pas les signaux à interrompre les opérations sur les fichiers dans une hiérarchie de répertoires montée en dur lorsqu'un délai d'attente important est atteint. intr- activer l'interruption.
• retrans=n(valeur de retransmission) - Après n petits délais d'attente, NFS génère un grand délai d'attente (3 par défaut). Un délai d'attente important met fin aux opérations ou affiche un message "le serveur ne répond pas" sur la console, selon que la fonction matérielle/logicielle est spécifiée ou non.
• réessayer=n(valeur de nouvelle tentative) - Nombre de minutes de tentatives de montage NFS avant d'abandonner (par défaut 10 000).
• heureo=n(valeur du délai d'attente) - Le nombre de 10 secondes que le service NFS attend avant de retransmettre en cas de RPC ou de délai d'attente faible (7 par défaut). Cette valeur augmente avec chaque délai d'attente jusqu'à une valeur supérieure de soixante secondes ou jusqu'à ce qu'un délai d'attente important se produise. Si le réseau est occupé, si le serveur est lent ou si la demande passe par plusieurs routeurs ou passerelles, l'augmentation de cette valeur peut améliorer les performances.

Montage NFS automatique au démarrage (description des systèmes de fichiers dans /etc/fstab)

J'ai mentionné la description du fichier /etc/fstab dans l'article correspondant. Dans l'exemple actuel, je vais examiner plusieurs exemples de montage de systèmes de fichiers NFS avec une description des options :

FICHIERS ~ # chat /etc/fstab | archive grep nfs :/archiv-small /archivs/archiv-small nfs rw,timeo=4,rsize=16384,wsize=16384 null null nfs-server:/archiv-big /archivs/archiv-big nfs rw,timeo=50 ,dur,fg Zéro 0

Le 1er exemple monte le système de fichiers /archiv-small de l'archive hôte au point de montage /archivs/archiv-small, le type de système de fichiers est nfs (doit toujours être spécifié pour ce type), le système de fichiers est monté avec l'option lire, écrire (rw) .

L'hôte d'archivage est connecté via une liaison locale rapide, de sorte que le paramètre timeo a été réduit et les valeurs rsize et wsize ont été considérablement augmentées pour améliorer les performances. Les champs des programmes dump et fsck sont définis sur zéro pour empêcher ces programmes d'utiliser un système de fichiers monté sur NFS.

Le deuxième exemple monte le système de fichiers /archiv-big à partir de l'hôte nfs-server. Car nous sommes connectés à l'hôte nfs-server via une connexion lente, le paramètre timeo est augmenté à 5 secondes (50 10 secondes), et le paramètre hard est également codé en dur afin que NFS continue à remonter le système de fichiers après un long délai , le paramètre fg est également défini, de sorte que lorsque le système démarre et que l'hôte nfs-server n'est pas disponible, il ne se bloque pas.

Avant d'enregistrer les configurations dans /etc/fstab, assurez-vous d'essayer de monter manuellement et assurez-vous que tout fonctionne !!!

Amélioration des performances NFS

Plusieurs éléments peuvent affecter les performances de NFS, en particulier lorsque vous travaillez sur des connexions lentes. Lorsque vous travaillez avec des connexions lentes et à charge élevée, il est préférable d'utiliser le paramètre hard afin que les délais d'attente n'empêchent pas les programmes de fonctionner. Mais vous devez considérer que si vous montez le système de fichiers via NFS avec l'option matérielle via fstab et que l'hôte distant n'est pas disponible, le système se bloquera lors du démarrage.

En outre, l'un des moyens les plus simples d'améliorer les performances NFS consiste à augmenter le nombre d'octets transférés à la fois. La taille de quatre mille quatre-vingt-dix 6 b est très petite pour les connexions rapides modernes, en augmentant cette valeur à huit mille 100 quatre-vingt-douze ou plus, on peut expérimentalement trouver la meilleure vitesse.

Aussi, ne négligez pas fonctions de temporisation. NFS attend une réponse pour envoyer des données dans le délai spécifié dans la fonction timeo, si aucune réponse n'est reçue pendant ce délai, un retransfert est effectué.

Mais sur des connexions occupées et lentes, ce temps peut être inférieur au temps de réponse du serveur et à la capacité des canaux de communication, entraînant éventuellement des retransmissions inutiles qui ralentissent les choses.Par défaut, timeo est de 0,7 seconde (700 millisecondes). après aucune réponse dans les 700 ms, le serveur renverra et doublera le délai d'attente à 1,4 s, timeo continuera d'augmenter jusqu'à une valeur supérieure à 60 s. De plus, en fonction du paramètre hard / soft, une action se produira (voir ci-dessus).

Vous pouvez choisir le meilleur timeo pour une valeur spécifique du paquet transmis (valeurs rsize / wsize) à l'aide de la commande ping :

FICHIERS ~ # ping -s 30 deux mille sept cent soixante huit archiv PING archiv.DOMAIN.local (10.0.0.6) 32768(32796) octets de données. 30 deux mille sept cent 70 6 octets de archiv.domain.local (10.0.0.6) : icmp_req=1 ttl=64 time=0.931 ms 30 deux mille sept cent 70 6 octets de archiv.domain.local (10.0.0.6) : icmp_req= 2 ttl=64 time=0.958 ms 30 deux mille sept cent 70 6 octets de archiv.domain.local (10.0.0.6): icmp_req=3 ttl=64 time=1.03 ms 30 deux mille sept cent 70 6 octets de archiv .domain.local (10.0.0.6) : icmp_req=4 ttl=64 time=1.00 ms 30 deux mille sept cents 70 6 octets de archiv.domain.local (10.0.0.6) : icmp_req=5 ttl=64 time=1.08 ms ^C --- archive.DOMAIN.local ping statistiques --- 5 paquets transmis, 5 reçus, 0% de perte de paquets, temps 4006ms rtt min/avg/max/mdev = 0.931/1.002/1.083/0.061 ms

Comme vous pouvez le voir, lors de l'envoi d'un paquet de taille 30 deux mille sept cent soixante huit (32 Ko), son temps de trajet du client au serveur et retour flotte autour d'une milliseconde. Si temps donné sortira de l'échelle pendant 200 ms, alors vous devriez penser à augmenter la valeur de timeo pour qu'elle dépasse de trois à quatre fois la valeur de l'échange. Par conséquent, il est préférable d'effectuer ce test lors d'une forte charge du réseau.

Démarrage de NFS et configuration du pare-feu

La note a été copiée du blog http://bog.pp.ru/work/NFS.html, pour lequel un grand merci à lui !!!

Démarrez le serveur NFS, montez, verrouillez, quota et statut avec les ports "corrects" (pour le pare-feu)

• il est préférable de démonter toutes les ressources sur les clients au préalable
• arrêter et désactiver le démarrage de rpcidmapd si NFSv4 n'est pas prévu : chkconfig --level Trista 40 5 rpcidmapd off service rpcidmapd stop
• si nécessaire, activez les services portmap, nfs et nfslock pour démarrer : chkconfig --levels Trista 40 5 portmap/rpcbind on chkconfig --levels Trista 40 5 nfs on chkconfig --levels Trista 40 5 nfslock on
• si nécessaire, arrêtez les services nfslock et nfs, démarrez portmap/rpcbind, déchargez les modules dont il a besoin pour être exécutés rmmod nfs rmmod nfs_acl rmmod lockd
• ouvrir des ports dans iptables
  • pour RPC : UDP/111, TCP/111
  • pour NFS : UDP/2049, TCP/2049
  • pour rpc.statd : UDP/4000, TCP/4000
  • pour lockd : UDP/4001, TCP/4001
  • pour mountd : UDP/4002, TCP/4002
  • pour rpc.rquota : UDP/4003, TCP/4003
• pour le serveur rpc.nfsd, ajoutez la ligne RPCNFSDARGS="--port 2049" à /etc/sysconfig/nfs
• pour le serveur de montage, ajoutez la ligne MOUNTD_PORT=4002 à /etc/sysconfig/nfs
• pour la fonction rpc.rquota pour les nouvelles versions, vous devez ajouter la ligne RQUOTAD_PORT=4003 à /etc/sysconfig/nfs
• pour la fonction rpc.rquota, il est nécessaire pour les anciennes versions (après tout, vous devez avoir le package quota 3.08 ou un plus récent) ajouter à /etc/services rquotad 4003/tcp rquotad 4003/udp
• vérifier /etc/exports pour la validité
• démarrer les services rpc.nfsd, mountd et rpc.rquota (en même temps rpcsvcgssd et rpc.idmapd sont démarrés si vous pensez à les supprimer) service nfsd start ou dans les versions plus récentes service nfs start
• pour le serveur de verrouillage des nouveaux systèmes, ajoutez les lignes LOCKD_TCPPORT=4001 LOCKD_UDPPORT=4001 à /etc/sysconfig/nfs
• pour un serveur de verrouillage pour les anciens systèmes ajouter directement à /etc/modprobe[.conf] : options lockd nlm_udpport=4001 nlm_tcpport=4001
• lier le serveur d'état rpc.statd au port 4000 (pour les systèmes plus anciens, exécutez rpc.statd avec -p 4000 dans /etc/init.d/nfslock) STATD_PORT=4000
• démarrer les services lockd et rpc.statd service nfslock démarrer
• assurez-vous que tous les ports sont correctement liés avec "lsof -i -n -P" et "netstat -a -n" (certains ports sont utilisés par les modules du noyau que lsof ne voit pas)
• si avant "reconstruction" le serveur était utilisé par des clients et qu'ils n'ont pas pu être démontés, alors vous devrez redémarrer les services de montage automatique sur les clients (am-utils, autofs)

Exemple de configuration de serveur et de client NFS

Configuration du serveur

Si vous souhaitez rendre votre répertoire partitionné NFS ouvert et accessible en écriture, vous pouvez utiliser l'option all_squash dans la composition avec les options anonuid et anongid. Par exemple, pour définir des autorisations pour l'utilisateur "nobody" dans le groupe "nobody", vous pouvez procéder comme suit :

ARCHIV ~ # cat /etc/exports # Accès en lecture/écriture pour le client à 192.168.0.100, avec accès rw pour l'utilisateur Ninety-nine avec gid Ninety-nine /files 192.168.0.100(rw,sync,all_squash,anonuid=99,anongid = 99)) # Accès en lecture et écriture pour le client à 192.168.0.100, avec accès rw pour l'utilisateur Ninety-nine avec gid Ninety-nine /files 192.168.0.100(rw,sync,all_squash,anonuid=99,anongid=99))

Cela signifie également que si vous souhaitez autoriser l'accès au répertoire désigné, personne.nobody doit être le propriétaire du répertoire partagé :

# chown -R personne.personne /fichiers

Configuration des clients

Sur le client, vous devez monter le répertoire distant de manière pratique, par exemple, avec la commande mount :

FICHIERS ~ # mount -t archive nfs :/fichiers /archives/fichiers

Résumé

Ouf... Article terminé. Pour l'instant nous avons étudié qu'est-ce que le système de fichiers réseau et avec quoi on le mange, dans le prochain article j'essaierai de faire un HOWTO avec l'authentification Kerberos. J'espère que le matériel est sorti intelligible et nécessaire.

Je serai heureux de vos ajouts et commentaires!

NFS HOWTO, nfs.sourceforge, man nfs? l'homme monte, l'homme exporte

RFC mille quatre-vingt-quatorze - NFSv1, v2
RFC 1813 - NFSv3
RFC Trois mille 500 30 - NFSv4
RFC 5 mille 600 soixante et un - NFSv4.1
TUTORIEL NFS
nfs.sourceforge.net
monture homme
l'homme exporte

Système de fichiers réseau (NFS)- Protocole d'accès réseau aux systèmes de fichiers, vous permet de connecter des systèmes de fichiers distants.
Initialement développé par Sun Microsystems en 1984. Basé sur Sun RPC : Remote Procedure Call. NFS est indépendant des types de système de fichiers serveur et client. Il existe de nombreuses implémentations de serveurs et de clients NFS pour divers systèmes d'exploitation. NFS v.4 est actuellement utilisé, prenant en charge divers moyens d'authentification (en particulier, Kerberos et LIPKEY utilisant le protocole RPCSEC GSS) et des listes de contrôle d'accès (types POSIX et Windows).
NFS fournit aux clients un accès transparent aux fichiers et au système de fichiers du serveur. Contrairement à FTP, le protocole NFS n'accède qu'aux parties du fichier accédées par le processus, et son principal avantage est de rendre cet accès transparent. De ce fait, toute application cliente pouvant fonctionner avec un fichier local peut tout aussi bien fonctionner avec un fichier NFS, sans modifier le programme lui-même.
Les clients NFS accèdent aux fichiers sur un serveur NFS en envoyant des requêtes RPC au serveur. Cela peut être implémenté à l'aide de processus utilisateur normaux - à savoir, le client NFS peut être un processus utilisateur qui effectue des appels RPC spécifiques au serveur, qui peut également être un processus utilisateur.

Versions
NFSv1 était destiné à un usage interne uniquement à des fins expérimentales. Les détails de mise en œuvre sont définis dans la RFC 1094.
NFSv2 (RFC 1094, mars 1989) fonctionnait à l'origine entièrement sur UDP.
NFSv3 (RFC 1813, juin 1995). Les descripteurs de fichiers dans la version 2 sont un tableau de taille fixe de 32 octets. Dans la version 3, il s'agit d'un tableau de taille variable avec une taille allant jusqu'à 64 octets. Un tableau de longueur variable dans XDR est défini par un nombre de 4 octets suivi d'octets réels. Cela réduit la taille du descripteur de fichier dans des implémentations telles qu'UNIX, où seulement 12 octets environ sont requis, mais permet aux implémentations non-Unix d'échanger des informations supplémentaires.
La version 2 limite le nombre d'octets par procédure READ ou WRITE RPC à 8192 octets. Cette limite n'est pas en vigueur dans la version 3, ce qui signifie qu'en utilisant UDP, la limite sera uniquement la taille IP du datagramme (65535 octets). Cela permet d'utiliser de grands paquets de lecture et d'écriture sur des réseaux rapides.
Les tailles de fichier et les décalages d'octet de début pour les routines READ et WRITE utilisent désormais un adressage 64 bits au lieu de 32 bits, ce qui vous permet de travailler avec des fichiers plus volumineux.
Les attributs du fichier sont renvoyés dans chaque appel pouvant affecter les attributs.
Les écritures (WRITE) peuvent être asynchrones, alors que dans la version 2 elles devaient être synchrones.
Une procédure a été supprimée (STATFS) et sept ont été ajoutées : ACCESS (Vérifier les autorisations du fichier), MKNOD (Créer fichier spécial Unix), READDIRPLUS (renvoie les noms des fichiers d'un répertoire avec leurs attributs), FSINFO (renvoie des informations statistiques sur le système de fichiers), FSSTAT (renvoie des informations dynamiques sur le système de fichiers), PATHCONF (renvoie des informations POSIX.1 sur un file) et COMMIT (valide les écritures asynchrones précédemment effectuées sur le stockage permanent).
Au moment de l'introduction de la version 3, les développeurs ont commencé à utiliser davantage TCP comme protocole de transport. Alors que certains développeurs utilisaient déjà TCP pour NFSv2, Sun Microsystems a ajouté la prise en charge de TCP dans la version 3 de NFS. Cela a rendu l'utilisation de NFS sur Internet plus faisable.
NFSv4 (RFC 3010, décembre 2000, RFC 3530, révisée en avril 2003), influencé par AFS et CIFS, comprenait des améliorations de performances, une haute sécurité et est apparu comme un protocole complet. La version 4 a été la première version développée en collaboration avec l'Internet Engineering Task Force (IETF) après que Sun Microsystems a confié le développement des protocoles NFS. La version v4.1 de NFS a été approuvée par l'IESG en janvier 2010 en tant que RFC 5661. Une nouvelle fonctionnalité importante de la version 4.1 est la spécification de pNFS - Parallel NFS, un mécanisme d'accès client NFS parallèle aux données de plusieurs serveurs NFS distribués. La présence d'un tel mécanisme dans la norme de système de fichiers réseau aidera à construire des systèmes de stockage et d'information distribués "en nuage".

Structure NFS
La structure NFS comprend trois composants à différents niveaux :
La couche application (NFS elle-même) est constituée d'appels de procédure à distance (rpc), qui effectuent les opérations nécessaires avec des fichiers et des répertoires côté serveur.
Les fonctions de la couche de présentation sont assurées par le protocole XDR (eXternal Data Representation), qui est une norme d'abstraction de données multiplateforme. Le protocole XDR décrit une forme de représentation des données unifiée, canonique et indépendante de l'architecture. système informatique. Lors de la transmission de paquets, le client RPC convertit les données locales en forme canonique, et le serveur fait le contraire.
Le service RPC (Remote Procedure Call), qui fournit une demande de procédures distantes par le client et leur exécution sur le serveur, représente des fonctions de niveau session. Connexion des ressources réseau
Procédure de connexion ressource réseau moyen de NFS est appelé "exportation". Le client peut demander au serveur une liste des ressources exportables qu'il présente. Le serveur NFS lui-même ne diffuse pas la liste de ses ressources exportées.
Selon les options spécifiées, la ressource exportée peut être montée (attachée) "en lecture seule", vous pouvez spécifier une liste d'hôtes autorisés à monter, spécifier l'utilisation de RPC sécurisé (secureRPC), etc. L'une des options détermine la méthode de montage : "hard" (hard) ou "soft" (soft).
Avec un montage "hard", le client essaiera de monter le système de fichiers quoi qu'il arrive. Si le serveur est en panne, cela entraînera le blocage de l'ensemble du service NFS, pour ainsi dire : les processus accédant au système de fichiers entreront dans un état d'attente de la fin de l'exécution des requêtes RPC. Du point de vue des processus utilisateur, le système de fichiers ressemblera à un disque local très lent. Lorsque le serveur revient à un état de fonctionnement, le service NFS continue de fonctionner.
Avec un montage logiciel, le client NFS fera plusieurs tentatives pour se connecter au serveur. Si le serveur ne répond pas, le système émet un message d'erreur et arrête toute tentative de montage. Du point de vue de la logique des opérations sur les fichiers, lorsqu'un serveur tombe en panne, un montage logiciel émule une panne de disque local.
Le choix du mode dépend de la situation. Si les données sur le client et le serveur doivent être synchronisées lors d'une défaillance temporaire du service, un montage "hard" est préférable. Ce mode est également indispensable dans les cas où les systèmes de fichiers montés contiennent des programmes et des fichiers indispensables au fonctionnement du client, en particulier pour les machines sans disque. Dans d'autres cas, en particulier lorsqu'il s'agit de systèmes en lecture seule, le mode de montage souple semble être plus pratique.

Partage dans un réseau mixte
NFS est idéal pour les réseaux sur Basé sur UNIX, car il est fourni avec la plupart des versions de ce système d'exploitation. De plus, la prise en charge de NFS est implémentée au niveau du noyau UNIX. L'utilisation de NFS sur les ordinateurs clients Windows crée certains problèmes liés à la nécessité d'installer des logiciels clients spécialisés et plutôt coûteux. Dans de tels réseaux, l'utilisation d'outils de partage de ressources basés sur le protocole SMB/CIFS, en particulier le logiciel Samba, semble plus préférable.

Normes
RFC 1094 NFS : spécification du protocole du système de fichiers réseau] (mars 1989)
Spécification du protocole RFC 1813 NFS version 3] (juin 1995)
Schéma d'URL NFS RFC 2224
RFC 2339 Accord entre l'Internet Society, l'IETF et Sun Microsystems, Inc. en matière de protocoles NFS V.4
RFC 2623 NFS Version 2 et Version 3 Problèmes de sécurité et utilisation de RPCSEC_GSS et Kerberos V5 par le protocole NFS
RFC 2624 NFS Version 4 Considérations de conception
Protocole RFC 3010 NFS version 4
Protocole NFS (Network File System) RFC 3530 version 4
RFC 5661 Network File System (NFS) Version 4 Version mineure 1 Protocole

Sources utilisées
1. fr.wikipedia.org
2. fr.science.wikia.com
3.phone16.ru
4.4stud.info
5.yandex.ru
6.google.com

Network File System NFS, ou Network File System, est un protocole de système de fichiers réseau populaire qui permet aux utilisateurs de monter des répertoires réseau distants sur leur machine et de transférer des fichiers entre serveurs. Vous pouvez utiliser l'espace disque d'une autre machine pour vos fichiers et travailler avec des fichiers situés sur d'autres serveurs. En fait, c'est une alternative au général Accès Windows pour Linux, contrairement à Samba, il est implémenté au niveau du noyau et fonctionne de manière plus stable.

Cet article couvrira l'installation de nfs sur Ubuntu 16.04. Nous analyserons l'installation de tous les composants nécessaires, la configuration d'un dossier partagé, ainsi que la connexion des dossiers réseau.

Comme déjà mentionné, NFS est un système de fichiers réseau. Pour fonctionner, vous avez besoin d'un serveur qui hébergera le dossier partagé et des clients qui pourront monter le dossier réseau en tant que disque normal dans le système. Contrairement à d'autres protocoles, NFS fournit un accès transparent aux fichiers distants. Les programmes verront les fichiers comme dans un système de fichiers normal et travailleront avec eux comme des fichiers locaux, nfs ne renvoie que la partie demandée du fichier, au lieu du fichier entier, donc ce système de fichiers fonctionnera bien sur les systèmes avec internet rapide ou sur le réseau local.

Installation des composants NFS

Avant de pouvoir travailler avec NFS, nous devrons installer quelques programmes. Sur la machine qui sera le serveur, vous devez installer le package nfs-kernel-server, qui ouvrira les boules nfs dans ubuntu 16.04. Pour ce faire, exécutez :

sudo apt install nfs-kernel-server

Vérifions maintenant si le serveur est correctement installé. Le service NFS écoute les connexions TCP et UDP sur le port 2049. Vous pouvez voir si ces ports sont réellement utilisés en ce moment avec la commande :

rpcinfo -p | grep nfs

Il est également important de vérifier si NFS est pris en charge au niveau du noyau :

cat /proc/filesystems | grep nfs

Nous voyons que cela fonctionne, mais sinon, vous devez charger manuellement le module du noyau nfs :

Ajoutons également nfs au chargement automatique :

sudo systemctl activer nfs

Sur l'ordinateur client, vous devez installer le package nfs-common pour pouvoir travailler avec ce système de fichiers. Vous n'avez pas besoin d'installer les composants du serveur, juste ce package suffira :

sudo apt installer nfs-common

Configurer un serveur NFS dans Ubuntu

Nous pouvons ouvrir l'accès NFS à n'importe quel dossier, mais créons-en un nouveau à cet effet :

client adresse_dossier (options)

L'adresse du dossier est le dossier que vous souhaitez rendre disponible sur le réseau. Client - adresse IP ou adresse réseau à partir de laquelle ce dossier est accessible. Mais les options sont un peu plus compliquées. Considérons certains d'entre eux:

• rw- autoriser la lecture et l'écriture dans ce dossier
• ro- autoriser la lecture seule
• synchroniser- répondre aux requêtes suivantes uniquement lorsque les données sont enregistrées sur le disque (par défaut)
• asynchrone- ne pas bloquer les connexions pendant l'écriture des données sur le disque
• sécurisé- utilisez uniquement les ports inférieurs à 1024 pour la connexion
• peu sûr- utiliser n'importe quel port
• cacher- ne masquez pas les sous-répertoires lors de l'accès à plusieurs répertoires
• root_squash- remplacer les requêtes de root par des requêtes anonymes
• all_squash- rendre toutes les demandes anonymes
• anonyme et anonyme- Spécifie l'uid et le gid pour l'utilisateur anonyme.

Par exemple, pour notre dossier, cette ligne pourrait ressembler à ceci :

/var/nfs 127.0.0.1(rw,sync,no_subtree_check)

Quand tout a été mis en place, il reste à mettre à jour la table d'export NFS :

sudo exportfs -a

Ça y est, l'ouverture des partages nfs dans Ubuntu 16.04 est terminée. Essayons maintenant de configurer le client et essayons de le monter.

Connexion NFS

Nous ne nous attarderons pas sur cette question en détail dans l'article d'aujourd'hui. C'est un sujet assez vaste qui mérite un article séparé. Mais je dirai quelques mots.

Pour monter un dossier réseau, vous n'avez besoin d'aucun client ubuntu nfs, utilisez simplement la commande mount :

sudo mount 127.0.0.1:/var/nfs/ /mnt/

Vous pouvez maintenant essayer de créer un fichier dans le répertoire joint :

Nous examinerons également les systèmes de fichiers montés avec df :

127.0.0.1:/var/nfs 30G 6.7G 22G 24% /min

Pour désactiver ce système de fichiers, il suffit d'utiliser le standard umount :

sudo umount /mnt/

résultats

Dans cet article, la mise en place de nfs ubuntu 16.04 a été envisagée, comme vous pouvez le constater, tout se fait de manière très simple et transparente. La connexion des partages NFS se fait en quelques clics, grâce à commandes standard, et ouvrir des partages nfs dans Ubuntu 16.04 n'est pas beaucoup plus difficile que de se connecter. Si vous avez des questions, écrivez dans les commentaires!

Articles Similaires:

Avant de poursuivre la lecture de ce document, vous devrez établir avec succès telnet entre les machines que vous utiliserez en tant que serveur et client. Si quelque chose ne fonctionne pas, vous devez lire le NET-3 HOWTO et configurer correctement le réseau.

Premier pas

Avant de pouvoir faire quoi que ce soit, nous devons configurer le serveur NFS. Si vous faites partie d'un réseau de facultés ou d'universités, plusieurs serveurs NFS sont probablement configurés. Bien sûr, s'ils vous permettent d'y accéder, et si vous lisez ce document pour accéder à l'un d'entre eux, vous n'avez pas besoin de lire cette section et vous pouvez simplement passer à Installer un client NFS.

Si vous devez configurer une machine non-Linux en tant que serveur, vous devez lire le manuel pour système souhaité pour déterminer comment activer le serveur NFS et exporter le système de fichiers via NFS. La description de la façon de procéder sur différentes plates-formes se trouve dans une section distincte. Une fois que vous avez déterminé ce dont vous avez besoin, vous pouvez continuer à lire la section suivante de ce document. Ou continuez à lire dans cette section, car pour certaines des choses dont je vais parler, peu importe le type de machine que vous utilisez comme serveur.

Si vous êtes pressé, veuillez consulter la section Linux 2.2 avant de continuer à lire ceci.

Ce que vous lirez vous obligera à configurer plusieurs programmes.

Mappeur de port

Portmapper sous Linux est appelé portmap ou rpc.portmap. La page de manuel de mon système indique qu'il s'agit de "Transformer les numéros de port DARPA en appels de programme RPC appropriés". C'est la première faille de sécurité que vous découvrirez en lisant ce document. Une description de la façon de fermer l'un de ces trous se trouve dans la section sur la sécurité, que je vous conseille de lire.

Démarrez le mappeur de ports. Il s'appelle portmap ou rpc.portmap et devrait se trouver dans le répertoire /usr/sbin (il s'appelle rpcbind sur certaines machines). Vous pouvez le démarrer manuellement maintenant, mais il doit être démarré à chaque fois que vous démarrez votre machine, vous devez donc créer/modifier les scripts rc. Le contenu de vos scripts rc est expliqué plus en détail dans la page de manuel init. Ils se trouvent généralement dans les répertoires /etc/rc.d, /etc/init.d ou /etc/rc.d/init.d. S'il existe un script appelé inet, nous le modifierons. Mais ce qui doit y être écrit ou quoi d'autre doit être fait sort du cadre de ce document. Démarrez portmap et vérifiez qu'il s'exécute avec ps aux suivi de rpcinfo -p. C'est fait? Bon.

Une chose. L'accès à distance à votre programme portmapper est déterminé par le contenu de vos fichiers /etc/hosts.allow et /etc/hosts.deny. Si rpcinfo -p ne fonctionne pas mais que votre portmapper est en cours d'exécution, veuillez vérifier les fichiers spécifiés. Voir la section sécurité pour Description détaillée ces fichiers.

mountd et nfsd

Les prochains programmes que nous devons exécuter ensuite sont mountd et nfsd. Mais d'abord, nous allons éditer un autre fichier. Il s'agit du fichier /etc/exports. Disons que je veux que le système de fichiers /mn/eris/local sur la machine eris soit accessible à la machine apollon. Ensuite je dois mettre les lignes suivantes dans le fichier /etc/exports sur la machine eris :

/mn/eris/local apollon(rw)

Les lignes ci-dessus donnent à la machine apollon l'autorisation de lecture/écriture sur le répertoire /mn/eris/local. Au lieu de rw, nous pouvons dire ro qui signifie en lecture seule (si vous ne mettez rien dedans, il sera par défaut en lecture seule. Il y a d'autres options que vous pouvez définir ici, et j'en couvrirai certaines plus tard qui sont correspondant au problème. sécurité. Ils sont tous répertoriés dans la page de manuel des exportations, que vous devriez lire au moins une fois dans votre vie. Il existe également de meilleurs moyens que de répertorier toutes les machines dans le fichier d'exportation. Vous pouvez par exemple utiliser des groupes réseau si vous avez un système NIS (ou NYS) (NIS est également connu sous le nom de YP), et utilisez toujours des caractères génériques de domaines IP et de sous-réseaux comme listes de machines autorisées à monter une telle autorisation complète.

Remarque : Ce fichier d'exportation n'a pas la même syntaxe que les autres systèmes Unix. Ce document comporte une section distincte sur les fichiers d'exportation d'autres systèmes Unix.

Nous sommes maintenant prêts à exécuter les programmes mountd (également appelé rpc.mountd) et nfsd (qui pourrait s'appeler rpc.nfsd). Ces deux programmes lisent les données du fichier d'exportation.

Si vous avez modifié le fichier /etc/exports, vous devez vous assurer que nfsd et mountd savent que le fichier a été modifié. La manière traditionnelle faites ceci;-- est d'exécuter le programme exportfs. De nombreuses distributions Linux n'ont pas le programme exportfs. Si c'est le cas, vous pouvez créer un script comme celui-ci sur votre machine :

#!/bin/ch
killall -HUP /usr/sbin/rpc.mountd
killall -HUP /usr/sbin/rpc.nfsd
écho des systèmes de fichiers réexportés

Enregistrez-le dans un fichier, dites /usr/sbin/exportfs, et n'oubliez pas de chmod a+rx dessus. Maintenant que vous avez modifié votre fichier d'exportation, vous devez exécuter le programme exportfs en tant qu'administrateur.

Vous devez maintenant vérifier que mountd et nfsd sont démarrés correctement. Cela se fait d'abord avec la commande rpcinfo -p. La sortie du programme doit afficher quelque chose de similaire à ce qui suit :

port programme vers proto
100000 2 mappeur de port tcp 111
100000 2 mappeur de ports udp 111
100005 1 udp 745 monté
100005 1 tcp 747 monté
100003 2 udp 2049 nfs
100003 2 tcp 2049 nfs

Comme vous pouvez le voir, portmapper a annoncé ses services et que mountd et nfsd sont en cours d'exécution.

Si vous obtenez le message rpcinfo: can "t contact portmapper: RPC: Remote system error - Connexion refusée, RPC_PROG_NOT_REGISTERED ou quelque chose de similaire à la place, alors portmapper n'est pas en cours d'exécution. Ou vous pouvez avoir quelque chose d'écrit dans /etc/hosts.(allow,deny ) qui empêche le portmapper de répondre, veuillez consulter la section sur la sécurité pour une description détaillée de ces fichiers Si vous recevez un message Aucun programme distant enregistré., soit le portmapper ne veut pas vous parler, soit quelque chose ne va pas Arrêtez nfsd, mountd et portmapper et essayez de redémarrer la séquence de démarrage.

Après avoir vérifié que le portmapper a annoncé des services, vous pouvez également vérifier le fonctionnement avec la commande ps. Portmapper continuera à faire la publicité de ses services même après que les programmes qui étendent ses capacités auront terminé leur travail. Il peut donc être nécessaire de vérifier avec ps si vous pensez que quelque chose ne fonctionne pas.

Bien sûr, vous devrez corriger les fichiers rc de votre système pour démarrer mountd et nfsd au démarrage. Il est très probable que ces scripts existent déjà sur votre machine, et il vous suffit de décommenter la section souhaitée ou d'activer le script au niveau d'exécution souhaité.

Les pages de manuel que vous devriez déjà consulter sont portmap, mountd, nfsd et exports.

Si vous avez tout fait comme je l'ai dit, vous devriez avoir installé tout le nécessaire pour que le serveur NFS fonctionne.

Configuration d'un client NFS

Tout d'abord, vous avez besoin d'un noyau prenant en charge le système de fichiers NFS, soit compilé dans le noyau, soit disponible sous forme de module. Ceci est configuré avant que le noyau ne soit compilé. Si vous n'avez jamais compilé de noyau, vous devrez peut-être lire le Rernel HOWTO et découvrir comment. Si vous utilisez une bonne distribution (comme RedHat) et que vous n'avez jamais expérimenté le noyau ou les modules (et que vous l'avez donc ruiné ;-), alors il est probable que le support nfs soit déjà dans le noyau.

Vous pouvez maintenant, à l'invite de commande de l'administrateur, entrer la commande de montage appropriée et le système de fichiers apparaîtra pour vous. Poursuivant l'exemple de la section précédente, nous souhaitons monter /mn/eris/local depuis la machine eris. Cela se fait avec la commande suivante :

mount -o rsize=1024,wsize=1024 eris:/mn/eris/local /mnt

(Nous reviendrons sur les options rsize et wsize plus tard.) Le système de fichiers est maintenant disponible dans /mnt et vous pouvez y aller et exécuter ls dessus et regarder les fichiers individuels. Vous remarquerez que cette opération n'est pas aussi rapide que sur le système de fichiers local, mais est plus pratique que ftp. Si, au lieu de monter le système de fichiers, la commande mount renvoie l'erreur mount : eris:/mn/eris/local failed, raison donnée par le serveur : autorisation refusée, alors le fichier d'exportation est erroné ou vous avez oublié d'exécuter exportfs après avoir modifié le exportations. Si la commande indique mount clntudp_create : RPC : Programme non enregistré, cela signifie que nfsd ou mountd ne s'exécute pas sur le serveur. Ou vous avez un problème avec les hôtes (autoriser, refuser) mentionnés ci-dessus.

Pour arrêter d'utiliser le système de fichiers, vous pouvez exécuter :

Afin de monter automatiquement le système de fichiers nfs au démarrage, vous devez éditer le fichier /etc/fstab comme d'habitude. Notre exemple nécessite cette ligne :

...
eris:/mn/eris/local/mnt nfs rsize=1024,wsize=1024 0 0
...

C'est à peu près tout ce qu'il faut. Veuillez lire plus loin.

Options de montage

Voici quelques-unes des options que vous devriez considérer immédiatement lorsque vous les ajoutez au fichier de paramètres. Ils contrôlent la façon dont le client NFS gère un arrêt de serveur ou une panne de réseau. L'un des avantages de NFS est qu'il peut gérer ces problèmes avec élégance si vous configurez correctement le client. Il existe deux modes distincts de gestion des erreurs :

Un client NFS signalera une erreur à un programme qui tente d'accéder à un fichier situé sur un système de fichiers monté sur NFS. Certains programmes gèrent assez bien ce type d'erreur, mais la plupart des programmes ne le font pas. Je ne recommande pas d'utiliser cette option, cela peut entraîner des fichiers corrompus et des données perdues. Vous ne devriez surtout pas utiliser cette option pour les lecteurs utilisés pour le courrier si votre courrier signifie quelque chose pour vous.

Un programme qui accède à un fichier sur un système de fichiers monté sur NFS suspendra simplement son exécution lorsque la connexion au serveur est interrompue. Le processus ne peut pas être interrompu ou tué à moins que vous ne spécifiiez explicitement l'option intr. Lorsque le serveur NFS est redémarré, le programme continuera sans être dérangé là où il s'était arrêté. C'est probablement ce dont vous avez besoin. Je recommande d'utiliser les options hard,intr sur tous les systèmes de fichiers montés NFS.

En continuant avec l'exemple précédent, notre entrée fstab ressemblera maintenant à ceci :

# options de type fs du point de montage du périphérique dump fsckorder
...
eris:/mn/eris/local /mnt nfs rsize=1024,wsize=1024,hard,intr 0 0
...

Optimisation NFS

Normalement, si les options rsize et wsize ne sont pas définies, alors NFS lira et écrira dans des blocs de 4096 ou 8192 octets. Certaines combinaisons de noyaux Linux et de cartes réseau ne peuvent pas gérer des blocs aussi volumineux, et cela peut ne pas être optimal. Nous devons donc expérimenter et trouver des valeurs rsize et wsize qui fonctionnent aussi vite que possible. Vous pouvez tester la vitesse de transfert avec des options données avec quelques commandes simples. En exécutant la commande mount ci-dessus et en obtenant un accès en écriture au disque, vous pouvez tester les performances d'écriture séquentielle :

temps jj if=/dev/zero of=/mnt/testfile bs=16k count=4096

Cette commande crée un fichier de 64 Mo rempli de zéros (ce fichier doit être suffisamment volumineux, suffisamment volumineux pour que la mise en cache ne joue pas un rôle significatif dans les performances, utilisez une taille de fichier plus grande si vous disposez de suffisamment de mémoire). Faites cette opération plusieurs fois (5-10 ?) et faites la moyenne des résultats. La valeur résultante est "pass time", c'est-à-dire la valeur qui nous intéresse le plus dans cette expérience. Vous pouvez ensuite mesurer les performances de lecture en relisant le fichier sur votre machine :

heure jj if=/mnt/testfile of=/dev/null bs=16k

effectuer cette opération plusieurs fois et faire la moyenne du résultat. Ensuite, démontez le système de fichiers et montez-le à nouveau avec rsize et wsize augmentés. Ils devraient probablement être des multiples de 1024, et pas plus de 16384 octets, car cela taille maximum bloc de données dans la version 2 de NFS. Juste après le montage avec des valeurs augmentées, accédez au système de fichiers monté et exécutez une commande comme ls, examinez le système de fichiers pour vous assurer que tout va bien. Si les valeurs rsize/wsize sont trop grandes, alors les symptômes sont très inhabituels et pas évidents à 100 %. Un symptôme typique est une liste incomplète de fichiers lors de l'exécution de la commande "ls" et aucun message d'erreur. Ou la lecture de fichiers échoue mystérieusement sans message d'erreur. Une fois que vous avez établi que les valeurs rsize/wsize données fonctionnent, vous pouvez continuer à tester les performances. Différentes plates-formes de serveur ont probablement différentes tailles de bloc optimales. SunOS et Solaris sont généralement considérés comme plus rapides avec une taille de bloc de 4096 octets qu'avec d'autres valeurs.

Les noyaux Linux plus récents (depuis la 1.3) effectuent une prélecture pour les valeurs de rsize supérieures ou égales à la taille de page de la machine. Sur les processeurs Intel, la taille de page est de 4096 octets. La lecture anticipée améliore considérablement les performances de lecture NFS. Ainsi sur les machines avec Processeur Intel vous pouvez utiliser une valeur rsize de 4096 octets.

N'oubliez pas que vous devez modifier /etc/fstab pour utiliser les valeurs rsize/wsize trouvées.

Une astuce pour améliorer les performances d'écriture NFS consiste à désactiver les écritures synchrones sur le serveur. La spécification NFS exige que les demandes d'écriture NFS ne soient pas considérées comme terminées tant que les données ne sont pas écrites sur le support (généralement un disque). Cela limite les performances d'écriture et les écritures asynchrones augmenteront considérablement la vitesse d'écriture NFS. Le démon Linux nfsd n'écrit jamais de manière synchrone car l'implémentation du système de fichiers Linux elle-même ne le permet pas, mais les serveurs s'exécutant sur un autre Systèmes Linux ah, vous pouvez augmenter les performances de cette façon en mettant dans votre fichier d'exportation :

/dir -async,access=linuxbox

ou quelque chose de similaire. Veuillez consulter la page de manuel des exportations sur cette machine. N'oubliez pas non plus que cela augmente le risque de perte de données.

NFS sur des lignes lentes

Les lignes lentes incluent les modems, le RNIS et d'autres connexions longue distance.

Cette section est basée sur la connaissance des protocoles utilisés et non sur des expériences réelles. N'hésitez pas à me dire si vous essayez ceci :-)

La première chose à retenir est que NFS est un protocole lent. L'utilisation de NFS ressemble beaucoup à l'utilisation du protocole kermit pour les transferts de fichiers. C'est lent. Presque tout est plus rapide que NFS. FTP est plus rapide. HTTP est plus rapide. rcp est plus rapide. ssh est plus rapide.

Voulez-vous toujours l'essayer au travail? D'ACCORD.

Les paramètres par défaut pour NFS sont définis sur des lignes assez rapides avec une faible latence. Si vous utilisez ces paramètres pour des lignes à forte latence, cela entraînera des messages d'erreur, des opérations interrompues, le système peut prétendre que les fichiers sont plus courts qu'ils ne le sont réellement et fonctionner étrangement dans d'autres cas.

La première chose que vous devez faire est de ne pas utiliser l'option de montage souple. Cela entraînera le retour des signaux d'erreur au logiciel lors des expirations de délai. La plupart des logiciels courants ne gèrent pas très bien ces erreurs. il bonne façon obtenir des accidents étranges. Utilisez plutôt l'option de montage dur. Lorsque l'option hard est activée, les délais d'attente provoquent des tentatives de reprise sans fin au lieu d'interrompre vos programmes. C'est ce dont vous avez vraiment besoin.

La prochaine chose à faire est d'expérimenter les options de montage timeo et retrans. Ils sont décrits dans la page de manuel nfs(5), en voici un extrait :

timeo=n Valeur en dixièmes de seconde avant envoi
le premier relais après le timeout RPC. Par
par défaut, cette valeur est de 7 dixièmes
secondes. Après le premier délai d'expiration, délai d'expiration
doublé après chaque temporisation jusqu'à
la valeur maximale du délai d'attente sera atteinte
équivaut à 60 secondes, ou il se passera assez
relais, provoquant un timeout important. Puis si
le système de fichiers est monté avec l'option hard, puis
chaque nouveau timeout est cascadé avec
la valeur initiale est deux fois plus grande qu'à
la cascade précédente, en plus de doubler sur
chaque relais. Le délai maximal est toujours
équivaut à 60 secondes. Meilleur dans l'ensemble
les performances peuvent être atteintes
augmentation du délai d'attente lors du montage sur
réseau occupé, à un serveur lent, ou
via plusieurs routeurs.

retrans=n Cette valeur spécifie le nombre de non-base
les délais d'attente et les retransmissions, qui devraient
se produire avant que le délai d'attente principal ne se produise. Par
cette valeur est 3 par défaut.
délai d'attente principal, puis les opérations sur les fichiers soit
sont interrompus ou un message est imprimé sur la console
"le serveur ne répond pas".

En d'autres termes : si la requête n'est pas transmise dans un délai de 0,7 seconde (700 ms), le client NFS réessayera la requête et doublera le délai à 1,4 seconde. Si la réponse n'est pas reçue dans les 1,4 secondes, la demande sera répétée à nouveau et le délai d'attente sera augmenté à 2,8 secondes.

La vitesse de la ligne peut être mesurée à l'aide de la commande ping avec une taille de paquet égale à la valeur définie par les options rsize/wsize.

$ ping -s 8192 lugulbanda
PING lugulbanda.uio.no (129.240.222.99) : 8192 octets de données
8200 octets depuis 129.240.222.99 : icmp_seq=0 ttl=64 time=15.2 ms
8200 octets à partir de 129.240.222.99 : icmp_seq=1 ttl=64 time=15.9 ms
8200 octets depuis 129.240.222.99 : icmp_seq=2 ttl=64 time=14.9 ms
8200 octets depuis 129.240.222.99 : icmp_seq=3 ttl=64 time=14.9 ms
8200 octets à partir de 129.240.222.99 : icmp_seq=4 ttl=64 time=15.0 ms

Statistiques de ping Lugulbanda.uio.no ---
5 paquets transmis, 5 paquets reçus, 0 % de perte de paquets
aller-retour min/moy/max = 14,9/15,1/15,9 ms

Ici, le temps indique combien de temps il faut au paquet ping pour aller et venir vers la machine lugulbanda. 15 ms c'est assez rapide. Lorsque vous travaillez via un modem à 28 000 bauds, vous pouvez vous attendre à environ 4 000 à 5 000 ms, et si la ligne est chargée par quelqu'un d'autre, le temps sera encore plus long, peut-être deux fois. Lorsque ce temps est élevé, on dit qu'il s'agit d'une "latence élevée". En général, pour les paquets plus volumineux et pour les lignes plus occupées, la latence augmentera. Augmentez le timeo en fonction de votre ligne et de votre charge. Et parce que la latence augmente lorsque vous utilisez la ligne pour d'autres choses : même si vous voulez utiliser FTP et NFS en même temps, vous devriez essayer de mesurer le temps de ping lorsque vous utilisez FTP pour transférer des fichiers.

Sécurité et NFS

Je ne suis en aucun cas un expert en sécurité informatique. Mais j'ai un petit conseil pour les soucieux de la sécurité. Mais attention : cette liste n'est en aucun cas une liste complète des problèmes liés à NFS, et si vous pensez être en sécurité une fois que vous avez lu et suivi tout ce que j'ai donné ici, je tiens à vous avertir.

Cette section ne devrait pas vous déranger si vous êtes dans Réseau fermé où vous faites confiance à tous les utilisateurs et personne en qui vous n'avez pas confiance ne peut accéder aux machines du réseau. Par exemple, il ne devrait pas y avoir de connexion commutée au réseau et il ne devrait y avoir aucun moyen de se connecter à un réseau où vous avez des personnes en qui vous n'avez pas confiance. Pensez-vous que je suis paranoïaque ? Je ne suis pas paranoïaque. Ceci est un conseil de sécurité de base. La sécurité nécessite un administrateur attentif et compétent qui sait où trouver des informations sur les problèmes de sécurité actuels et potentiels.

Le principal problème avec NFS est que le client, s'il n'est pas défini, fera confiance au serveur et vice versa. C'est peut-être mauvais. Cela signifie que si l'entrée d'administration du serveur NFS est compromise, l'entrée d'administration de la machine cliente peut également être facilement compromise. Et vice versa. Il existe un ensemble de stratégies policières pour cela, nous y reviendrons plus tard.

Ce que vous devez lire, ce sont les documents consultatifs du CERT relatifs à NFS. La plupart des textes ci-dessous sont liés à des avis rédigés dans des éditions CERT. Voir ftp.cert.org/01-README pour une liste mise à jour des documents consultatifs CERT. Voici quelques documents consultatifs liés à NFS :

CA-91:21.SunOS.NFS.Jumbo.and.fsirand 06/12/91
Vulnérabilité du système de fichiers réseau Sun (NFS)
Microsystèmes Inc. (Soleil) et programmes fsirand. Cette vulnérabilité
disponible dans SunOS 4.1.1, 4.1 et 4.0.3 sur tous
architectures. Correctifs disponibles pour SunOS
4.1.1. Un correctif initial pour SunOS 4.1 NFS est également disponible. Soleil
fournira des correctifs complets pour SunOS 4.1 et SunOS 4.0.3 à une date ultérieure.

CA-94:15.NFS.Vulnérabilités 19/12/94
Ce matériel consultatif fournit des mesures
sécurité pour se prémunir contre certaines failles de sécurité
sur le système de fichiers réseau (NFS). Cet article a été publié en lien avec
augmentation des cas de piratage de machines utilisant des utilitaires pour
piratage à travers les points vulnérables.

CA-96.08.pcnfsd 18/04/96
Ce document décrit les problèmes de sécurité dans le programme pcnfsd.
(également appelé rpc.pcnfsd). Correctif de bogue
attaché.

Sécurité des clients

Du côté client, nous pouvons décider que nous ne voulons pas trop faire confiance au serveur. Cela se fait de plusieurs manières en utilisant les options de montage. Par exemple, nous pouvons désactiver l'exécution de programmes avec le bit suid défini sur un système de fichiers NFS, cela se fait avec l'option de montage nosuid. il une bonne idée et vous devriez l'envisager en utilisant des systèmes de fichiers montés sur NFS. Cela signifie que l'administrateur du serveur ne pourra pas créer de programmes avec le suid admin défini sur le système de fichiers, puis se connecter à la machine cliente en tant qu'utilisateur normal et utiliser le programme avec suid admin pour acquérir également des droits d'administrateur sur la machine cliente. . Nous pouvons également empêcher l'exécution de fichiers sur un système de fichiers monté avec l'option noexec. Mais elle est moins courante que l'option nosuid car le système de fichiers peut contenir au moins quelques scripts ou programmes qui doivent être exécutés. Vous pouvez entrer ces options dans la colonne des options avec les options rsize et wsize, séparées par des virgules.

Sécurité du serveur : nfsd

Côté serveur, nous pouvons décider que nous ne voulons pas faire confiance à l'administrateur client. Nous pouvons le faire en spécifiant l'option root_squash dans le fichier exports :

/mn/eris/local apollon(rw,root_squash)

Désormais, si un utilisateur avec l'UID 0 côté client essaie d'accéder (lecture, écriture, suppression), le serveur de fichiers effectuera une substitution d'UID de l'utilisateur "nobody" sur le serveur. Cela signifie que l'administrateur du client ne être en mesure d'accéder ou de modifier des fichiers que seul l'administrateur du serveur peut modifier ou avoir accès. C'est très bien et vous devriez utiliser l'option root_squash sur tous les systèmes de fichiers exportés. Vous direz que "L'administrateur client peut toujours exécuter le 'su ' pour se connecter en tant que n'importe quel autre utilisateur et accéder et modifier tous les fichiers utilisateur." La réponse à cette question est "Oui, il existe un moyen, et cela fonctionne sous Unix et NFS. Cela a une conclusion importante : tous les fichiers et programmes importants doivent appartenir à l'utilisateur root et non à l'utilisateur bin ou à un autre utilisateur non administrateur, car seul l'administrateur du client ne peut pas accéder en tant qu'administrateur du serveur. Il existe plusieurs autres options similaires dans la page de manuel NFSd, vous pouvez donc décider de ne faire confiance à personne du côté client. Vous avez également la possibilité de tronquer les plages UID et GID. Ceci est décrit dans la page de manuel Linux NFSd.

L'option root_squash est la valeur par défaut pour NFSd sous Linux, utilisez l'option no_root_squash pour accorder aux administrateurs les autorisations d'accès au système de fichiers.

Une autre chose importante à faire est de s'assurer que nfsd vérifie que toutes les requêtes proviennent d'un port privilégié. S'il accepte les demandes de n'importe quel ancien port sur le client, un utilisateur sans privilèges spéciaux peut exécuter un programme facile à obtenir sur Internet. Il peut "parler" le langage du protocole nfs et prétendra que l'utilisateur est l'utilisateur qu'il veut être. NFSD sur Linux effectue cette vérification par défaut, mais pour les autres systèmes d'exploitation, vous devez activer cette vérification vous-même. Cela devrait être décrit dans la page de manuel nfsd de votre système d'exploitation.

Autre chose. N'exportez jamais un système de fichiers pour une machine nommée "localhost" ou 127.0.0.1. Croyez-moi.

Sécurité du serveur : portmapper

Le portmapper de base, en conjonction avec nfsd, a un problème de conception qui permet d'obtenir des fichiers à partir de serveurs NFS sans aucun privilège. Heureusement, le portmapper utilisé par la plupart des distributions Linux est relativement sécurisé contre une telle attaque, et peut être rendu plus sécurisé en configurant une liste d'accès dans deux fichiers.

Toutes les distributions Linux ne sont pas créées égales. Certaines distributions qui semblent modernes n'incluent pas de version sécurisée du programme portmapper, même maintenant, plusieurs années après que ses vulnérabilités ont été connues. Au moins une distribution contient même une page de manuel pour un portmapper plus sécurisé, mais son portmapper n'est en fait pas sécurisé. par le plus la manière facile pour vérifier si votre portmapper est bon ou non, il faut lancer le programme strings(1) et regarder sa sortie pour les fichiers /etc/hosts.deny et /etc/hosts.allow. En supposant que votre portmapper est /usr/sbin/portmap, vous pouvez le vérifier en exécutant la commande suivante : strings /usr/sbin/portmap | grep hôtes. sur ma machine, il a fonctionné avec les résultats suivants:

/etc/hosts.allow
/etc/hosts.deny
@(#) hosts_ctl.c 1.4 94/12/28 17:42:27
@(#) hosts_access.c 1.20 96/02/11 17:01:27

Nous allons d'abord éditer le fichier /etc/hosts.deny. Il doit contenir la ligne

qui refusera l'accès à tout le monde. Puisque cela a refusé l'accès à tout le monde, exécutez rpcinfo -p juste pour vérifier que votre portmapper lit ce fichier et exécute les instructions données. La commande rpcinfo ne doit rien afficher ou renvoyer un message d'erreur. Le redémarrage de portmapper n'est pas nécessaire.

Fermer le portmap pour tout le monde peut être trop drastique, nous allons donc ouvrir à nouveau l'accès en modifiant le fichier /etc/hosts.allow. Mais d'abord, nous devons déterminer ce que nous y mettrons. Ce fichier répertorie toutes les machines qui peuvent accéder à votre portmapper. Parmi les nombreux systèmes exécutant Linux, seules quelques machines ont besoin d'un accès complet pour faire quoi que ce soit. Portmapper sert les services nfsd, mountd, ypbind/ypserv, pcnfsd et "r" tels que uptime et rusers. Parmi ceux-ci, seuls nfsd, mountd, ypbind/ypserv et éventuellement pcnfsd sont importants. Toutes les machines qui ont besoin d'accéder aux services sur votre machine doivent être autorisées à le faire. Disons que l'adresse de la machine est 129.240.223.254 et qu'elle se trouve sur le sous-réseau 129.240.223.0 et qu'elle doit accéder aux services sur votre machine (ces termes sont introduits par le réseau HOWTO, revenez en arrière et rafraîchissez-vous si nécessaire). Pour cela, nous allons écrire dans le fichier hosts.allow

portmap : 129.240.223.0/255.255.255.0

C'est la même que l'adresse réseau que vous donnez avec la commande route et le masque de sous-réseau que vous donnez avec la commande ifconfig. Pour le périphérique eth0 sur cette machine, ifconfig doit afficher

...
eth0 Link encap:10Mbps Ethernet HWadr 00:60:8C:96:D5:56
Adresse inet : 129.240.223.254 Bcast : 129.240.223.255 Masque : 255.255.255.0
UP BROADCAST EN COURS MULTICAST MTU : 1 500 Métrique : 1
Paquets RX : 360315 erreurs : 0 abandonnées : 0 dépassements : 0
Paquets TX :179274 erreurs :0 abandonnées :0 dépassements :0
Interruption : 10 Adresse de base : 0x320
...

et netstat -rn devrait montrer

Table de routage du noyau
Destination Gateway Genmask Flags Metric Ref Use Iface
...
129.240.223.0 0.0.0.0 255.255.255.0 U 0 0 174412 eth0
...

(L'adresse réseau est dans la première colonne).

Les fichiers hosts.deny et hosts.allow sont décrits dans les pages de manuel du même nom.

IMPORTANT : Ne mettez rien d'autre dans ces fichiers que les NUMÉROS IP sur les lignes pour configurer le portmap. La recherche de nom d'hôte peut invoquer une activité portmap, qui invoquera une recherche de nom d'hôte, qui invoquera un portmap, qui invoquera ...

Les choses ci-dessus devraient déclencher votre changement de serveur. Le problème restant est que quelqu'un va pirater l'administrateur (ou démarrer MS-DOS) sur une machine de confiance et utiliser ces privilèges pour envoyer des requêtes à un port sécurisé comme n'importe quel utilisateur qu'il veut être.

NFS et pare-feu

C'est une très bonne idée de pare-feu les ports nfs et portmap sur votre routeur. Nfsd s'exécute sur le port 2049 en utilisant les deux protocoles -- udp et tcp. Portmapper s'exécute sur le port 111, tcp et udp, et mountd s'exécute sur les ports 745 et 747, tcp et udp. Défaut. Vous devez vérifier les numéros de port utilisés à l'aide de la commande rpcinfo -p.

Si vous souhaitez utiliser NFS via le pare-feu, il existe des options pour les nouvelles versions de NFSd et mountd pour les forcer à utiliser des ports non standard qui peuvent être ouverts dans le pare-feu.

Résumé

Si vous utilisez hosts.allow/deny, root_squash, nosuid et les ports privilégiés dans le logiciel portmapper/nfs, vous pouvez éviter bogues connus dans nfs et vous pouvez presque vous sentir en sécurité. Mais encore : lorsqu'un intrus a accès à votre réseau, il peut ajouter des commandes étranges à votre fichier .forward ou à votre boîte aux lettres lorsque /home ou /var/spool/mail est monté en NFS. Pour la même raison, vous ne devez jamais accéder à vos clés PGP privées via nfs. Ou du moins, vous devriez savoir quel est le risque. Et en savoir au moins un peu sur lui.

NFS et portmapper créent un système complexe et il n'est donc pas tout à fait incroyable que de nouveaux bogues soient trouvés, soit dans le cœur du projet, soit dans l'implémentation que nous utilisons. Il peut également y avoir des trous connus que quelqu'un exploite. Mais telle est la vie. Vous devriez au moins lire les newsgroups comp.os.linux.announce et comp.security.announce pour être au courant de ces choses.

Monter la liste de contrôle de dépannage

Cette section est basée sur la liste de contrôle des problèmes de montage, ce document est rédigé par IBM Corp. Je leur suis reconnaissant de l'avoir mis à disposition pour être utilisé dans ce document. Si vous avez un problème pour monter un système de fichiers sur NFS, veuillez vérifier cette liste avant de déposer un rapport de bogue. Chaque élément décrit un problème spécifique et sa solution.

La commande mount n'arrête pas de dire RPC : Programme non enregistré Portmapper est-il en cours d'exécution ?

Correction : exécutez-le.

Mountd est-il en cours d'exécution ?

Correction : exécutez-le.

Nfsd est-il en cours d'exécution ?

Correction : exécutez-le.

Portmapper n'est-il pas autorisé à répondre à vos requêtes avec le fichier /etc/hosts.deny ?

Correction : supprimez la règle du fichier hosts.deny ou ajoutez une règle au fichier hosts.allow afin que portmapper soit autorisé à vous parler.

Le système de fichiers n'est pas exporté ou n'est pas exporté à la demande du client. Correction : Exportez-le

Le système de résolution de noms ne correspond pas à la liste des machines dans les exportations. Par exemple : La liste des ressources exportées spécifie l'exportation de johnmad, mais le nom johnmad se résout en johnmad.austin.ibm.com et le montage est refusé.

Correction : exportez la ressource pour les deux formes du nom de la machine.

Cela se produit également si le client a 2 interfaces avec noms différents pour chacun d'eux et le système de fichiers est exporté pour un seul nom spécifié.

Correction : Exportez les deux interfaces.

Cela peut également se produire si le serveur ne peut pas exécuter les fonctions lookuphostbyname ou lookuphostbyaddr (ce sont des fonctions de bibliothèque) sur le client. Assurez-vous que le client peut exécuter les commandes de l'hôte ; héberger ; et ils pointent tous les deux vers la même voiture.

Correction : corrige le système de résolution de noms.

Le système de fichiers a été monté après le démarrage de NFS (sur ce serveur). Dans ce cas, le serveur exporte le point de montage lui-même, et non le système de fichiers monté. Correction : Arrêtez NFSd, puis redémarrez-le.

Remarque : les clients qui ont déjà été montés sur un point de montage de système de fichiers auront des problèmes pour y accéder après un redémarrage du serveur.

La date est modifiée de manière aléatoire sur une ou les deux machines (cela peut confondre make). Correction : définissez la date correcte.

L'auteur du HOWTO recommande d'utiliser NTP pour la synchronisation d'horloge. Parce qu'il existe des restrictions d'exportation sur US NTP, vous pouvez obtenir NTP pour Debian, Red Hat ou Slackware depuis ftp://ftp.hacktic.nl/pub/replay/pub/linux ou depuis un serveur miroir.

Le serveur n'autorise pas le montage à partir d'un utilisateur appartenant à plus de 8 groupes. Correction : réduisez le nombre de groupes auxquels l'utilisateur appartient ou montez sous le nom d'un autre utilisateur.

Foire aux questions (FAQ)

Ceci est la section Foire Aux Questions (FAQ). Une grande partie est basée sur une vieille FAQ écrite par Alan Cox.

Si vous rencontrez des problèmes pour monter un système de fichiers, veuillez vérifier s'il est décrit dans la section ``Liste de vérification du montage''.

J'obtiens des messages d'erreur ``stale nfs handle (obsolete nfs handle)'' lorsque j'utilise Linux comme serveur nfs. Ceci est dû à un bogue dans l'une des anciennes versions de nfsd. Cela a été corrigé dans nfs-server2.2beta16 et versions ultérieures.

Lorsque j'essaie de monter le système de fichiers, j'obtiens le message
ne peut pas s'enregistrer avec portmap : erreur système lors de l'envoi
(impossible de s'enregistrer avec portmap : erreur système lors de l'envoi)

Vous utilisez probablement le système Caldera. Il s'agit d'un bogue dans les scripts rc. Veuillez contacter Caldera pour un correctif.

Pourquoi ne puis-je pas exécuter un fichier après l'avoir copié sur un serveur NFS ? La raison en est que nfsd met en cache les descripteurs de fichiers ouverts pour améliorer les performances (rappelez-vous qu'il s'exécute dans l'espace utilisateur). Tant que nfsd garde le fichier ouvert (comme dans ce cas, après y avoir écrit), le noyau ne vous laissera pas l'exécuter. Les Nfsd plus récents que les versions du printemps 95 gardent les fichiers ouverts pendant quelques secondes, les plus anciens peuvent garder un fichier ouvert pendant des jours.

Mes fichiers sur NFS sont tous traités en lecture seule Par défaut, NFS Server pour Linux émet tout en lecture seule. Relisez les sections ``Mountd et nfsd"" et ``Exportation des systèmes de fichiers"" ce document, ainsi que des pages de manuel pour ``exports"" et nfsd. Vous devez modifier le fichier /etc/exports.

Je monte un système de fichiers à partir d'un serveur nfs sous linux et pendant que la commande ls est en cours d'exécution, je ne peux ni lire ni écrire de fichiers. Sur le vieux Versions Linux vous devez monter le serveur NFS avec les options rsize=1024,wsize=1024.

Je monte un système de fichiers à partir d'un serveur NFS Linux avec une taille de bloc comprise entre 3500 et 4000 et il plante régulièrement la machine Linux.Ne le faites pas normalement. Cela ne se produit pas avec les versions de noyau 2.0 et 2.2. Il n'y a pas non plus de problème avec les noyaux de la série 2.1.

Linux peut-il faire NFS sur TCP Non

Je reçois bugs étranges lors du montage d'une machine à partir d'une machine Linux. Assurez-vous que votre utilisateur est dans 8 groupes ou moins. Les anciens serveurs en ont besoin.

Lorsque je redémarre ma machine, il se bloque parfois lorsque j'essaie de démonter à partir d'un serveur NFS bloqué. Ne démontez pas des serveurs NFS au redémarrage ou à l'arrêt, ignorez-le simplement, rien ne sera endommagé si vous ne le démontez pas. La commande ressemblera à ceci umount -avt nonfs.

Le client NFS pour Linux est très lent lors de l'écriture sur les systèmes Sun et BSD. Normalement, NFS écrit en mode synchrone (vous pouvez le désactiver si vous ne pensez pas risquer de perdre des données). Pire encore, les noyaux dérivés de BSD ne peuvent pas gérer de petits blocs. Ainsi, lorsque vous écrivez des données 4K à partir d'une machine Linux en paquets de 1K, BSD le fait comme ceci

lire la page en 4K
changer 1K

lire la page en 4K
changer 1K
écrire une page 4K sur le disque
etc...

Lorsque je connecte de nombreux clients à un serveur Linux NFS, ses performances chutent soudainement. Le protocole NFS utilise des paquets UDP fragmentés. Le noyau a une limite sur le nombre de fragments ou de paquets incomplets qui arriveront avant qu'il ne commence à supprimer des paquets. Dans les noyaux de la série 2.2, ceci est configuré au moment de l'exécution via le système de fichiers /proc : /proc/sys/net/ipv4/ipfrag_high_thresh et ipfrag_low_thresh. Dans les noyaux de la série 2.0, ces constantes sont définies au moment de la compilation et sont définies dans .../linux/net/ipv4/ip_fragment.c, IPFRAG_HIGH_THRESH et IPFRAG_LOW_THRESH. Ces options signifient que lorsque la consommation de mémoire des fragments non collectés des paquets UDP atteint la valeur de ``ipfrag_high_thresh"" en octets (par défaut 256K dans les noyaux 2.2.3 et 2.0.36), elle diminuera jusqu'à la valeur de ``ipfrag_low_tresh"" . Cela se fait en jetant des fragments. Cela ressemblera à une perte de paquets presque complète, et si la limite supérieure est atteinte, les performances de votre serveur seront considérablement réduites.

256K suffisent pour servir jusqu'à 30 clients. Si vous avez 60 clients, augmentez cette valeur de 2 fois. Et augmentez également la valeur de la bordure inférieure.

J'utilise Linux 2.2 (ou version ultérieure) avec knfsd et je n'arrive pas à monter mes machines AIX, IRIX, Solaris, DEC-Unix, .... Knfsd prétend implémenter la version 3 de NFS. Ce n'est pas le cas. Il y a une option qui l'empêche de l'annoncer. Utilisez-la. Ou vous pouvez mettre "vers=2" dans la liste des options de montage sur le client.

Ma machine AIX 4 ne peut pas monter mon serveur Linux NFS. Elle rapporte
montage : 1831-011 accès refusé pour le serveur :/dir
monture : 1831-008 abandonnant :
serveur :/répertoire
Les autorisations d'accès au fichier n'autorisent pas l'action spécifiée.

ou quelque chose de similaire. AIX 4.2 utilise des ports réservés (<1024) для NFS. AIX 4.2.1 и 4.3 не ограничены резервированными портами. Также AIX 4.2.1 и 4.3 пытаются произвести монтирование используя версию NFS3, затем NFS/TCP, и только потом NFS/UDP.

Ajout de lignes

nfso -o nfs_use_reserved_ports=1

à la fin du fichier rc.tcpip le forcera à utiliser des ports réservés. (Ce conseil a été envoyé par Brian Gorka).

Exportation de systèmes de fichiers

La façon dont les systèmes de fichiers sont exportés à l'aide de NFS n'est pas entièrement compatible entre les plates-formes. Dans ce cas, Linux et Solaris 2 diffèrent.Cette section répertorie brièvement les manières d'effectuer cette opération sur la plupart des systèmes. Si votre système n'est pas répertorié ici, veuillez consulter les pages de manuel de votre système d'exploitation. Les mots clés sont : nfsd, outil d'administration système, scripts rc, scripts de démarrage, séquence de démarrage, /etc/exports, exportfs. Je vais utiliser un exemple pour l'ensemble de la partition : comment exporter le système de fichiers /mn/eris/local pour une machine apollon avec des autorisations de lecture/écriture.

IRIX, HP-UX, Digital-UNIX, Ultrix, SunOS 4 (Solaris 1), AIX

Ces systèmes d'exploitation utilisent le format d'exportation Sun traditionnel. Dans le fichier /etc/exports écrivez :

/mn/eris/local -rw=apollon

La documentation complète se trouve dans la page de manuel des exportations. Après avoir modifié le fichier, exécutez exportfs -av pour exporter les systèmes de fichiers.

La syntaxe exacte de la commande exportfs varie. Sur certains systèmes d'exploitation, vous pouvez constater que les lignes saisies se lisent comme suit :

/mn/eris/apollon local

ou même comme ça :

Solaris 2

Sun a complètement réinventé la roue avec Solaris 2. C'est donc complètement différent des autres systèmes d'exploitation. Ce que vous devez faire est de modifier le fichier /etc/dfs/dfstab. Vous devez y placer les commandes de partage comme décrit dans la page de manuel share(1M). Grosso modo ces lignes :

share -o rw=apollon -d "Eris Local" /mn/eris/local

Après l'édition, exécutez le programme shareall pour exporter le système de fichiers.

NFS sous Linux 2.2

Comme je l'ai écrit, Linux 2.2.12 est la version actuelle du noyau et cela peut prendre un peu de corvée pour utiliser NFS dessus. Ou pas nécessaire.

Je ne sais pas quel sera le statut de NFS dans Linux 2.4.

Une grande nouveauté de Linux 2.2 est la prise en charge d'un démon nfs dans le noyau appelé knfsd. Cette façon d'implémenter nfsd présente plusieurs avantages, le principal étant la rapidité. Une machine avec Linux 2.2 et knfsd est un serveur nfs solide. Vous pouvez toujours utiliser l'ancien nfsd avec Linux 2.2 et il y a aussi quelques avantages, principalement la simplicité.

Si vous utilisez des sources du noyau ou des packages binaires créés par quelqu'un comme RedHat (6.0 et versions ultérieures), SuSE (6.1 ou versions ultérieures) ou un autre intégrateur système professionnel, ils seront très probablement livrés avec une intégration "knfsd" complète dans le noyau et vous avez gagné pas besoin de s'inquiéter. Dans la plupart des cas. Jusqu'à ce que vous veniez compiler le noyau vous-même. Si vous utilisez un noyau Linux 2.2 normal (au moins 2.2.12), alors knfsd ne fonctionnera pas.

Pour que cela fonctionne vous-même, vous devez obtenir le package knfsd créé par H.J. Lus. Ce paquet est une collection de correctifs et d'utilitaires nécessaires pour les noyaux de la série 2.2 que Lu maintient pendant son temps libre. Vous pouvez l'obtenir depuis le miroir de votre serveur noyau local, ou depuis le serveur principal, sur ftp.kernel.org:/pub/linux/devel/gcc/. Il n'est pas destiné à un usage général. Si vous ne comprenez pas ce package, n'essayez pas de l'utiliser vous-même. Attendez que les packages du noyau soient publiés par votre intégrateur système préféré (par exemple Red Hat, SuSE ou...).

Aussi, s'il vous plaît ne m'envoyez pas de questions sur ce paquet, je ne peux pas vous aider. Je n'ai aucun serveur exécutant knfsd. Si vous trouvez une erreur ou une omission dans la documentation, écrivez-moi, je corrigerai ce document et le publierai à nouveau.

Lisez-vous encore ? D'ACCORD. H.J.Lu envoie des messages sur les nouvelles versions de son paquet à la liste de diffusion linux-kernel. D'autres messages liés à NFS dans la version 2.2 du noyau y sont également envoyés. Lis-les.

Il y a une chose intéressante à dire sur le paquetage knfsd. Il annonce qu'il utilise NFS version 3. Cependant, il ne prend pas en charge cette version. Il existe une option que vous pouvez utiliser pour empêcher un paquet d'annoncer NFS3, ou sur les clients, vous devez spécifier l'option "vers=2" parmi d'autres options de montage.

Client

Le client est très simple. Afin d'obtenir un blocage correct, vous devez avoir compilé, installé et démarré statd (du paquet knfsd) à partir des scripts de démarrage. Fais-le. statd a besoin du répertoire /var/lib/nfs pour fonctionner, sinon il se fermera sans aucun message d'erreur, vous devez donc créer le répertoire avant d'exécuter le programme.

Une fois que statd est en cours d'exécution, vous pouvez utiliser le programme testlk (dans le répertoire tools/locktest) pour tester que le verrouillage de fichiers fonctionne sur les systèmes de fichiers montés NFS. Cela devrait bien fonctionner. Si le programme indique Aucun verrou disponible, cela signifie que statd n'est pas en cours d'exécution.

En fait, vous pouvez également éviter complètement les verrous (notez que je ne vous recommande pas de le faire) en utilisant l'option "nolock" dans la liste des options de montage.

Autant que je sache, c'est tout ce qui est nécessaire pour le travail des clients.

Si vous avez un serveur Sparc ou Alpha NFS, vous constaterez que le client nfs de Linux 2.2 est complètement cassé. La vitesse de transfert vers et depuis le serveur est si mauvaise qu'il est difficile à imaginer. C'est encore pire que sous Linux 2.0. Bien pire. Mais il existe une solution à ce problème. La série de noyaux 2.2 d'Alan Cox (qui sont plus expérimentaux que les noyaux 2.2 normaux fournis par Linus) inclut un correctif qui permet à Linux 2.2 d'améliorer les performances lors de l'exécution de serveurs Alpha et Sparc. Si vous souhaitez utiliser des noyaux corrigés par Alan Cox, vous devriez lire la liste de diffusion linux-kernel et vous devriez savoir où trouver les correctifs requis. Le serveur principal pour ce correctif est http://www.uio.no/~trondmy/src/, au cas où vous voudriez l'essayer avec un noyau normal de la série 2.2. Ce correctif ne sera probablement pas inclus dans Linux 2.4 car il nécessite trop de modifications à apporter au cours du cycle de développement actuel. Attention à Linux 2.5.

trondmy a également des correctifs pour que Linux utilise NFS version 3, ils vous permettront également d'utiliser tcp comme transport au lieu d'UDP. NFSv3 est très bon pour les réseaux avec beaucoup de sauts, et aussi pour les réseaux où la perte de paquets est non nulle ou où la latence est très élevée.

Vous devriez lire la liste de diffusion linux-kernel si vous comptez utiliser ces correctifs, car ils reçoivent de temps en temps des bogues désagréables. Bugs qui corrompent vos fichiers. Alors s'il vous plaît soyez prudent.

Serveur

Le démon du serveur nfs sous Linux 2.2 et versions ultérieures s'appelle "knfsd". Il est difficile à installer. Vous pouvez le personnaliser vous-même ou installer ce que SuSE, Red Hat et d'autres vous proposent sous forme de packages de noyau de la série 2.2. Pardon. Bien que vous puissiez toujours utiliser l'ancien nfsd sous Linux 2.2. Il est lent mais facile à installer.

serveur NFS de disquette

Cette section a été écrite par Ron Peters, [courriel protégé] Il explique comment configurer un serveur NFS lors du démarrage à partir d'une disquette. Cela a été conçu à l'origine pour fournir un accès NFS à un cdrom sur une autre machine non-Linux/UNIX pour installer Linux sur une machine qui n'a pas de cdrom.