Cómo funciona autofs

Autofs es un servicio por parte del cliente que monta automáticamente el sistema de archivos adecuado. Los componentes que trabajan juntos para lograr el montaje automático son los siguientes:

• El comando automount

• El sistema de archivos autofs

• El daemon automountd

El servicio automount, svc:/system/filesystem/autofs, que se invoca en el momento de inicio del sistema, lee el archivo de mapa maestro auto_master para crear el conjunto inicial de montajes de autofs. Estos montajes de autofs no se montan automáticamente en momento de inicio. Estos montajes son puntos en los que los sistemas de archivos se montan en el futuro. Estos puntos también se conocen como nodos desencadenadores.

Después de que los montajes autofs están configurados, estos montajes puede desencadenar sistemas de archivos para que se monten en ellos. Por ejemplo, cuando autofs recibe una solicitud para acceder a un sistema de archivos que no está montado en la actualidad, autofs invoca el comando automountd , que monta el sistema de archivos solicitado.

Después del montaje inicial de autofs, se utiliza el comando automount para actualizar los montajes autofs según sea necesario. El comando compara la lista de los montajes en el mapa auto_master con la lista de sistemas de archivos montados en el archivo de tabla de montaje /etc/mnttab (anteriormente /etc/mtab). automount realiza los cambios adecuados. Este proceso les permite a los administradores del sistema cambiar la información de montaje dentro de auto_master y que los procesos autofs utilicen esos cambios sin detener y reiniciar el daemon autofs. Una vez que el sistema de archivos está montado, no es necesario que automountd realice ninguna acción hasta que el sistema de archivos se desmonte automáticamente.

A diferencia de mount, automount no lee el archivo /etc/vfstab (que es específico para cada equipo) para obtener una lista de sistemas de archivos para montar. El comando automount se controla dentro de un dominio y en los equipos a través de espacio de nombres o archivos locales.

A continuación se muestra una descripción general simplificada de cómo funciona autofs.

El daemon automountd se inicia en el momento del inicio mediante el servicio svc:/system/filesystem/autofs. Consulte la Figura 6-3. Este servicio también ejecuta el comando automount, que lee el mapa maestro e instala los puntos de montaje de autofs. Consulte Cómo Autofs inicia el proceso de navegación (mapa maestro) para obtener más información.

Figura 6-3 El servicio svc:/system/filesystem/autofs inicia automount

Autofs es un sistema de archivos de núcleos que admite montaje y desmontaje automático.

Cuando se realiza una solicitud para acceder a un sistema de archivos en un punto de montaje autofs, se produce lo siguiente:

1. Autofs intercepta la solicitud.

2. Autofs envía un mensaje al comando automountd para el sistema de archivos solicitado que se montará.

3. automountd localiza la información del sistema de archivos en un mapa, crea el nodo desencadenador y realiza el montaje.

4. Autofs permite que continue la solicitud interceptada.

5. Autofs desmonta el sistema de archivos después de un período de inactividad.

Cómo navega autofs por la red (mapas)

Autofs busca una serie de mapas para navegar a través de la red. Los mapas son archivos que contienen información como las entradas de las contraseñas de todos los usuarios en una red o los nombres de todos los equipos de una red. De hecho, los mapas contienen equivalentes para toda la red de los archivos de administración de UNIX. Los mapas están disponibles localmente o a través de un servicio de nombres de red, como NIS o NIS+. Consulte Modificar cómo navega autofs por la red (modificación de mapas) .

Cómo Autofs inicia el proceso de navegación (mapa maestro)

El comando automount lee el mapa maestro en el inicio del sistema. Cada entrada del mapa maestro es un nombre de mapa directo o un nombre de mapa indirecto, su ruta de acceso y sus opciones de montaje, como se muestra en la Figura 6-4. El orden específico de las entradas no es importante. automount compara las entradas del mapa maestro con las entradas en la tabla de montaje para generar una lista actual.

Figura 6-4 Navegación por el mapa maestro

Proceso de montaje autofs

Lo que hace el servicio autofs cuando se desencadena una solicitud de montaje depende de cómo estén configurados los mapas del montador automático. El proceso de montaje normalmente es el mismo para todos los montajes. Sin embargo, el resultado final cambia según el punto de montaje que se especifica y la complejidad de los mapas. El proceso de montaje incluye la creación de nodos desencadenadores.

Montaje autofs simple

Para ayudar a explicar el proceso de montaje autofs, supongamos que los siguientes archivos están instalados.

$ 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

Cuando se accede al directorio /share, el servicio autofs crea un nodo desencadenador para /share/ws, que es una entrada de /etc/mnttab que se parece a la siguiente entrada:

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

Cuando se accede al directorio /share/ws, el servicio autofs completa el proceso con estos pasos:

1. Comprueba la disponibilidad del servicio de montaje del servidor.

2. Monta el sistema de archivos solicitados en /share. Ahora el archivo /etc/mnttab contiene las siguientes entradas.

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

Montaje jerárquico

Cuando se definen varias capas en los archivos del montador automático, el proceso de montaje se hace más complejo. Por ejemplo, si amplía el archivo /etc/auto_shared del ejemplo anterior para incluir lo siguiente:

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

El proceso de montaje es básicamente igual que el ejemplo anterior en el que se accede al punto de montaje /share/ws. Además, se crea un nodo desencadenador hacia el siguiente nivel (/usr) en el sistema de archivos /share/ws de forma que el siguiente nivel se puede montar si es que se accede a él. En este ejemplo, /export/share/ws/usr debe existir en el servidor NFS para que se cree el nodo desencadenador.

---

Precaución - No utilice la opción -soft al especificar capas jerárquicas. Consulte Desmontaje de autofs para obtener una explicación de esta limitación.

---

Desmontaje de autofs

El desmontaje que se produce después de un cierto tiempo de inactividad es ascendente (orden inverso de montaje). Si uno de los directorios en un nivel superior en la jerarquía está ocupado, sólo los sistemas de archivos debajo de ese directorio se desmontan. Durante el proceso de desmontaje, se eliminan todos los nodos desencadenadores y se desmonta el sistema de archivos. Si el sistema de archivos está ocupado, el desmontaje falla y los nodos desencadenadores se vuelven a instalar.

---

Precaución - No utilice la opción -soft al especificar capas jerárquicas. Si se utiliza la opción -soft, las solicitudes para volver a instalar los nodos desencadenadores se ponen en tiempo de espera. Si no se vuelven a instalar los nodos desencadenadores, no se obtiene acceso al siguiente nivel de montajes. La única forma para eliminar este problema es que el montador automático desmonte todos los componentes de la jerarquía. El montador automático puede completar el desmontaje si espera que los sistemas de archivos se desmonten automáticamente o si reinicia el sistema.

---

Cómo selecciona autofs los archivos de sólo lectura más cercanos para los clientes (ubicaciones múltiples)

El mapa directo de ejemplo contiene lo siguiente:

/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 

Los puntos de montaje /usr/man y /usr/spool/news muestran más de una ubicación, tres ubicaciones para el primer punto de montaje y dos ubicaciones para el segundo punto de montaje. Cualquiera de las ubicaciones replicadas puede proporcionar el mismo servicio para cualquier usuario. Este procedimiento sólo es necesario cuando se monta un sistema de archivos de sólo lectura, ya que debe tener algún control sobre las ubicaciones de los archivos que escribe o modifica. Debe evitar modificar archivos en un servidor en un momento y, minutos más tarde, modificar el “mismo” archivo en otro servidor. El beneficio es que se utiliza automáticamente el mejor servidor disponible sin esfuerzo por parte del usuario.

Si los sistemas de archivos están configurados como réplicas (consulte ¿Qué es un sistema de archivos replicado?), los clientes tienen la ventaja de utilizar conmutación por error. No sólo se determina automáticamente el mejor servidor, sino que si el servidor deja de estar disponible, el cliente utiliza automáticamente el siguiente mejor servidor.

Un ejemplo de un buen sistema de archivos para configurar como una réplica son las páginas del comando man. En una red grande, más de un servidor puede exportar el conjunto actual de páginas del comando man. No importa desde qué servidor se montan las páginas del comando man si el servidor ejecuta y exporta sus sistemas de archivos. En el ejemplo anterior, se expresan varias ubicaciones de montaje como una lista de ubicaciones de montaje en la entrada de mapa.

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

En este ejemplo, puede montar las páginas del comando man de los servidores oak, rose o willow. El mejor servidor depende de una serie de factores, incluidos los siguientes:

• El número de servidores que admiten un nivel de protocolo NFS particular

• La proximidad del servidor

• La ponderación

Durante el proceso de ordenación, se realiza un recuento del número de servidores que admiten cada versión del protocolo NFS. La versión del protocolo compatible con la mayoría de los servidores se convierte en el protocolo que se utiliza de manera predeterminada. Esta selección proporciona al cliente el número máximo de servidores de los que puede depender.

Una vez que se encuentra el mayor subconjunto de servidores con la misma versión del protocolo, esa lista de servidores se ordena por proximidad. Para determinar la proximidad, se inspeccionan las direcciones IPv4. Las direcciones IPv4 muestran qué servidores se incluyen en cada subred. Los servidores en una subred local obtienen preferencia sobre los servidores en una subred remota. La preferencia del servidor más cercano reduce la latencia y el tráfico en la red.

La Figura 6-5 ilustra la proximidad de servidor.

Figura 6-5 Proximidad de servidor

Si varios servidores que admiten el mismo protocolo se encuentran en la subred local, se determina el tiempo de conexión de cada servidor y se utiliza el servidor más rápido. El proceso de ordenación también puede estar influido por el uso de ponderación (consulte Autofs y ponderación).

Por ejemplo, si hay más servidores versión 4, la versión 4 pasa a ser el protocolo que se utiliza de manera predeterminada. Sin embargo, ahora el proceso de ordenación es más complejo. A continuación se exponen algunos ejemplos de cómo la funciona el proceso de ordenación:

• Los servidores en una subred local obtienen preferencia sobre los servidores en una subred remota. Por lo tanto, si un servidor versión 3 está en la subred local y el servidor versión 4 más próximo se encuentra en una subred remota, el servidor versión 3 tiene preferencia. Del mismo modo, si la subred local tiene servidores versión 2, éstos tienen preferencia sobre las subredes remotas con servidores versión 3 y versión 4.

• Si la subred local tiene un número variado de servidores versión 2, versión 3 y versión 4, es necesario seguir realizando el proceso de ordenación. El montador automático prefiere la versión más alta de la subred local. En este ejemplo, la versión 4 es la versión más alta. Sin embargo, si la subred local tiene más servidores versión 3 o versión 2 que servidores versión 4, el montador automático “disminuye” de la versión más alta en la subred local de a una versión. Por ejemplo, si la subred local dispone de tres servidores con la versión 4, tres servidores con la versión 3 y diez servidores con la versión 2, se selecciona un servidor versión 3.

• De igual forma, si la subred local tiene un número variado de servidores versión 2 y versión 3, el montador automático primero busca qué versión representa la versión más alta de la subred local. A continuación, el montador automático recuenta el número de servidores que ejecuta cada versión. Si la versión más alta en la subred local también representa a la mayoría de los servidores, se selecciona la versión más alta. Si una versión más baja tiene más servidores, el montador automático disminuye de la versión más alta en la subred local de a una versión. Por ejemplo, si hay más servidores versión 2 en la subred local que servidores versión 3, se selecciona un servidor versión 2.

Con la conmutación por errores, la ordenación se comprueba en el momento del montaje cuando se selecciona un servidor. Es útil contar con varias ubicaciones en un entorno donde los servidores individuales no puedan exportar sus sistemas de archivos temporalmente.

La conmutación por errores es especialmente útil en una red grande con muchas subredes. Autofs elige el servidor adecuado y es capaz de confinar el tráfico de red NFS a un segmento de la red local. Si un servidor tiene varias interfaces de red, puede mostrar el nombre de host que está asociado con cada una de las interfaces de red si la interfaz fuera otro servidor. Autofs selecciona la interfaz más próxima al cliente.

Para obtener más información, consulte la página del comando man automount(1M).

Autofs y ponderación

Puede influir en la selección de los servidores con el mismo nivel de proximidad si añade un valor de ponderación al mapa autofs. Por ejemplo:

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

Los números entre paréntesis indican una ponderación. Los servidores sin una ponderación tienen un valor de cero y, por lo tanto, es más probable que se seleccionen. Cuanto mayor sea el valor de ponderación, menos probabilidades hay de que se seleccione ese servidor.

Variables en una entrada de mapa

Puede crear una variable específica del cliente si agrega un signo de dólar ($) a su nombre. La variable le ayuda a acomodar diferentes tipos de arquitecturas que están accediendo a la misma ubicación del sistema de archivos. También puede utilizar llaves para delimitar el nombre de la variable de las letras o dígitos agregados. La Tabla 6-2 muestra las variables de mapa predefinidas.

Tabla 6-2 Variables de mapa predefinidas

Puede utilizar variables en cualquier parte de una línea de entrada excepto como clave. Por ejemplo, suponga que tiene un servidor de archivos que exporta binarios para SPARC y arquitecturas x86 de /usr/local/bin/sparc y /usr/local/bin/x86 respectivamente. Los clientes pueden montarse mediante una entrada de mapa como la siguiente:

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

La misma entrada para todos los clientes se aplica a todas las arquitecturas.

Mapas que hacen referencia a otros mapas

Una entrada de mapa +nombre_mapa que se usa en un mapa de archivos hace que automount lea el mapa especificado como si estuviera incluido en el archivo actual. Si nombre_mapa no está precedido por una barra diagonal, autofs trata el nombre de mapa como una cadena de caracteres y utiliza la política de conmutación de nombre y servicio para buscar el nombre del mapa. Si el nombre de ruta es un nombre de ruta absoluto, automount comprueba un mapa local de dicho nombre. Si el nombre del mapa comienza con un guión (-), automount consulta el mapa integrado adecuado, como hosts .

Este archivo de conmutador de nombre y servicio contiene una entrada para autofs con la etiqueta automount, que contiene el orden en que los servicios de nombres se buscan. El siguiente archivo es un ejemplo de un archivo de conmutador de nombre y servicio.

#
# /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 

En este ejemplo, los mapas locales se buscan antes que los mapas NIS. Por lo tanto, puede tener unas pocas entradas en su mapa /etc/auto_home para los directorios principales a los que se accede con más frecuencia. A continuación, puede utilizar el conmutador a fin de volver al mapa NIS para las otras entradas.

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

Después de consultar el mapa incluido, si no se encuentra ninguna coincidencia, automount continúa la exploración del mapa actual. Por lo tanto, puede agregar más entradas después de una entrada +.

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

El mapa que se incluye puede ser un archivo local o un mapa integrado. Recuerde, sólo los archivos locales pueden contener entradas +.

+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 

Mapas autofs ejecutables

Puede crear un mapa autofs que ejecute algunos comandos para generar puntos de montaje autofs. Puede beneficiarse del uso de un mapa autofs ejecutable si necesita poder crear la estructura autofs desde una base de datos o un archivo plano. El inconveniente que presenta el uso de un mapa ejecutable es que el mapa debe instalarse en cada host. Un mapa ejecutable no puede incluirse en el servicio de nombres NIS o NIS+.

El mapa ejecutable debe contener una entrada en el archivo auto_master.

/execute    auto_execute

A continuación se muestra un ejemplo de mapa ejecutable:

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

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

Para que este ejemplo funcione, el archivo debe ser instalado como /etc/auto_execute y debe disponer de un conjunto de bits ejecutable. Establezca los permisos en 744. En estas circunstancias, si ejecuta el siguiente comando, hace que se monte el sistema de archivos /export1 de bee:

% ls /execute/src

Modificar cómo navega autofs por la red (modificación de mapas)

Puede modificar, suprimir o agregar entradas a mapas para satisfacer las necesidades de su entorno. Cuando las aplicaciones y otros sistemas de archivos que los usuarios necesitan cambian su ubicación, los mapas deben reflejar los cambios. Puede modificar los mapas autofs en cualquier momento. Que las modificaciones sean efectivas la próxima vez que automountd monte un sistema de archivos depende de qué mapa se modifique y de qué tipo de cambios realice.

Comportamiento predeterminado de autofs con los servicios de nombres

En el momento del inicio, el servicio svc:/system/filesystem/autofs invoca a autofs, y autofs comprueba el mapa maestro auto_master. Autofs está sujeto a las reglas que se tratan más adelante.

Autofs utiliza el servicio de nombres que se especifica en la entrada automount del archivo /etc/nsswitch.conf. Si NIS+ se especifica, en contraposición con los archivos locales o NIS, todos los nombres de mapas se utilizan tal como están. Si se selecciona NIS y autofs no puede encontrar un mapa que autofs necesite, pero encuentra un nombre de mapa que contiene uno o más guiones bajos, los guiones bajos se cambian por puntos. Este cambio permite que los antiguos nombres NIS funcionen. A continuación, autofs vuelve a comprobar el mapa, como se muestra en la Figura 6-6.

Figura 6-6 Cómo utiliza autofs el servicio de nombres

La actividad de la pantalla para esta sesión se asemeja al ejemplo siguiente.

$ 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 selecciona “archivos” como servicio de nombres, se asume que todos los mapas serán archivos locales en el directorio /etc. Autofs interpreta un nombre de mapa que comienza con una barra diagonal (/) como local, independientemente de qué servicio de nombres utilice autofs.