Fonctionnement d'autofs

Autofs est un service côté client qui monte automatiquement le système de fichiers adéquat. Les composants qui fonctionnent ensemble pour effectuer le montage automatique sont les suivants :

• Commande automount

• Système de fichiers autofs

• Démon automountd

Le service de montage automatique, svc:/système/système de fichiers/autofs , qui est appelé au moment du démarrage du système, lit le fichier de mappe principale auto_master pour créer l'ensemble initial de montages autofs. Ces montages autofs ne sont pas montés automatiquement lors du démarrage. Ces montages sont des points sous lesquels les systèmes de fichiers seront montés à l'avenir. Ces points sont également appelés nœuds déclencheurs.

Une fois les montages autofs définis, ces montages peuvent déclencher les systèmes de fichiers à monter sous eux. Par exemple, lorsqu'autofs reçoit une demande d'accès à un système de fichiers qui n'est pas actuellement monté, autofs appelle automountd, qui permet de monter le système de fichiers demandé.

Après le montage initial des montages autofs, la commande automount est utilisée pour mettre à jour les montages autofs le cas échéant. La commande compare la liste des montages dans la mappe auto_master à la liste des systèmes de fichiers montés dans le fichier de table de montage /etc/mnttab (anciennement /etc/mtab). automount effectue ensuite les modifications appropriées. Ce processus permet aux administrateurs système de modifier des informations de montage dans auto_master et que ces modifications soient utilisées par le processus autofs sans arrêter et redémarrer le démon autofs. Une fois que le système de fichiers est monté, tout accès supplémentaire ne nécessite aucune action de automountd jusqu'à ce que le système de fichiers soit automatiquement démonté.

Contrairement à mount, automount ne lit pas le fichier /etc/vfstab (qui est spécifique à chaque ordinateur) pour obtenir une liste de systèmes de fichiers à monter. La commande automount est contrôlée au sein d'un domaine et sur les ordinateurs via l'espace de nom ou les fichiers locaux.

Vous trouverez ci-après une présentation simplifiée du fonctionnement d'autofs.

Le démon de montage automatique automountd est lancé au démarrage par le service svc:/system/filesystem/autofs. Reportez-vous à la Figure 6-3. Ce service exécute également la commande automount qui lit la mappe principale et installe les points de montage autofs. Pour plus d'informations, reportez-vous à la section Démarrage du processus de navigation par autofs (mappe principale).

Figure 6-3 Démarrage d'automount par le service svc:/system/filesystem/autofs

Autofs est un système de fichiers du noyau qui prend en charge le montage et démontage automatiques.

Lorsqu'une demande est effectuée pour accéder à un système de fichiers au niveau d'un point de montage autofs, il se produit ce qui suit :

1. Autofs intercepte la requête.

2. Autofs envoie un message à la commande automountd pour que le système de fichiers demandé soit monté.

3. automountd localise les informations du système de fichiers dans une mappe, crée les nœuds de déclencheur et exécute le montage.

4. Autofs permet à la requête interceptée de s'effectuer.

5. Autofs démonte le système de fichiers après une période d'inactivité.

Comment Autofs Permet de naviguer à travers le réseau (cartes)

Autofs recherche une série de mappes pour parcourir le réseau. Les mappes sont des fichiers qui contiennent des informations telles que les entrées de mot de passe de tous les utilisateurs sur un réseau ou les noms de tous les ordinateurs hôte sur un réseau. En réalité, les mappes contiennent des équivalents de fichiers d'administration UNIX à l'échelle du réseau. Les mappes sont disponibles localement ou par l'intermédiaire d'un service de nom de réseau, tel que NIS ou NIS+. Reportez-vous à la rubrique Modification de la navigation du réseau par autofs (modification des mappes).

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

La commande automount lit la mappe principale au démarrage du système. Chaque entrée de la mappe principale est un nom de mappe directe ou de mappe indirecte, son chemin d'accès et ses options de montage, tel qu'illustré dans la Figure 6-4. L'ordre des entrées n'est pas important. automount compare les entrées dans la mappe principale avec des entrées dans la table de montage pour générer une liste actuelle.

Figure 6-4 Navigation par l'intermédiaire de la mappe principale

Processus de montage autofs

Le comportement du service autofs lorsqu'une demande de montage est déclenchée dépend de la façon dont les mappes de montage automatique sont configurées. Le processus de montage est généralement le même pour tous les montages. Cependant, le résultat final change avec le point de montage qui est spécifié et la complexité de ces mappes. Le processus de montage comprend la création des nœuds de déclencheur.

Montage autofs simple

Pour mieux comprendre le processus de montage autofs, supposons que les fichiers suivants sont installés.

$ cat /etc/auto_master
# Master map for automounter
#
+auto_master
/net        -hosts        -nosuid,nobrowse
/home       auto_home     -nobrowse
/share      auto_share
$ cat /etc/auto_share
# share directory map for automounter
#
ws          gumbo:/export/share/ws

En cas d'accès au répertoire /share, le service autofs crée un noeud de déclencheur pour /share/ws, qui est une entrée dans /etc/mnttab et qui ressemble à l'entrée suivante :

-hosts  /share/ws     autofs  nosuid,nobrowse,ignore,nest,dev=###

En cas d'accès au répertoire /share/ws, le service autofs termine le processus avec ces étapes :

1. Vérifie la disponibilité du service de montage du serveur.

2. Monte le système de fichiers demandé sous /share. Maintenant le fichier /etc/mnttab contient les entrées suivantes.

   -hosts  /share/ws     autofs  nosuid,nobrowse,ignore,nest,dev=###
   gumbo:/export/share/ws /share/ws   nfs   nosuid,dev=####    #####

Montage hiérarchique

Lorsque plusieurs couches sont définies dans les fichiers de montage automatique, le processus de montage devient plus complexe. Supposons que vous développez le fichier /etc/auto_shared de l'exemple précédent pour qu'il contienne les éléments suivants :

# share directory map for automounter
#
ws       /       gumbo:/export/share/ws
         /usr    gumbo:/export/share/ws/usr

Le processus de montage est essentiellement le même que dans l'exemple précédent en cas d'accès au point de montage /share/ws. En outre, un noeud de déclencheur au niveau suivant (/usr) est créé dans le système de fichiers /share/ws pour que le niveau suivant puisse être monté si on y accès. Dans cet exemple, /export/share/ws/usr doit exister sur le serveur NFS pour le noeud de déclencheur soit créé.

---

Attention - N'utilisez pas l'option -soft lors de la spécification de calques hiérarchiques. Reportez-vous à la rubrique Démontage autofs pour obtenir une explication sur cette limite.

---

Démontage autofs

Le démontage qui se produit après un certain temps d'inactivité suit l'ordre inverse de montage. Si l'un des répertoires à un niveau plus élevé dans la hiérarchie est occupé, seuls les systèmes de fichiers sous ce répertoire sont démontés. Pendant le processus de démontage, les nœuds de déclencheur sont supprimé et le système de fichiers est ensuite démonté. Si le système de fichiers est occupé, le démontage échoue et le nœuds de déclencheur sont réinstallés.

---

Attention - N'utilisez pas l'option -soft lors de la spécification de calques hiérarchiques. Si l'option -soft est utilisée, les demandes de réinstallation des nœuds de déclencheur peuvent dépasser le délai imparti. L'échec de réinstallation des nœuds de déclencheur ne laisse aucun accès au niveau suivant de montages. La seule façon de résoudre le problème est de laisser l'agent de montage automatique démonter tous les composants dans la hiérarchie. L'agent de montage automatique peut terminer le démontage soit en attendant que les systèmes de fichiers soient démontés automatiquement, soit le redémarrage du système.

---

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

L'exemple de mappe directe contient les éléments suivants :

/usr/local          -ro \
   /bin                   ivy:/export/local/sun4\
   /share                 ivy:/export/local/share\
   /src                   ivy:/export/local/src
/usr/man            -ro   oak:/usr/man \
                          rose:/usr/man \
                          willow:/usr/man
/usr/games          -ro   peach:/usr/games
/usr/spool/news     -ro   pine:/usr/spool/news \
                          willow:/var/spool/news 

Les points de montage /usr/man et /usr/spool/news répertorient plusieurs emplacements, trois emplacements pour le premier point de montage, et deux emplacements pour le deuxième point de montage. Tous les emplacements répliqués peuvent fournir le même service à n'importe quel utilisateur. Cette procédure est délicate uniquement lorsque vous montez un système de fichiers en lecture seule, dans la mesure où vous devez avoir un contrôle sur les emplacements des fichiers sur lesquels vous écrivez ou que vous modifiez. Vous devez éviter de modifier les fichiers sur un serveur à un moment donné, puis, quelques minutes plus tard, modifier le "même" fichier sur un autre serveur. L'avantage est que le meilleur serveur disponible est utilisé automatiquement sans intervention de l'utilisateur.

Si les systèmes de fichiers sont configurés en tant que répliques (voir Qu'est-ce qu'un système de fichiers répliqué ?), les clients ont l'avantage de l'utilisation du basculement. Non seulement le meilleur serveur est automatiquement déterminé, mais si ce serveur n'est plus disponible, le client utilise automatiquement le meilleur serveur suivant.

Un exemple d'un bon système de fichiers à configurer est une réplique de pages de manuel. Dans un réseau de grande taille, plusieurs serveurs peuvent exporter l'ensemble actuel de pages de manuel. Le serveur à partir duquel vous montez les pages de manuel n'a pas d'importance s'il est en cours d'exécution et exporte ses systèmes de fichiers. Dans l'exemple précédent, plusieurs emplacements de montage sont exprimés sous forme d'une liste d'emplacements de montage dans l'entrée de mappe.

/usr/man -ro oak:/usr/man rose:/usr/man willow:/usr/man 

Dans cet exemple, vous pouvez monter les pages de manuel à partir des serveurs oak, rose ou willow. Quel serveur est le meilleur dépend d'un certain nombre de facteurs, y compris les éléments suivants :

• le nombre de serveurs qui prennent en charge un niveau donné de protocole NFS ;

• la proximité du serveur ;

• la pondération.

Au cours du processus de tri, le nombre de serveurs qui prennent en charge chaque version du protocole NFS est compté. La version du protocole qui est prise en charge sur la plupart des serveurs devient le protocole par défaut. Cette sélection permet au client de disposer du nombre maximal de serveurs sur lesquels il peut dépendre.

Lorsque le plus grand sous-ensemble de serveurs avec la même version du protocole est trouvé, cette liste de serveurs est triée suivant leur proximité. Pour déterminer la proximité, les adresses IPv4 sont examinées. Les adresses IPv4 indiquent quels serveurs se trouvent dans chaque sous-réseau. Les serveurs d'un sous-réseau local sont préférés aux serveurs sur un sous-réseau distant. La préférence pour le serveur le plus proche réduit les délais d'attente et le trafic sur le réseau.

La Figure 6-5 illustre la proximité de serveur.

Figure 6-5 Proximité de serveur

Si plusieurs serveurs qui prennent en charge le même protocole sont sur le sous-réseau local, le temps connexion à chaque serveur est déterminé et le plus rapide des serveurs est utilisé. Le tri peut également être influencé par la pondération (reportez-vous à la section Autofs et pondération).

Par exemple, si les serveurs version 4 sont plus nombreux, la version 4 devient le protocole utilisé par défaut. Cependant, le processus de tri est maintenant plus complexe. Voici quelques exemples de la manière dont le processus de tri fonctionne :

• Les serveurs sur le sous-réseau local sont préférés aux serveurs sur un sous-réseau distant. Par conséquent, si un serveur version 3 se trouve sur le sous-réseau local et que le serveur version 4 le plus proche est sur un sous-réseau distant, le serveur version 3 se voit donner la préférence. De même, si le sous-réseau local se compose de serveurs version 2, ils sont privilégiés par rapport à des sous-réseaux distants avec des serveurs version 3 et version 4.

• Si le sous-réseau local est constitué d'un nombre varié de serveurs version 2, version 3 et version 4, plus de tri est nécessaire. L'agent de montage automatique préfère la version la plus récente sur le sous-réseau local. Dans cet exemple, la version 4 est la version la plus récente. Toutefois, si le sous-réseau local a plus de serveurs version 3 ou 2 que de serveurs version 4, l'agent de montage automatique "descend" d'une version sur le sous-réseau local. Par exemple, si le sous-réseau local dispose de trois serveurs de version 4, trois serveurs de version 3 et dix serveurs de version 2, un serveur de version 3 est sélectionné.

• De même, si le sous-réseau local est constitué d'un nombre variable de serveurs de version 2 et 3, l'agent de montage automatique examine d'abord la version qui représente la version la plus récente sur le sous-réseau local. Ensuite, l'agent de montage automatique compte le nombre de serveurs qui exécutent chaque version. Si la version la plus récente sur le sous-réseau local représente également la plupart des serveurs, la version la plus élevée est sélectionnée. Si une version inférieure a davantage de serveurs, l'agent de montage automatique descend d'une version sur le sous-réseau local. Par exemple, s'il y a plus de serveurs de version 2 sur le sous-réseau local que de serveurs version 3, un serveur version 2 est sélectionné.

Avec le basculement, le tri est vérifié au moment du montage lorsqu'un serveur est sélectionné. Plusieurs emplacements sont utiles dans un environnement où les serveurs individuels peuvent ne pas exporter leurs systèmes de fichiers temporairement.

Le basculement est particulièrement utile dans les réseaux de grande taille avec de nombreux sous-réseaux. Autofs choisit le serveur approprié et est en mesure de limiter le trafic du réseau NFS à un segment de réseau local. Si un serveur dispose de plusieurs interfaces réseau, vous pouvez répertorier le nom d'hôte qui est associé à chaque interface réseau comme si l'interface était un serveur distinct. Autofs sélectionne l'interface la plus proche pour le client.

Pour plus d'informations, reportez-vous à la page de manuel automount(1M).

Autofs et pondération

Vous pouvez influencer la sélection de serveurs au même niveau de proximité par l'ajout d'une valeur de pondération à la mappe autofs. Par exemple :

/usr/man -ro oak,rose(1),willow(2):/usr/man

Les nombres entre parenthèses indiquent une pondération. Les serveurs sans pondération ont une valeur de zéro et, par conséquent, sont plus susceptibles d'être sélectionnés. Plus la valeur de pondération est élevée, plus la probabilité que le serveur soit sélectionné est basse.

Variables d'une entrée de mappe

Vous pouvez créer une variable spécifique au client en précédant son nom du signe du dollar ($). La variable vous aide à satisfaire à différents types d'architecture qui accèdent au même emplacement du système de fichiers. Vous pouvez également utiliser des accolades pour délimiter le nom de la variable par rapport aux lettres ou chiffres ajoutés. Le Tableau 6-2 montre les variables de mappe prédéfinie.

Tableau 6-2 Variables de mappe prédéfinie

Vous pouvez utiliser des variables n'importe où dans une ligne de saisie, sauf en tant que clé. Par exemple, supposons que vous disposez d'un serveur de fichiers qui exporte des fichiers binaires SPARC et des architectures /usr/local/bin/sparc et /usr/local/bin/x86 respectivement. Les clients peuvent monter via une entrée de mappe, comme suit :

/usr/local/bin       -ro    server:/usr/local/bin/$CPU

La même entrée pour tous les clients s'applique maintenant à toutes les architectures.

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

Une entrée de mappe +nom-mappe utilisée dans un fichier de mappe fait qu'automount lit la mappe spécifiée comme si elle était incluse dans le fichier en cours. Si nom-mappe n'est pas précédé d'une barre oblique, autofs traite le nom de la mappe comme une chaîne de caractères et utilise la stratégie de changement nom-service pour trouver le nom de la mappe. Si le nom du chemin d'accès est un nom de chemin d'accès absolu, automount vérifie une mappe locale de ce nom. Si le nom de la carte commence par un tiret (-), automount consulte la mappe intégrée appropriée telle que hosts.

Ce fichier de changement nom-service contient une entrée pour autofs qui est libellée automount et contient l'ordre de recherche des services de noms. Le fichier suivant est un exemple de fichier de changement nom-service.

#
# /etc/nsswitch.nis:
#
# An example file that could be copied over to /etc/nsswitch.conf;
# it uses NIS (YP) in conjunction with files.
#
# "hosts:" and "services:" in this file are used only if the /etc/netconfig
# file contains "switch.so" as a nametoaddr library for "inet" transports.
# the following two lines obviate the "+" entry in /etc/passwd and /etc/group.
passwd:         files nis
group:          files nis

# consult /etc "files" only if nis is down.
hosts:          nis [NOTFOUND=return] files
networks:       nis [NOTFOUND=return] files
protocols:      nis [NOTFOUND=return] files
rpc:            nis [NOTFOUND=return] files
ethers:         nis [NOTFOUND=return] files
netmasks:       nis [NOTFOUND=return] files
bootparams:     nis [NOTFOUND=return] files
publickey:      nis [NOTFOUND=return] files
netgroup:       nis
automount:      files nis
aliases:        files nis
# for efficient getservbyname() avoid nis
services:       files nis 

Dans cet exemple, les mappes locales sont recherchées avant que les mappes NIS. Par conséquent, il est possible d'avoir peu d'entrées dans la mappe /etc/auto_home locale pour les répertoires d'accueil le plus couramment accédés. Vous pouvez ensuite utiliser le commutateur pour restaurer la mappe NIS pour d'autres entrées.

bill               cs.csc.edu:/export/home/bill
bonny              cs.csc.edu:/export/home/bonny

Après avoir consulté la mappe incluse, si aucune correspondance n'est trouvée, automount poursuit l'analyse de la mappe actuelle. Par conséquent, vous pouvez ajouter plusieurs entrées après une entrée +.

bill               cs.csc.edu:/export/home/bill
bonny              cs.csc.edu:/export/home/bonny
+auto_home 

La carte qui est incluse peut être un fichier local ou une mappe intégrée. N'oubliez pas que seuls les fichiers locaux peuvent contenir des entrées +.

+auto_home_finance      # NIS+ map
+auto_home_sales        # NIS+ map
+auto_home_engineering  # NIS+ map
+/etc/auto_mystuff      # local map
+auto_home              # NIS+ map
+-hosts                 # built-in hosts map 

Mappes autofs exécutables

Vous pouvez créer une mappe autofs qui exécute des commandes permettant de générer les points de montage autofs. Vous pouvez bénéficier de l'utilisation d'une mappe autofs exécutable si vous devez être en mesure de créer la structure autofs à partir d'une base de données ou d'un fichier plat. L'inconvénient de l'utilisation d'une mappe exécutable est qu'elle doit être installée sur chaque hôte. Une mappe exécutable ne peut pas être incluse ni dans le NIS ni dans le service de noms NIS+.

La mappe exécutable doit disposer d'une entrée dans le fichier auto_master.

/execute    auto_execute

Voici un exemple d'une mappe exécutable :

#!/bin/ksh
#
# executable map for autofs
#

case $1 in
             src)  echo '-nosuid,hard bee:/export1' ;;
esac

Pour cet exemple fonctionne, le fichier doit être installé comme /etc/auto_execute et doit avoir le bit d'exécution défini. Configurer les permissions sur 744. Dans ces circonstances, l'exécution de la commande ci-dessous est à l'origine du montage du système de fichiers /export1 de bee :

% ls /execute/src

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

Vous pouvez modifier, supprimer ou ajouter des entrées aux mappes pour répondre aux besoins de votre environnement. Au fur et à mesure du changement de l'emplacement des applications et autres systèmes de fichiers nécessaires pour les utilisateurs, les mappes doivent refléter ces changements. Vous pouvez modifier les mappes autofs à tout moment. L'entrée en vigueur de vos modifications lors du prochain montage d'automountd d'un système de fichiers dépend de la mappe que vous modifiez et du type de modification apportée.

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

Lors du démarrage, autofs est appelé par le service svc:/system/filesystem/autofs et autofs vérifie la mappe principale auto_master. Autofs est soumis aux règles qui sont traitées par la suite.

Autofs utilise le nom de service qui est spécifié dans l'entrée automount du fichier /etc/nsswitch.conf. Si NIS+ est spécifié, par opposition à des fichiers locaux ou NIS, tous les noms de mappe sont utilisés en tant que tels. Si NIS est sélectionné et qu'autofs ne peut pas afficher une mappe dont autofs a besoin, mais trouve un nom de mappe qui contient un ou plusieurs caractères de soulignement, les caractères de soulignement ne sont pas changés en points. Cette modification permet aux anciens noms de fichiers NIS de fonctionner. Ensuite, autofs vérifie à nouveau la mappe, comme illustré dans la Figure 6-6.

Figure 6-6 Utilisation du service de noms par autofs

L'activité d'écran pour cette session ressemblerait à l'exemple suivant.

$ grep /home /etc/auto_master
/home           auto_home

$ ypmatch brent auto_home
Can't match key brent in map auto_home.  Reason: no such map in
server's domain.

$ ypmatch brent auto.home
diskus:/export/home/diskus1/&

Si l'option "fichiers" est sélectionnée en tant que service de noms, toutes les mappes sont supposées être des fichiers locaux dans le répertoire /etc. Autofs interprète un nom de mappe qui commence par une barre oblique (/) comme étant locale quel que soit le service de noms utilisé par autofs.