JavaScript is required to for searching.
Ignorer les liens de navigation
Quitter l'aperu
Administration d'Oracle Solaris : Services réseau     Oracle Solaris 11 Information Library (Fran├žais)
search filter icon
search icon

Informations document

Préface

Partie I Sujets relatifs aux services réseau

1.  Service réseau (présentation)

2.  Gestion des serveurs cache Web

3.  Services d'horodatage

Partie II Accès aux systèmes de fichiers réseau

4.  Gestion des systèmes de fichiers NFS (présentation)

5.  Administration de système de fichiers réseau (tâches)

6.  Accès aux systèmes de fichiers réseau (référence)

Fichiers NFS

Fichier /etc/default/le

Fichier /etc/nfs/nfslog.conf

Démons NFS

Démon automountd

Démon lockd

Démon mountd

Démon nfs4cbd

Démon nfsd

Démon nfslogd

Démon nfsmapid

Fichiers de configuration et nfsmapid

Règles de priorité

nfsmapid et enregistrements DNS TXT

Vérification du domaine de la version 4 de NFS

Configuration du domaine par défaut de la version 4 de NFS

Informations complémentaires sur nfsmapid

Démon reparsed

Démon statd

Commandes NFS

Commande automount

clear_locks, commande

Commande fsstat

Commande mount

Options mount pour les systèmes de fichiers NFS

Utilisation de la commande mount

Commande umount

Commande mountall

Commande umountall

Commande sharectl

Sous-commande set

Sous-commande get

Sous-commande status

Commande share

Options share non spécifiques aux systèmes de fichiers

Options share spécifiques à NFS

Définition des listes d'accès avec la commande share

Commande unshare

Commande shareall

Commande unshareall

Commande showmount

Commande setmnt

Commande nfsref

Commandes pour le dépannage des problèmes liés à NFS

Commande nfsstat

Commande pstack

Commande rpcinfo

Commande snoop

Commande truss

NFS sur RDMA

Fonctionnement du service NFS

Négociation de version dans NFS

Fonctionnalités de la version 4 de NFS

Annulation et rétablissement du partage d'un système de fichiers dans la version 4 de NFS

Espace de noms du système de fichiers dans la version 4 de NFS

Identificateurs de fichiers volatile de la version 4 de NFS

Récupération d'un client dans la version 4 de NFS

Prise en charge du partage OPEN dans la version 4 de NFS

Délégation dans la version 4 de NFS

Listes de contrôle d'accès (ACL) et nfsmapid dans la version 4 de NFS

Négociation UDP et TCP

Négociation de la taille de transfert de fichiers

Montage des systèmes de fichiers

Effets de l'option -public et des URL NFS lors du montage

Basculement côté client

Terminologie du basculement

Qu'est-ce qu'un système de fichiers répliqué ?

Basculement et verrouillage NFS

Basculement côté client dans la version 4 de NFS

Fichiers volumineux

Fonctionnement de la journalisation du serveur NFS

Fonctionnement du service WebNFS

Fonctionnement de la négociation de sécurité WebNFS

Restrictions WebNFS liées à l'utilisation de navigateur Web

Système NFS sécurisé

RPC sécurisé

Authentification DH

Authentification KERB

Utilisation du RPC sécurisé avec NFS

Fonctionnement des montages miroir

Cas d'utilisation des montages miroir

Montage d'un système de fichiers à l'aide de montages miroir

Démontage d'un système de fichiers recourant à des montages miroir

Fonctionnement des références NFS

Cas d'utilisation des références NFS

Création d'une référence NFS

Suppression d'une référence NFS

Mappes Autofs

Mappe principale Autofs

Point de montage /home

Point de montage /net

Point de montage /nfs4

Mappe directe Autofs

Point de montage /-

Mappe indirecte Autofs

Fonctionnement d'Autofs

Fonctionnement de la navigation par Autofs dans le réseau (mappes)

Démarrage du processus de navigation par autofs (mappe principale)

Processus de montage Autofs

Montage autofs simple

Montage hiérarchique

Démontage autofs

Méthode de sélection par Autofs des fichiers en lecture seule les plus proches pour les clients (plusieurs emplacements)

Autofs et pondération

Variables d'une entrée de mappe Autofs

Mappes faisant référence à d'autres mappes

Mappes Autofs exécutables

Modification de la navigation du réseau par Autofs (modification des mappes)

Comportement par défaut d'Autofs avec les services de noms

Référence Autofs

Autofs et les métacaractères

Esperluette (&)

Astérisque (*)

Autofs et caractères spéciaux

Partie III SLP

7.  SLP (présentation)

8.  Planification et activation de SLP (tâches)

9.  Administration de SLP (tâches)

10.  Intégration des services hérités

11.  SLP (références)

Partie IV Sujets relatifs aux services de messagerie

12.  Services de messagerie (présentation)

13.  Services de messagerie (tâches)

14.  Services de messagerie (référence)

Partie V Sujets relatifs à la mise en réseau série

15.  Solaris PPP 4.0 (Présentation)

16.  Planification de la liaison PPP (tâches)

17.  Configuration d'une liaison PPP commutée (tâches)

18.  Configuration d'une liaison PPP de ligne spécialisée (tâches)

19.  Paramétrage de l'authentification PPP (tâches)

20.  Configuration d'un tunnel PPPoE (tâches)

21.  Résolution des problèmes PPP courants (tâches)

22.  Solaris PPP 4.0 (Référence)

23.  Migration de Solaris PPP asynchrone à Solaris PPP 4.0 (tâches)

24.  UUCP (présentation)

25.  Administration du protocole UUCP (tâches)

26.  UUCP (référence)

Partie VI Utilisation de systèmes distants

27.  Utilisation de systèmes distants (présentation)

28.  Administration du serveur FTP (tâches)

29.  Accès aux systèmes distants (tâches)

Partie VII Sujets relatifs au contrôle des services réseau

30.  Contrôle des performances du réseau (tâches)

Glossaire

Index

Fonctionnement du service NFS

Les sections suivantes décrivent certaines des fonctions complexes du logiciel NFS. Notez qu'une partie de la description des fonctions de cette section s'applique exclusivement à la version 4 de NFS.


Remarque - Si votre système comporte des zones activées et que vous souhaitez utiliser cette fonction dans une zone non globale, reportez-vous au manuel Administration Oracle Solaris : Oracle Solaris Zones, Oracle Solaris 10 Zones et gestion des ressources pour plus d'informations.


Négociation de version dans NFS

Le processus de lancement de NFS inclut la négociation des niveaux de protocole pour les serveurs et les clients. Si vous ne spécifiez pas le niveau de version, le meilleur niveau est sélectionné par défaut. Par exemple, si le client et le serveur prennent en charge la version 3, cette version est utilisée. Si le client ou le serveur ne peut prendre en charge que la version 2, cette version est utilisée.

Vous pouvez définir les paramètres client_versmin , client_versmax, server_versmin et server_versmax à l'aide de la commande sharectl. Les valeurs minimum et maximum spécifiées pour le serveur et le client remplacent les valeurs par défaut de ces mots-clés. Pour le client et le serveur, la valeur minimum par défaut est 2 et la valeur maximale par défaut est 4. Pour trouver la version prise en charge par le serveur, le client NFS commence avec le paramètre de client_versmax et essaie ensuite chaque version jusqu'à atteindre le paramètre de version de client_versmin. Dès que la version prise en charge est trouvée, le processus se termine. Par exemple, si client_versmax =4 et que client_versmin =2, alors le client essaie d'abord la version 4, puis la version 3 et enfin la version 2. Si client_versmax et client_versmin sont définis sur la même valeur, alors le client utilise toujours cette version et n'essaie pas d'autre version. Si le serveur n'offre pas cette version, le montage échoue.


Remarque - Vous pouvez remplacer les valeurs qui sont déterminées par la négociation en utilisant l'option vers avec la commande mount. Reportez-vous à la page de manuel mount_nfs(1M).


Pour des informations sur les procédures à suivre, reportez-vous à la rubrique Configuration des services NFS.

Fonctionnalités de la version 4 de NFS

De nombreuses modifications ont été apportées à NFS dans la version 4. Cette section fournit les descriptions de ces nouvelles fonctionnalités.


Remarque - A partir de la version Solaris 10, la version 4 de NFS ne prend pas en charge la variante de sécurité LIPKEY/SPKM. De plus, la version 4 de NFS n'utilise pas les démons mountd , nfslogd et statd.


Pour des informations sur l'utilisation de la version 4 de NFS, reportez-vous à Configuration des services NFS.

Annulation et rétablissement du partage d'un système de fichiers dans la version 4 de NFS

Dans les versions 3 et 4 de NFS, si un client tente d'accéder à un système de fichiers dont le partage a été annulé, le serveur renvoie un code d'erreur. Cependant, avec la version 3 de NFS, le serveur conserve tous les verrous que les clients avaient obtenu avant que l'annulation du partage du système de fichiers. Par conséquent, lorsque le partage du système de fichiers est rétabli, les clients de la version 3 de NFS peuvent accéder au système de fichiers comme si son partage n'avait jamais été annulé.

Avec la version 4 de NFS, lorsqu'un système de fichiers n'est pas partagé, tous les états de tout fichier ouvert ou de tout verrou de fichier dans ce système de fichiers sont détruits. Si le client tente d'accéder à ces fichiers ou à ces verrous; il reçoit un message d'erreur. Généralement, cette erreur est signalée comme étant une erreur I/O à l'application. Notez, cependant, que le rétablissement du partage d'un système de fichiers partagé pour modifier les options ne détruit aucun état sur le serveur.

Pour obtenir des informations connexes, reportez-vous à la rubrique Récupération d'un client dans la version 4 de NFS ou à la page de manuel unshare_nfs(1M).

Espace de noms du système de fichiers dans la version 4 de NFS

Les serveurs de la version 4 de NFS créent et mettent à jour un pseudo-système de fichiers qui donne aux clients un accès transparent à tous les objets exportés sur le serveur. Dans les versions antérieures à la version 4 de NFS, le pseudo-système de fichiers n'existait pas. Les clients devaient monter chaque système de fichiers de serveur partagé pour l'accès. Voyez l'exemple suivant :

Figure 6-2 Vues du système de fichiers du serveur et du système de fichiers client

image:Ce graphique illustre l'affichage du serveur et du client du même système de fichiers.

Notez que le client ne peut pas voir les répertoires payroll et nfs4x, car ces répertoires ne sont pas exportés et ne mènent pas à des répertoires exportés. Toutefois, le répertoire local est visible pour le client, car local est un répertoire exporté. Le répertoire projects est visible pour le client, car projects mène vers le répertoire exporté, nfs4. Par conséquent, certaines parties de l'espace de noms du serveur qui ne sont pas explicitement exportées sont reliées par un pont avec un pseudo-système de fichiers qui affiche uniquement les répertoires exportés et ceux qui mènent à des exports de serveur.

Un pseudo-système de fichiers est une structure qui contient uniquement des répertoires et est créée par le serveur. Le pseudo-système de fichiers permet à un client de parcourir la hiérarchie des systèmes de fichiers exportés. Par conséquent, la vue du client du pseudo-système de fichiers est limitée aux chemins qui conduisent à systèmes de fichiers exportés.

Les versions précédentes de NFS n'autorisaient pas un client de parcourir les systèmes de fichiers serveur sans monter chaque système de fichiers. Cependant, dans la version 4 de NFS, l'espace de noms de serveur se comporte comme suit :

Pour des raisons liées à POSIX, le client de la version 4 de Oracle Solaris NFS ne franchit pas les limites du système de fichiers du serveur. En cas de telles tentatives, le client fait que le répertoire semble vide. Pour remédier à cette situation, vous devez effectuer un montage pour chacun des systèmes de fichiers du serveur.

Identificateurs de fichiers volatile de la version 4 de NFS

Les identificateurs de fichiers sont créés sur le serveur et contiennent des informations qui identifient de manière unique les fichiers et les répertoires. Dans les versions 2 et 3 de NFS le serveur renvoyait des identificateurs de fichier persistants. Par conséquent, le client pouvait garantir que le serveur génèrerait un identificateur de fichier qui désigne toujours le même fichier. Par exemple :

Par conséquent, lorsque le serveur a reçu une demande d'un client qui comporte un identificateur de fichier, la résolution est simple et l'identificateur de fichier désigne toujours le fichier approprié.

Cette méthode d'identification des fichiers et répertoires pour les opérations NFS convient à la plupart des serveurs UNIX. Cependant, elle n'a pas pu être implémentée sur les serveurs s'appuyant sur d'autres méthodes d'identification telles que le chemin d'accès d'un fichier. Pour résoudre ce problème, le protocole de la version 4 de NFS permet à un serveur de déclarer ses identificateurs de fichier comme étant volatiles. Ainsi, un identificateur de fichier peut changer. Si l'identificateur de fichier est modifié, le client doit trouver le nouvel identificateur.

Comme pour les versions 2 et 3 de NFS, le serveur de la version 4 de Oracle Solaris NFS fournit toujours des identificateurs de fichier persistants. Toutefois, les clients de la version 4 de Solaris NFS qui accèdent à des serveurs non équipés de la version 4 de Solaris NFS doivent prendre en charge les identificateurs de fichier volatiles si le serveur les utilise. En particulier, lorsque le serveur indique au client que l'identificateur de fichier est volatile, le client doit mettre en cache le mappage entre le nom du chemin d'accès et l'identificateur de fichier. Le client utilise l'identificateur de fichier volatile jusqu'à ce qu'il expire. Lors de son expiration, le client effectue les opérations suivantes :


Remarque - Le serveur indique toujours au client quels identificateurs de fichier sont persistants ou volatiles.


Les identificateurs de fichier volatiles peuvent expirer pour l'une des raisons suivantes :

Notez que si le client n'est pas en mesure de trouver le nouvel identificateur de fichier, un message d'erreur est placé dans le fichier syslog. Les autres tentatives d'accès à ce fichier échouent avec une erreur I/O.

Récupération d'un client dans la version 4 de NFS

Le protocole de la version 4 de NFS est un protocole avec état. Un protocole est avec état lorsque le client et le serveur assurent la maintenance des informations sur les éléments suivants.

Lorsqu'une panne se produit, comme une panne de serveur, le client et le serveur collaborent pour rétablir les états d'ouverture et de verrouillage qui existaient avant cette panne.

Si un serveur s'arrête brutalement et est réinitialisé, le serveur perd son état. Le client détecte que le serveur s'est réinitialisé et commence le processus pour aider le serveur à reconstruire son état. Ce processus est appelé restauration du client, car le client dirige le processus.

Lorsque le client détecte que le serveur s'est réinitialisé, le client suspend immédiatement son activité actuelle et lance le processus de récupération du client. Lorsque le processus de récupération démarre, un message tel que le suivant s'affiche dans le journal d'erreurs système /var/adm/messages.

NOTICE: Starting recovery server basil.example.company.com

Au cours du processus de récupération, le client envoie les informations du serveur à propos de l'état précédent du client. Notez cependant que, pendant cette période, le client n'envoie pas de nouvelles demandes pour le serveur. Toutes les nouvelles demandes d'ouverture de fichiers ou de définition de verrous de fichiers doit attendre que le serveur termine le processus de récupération avant de poursuivre.

Lorsque la récupération du client est terminée, le message suivant s'affiche dans le journal d'erreurs système /var/adm/messages.

NOTICE: Recovery done for server basil.example.company.com

Maintenant, le client a terminé l'envoi des informations d'état pour au serveur. Toutefois, même si le client a terminé ce processus, d'autres clients n'ont peut-être pas été terminé leur processus d'envoi informations d'état au serveur. Par conséquent, le serveur n'accepte pas les demandes d'ouverture ou de verrouillage pendant un certain temps. Cette période appelée délai de grâce, permet à tous les clients de terminer leur processus de récupération.

Au cours de la période de grâce, si le client tente d'ouvrir de nouveaux fichiers ou d'établir de nouveaux verrous, le serveur refuse la demande avec le code d'erreur GRACE. A la réception de l'erreur, le client doit attendre la fin de la période de grâce, puis renvoyer la demande au serveur. Pendant la période de grâce, le message suivant s'affiche.

NFS server recovering

Notez que pendant la période de grâce, les commandes qui n'ouvrent pas les fichiers ou ne définissent pas de verrouillages peuvent s'effectuer. Par exemple, les commandes ls et cd n'ouvrent par de fichiers ni ne définissent un verrouillage de fichier. Par conséquent, ces commandes ne sont pas suspendues. Toutefois, une commande telle que cat, qui ouvre un fichier, serait suspendue jusqu'à ce que la période de grâce se termine.

Lorsque la période de grâce est terminée, le message suivant s'affiche.

NFS server recovery ok.

Le client peut maintenant envoyer de nouvelles demandes d'ouverture et de verrouillage au serveur.

La récupération du client peut échouer pour diverses raisons. Par exemple, si une partition réseau existe après la réinitialisation du serveur, le client peut ne pas être en mesure de rétablir son état avec le serveur avant la fin de la période de grâce. Lorsque la période de grâce est terminée, le serveur n'autorise pas le client afin de rétablir son état parce que de nouvelles opérations d'état pourraient créer des conflits. Par exemple, un nouveau verrou de fichier peut entrer en conflit avec un ancien verrou de fichier que le client tente de récupérer. Lorsque de telles situations se produisent, le serveur renvoie le code d'erreur NO_GRACE au client.

Si la récupération d'une opération d'ouverture pour un fichier en particulier échoue, le client identifie le fichier comme inutilisable et le message suivant s'affiche.

WARNING: The following NFS file could not be recovered and was marked dead 
(can't reopen:  NFS status 70):  file :  filename

Notez que le nombre 70 n'est qu'un exemple.

Si le rétablissement d'un verrou de fichier échoue pendant la restauration, le message d'erreur suivant est publié.

NOTICE: nfs4_send_siglost:  pid PROCESS-ID lost
lock on server SERVER-NAME

Dans cette situation, le signal SIGLOST est publié dans le processus. L'action par défaut pour le signal SIGLOST est de mettre fin au processus.

Pour vous permettre de restaurer à partir de cet état, vous devez redémarrer toutes les applications qui avaient des fichiers ouverts au moment de la panne. Notez que les événements suivants peuvent se produire.

Par conséquent, certains processus peuvent accéder à un fichier en particulier tandis que d'autres processus ne le peuvent pas.

Prise en charge du partage OPEN dans la version 4 de NFS

Le protocole de la version 4 de NFS offre plusieurs modes partage de fichiers que le client peut utiliser pour contrôler l'accès aux fichiers par d'autres clients. Un client peut spécifier les éléments suivants :

Le serveur de la version 4 de Oracle Solaris NFS effectue une implémentation complète de ces modes de partage de fichier. Par conséquent, si un client tente d'ouvrir un fichier d'une manière qui entre en conflit avec le mode de partage, le serveur refuse la tentative en faisant échouer l'opération. Lorsque de telles tentatives échouent avec le lancement des opérations de création ou d'ouverture, le client de la version 4 de NFS reçoit une erreur de protocole. Cette erreur est mise en correspondance avec l'erreur d'application EACCES.

Même si le protocole offre plusieurs modes de partage, actuellement, l'opération d'ouverture dans Oracle Solaris n'offre pas plusieurs modes de partage. Lors de l'ouverture d'un fichier, un client de la version 4 de Oracle Solaris NFS peut uniquement utiliser le mode DENY_NONE.

Bien que l'appel de système fcntl dispose d'une commande F_SHARE pour contrôler le partage de fichiers, les commandes fcntl ne peuvent pas être implémentées correctement avec la version 4 de NFS. Si vous utilisez ces commandes fcntl sur un client de la version 4 de NFS, le client renvoie l'erreur EAGAIN à l'application.

Délégation dans la version 4 de NFS

La version 4 de NFS fournit à la fois la prise en charge du client et la prise en charge du serveur pour la délégation. La délégation est une technique par laquelle le serveur délègue la gestion d'un fichier à un client. Par exemple, le serveur peut attribuer une délégation de lecture ou d'écriture à un client. Les délégations de lecture peuvent être accordées à plusieurs clients en même temps, car ces délégations de lecture n'entrent pas en conflit les unes avec les autres. Une délégation d'écriture peut être accordée à un seul client, car une telle délégation peut entrer en conflit avec tout autre accès de fichier par tout autre client. Lorsqu'il détient une délégation d'écriture, le client n'enverrait pas diverses opérations sur le serveur car le client est se voit accorder un accès exclusif à un fichier. De même, le client n'envoie pas diverses opérations au serveur tout en détenant une délégation de lecture. La raison est que le serveur garantit qu'aucun client ne peut ouvrir un fichier en mode écriture. L'effet de la délégation est de réduire considérablement les interactions entre le serveur et le client pour les fichiers délégués. Par conséquent, le trafic réseau est réduit et les performances sur le client et le serveur sont améliorées. Notez, cependant, que le degré d'amélioration des performances dépend du type d'interaction de fichier utilisé par une application et la quantité de surcharge sur le réseau ou le serveur.

La décision d'accorder ou non une délégation revient exclusivement au serveur. Un client ne demande pas de délégation. Le serveur prend des décisions concernant la cession d'une délégation, basée sur les modèles d'accès du fichier. Si différents clients ont récemment accédé à un fichier en mode écriture, le serveur peut ne pas accorder de délégation. La raison est que ce modèle d'accès indique le potentiel de conflits futurs.

Un conflit survient lorsqu'un client accède à un fichier d'une manière qui n'est pas cohérente avec les délégations actuellement accordées à ce fichier. Par exemple, si un client détient une délégation d'écriture sur un fichier et qu'un deuxième client ouvre ce fichier pour lire ou écrire l'accès, le serveur rappelle la délégation d'écriture du premier client. De même, si un client détient une délégation de lecture et qu'un autre client ouvre le même fichier pour l'écriture, le serveur rappelle la délégation de lecture. Notez que dans les deux cas, le second client ne se voit pas accorder de délégation parce qu'un conflit existe maintenant. Lorsqu'un conflit survient, le serveur utilise un mécanisme de rappel pour contacter le client qui détient actuellement la délégation. Lors de la réception de ce rappel, le client envoie l'état mis à jour du fichier au serveur et renvoie la délégation. Si le client ne répond pas au rappel, le serveur révoque la délégation. Dans de tels cas, le serveur rejette toutes les opérations provenant du client pour ce fichier, et le client rapporte les opérations demandées comme ayant échoué. En règle générale, ces défaillances sont signalées à l'application comme des erreurs d'E/S. Pour restaurer à partir de ces erreurs, le fichier doit être fermé, puis rouvert. Les échecs de délégations révoquées peuvent se produire lorsqu'une partition de réseau existe entre le client et le serveur, lorsque le client détient une délégation.

Notez qu'un serveur n'est pas en mesure de résoudre les conflits d'accès à un fichier qui est stocké sur un autre serveur. Par conséquent, un serveur NFS résout uniquement les conflits pour les fichiers qu'il stocke. En outre, en réponse aux conflits causés par des clients qui exécutent différentes versions de NFS, un serveur NFS peut uniquement lancer des rappels pour le client qui exécute la version 4 de NFS. Un serveur NFS ne peut pas initier de rappels pour les clients qui exécutent des versions antérieures de NFS.

Le processus de détection des conflits varie. Par exemple, contrairement à la version 4 de NFS, dans la mesure où les versions 2 et 3 n'ont pas de procédure d'ouverture, le conflit n'est détecté qu'après une tentative de lecture, d'écriture ou de verrouillage d'un fichier par un client. La réponse du serveur à ces conflits varie également. Par exemple :

Ces conditions sont supprimées une fois le conflit de délégation résolu.

Par défaut, la délégation de serveur est activée. Vous pouvez désactiver la délégation en définissant le paramètre server_delegation sur aucun. Pour des informations sur les procédures à suivre, reportez-vous à la rubrique Sélection de versions différentes de NFS sur un serveur.

Aucun mot de passe n'est requis pour la délégation de client. Le démon de rappel de la version 4 de NFS, nfs4cbd, fournit le service de rappel sur le client. Ce démon démarre automatiquement dès qu'un montage pour la version 4 de NFS est activé. Par défaut, le client fournit les informations de rappel pour le serveur pour tous les transports Internet répertoriés dans le fichier système /etc/netconfig. Notez que si le client est compatible avec IPv6 et que l'adresse IPv6 pour le nom du client peut être déterminée, le démon de rappel accepte les connexions IPv6.

Le démon de rappel utilise un numéro de programme transitoire et un numéro de port attribué de façon dynamique. Ces informations sont fournies au serveur et ce dernier vérifie le chemin de rappel avant d'accorder les délégations. Si la vérification du chemin de rappel échoue, le serveur n'accorde pas de délégations (il s'agit du seul comportement visible de l'extérieur).

Notez que dans la mesure où les informations de rappel sont intégrées à une demande de la version 4 de NFS, le serveur n'est pas en mesure de contacter le client par le biais d'un périphérique qui utilise la méthode NAT (Network Address Translation). En outre, le démon de rappel utilise un numéro de port dynamique. Par conséquent, le serveur peut ne pas être en mesure de traverser un pare-feu, même si ce pare-feu autorise normalement le trafic NFS sur le port 2049. Dans de telles situations, le serveur n'accorde pas de délégations.

Listes de contrôle d'accès (ACL) et nfsmapid dans la version 4 de NFS

Une liste de contrôle d'accès (ACL) offre une meilleure sécurité pour les fichiers en permettant au propriétaire d'un fichier de définir les autorisations de fichier pour un propriétaire du fichier, un groupe et autres utilisateurs et groupes spécifiques. Sur les systèmes de fichiers ZFS, les ACL sont définies sur le serveur et le client à l'aide de la commande chmod. Pour les systèmes de fichiers UFS, utilisez la commande setfacl. Reportez-vous aux pages de manuel chmod(1) et setfacl(1) pour plus d'informations. Dans la version 4 de NFS, le mappeur d'ID, nfsmapid, est utilisé pour mettre en correspondance un ID d'utilisateur ou de groupe dans les entrées d'ACL sur un serveur et l'ID d'utilisateur ou de groupe dans entrées d'ACL sur un client. L'inverse est également vrai. Les ID d'utilisateur et de groupe dans les entrées d'ACL doivent exister à la fois sur le client et le serveur.

Motifs d'échecs de mappages d'ID

Les situations suivantes peuvent provoquer un échec de mappage d'ID :

Prévention des problèmes de mappage d'ID avec les ACL

Afin d'éviter les problèmes de mappage d'ID, procédez comme suit :

Vérification d'ID d'utilisateur ou de groupe non mappé

Pour déterminer si un utilisateur ou un groupe ne peut pas être mappé sur le serveur ou le client, utilisez le script suivant :

#! /usr/sbin/dtrace -Fs

sdt:::nfs4-acl-nobody
{
     printf("validate_idmapping: (%s) in the ACL could not be mapped!", 
stringof(arg0));
}

Remarque - Le nom de la sonde utilisée dans ce script est une interface qui est susceptible de changer à l'avenir. Pour plus d'informations, reportez-vous à la rubrique Stability Levels du manuel Solaris Dynamic Tracing Guide.


Informations supplémentaires sur les ACL ou nfsmapid

Reportez-vous aux rubriques suivantes :

Négociation UDP et TCP

Pendant l'initialisation, le protocole de transport est également négocié. Par défaut, le premier transport orienté connexion pris en charge à la fois sur le client et le serveur est sélectionné. Si la sélection de cette valeur entraine un échec, le premier protocole de transport sans connexion disponible est utilisé. Les protocoles de transport qui sont pris en charge sur un système sont répertoriés dans /etc/netconfig. TCP est le protocole de transport orienté connexion pris en charge par la version. UDP est le protocole de transport sans connexion.

Lorsque les versions du protocole NFS et du protocole de transport sont déterminées par la négociation, la version du protocole NFS est prioritaire sur le protocole de transport. Le protocole de la version 3 de NFS qui utilise UDP a une priorité plus élevée que le protocole de la version 2 de NFS qui utilise TCP. Vous pouvez sélectionner manuellement la version du protocole NFS et le protocole de transport avec la commande mount. Reportez-vous à la page de manuel mount_nfs(1M). Dans la plupart des cas, laissez la négociation sélectionner les meilleures options.

Négociation de la taille de transfert de fichiers

La taille de transfert de fichier établit la taille des tampons utilisés lors du transfert des données entre le client et le serveur. En général, les tailles de transfert importantes sont préférables. Le protocole de la version 3 de NFS a une taille de transfert illimitée. Le client peut offrir une plus petite taille de transfert au moment du montage si nécessaire, mais dans la plupart des cas, ce n'est pas nécessaire.

La taille de transfert n'est pas négociée avec des systèmes qui utilisent le protocole de la version 2 de NFS. Dans ces conditions, la taille maximale de transfert est définie sur 8 Ko.

Vous pouvez utiliser les options -rsize et -wsize pour définir la taille du transfert manuellement avec la commande mount. Vous pouvez être amené à réduire la taille de transfert de certains clients PC. Par ailleurs, vous pouvez augmenter la taille de transfert si le serveur NFS est configuré pour pouvoir utiliser de plus grandes tailles de transfert.


Remarque - A partir de la version Solaris 10, les restrictions concernant les tailles des transferts par câble ont été assouplies. La taille du transfert dépend des possibilités de transport sous-jacent. Par exemple, la limite du transfert NFS pour le protocole UDP est toujours de 32 Ko. Cependant, TCP étant un protocole de transmission ne possédant pas les limites de datagramme UDP, les tailles maximales de transfert via TCP ont été augmentées à 1 Mo.


Montage des systèmes de fichiers

La description suivante s'applique aux montages de la version 3 de NFS. Le processus de montage de la version 4 de NFS n'inclut ni le service portmap ni le protocole MOUNT.

Lorsqu'un client a besoin de monter un système de fichiers à partir d'un serveur, le client doit obtenir un identificateur de fichier auprès du serveur. L'identificateur de fichier doit correspondre à celui du système de fichiers. Cette procédure nécessite que plusieurs transactions s'effectuent entre le client et le serveur. Dans cet exemple, le client tente de monter /home/terry à partir du serveur. Un suivi snoop pour cette transaction suit.

client -> server PORTMAP C GETPORT prog=100005 (MOUNT) vers=3 proto=UDP
server -> client PORTMAP R GETPORT port=33492
client -> server MOUNT3 C Null
server -> client MOUNT3 R Null 
client -> server MOUNT3 C Mount /export/home9/terry
server -> client MOUNT3 R Mount OK FH=9000 Auth=unix
client -> server PORTMAP C GETPORT prog=100003 (NFS) vers=3 proto=TCP
server -> client PORTMAP R GETPORT port=2049
client -> server NFS C NULL3
server -> client NFS R NULL3 
client -> server NFS C FSINFO3 FH=9000
server -> client NFS R FSINFO3 OK
client -> server NFS C GETATTR3 FH=9000
server -> client NFS R GETATTR3 OK

Dans ce suivi, le client demande d'abord le numéro de port de montage au le service portmap sur le serveur NFS. Une fois que le client reçoit le numéro de port de montage (33492), ce numéro est utilisé pour tester la disponibilité du service sur le serveur. Une fois que le client a déterminé qu'un service est en cours d'exécution sur ce numéro de port, il effectue une demande de montage. Lorsque le serveur répond à cette demande, le serveur inclut l'identificateur de fichier pour le système de fichiers (9000) en cours de montage. Le client envoie ensuite une demande pour le numéro de port NFS. Lorsque le client reçoit le numéro du serveur, il vérifie la disponibilité du service NFS (nfsd). En outre, il demande des informations NFS sur le système de fichiers qui utilise l'identificateur de fichier.

Dans le suivi ci-après, le client monte le système de fichiers avec l'option public.

client -> server NFS C LOOKUP3 FH=0000 /export/home9/terry
server -> client NFS R LOOKUP3 OK FH=9000
client -> server NFS C FSINFO3 FH=9000
server -> client NFS R FSINFO3 OK
client -> server NFS C GETATTR3 FH=9000
server -> client NFS R GETATTR3 OK

A l'aide de l'identificateur de fichier public par défaut ( 0000), toutes les transactions devant obtenir des informations à partir du service portmap et déterminer le numéro de port NFS sont ignorées.


Remarque - La version 4 de NFS prend en charge les identificateurs de fichiers volatiles. Pour plus d'informations, reportez-vous à la section Identificateurs de fichiers volatile de la version 4 de NFS.


Effets de l'option -public et des URL NFS lors du montage

L'option -public peut créer des conditions à l'origine de l'échec d'un montage. L'ajout d'une URL NFS peuvent également causer des problèmes. La liste suivante décrit la façon dont un système de fichiers est monté lorsque vous utilisez ces options.

Basculement côté client

En utilisant le basculement côté client, un client NFS peut détecter plusieurs serveurs qui rendent les mêmes données disponibles et peuvent passer à un autre serveur lorsque le serveur actuel n'est pas disponible. Le système de fichiers peut devenir indisponible si l'une des conditions suivantes se produit.

Le basculement, dans ces conditions, est normalement transparent pour l'utilisateur. Par conséquent, le basculement peut se produire à tout moment et sans perturber les processus qui sont en cours d'exécution sur le client.

Le basculement nécessite que le système de fichiers soit monté en lecture seule. Les systèmes de fichiers doivent être identiques pour que le basculement s'effectue avec succès. Reportez-vous à la section Qu'est-ce qu'un système de fichiers répliqué ? pour obtenir une description de qui fait qu'un système de fichiers est identique. Un système de fichiers statique ou qui n'a pas été modifiée est souvent le meilleur candidat pour un basculement.

Vous ne pouvez pas utiliser CacheFS et le basculement côté client sur un même montage NFS. Des informations supplémentaires sont enregistrées pour chaque système de fichiers CacheFS. Ces informations ne peuvent pas être mises à jour lors du basculement, de sorte que seule l'une de ces fonctions peut être utilisée lors du montage d'un système de fichiers.

Le nombre de répliques devant être établies pour chaque système de fichiers dépend de nombreux facteurs. Dans l'idéal, vous devez disposer d'au moins deux serveurs. Chaque serveur doit prendre en charge plusieurs sous-réseaux. Cette configuration est préférable au fait d'avoir un serveur unique sur chaque sous-réseau. Le processus exige que chaque serveur répertorié soit vérifié. Par conséquent, si plusieurs serveurs sont répertoriés, chaque montage est plus lent.

Terminologie du basculement

Pour bien comprendre le processus, vous devez comprendre deux termes.

Qu'est-ce qu'un système de fichiers répliqué ?

Pour les besoins du basculement, un système de fichiers peut être appelé réplique lorsque chaque fichier est de la même taille et a la même taille de fichier ou le même type de fichier que le système de fichiers d'origine. Les autorisations, dates de création et autres attributs de fichier ne sont pas pris en compte. Si la taille du fichier ou les types de fichier sont différents, le remappage échoue et le processus se bloque jusqu'à ce que l'ancien serveur devienne disponible. Dans la version 4 de NFS, le comportement est différent. Reportez-vous à la section Basculement côté client dans la version 4 de NFS.

Vous pouvez entretenir un système de fichiers répliqué à l'aide de rsync, cpio ou d'un autre mécanisme de transfert de fichiers. Dans la mesure où la mise à jour des systèmes de fichiers répliqués entraîne des incohérences, prenez les précautions suivantes pour obtenir de meilleurs résultats :

Basculement et verrouillage NFS

Certains logiciels requièrent des verrous de lecture sur les fichiers. Pour éviter que ces produits ne dysfonctionnent, les verrous de lecture sur des systèmes de fichiers en lecture seule sont autorisés, mais sont visibles pour le côté client seulement. Les verrous sont conservés par le biais d'un remappage car le serveur n'est pas au courant de l'existence des verrous. Etant donné que les fichiers ne doivent pas changer, vous n'avez pas besoin de verrouiller le fichier sur le côté serveur.

Basculement côté client dans la version 4 de NFS

Dans la version 4 de NFS, si une réplique ne peut pas être établie car les tailles ou les types de fichier sont différents, les événements suivants se produisent.


Remarque - Si vous redémarrez l'application et essayez à nouveau d'accéder à un fichier, vous devriez y parvenir.


Dans la version 4 de NFS, vous ne recevez plus d'erreurs de réplication pour les répertoires de tailles différentes. Dans les précédentes versions de NFS, cette condition était considérée comme une erreur et entravait le processus de remappage.

En outre, dans la version 4 de NFS, si une opération de répertoire de lecture est infructueuse, l'opération est exécutée par le serveur suivant de la liste. Dans les précédentes versions de NFS, les opérations de lecture ayant échoué risquaient d'entraîner un échec du remappage et un blocage du processus jusqu'à ce que le serveur d'origine soit disponible.

Fichiers volumineux

Le système d'exploitation prend en charge les fichiers de plus de 2 Go. Par défaut, les systèmes de fichiers UFS sont montés avec l'option - largefiles pour prendre en charge la nouvelle fonctionnalité. Si nécessaire, reportez-vous à Désactivation des fichiers volumineux sur un serveur NFS pour obtenir des instructions.

Si le système de fichiers du serveur est monté avec l'option -largefiles, un client peut accéder aux fichiers volumineux sans que des modifications ne soient nécessaires. Toutefois, toutes les commandes ne peuvent pas gérer ces fichiers volumineux. Reportez-vous à la page de manuel largefile(5) pour obtenir une liste de commandes capables de gérer les grands fichiers. Les clients qui ne peuvent pas prendre en charge le protocole de la version 3 de NFS avec les extensions de fichiers volumineux ne peuvent pas accéder à des fichiers volumineux.

Fonctionnement de la journalisation du serveur NFS

La journalisation du serveur NFS fournit les enregistrements des lectures et écritures NFS, ainsi que des opérations qui modifient le système de fichiers. Ces données peuvent être utilisées pour suivre l'accès aux informations. En outre, ces enregistrements peuvent fournir un moyen quantitatif de mesurer l'intérêt pour l'information.

En cas d'accès à un système de fichiers avec la journalisation activée, le noyau écrit les données brutes dans un fichier tampon. Les données incluent ce qui suit :

Le démon nfslogd convertit ces données brutes en enregistrements au format ASCII qui sont stockés dans des fichiers journaux. Lors de la conversion, les adresses IP sont modifiées en noms d'hôte et les UID sont modifiés en informations de connexion si le service de noms qui est activé peut trouver des correspondances. Les identificateurs de fichiers sont également convertis en noms de chemin d'accès. Pour accomplir la conversion, le démon assure le suivi des identificateurs de fichiers et stocke les informations dans une table identificateur de fichier-chemin d'accès distincte. De cette façon, le chemin d'accès n'a pas à être identifié à nouveau à chaque accession à un identificateur de fichier. Dans la mesure où aucune modification n'est apportée aux mappages dans la table identificateur de fichier-chemin lorsque la commande nfslogd est désactivée, vous devez conserver le démon en cours d'exécution.


Remarque - La journalisation du serveur n'est pas prise en charge dans la version 4 de NFS.


Fonctionnement du service WebNFS

Le service WebNFS rend les fichiers dans un répertoire accessibles par les clients à l'aide d'un identificateur de fichier. Un identificateur de fichier est une adresse qui est générée par le noyau qui identifie un fichier pour les clients NFS. L'identificateur de fichier public a une valeur prédéfinie, de sorte que le serveur n'a pas besoin de générer un identificateur de fichier pour le client. La capacité d'utiliser cet identificateur de fichier prédéfini réduit le trafic réseau en éliminant le protocole MOUNT. Cette capacité devrait également accélérer les processus pour les clients.

Par défaut, l'identificateur de fichier public sur un serveur NFS est établi sur le système de fichiers racine. Cette valeur par défaut fournit l'accès WebNFS à tous les clients disposant déjà de privilèges de montage sur le serveur. Vous pouvez modifier l'identificateur de fichier public pour pointer sur n'importe quel système de fichiers en utilisant la commande share.

Lorsque le client dispose de l'identificateur de fichier pour le système de fichiers, une commande LOOKUP est exécutée pour déterminer l'identificateur du fichier auquel accéder. Le protocole NFS permet l'évaluation d'un seul composant de nom de chemin à la fois. Chaque niveau supplémentaire de hiérarchie de répertoires nécessite une autre opération de LOOKUP. Un serveur WebNFS peut évaluer un nom de chemin d'accès entier à l'aide d'une transaction de recherche de composant multi-transaction lorsque la commande LOOKUP est relative à l'identificateur de fichier public. La recherche de multi-composant permet au serveur WebNFS de fournir l'identificateur de fichier pour le fichier désiré sans échanger d'identificateurs de fichiers pour chaque niveau de répertoire dans le nom du chemin d'accès.

En outre, un client NFS peut lancer des téléchargements simultanés sur une seule connexion TCP. Cette connexion permet d'avoir un accès rapide sans la charge supplémentaire sur le serveur causée par la configuration de plusieurs connexions. Bien que les applications de navigateur Web prennent en charge le téléchargement de plusieurs fichiers, chaque fichier a sa propre connexion. En utilisant une connexion, le logiciel WebNFS réduit le temps système sur le serveur.

Si le composant final dans le nom de chemin est un lien symbolique vers un autre système de fichiers, le client peut accéder au fichier si le client a déjà un accès par l'intermédiaire des activités NFS normale.

En règle générale, l'URL NFS est évaluée par rapport à l'identificateur de fichier public. L'évaluation peut être modifiée de manière à être relative à la racine du serveur du système de fichiers par l'ajout d'une autre barre oblique au début du chemin d'accès. Dans cet exemple, ces deux URL NFS sont équivalentes si l'identificateur de fichier public a été établi sur le système de fichiers /export/ftp.

nfs://server/junk
nfs://server//export/ftp/junk

Remarque - Le protocole de la version 4 de NFS est préféré au service WebNFS. La version 4 de NFS intègre pleinement toutes les négociations de sécurité ajoutées au protocole MOUNT et au service WebNFS.


Fonctionnement de la négociation de sécurité WebNFS

Le service NFS inclut un nouveau protocole qui permet à un client WebNFS de négocier le mécanisme de sécurité sélectionné avec un serveur WebNFS. Le nouveau protocole utilise une recherche de négociation de sécurité multi-composant, qui est une extension de la recherche multi-composant qui a été utilisée dans les versions antérieures du protocole WebNFS.

Le client WebNFS lance le processus en faisant une demande de recherche multi-composant standard en utilisant l'identificateur de fichier public. Puisque le client ne sait pas comment le chemin est protégé par le serveur, le mécanisme de sécurité par défaut est utilisé. Si le mécanisme de sécurité par défaut n'est pas suffisant, la réponse du serveur est une erreur AUTH_TOOWEAK. Cette réponse indique que le mécanisme par défaut n'est pas valide. Le client doit utiliser un mécanisme par défaut plus fort.

Lorsque le client reçoit l'erreur AUTH_TOOWEAK, le client envoie une demande au serveur pour déterminer quels mécanismes de sécurité sont requis. Si la demande réussit, le serveur répond avec un tableau de mécanismes de sécurité requis pour le chemin d'accès spécifié. En fonction de la taille du tableau de mécanismes de sécurité, le client peut être amené à effectuer des demandes supplémentaires pour obtenir le tableau complet. Si le serveur ne prend pas en charge la négociation de sécurité WebNFS, la demande échoue.

Si la demande aboutit, le client WebNFS sélectionne le premier mécanisme de sécurité à partir du tableau que le client prend en charge. Le client émet ensuite une demande de recherche multi-composant standard à l'aide des mécanismes de sécurité pour acquérir l'identificateur de fichier. Toutes les autres demandes NFS sont effectuées à l'aide du mécanisme de sécurité et de l'identificateur de fichier.


Remarque - Le protocole de la version 4 de NFS est préféré au service WebNFS. La version 4 de NFS intègre pleinement toutes les négociations de sécurité ajoutées au protocole MOUNT et au service WebNFS.


Restrictions WebNFS liées à l'utilisation de navigateur Web

Plusieurs fonctions qu'un site Web utilisant HTTP est capable de fournir ne sont pas prises en charge par le logiciel WebNFS. Ces différences proviennent du fait que le serveur NFS n'envoie que le fichier, de sorte que tout traitement spécial doit être effectué par le client. Si vous avez besoin d'un site web configuré pour l'accès WebNFS et HTTP, vous devez tenir compte des points suivants :

Système NFS sécurisé

L'environnement NFS est un moyen efficace et pratique pour partager des systèmes de fichiers sur un réseau doté de diverses architectures et systèmes d'exploitation. Cependant, les mêmes fonctions qui font que le partage des systèmes de fichiers à l'aide des opérations NFS est pratique posent également des problèmes de sécurité. Historiquement, la plupart des implémentations NFS utilisaient l'authentification UNIX (ou AUTH_SYS), mais aussi des méthodes d'authentification plus fortes comme AUTH_DH étaient également disponibles. Lorsque vous utilisez l'authentification UNIX, un serveur NFS authentifie une demande de fichier en authentifiant l'ordinateur qui effectue la demande, mais pas l'utilisateur. Par conséquent, un utilisateur client peut exécuter su et usurper l'identité du propriétaire d'un fichier. Si l'authentification DH est utilisée, le serveur NFS authentifie l'utilisateur, ce qui rend ce type d'usurpation d'identité beaucoup plus difficile.

Avec un accès à la racine et des connaissances en programmation réseau, n'importe qui peut introduire des données arbitraire dans le réseau et extraire des données du réseau. Les attaques les plus dangereuses sont celles qui concernent l'introduction de données. Un exemple est l'usurpation de l'identité d'un utilisateur effectuée en générant les bons paquets ou en enregistrant des conversations et en les rejouant ultérieurement. Ces attaques ont une incidence sur l'intégrité des données. Les attaques qui impliquent l'écoute passive, qui correspond simplement à l'écoute du trafic réseau sans usurpation d'identité, ne sont pas aussi dangereuses, car l'intégrité des données n'est pas compromise. Les utilisateurs peuvent protéger la confidentialité des informations sensibles en chiffrant les données envoyées sur le réseau.

Une approche courante aux problèmes de sécurité réseau consiste à laisser la solution à chaque application. Une meilleure approche consiste à mettre en oeuvre un système d'authentification standard à un niveau qui couvre toutes les applications.

Le système d'exploitation Oracle Solaris inclut un système d'authentification au niveau de l'appel de procédure à distance (RPC), qui est le mécanisme sur lequel les opérations NFS sont construites. Ce système, appelé RPC sécurisé, améliore considérablement la sécurité d'un environnement réseau et fournit une sécurité supplémentaire pour les services tels que le système NFS. Lorsque le système NFS utilise les fonctions qui sont fournies par RPC sécurisé, il est connu comme un système NFS sécurisé.

RPC sécurisé

RPC sécurisé est fondamental pour le système NFS sécurisé. L'objectif de RPC sécurisé est de construire un système qui est au moins aussi sécurisé qu'un système travaillant en temps partagé. Dans un système travaillant en temps partagé, tous les utilisateurs partagent le même ordinateur. Un système travaillant en temps partagé authentifie un utilisateur par le biais d'un mot de passe de connexion. Avec l'authentification DES (Data Encryption Standard), le même processus d'authentification est terminé. Les utilisateurs peuvent se connecter sur n'importe quel ordinateur distant tout comme les utilisateurs peuvent se connecter sur un terminal local. Les mots de passe de connexion sont leur assurance de la sécurité du réseau. Dans un environnement en temps partagé, l'administrateur système a une obligation éthique de ne pas modifier un mot de passe pour usurper l'identité quelqu'un. Dans RPC sécurisé, l'administrateur réseau n'est pas autorisé à modifier les entrées d'une base de données qui stocke les clés publiques.

Vous devez être familier avec deux termes pour comprendre un système d'authentification RPC : informations d'identification et de connexion et vérificateurs. Comme pour les cartes d'identité, les données d'identification sont ce qui identifie une personne : un nom, une adresse et une date de naissance. Le vérificateur est la photo sur la carte. Vous pouvez vérifier que la carte n'a pas été volée en vérifiant la photo sur la carte et en la comparant à la personne qui la détient. Dans RPC, le processus client envoie les informations d'identification et de connexion et un vérificateur au serveur avec chaque demande RPC. Le serveur renvoie uniquement un vérificateur car le client connaît déjà les informations d'identification et de connexion du serveur.

L'authentification RPC est illimitée, ce qui signifie qu'une grande variété de systèmes d'authentification peuvent y être raccordés, comme UNIX, DH et KERB.

Lorsque l'authentification UNIX est utilisée par un service réseau, les informations d'authentification et de connexion contiennent le nom d'hôte du client, l'UID, le GID et la liste d'accès de groupe. Cependant, le vérificateur ne contient rien. Dans la mesure où aucun vérificateur n'existe, un superutilisateur peut falsifier les informations d'identification et de connexion appropriées à l'aide des commandes telles que su. Un autre problème de l'authentification UNIX est qu'elle suppose que tous les ordinateurs d'un réseau sont des ordinateurs UNIX. L'authentification UNIX ne fonctionne pas lorsqu'elle est appliquée à d'autres systèmes d'exploitation dans un réseau hétérogène.

Pour surmonter les problèmes de l'authentification UNIX, le RPC sécurisé utilise l'authentification DH.

Authentification DH

L'authentification DH utilise la cryptographie par clé publique DES (Data Encryption Standard) et Diffie-Hellman pour authentifier les utilisateurs et les ordinateurs du réseau. DES est un mécanisme de chiffrement standard. La cryptographie par clé publique Diffie-Hellman est un système de chiffrement qui implique deux clés : une publique et une secrète. Les clés publiques et secrètes sont stockées dans l'espace de noms. NIS stocke les clés dans la mappe de clé publique. Ces mappes contiennent la clé publique et la clé secrète pour tous les utilisateurs potentiels. Reportez-vous au manuel Oracle Solaris Administration: Naming and Directory Services pour plus d'informations sur la configuration des mappes.

La sécurité de l'authentification DH est basée sur la capacité d'un expéditeur à chiffrer l'heure actuelle, que le destinataire peut ensuite déchiffrer et vérifier par rapport à son propre horloge. L'horodatage est chiffré à l'aide de DES. La configuration requise pour que ce plan fonctionne est la suivante :

Si un réseau exécute un programme de synchronisation d'heure, l'heure sur le client et le serveur est synchronisée automatiquement. Si un programme de synchronisation n'est pas disponible, les horodatages peuvent être calculés à l'aide de l'heure de serveur au lieu de l'heure du réseau. Le client demande l'heure au serveur avant le démarrage de la session RPC, puis calcule la différence de temps entre sa propre horloge et celle du serveur. Cette différence est utilisée pour compenser l'horloge du client lors du calcul des horodatages. Si les horloges du client et du serveur se désynchronisent, le serveur commence à rejeter les demandes du client. Le système d'authentification DH sur le client permet d'effectuer une resynchronisation avec le serveur.

Le client et le serveur arrivent à la même clé de chiffrement en générant une clé de conversation aléatoire également appelée clé de session, et en utilisant la cryptographie par clé publique pour déduire une clé commune. La clé commune est une clé que seuls le client et le serveur sont capables de déduire. La clé de conversation est utilisée pour chiffrer et déchiffrer l'horodatage du client. La clé commune est utilisée pour chiffrer et déchiffrer la clé de conversation.

Authentification KERB

Kerberos est un système d'authentification qui a été développé au MIT. Kerberos offre une variété de types de chiffrement, y compris DES. La prise en charge de Kerberos n'est plus fournie dans le cadre du RPC sécurisé, mais cette version inclut une implémentation côté serveur et côté client. Reportez-vous au Chapitre 19, Introduction au service Kerberos du manuel Administration d’Oracle Solaris : services de sécurité pour plus d'informations sur l'implémentation de l'authentification Kerberos.

Utilisation du RPC sécurisé avec NFS

Tenez compte des points suivants si vous avez l'intention d'utiliser le RPC sécurisé :