13.1. Familiarizándose con NIS

NIS guarda la información de la base de datos en ficheros llamados mapas, que contienen pares clave-valor. Un ejemplo de par clave-valor es el identificativo de un usuario (login) y la forma encriptada de su contraseña. Los mapas se almacenan en un nodo central que corre el servidor NIS, desde el que los clientes deben obtener la información mediante varias llamadas RPC. Con bastante frecuencia, los mapas se almacenan en ficheros DBM. [1]

Los mapas suelen generarse a partir de ficheros de texto maestros como el /etc/hosts o el /etc/passwd. Para algunos ficheros se crean varios mapas, uno para cada tipo de clave de búsqueda. Por ejemplo, usted puede buscar en el fichero hosts tanto nombres de nodo como direcciones IP. Así pues, de él se derivan dos mapas NIS, llamados hosts.byname y hosts.baddr. La Tabla 13-1 muestra una lista de mapas comunes y los ficheros a partir de los que se generan.

Puede encontrar soporte para otros ficheros y mapas en otros paquetes NIS. Normalmente contienen información sobre aplicaciones que no se discuten en este libro, como el mapa bootparams utilizado por el servidor bootparamd de Sun.

Hay mapas para los que la gente usa normalmente apodos, que son más cortos y por tanto más fáciles de escribir. Tenga en cuenta que estos apodos sólo los entienden ypcat e ypmatch, dos herramientas para comprobar su configuración NIS. Para obtener una lista completa de los apodos que entienden estas herramientas, ejecute el siguente comando:

$ ypcat -x Use "passwd" for "passwd.byname" Use "group" for "group.byname" Use "networks" for "networks.byaddr" Use "hosts" for "hosts.byaddr" Use "protocols" for "protocols.bynumber" Use "services" for "services.byname" Use "aliases" for "mail.aliases" Use "ethers" for "ethers.byname"

El servidor NIS se llama tradicionalmente ypserv. Para una red mediana, normalmente un solo servidor es suficiente; las redes grandes pueden elegir ejecutar varios de estos servidores en máquinas diferentes y en segmentos de red diferentes para reducir la carga en las máquinas servidor y en los enrutadores. Estos servidores se sincronizan haciendo a uno de ellos el servidor maestro, y a los otros servidores esclavo. Los mapas se crean sólo en el nodo del servidor maestro. Desde él se distribuyen a todos los esclavos.

Hemos hablado muy vagamente sobre “redes.” Hay un término distintivo en NIS que se refiere a una colección de todos los nodos que comparten parte de sus datos de configuración de sistema a través de NIS: el dominio NIS. Desafortunadamente, los dominios NIS no tienen absolutamente nada en común con los dominios que nos encontramos en DNS. Para evitar cualquier ambigüedad a lo largo de este capítulo, siempre especificaremos a qué tipo de dominio nos referimos.

Los dominios NIS tienen una función puramente administrativa. En general son transparentes a los usuarios, excepto al compartir contraseñas entre todas las máquinas del dominio. Por tanto, el nombre que se le da a un dominio NIS es relevante sólo para los administradores. Normalmente, cualquier nombre servirá, mientras sea distinto a cualquier otro dominio NIS de su red local. Por ejemplo, la administradora de la Cervecería Virtual puede querer crear dos dominios NIS, uno para la propia Cervecería, y otro para la Vinatera, a los que llamará cerveceria y vinatera respectivamente. Otro proceder común es usar simplemente el dominio DNS como dominio NIS.

Para establecer y mostrar el dominio NIS de su nodo, puede usar el comando domainname. Cuando se invoca sin argumentos, imprime el dominio NIS actual; para establecer el dominio, hace falta ser superusuario:

# domainname cerveceria

Los dominios NIS determinan a qué servidor NIS consultará una aplicación. Por ejemplo, el programa login de un nodo de la Vinatera debe, por supuesto, consultar sólo al servidor NIS de la Vinatera (o a uno de ellos, si hay varios) la contraseña de un usuario, mientras que una aplicación de un nodo de la Cervecería debe llamar al servidor de la Cervecería.

Queda un misterio por resolver: ¿cómo averigua un cliente a qué servidor conectarse? La solución más simple sería utilizar un fichero de configuración que diga el nombre del nodo que hace de servidor. Sin embargo, esta solución es algo inflexible porque no permite a los clientes utilizar diferentes servidores (del mismo dominio, claro) dependiendo de su disponibilidad. Por tanto, las implementaciones de NIS cuentan con un demonio especial llamado ypbind para detectar un servidor NIS adecuado dentro del dominio NIS. Antes de realizar una consulta NIS, una aplicación averigua primero qué servidor usar mediante ypbind.

ypbind busca servidores haciendo un broadcast a la red IP local; se asume que el primero en responder es el más rápido, y es el utilizado en todas las consultas NIS subsiguientes. Después de que ha transcurrido un cierto intervalo de tiempo, o si el servidor deja de estar disponible, ypbind busca de nuevo servidores activos.

La ligadura dinámica es útil sólo cuando su red proporciona más de un servidor NIS. Además, la ligadura dinámica introduce un problema de seguridad. ypbind cree ciegamente en cualquiera que responda, sea un humilde servidor NIS o un intruso malicioso. No es necesario decir que esto es especialmente problemático si usted maneja sus bases de datos de contraseñas a través de NIS. Para protegerse de esto, el programa ypbind de Linux le proporciona la opción de buscar un servidor NIS en la red local o configurar el nombre de nodo del servidor NIS en un fichero de configuración.