garl10

 

Capítulo 10


El Sistema de Información de Red (NIS)

Cuando se usa una red de área local, su objetivo fundamental es, normalmente, proporcionar a sus usuarios un entorno que haga a la red transparente. Para este fin una importante piedra de toque es mantener datos vitales, como la información de cuentas de usuario, sincronizadas entre todos los nodos. Vimos anteriormente que para resolver nombres de nodos existe un potente y sofisticado servicio denominado DNS. Para otras tareas, sin embargo, no existe un servicio especializado similar. Mas aun, si usted sólo está administrando una pequeña LAN sin conexión a Internet, puede que no le merezca la pena el esfuerzo de instalar un DNS.

Esta es la razón por la que Sun desarrolló NIS, el Sistema de Información de Red. NIS proporciona facilidades de acceso genérico a bases de datos que pueden ser usadas para distribuir información como la contenida en los ficheros passwd y groups entre todos los nodos de su red. Esto hace que la red aparezca como un sistema único, con las mismas cuentas en todos los nodos. De forma similar usted puede usar NIS para distribuir el fichero de información de nombres de nodos /etc/hosts entre todas las máquinas de la red.

NIS está basado en RPC, e incluye un servidor, una biblioteca para la parte del cliente, y varias herramientas de administración. Originalmente NIS se llamaba Yellow Pages1, o YP, que todavía son términos ampliamente usados para referirse informalmente a este servicio. Por otra parte Yellow Pages es una marca registrada de la compañía British Telecom, la cual pidió que Sun dejara de utilizar ese nombre. Pero, como algunos nombres impactan mucho entre la gente, YP continúa viviendo como prefijo en los nombres de la mayoría de los comandos relacionados con NIS como ypserv, ypbind, etc.

_____________________________________________
1 N. del T.: Páginas Amarillas

 

Hoy en día NIS está disponible en prácticamente todos los sistemas UNIX, y hay incluso implementaciones gratuitas de él. Una de ellas es de la edición BSD Net-2, derivada de una implementación de referencia de dominio público donada por Sun. El código de la biblioteca cliente de esta versión existe en la GNU libc desde hace mucho tiempo, mientras que los programas de administración han sido recientemente portados a Linux por Swen Thümmler.2 Falta, sin embargo, un servidor NIS en la implementación de referencia. Tobias Reber ha escrito otro paquete NIS incluyendo todas las herramientas y un servidor; se llama yps.3

Actualmente, el código de NIS está siendo reescrito por completo por Peter Eriksson4, se denominará NYS y soportará tanto el NIS normal como la revisión ampliada de Sun, el NIS+. NYS no solo proporciona un conjunto de herramientas NIS y un servidor, sino que también añade un nuevo y completo conjunto de funciones de biblioteca que muy probablemente se incluirán con el tiempo en la libc estándar. Esto incluye un nuevo sistema de configuración para resolver nombres de nodos que reemplace el sistema actual que usa el fichero host.conf. Las características de estas funciones serán discutidas más adelante.

Este capítulo se centrará en NYS más que en los otros dos paquetes, a los que nos referiremos como el código NIS "tradicional". Si usted desea utilizar alguno de esos paquetes, las instrucciones de este capítulo podrían ser suficientes o tal vez no. Para obtener información adicional, por favor, consiga un libro estándar sobre NIS como el NFS y NIS de Hal Stern (véase [Stern92]).

Por el momento NYS está todavía en desarrollo y por lo tanto las utilidades estándar de Linux como los programas de red o el programa de login todavía no tienen en cuenta el sistema de configuración de NYS. Por lo tanto, hasta que NYS no sea incluido en la libc principal tendrá que compilar todos esos programas usted mismo si quiere conseguir que usen NYS. Para ello, en los Makefiles de cualquiera de esas aplicaciones deberá especificar -lnsl como la última opción antes de libc al enlazador. Esto enlazará las funciones relevantes de libnsl, la biblioteca NYS, en lugar de la biblioteca C estándar.

10.1 Familiarización con NIS
10.2 NIS frente a NIS+
10.3 El lado cliente de NIS
10.4 Ejecución de un servidor NIS
10.5 Configurar un Cliente NIS con NYS
10.6 Elección de los Mapas Correctos
10.7 Uso de los mapas passwd y group
10.8 Uso de NIS con Soporte Shadow
10.9 Uso del Código NIS Tradicional

10.1 Familiarización con NIS

NIS mantiene información de la base de datos en los llamados mapas que contienen pares clave-valor. Los mapas se almacenan en un nodo central que está ejecutando el servidor NIS y del que los clientes pueden obtener la información a través de varias llamadas RPC.

Muy frecuentemente, los mapas se almacenan en ficheros DBM.5

_____________________________________________
2 Que puede ser localizado en swen@uni-paderborn.de. Los clientes NIS están disponibles como yp-linux.tar.gz en metalab.unc.edu en el directorio system/Network.3 La última versión (en la fecha en que se escribió este documento) es yps-0.21 y puede obtenerse en ftp.lysator.liu.se, en el directorio /pub/NYS.
4 Localizable en pen@lysator.liu.se.

 

Los mapas en sí mismos suelen ser generados a partir de ficheros de texto maestros como /etc/hosts o /etc/passwd. Para algunos ficheros se crean varios mapas, uno por cada tipo de clave de búsqueda. Por ejemplo, usted podría buscar en el fichero hosts tanto por un nombre de nodo como por su dirección IP. Así pues, de él se derivan dos mapas NIS, llamados hosts.byname y hosts.byaddr respectivamente. La tabla 10.1 lista los mapas típicos y los ficheros de los que son generados.

Fichero Maestro

Mapa(s)

/etc/hosts

hosts.byname hosts.byaddr

/etc/networks

networks.byname networks.byaddr

/etc/passwd

passwd.byname passwd.byuid

/etc/group

group.byname group.bygid

/etc/services

services.byname services.bynumber

/etc/rpc

rpc.byname rpc.bynumber

/etc/protocols

protocols.byname protocols.bynumber

/usr/lib/aliases

mail.aliases

Tabla 10.1: Algunos mapas NIS estándar y los ficheros correspondientes.

 

Hay otros ficheros y mapas para los que puede encontrar soporte en uno u otro paquete NIS. Estos pueden contener información sobre aplicaciones no tratadas en este libro, como el mapa bootparams6 que puede ser usado por algunos servidores BOOTP, o mapas que actualmente no tienen ninguna función en Linux (como los mapas ethers.byname y ethers.byaddr).

La gente usa habitualmente apodos para algunos mapas, ya que son más cortos y por lo tanto más fáciles de escribir. Para obtener una lista completa de los apodos7 reconocidos por sus herramientas NIS, ejecute el siguiente comando:

$ ypcat -x
NIS map nickname translation table:
"passwd" -> "passwd.byname"
"group" -> "group.byname"
"networks" -> "networks.byaddr"
"hosts" -> "hosts.byname"
"protocols" -> "protocols.bynumber"
"services" -> "services.byname"
"aliases" -> "mail.aliases"
"ethers" -> "ethers.byname"
"rpc" -> "rpc.bynumber"
"netmasks" -> "netmasks.byaddr"
"publickey" -> "publickey.byname"
"netid" -> "netid.byname"
"passwd.adjunct" -> "passwd.adjunct.byname"
"group.adjunct" -> "group.adjunct.byname"
"timezone" -> "timezone.byname"

_____________________________________________
5 DBM es una biblioteca de manejo de bases de datos sencillas que usa técnicas hashing para acelerar operaciones de búsqueda. Existe una implementación gratuita de DBM perteneciente al proyecto GNU llamada gdbm, que forma parte de la mayoría de las distribuciones de Linux.
6 N. del T.: relacionado con los parámetros de arranque
7 N. del T.: del inglés nicknames

 

El servidor NIS suele llamarse ypserv. Para una red de tipo medio un único servidor suele ser suficiente; en redes mayores pueden elegir ejecutar varios en máquinas diferentes y en diferentes segmentos para aliviar la carga en los servidores y en los encaminadores.

Estos servidores están sincronizados haciendo que uno de ellos sea el servidor maestro y que los demás sean servidores esclavos. Los mapas se crearán solo en la máquina del servidor maestro. A partir de ahí son distribuidos a todos los esclavos.

Habrá notado usted que hemos estado hablando de "redes" todo el rato muy vagamente; por supuesto existe un concepto diferenciado en NIS sobre lo que es un dominio en la red: es el conjunto de todos los nodos que comparten parte de sus datos de configuración del sistema mediante NIS. Desafortunadamente los dominios NIS no tienen absolutamente nada que ver con los dominios que podemos encontrar en DNS. Por ello, para evitar cualquier tipo de ambigüedad a lo largo de este capítulo, especificaremos en todo momento el tipo de dominio al que nos estemos refiriendo.

Los dominios NIS tienen solo una función puramente administrativa. Son, además, invisibles para los usuarios. Por ello el nombre dado a un dominio NIS es solo relevante para administradores. Por lo general cualquier nombre valdrá con tal de que sea distinto de cualquier otro nombre de dominio NIS de su red local. Por ejemplo, el administrador de la Cervecera Virtual puede decidir crear dos dominios NIS, uno para la Cervecera en sí, y otro para la Vinatera, a los que llama cervecera y vinatera respectivamente. Otra idea bastante utilizada es usar simplemente el nombre de dominio DNS también para el NIS. Para establecer y ver el nombre de dominio NIS de su nodo puede usar el comando domainname.

Cuando se ejecuta sin ningún argumento, muestra el nombre de dominio NIS actual; para establecer el nombre de dominio, debe usted entrar como superusuario y escribir:

# domainname cervecera

Los dominios NIS determinan a que servidor NIS preguntarán las aplicaciones. Por ejemplo, el programa login de un nodo de la Vinatera debería, por supuesto, pedir información de la contraseña de un usuario solo al servidor NIS de la Vinatera (o a uno de ellos si es que hay varios), mientras que una aplicación de un nodo de la Cervecera debería arreglárselas con el servidor de la Cervecera.

Queda un misterio por resolver: como sabe un cliente a que servidor conectarse. La solución más simple seria tener un fichero de configuración que diga el nodo en el que encontrar el servidor. Sin embargo, esta solución es bastante inflexible porque no permite a los clientes usar servidores diferentes (del mismo dominio, se entiende), dependiendo de su disponibilidad. Por ello las implementaciones tradicionales de NIS se apoyan en un demonio especial denominado ypbind para detectar un servidor NIS adecuado dentro de su dominio NIS. Cualquier aplicación, antes de poder realizar cualquier consulta NIS, debe averiguar primero, a través de ypbind, qué servidor usar.

ypbind busca los servidores mandando un mensaje de difusión por toda la red IP local. El primero en responder se supone que será el más rápido potencialmente y será el que se use en todas las consultas NIS subsiguientes. Después de un cierto intervalo de tiempo, o si el servidor se vuelve inaccesible, ypbind volverá a buscar los servidores activos.

Ahora bien, hay dos aspectos discutibles sobre el enlazado dinámico: uno es que raramente es necesario y el otro es que introduce un problema de seguridad: ypbind cree a ciegas a cualquiera que conteste, que podría ser lo mismo un humilde servidor NIS que un intruso malicioso. No hace falta decir que esto es especialmente problemático si usted maneja sus bases de datos de contraseñas a través de NIS. Para protegerse contra esto, NYS no usa ypbind por defecto, sino que obtiene el nombre de nodo del servidor de un fichero de configuración.

 

10.2 NIS frente a NIS+

NIS y NIS+ comparten poco más que su nombre y un objetivo común. NIS+ está estructurado de una forma completamente diferente. En lugar de un simple espacio de nombres con dominios NIS inconexos, usa un espacio de nombres jerárquico similar al de DNS. En lugar de mapas, usa tablas que están compuestas por filas y columnas, donde cada fila representa un objeto en la base de datos NIS+, mientras que las columnas cubren aquellas propiedades de los objetos que NIS+ conoce y que le interesan. Cada tabla de un dominio NIS+ dado incluye las de sus dominios padre. Además, una entrada en una tabla puede contener un enlace a otra tabla. Todas estas características hacen posible la estructuración de la información de muchas formas.

El NIS tradicional tiene un número de versión RPC de 2, mientras que NIS+ tiene un número de versión RPC de 3. NIS+ no parece ser ampliamente usado todavía 8, y no conozco tanto sobre él realmente (bueno, prácticamente nada). Por esta razón, no lo trataremos aquí. Si esta interesado en aprender mas sobre él, por favor, refiérase al manual de administración de NIS+ de Sun ([NISPlus]).

 

10.3 El lado cliente de NIS

Si está usted familiarizado con la escritura o el portado de aplicaciones de red, notará que la mayoría de los mapas NIS listados arriba corresponden a funciones de la biblioteca C.

Por ejemplo, para obtener información del fichero passwd, se suelen usar normalmente las funciones getpwnam(3) y getpwuid(3) que devuelven información de la cuenta asociada al nombre de usuario dado, o al identificador de usuario dado, respectivamente. En circunstancias normales, estas funciones realizarán la búsqueda requerida en el fichero estándar /etc/passwd.

Una implementación de estas funciones que tenga en cuenta NIS, sin embargo, modificará este comportamiento, y realizará una llamada RPC para que sea el servidor NIS el que realice la búsqueda del nombre o identificador de usuario. Esto ocurre de forma completamente transparente a la aplicación. La función podría "añadir" el mapa NIS o "sustituir" el fichero original con él. Por supuesto, esto no implica una modificación real del fichero, solo significa que a la aplicación le parece que el fichero ha sido sustituido o que le han añadido algo.

En las implementaciones tradicionales de NIS solía haber ciertas convenciones sobre que mapas se sustituían y cuales eran añadidos a la información original. Alguno, como el mapa passwd, requería modificaciones extrañas del fichero passwd que, si se hacían mal, podrían abrir agujeros de seguridad. Para evitar estos obstáculos, NYS usa un modo general de configuración que determina si un conjunto de funciones cliente en particular usa los ficheros originales, NIS o NIS+, y en que orden. Esto será descrito en otra sección mas adelante en este mismo capítulo.

 

10.4 Ejecución de un servidor NIS

Después de todo este parloteo técnico teórico, ya empieza a ser hora de que metamos mano al verdadero trabajo de configuración. En esta sección cubriremos la configuración de un servidor NIS. Si ya hay un servidor NIS corriendo en su red, no necesita configurar su propio servidor; en este caso puede usted saltarse esta sección.

_____________________________________________
8 N. del T.: En el momento de escribirse este manual esta afirmación era cierta. Sin embargo, hoy en día NIS+ es ampliamente usado por sus ventajas frente a NIS.

 

3 Observe que si únicamente va usted a experimentar con el servidor, tiene que asegurarse de que no lo configura con un nombre de dominio NIS que ya esté en uso en su red. Ello podría desbaratar todo el servicio de red y hacer a mucha gente desdichada, y muy enfadada.

Actualmente hay disponibles dos servidores NIS de forma gratuita para Linux, uno contenido en el paquete yps de Tobias Reber, y el otro en el paquete ypserv de Peter Eriksson. No debería importar cual utilice usted, independientemente de que usted use NYS o el código de cliente NIS estándar que existe actualmente en libc. En el momento de escribir esto, el código para manejar servidores NIS esclavos parece ser más completo en yps. Así que si tiene que tratar con servidores esclavo, yps puede ser una opción mejor.

Tras instalar el programa servidor (ypserv) en /usr/sbin, deberá crear el directorio que va a contener los ficheros mapa que su servidor va a distribuir. Al establecer un dominio NIS para el dominio cervecera, los mapas irían al fichero /var/yp/cervecera. El servidor determina si está sirviendo un dominio NIS en particular comprobando si el directorio mapa está presente. Si va a deshabilitar el servicio para algún dominio NIS, asegúrese de eliminar el directorio también.

Los mapas normalmente se almacenan en ficheros DBM para acelerar las búsquedas. Se crean a partir de los ficheros maestro usando un programa llamado makedbm (para el servidor de Tobias) o dbmload (para el servidor de Peter). Estos pueden no ser intercambiables. Transformar un fichero maestro a una forma entendible por dbmload normalmente requiere un poco de magia awk o sed, lo que tiende a ser un poco tedioso de escribir y difícil de recordar. Por ello, el paquete ypserv de Peter Eriksson contiene un Makefile (llamado ypMakefile) que realiza todos esos trabajos por usted. Debería instalarlo como Makefile en su directorio de mapas, y editarlo para que refleje los mapas que desee distribuir. Hacia el principio del fichero encontrará la etiqueta all que lista los servicios que ypserv ofrece. Por defecto, la línea es algo parecido a esto:

all: ethers hosts networks protocols rpc services passwd group netid

Si no desea producir los mapas ethers.byname y ethers.byaddr, por ejemplo, simplemente elimine la palabra ethers de la línea. Para probar su configuración, puede ser suficiente con empezar con solo uno o dos mapas, como los mapas services.*.

Tras editar el Makefile, y sin salir del directorio de mapas, teclee "make". Esto generará e instalará automáticamente los mapas. Debe asegurarse de actualizar los mapas cada vez que cambie los ficheros maestros, de otro modo los cambios seguirán siendo invisibles para la red.

La siguiente sección explica como configurar el código de cliente NIS. Si su configuración no funciona, debería comprobar si llega alguna petición a su servidor o no. Si especifica el parámetro -D al servidor NYS, éste imprimirá mensajes de depuración en la consola sobre todas las peticiones NIS entrantes, y los resultados devueltos. Esto debería darle una idea sobre donde puede estar el problema. El servidor de Tobias no tiene esa opción.

 

10.5 Configurar un Cliente NIS con NYS

A lo largo de lo que queda de este capítulo, cubriremos la configuración de un cliente NIS.

Su primer paso debería ser indicarle a NYS que servidor usar para el servicio NIS, estableciéndolo en el fichero de configuración /etc/yp.conf. Un fichero de ejemplo muy sencillo para un nodo en la red de la Vinatera seria algo así:

# yp.conf - Configuración YP para la biblioteca NYS.
#
domainname vinatera
ypserver vbardolino

La primera sentencia indica a los clientes NIS que pertenecen al dominio NIS vinatera. Si omite esta línea, NYS usará el nombre de dominio que usted asignó a su sistema con el comando domainname. La sentencia ypserver indica el servidor a usar. Por supuesto, la dirección IP correspondiente a vbardolino debe estar establecida en el fichero hosts; alternativamente, podría usar directamente la dirección IP en la sentencia ypserver.

En el fichero mostrado arriba, el comando ypserver indica a NYS que use el servidor indicado sea cual sea el dominio NIS actual. Sin embargo, si mueve frecuentemente su máquina entre diferentes dominios NIS, tal vez le interesaría mantener la información de varios dominios en el fichero yp.conf. Puede tener información sobre los servidores para varios dominios NIS en yp.conf añadiendo el nombre de dominio NIS a la sentencia ypserver.

Por ejemplo, podría cambiar el fichero del ejemplo anterior para que sea algo así:

# yp.conf - Configuración YP para la biblioteca NYS.
#
ypserver vbardolino vinatera
ypserver vstout cervecera

Esto le permite mover su máquina a cualquiera de los dos dominios simplemente con establecer el dominio NIS deseado durante el arranque con el comando domainname.

Una vez creado este fichero de configuración básico y de asegurarse de que tiene permiso de lectura para todo el mundo, debería realizar su primera prueba para comprobar si puede conectar con su servidor. Asegúrese de elegir cualquier mapa que su servidor distribuya, como hosts.byname, e intente obtenerlo usando la utilidad ypcat. ypcat, como todas las demás herramientas NIS, debe encontrarse en /usr/sbin.

# ypcat hosts.byname
191.72.2.2 vbeaujolais vbeaujolais.linus.lxnet.org
191.72.2.3 vbardolino vbardolino.linus.lxnet.org
191.72.1.1 vlager vlager.linus.lxnet.org
191.72.2.1 vlager vlager.linus.lxnet.org
191.72.1.2 vstout vstout.linus.lxnet.org
191.72.1.3 vale vale.linus.lxnet.org
191.72.2.4 vchianti vchianti.linus.lxnet.org

La salida que obtenga debe ser algo parecido a lo expuesto arriba. Si recibe un mensaje de error en su lugar que diga "Can't bind to server which serves domain" (no se puede conectar al servidor del dominio), o algo similar, entonces, o el nombre de dominio NIS que ha establecido no tiene definido su servidor correspondiente en yp.conf, o el servidor, por alguna razón, no está disponible. En este último caso, asegúrese que un ping a esa máquina da un resultado positivo, y de que está en efecto ejecutando un servidor NIS.

Puede verificar esto último usando rpcinfo, que debería producir la siguiente salida:

# rpcinfo -u servidor ypserv
program 100004 version 2 ready and waiting

 

10.6 Elección de los Mapas Correctos

Una vez que este seguro de que puede llegar al servidor NIS, debe decidir que ficheros de configuración sustituir o aumentar con mapas NIS. Normalmente deseará usar mapas NIS para las funciones de búsqueda de nodos y de claves de usuario. El primero es especialmente útil si no utiliza DNS. El segundo permite a todos los usuarios entrar en su cuenta desde cualquier sistema dentro del dominio NIS; esto suele requerir compartir un directorio /home central entre todos los nodos mediante NFS. Todo esto se explica en detalle en la sección 10.7 más abajo. Otros mapas, como services.byname, no proporcionan una ganancia tan clara, pero ahorran algo de trabajo de edición si instala alguna aplicación de red que use un nombre de servicio que no esté en el fichero services estándar.

Por lo general, usted deseará tener alguna libertad de elección acerca de cuando una función de búsqueda usará ficheros locales y cuando hará una petición al servidor NIS.

NYS le permite configurar el orden en que una función accede a estos servicios. Esto se controla mediante el fichero /etc/nsswitch.conf, que quiere decir Selector del Servicio de Nombrado9 pero por supuesto no está limitado a los servicios de nombres. Para cualquiera de las funciones de búsqueda de datos soportadas por NYS, contiene una línea citando los servicios a usar.

El orden correcto de los servicios depende del tipo de datos. Es improbable que el mapa services.byname contenga entradas diferentes que las que se encuentran en el fichero services local; únicamente podría contener más. Así que una buena elección seria consultar los ficheros locales primero, y probar con NIS solo si el nombre del servicio no fue encontrado.

Por otro lado, la información de nombres de nodos puede cambiar muy frecuentemente, de forma que el DNS o el servidor NIS tendrían siempre la información mas precisa, mientras que el fichero hosts local solo se mantiene como copia de respaldo por si el DNS y NIS fallasen. En este caso, habría que comprobar el fichero local en último lugar.

El siguiente ejemplo muestra como configurar las funciones gethostbyname(2), gethostbyaddr(2), y getservbyname(2) de la forma descrita anteriormente. Probarán los servicios listados por orden; si una búsqueda es satisfactoria, se devuelve el resultado, si no, se intentará con el siguiente servicio.

# /etc/nsswitch.conf de ejemplo
#
hosts: nis dns files
services: files nis

Más abajo se muestra la lista completa de servicios que pueden ser usados en una entrada del fichero nsswitch.conf. Los mapas, ficheros, servidores y objetos que se pueden consultar dependen del nombre de la entrada.

nisplus o nis+

Usa el servidor NIS+ para este dominio. La situación del servidor se obtiene del fichero /etc/nis.conf.

nis Usa el servidor NIS actual de este dominio. La situación del servidor consultado esta configurada en el fichero yp.conf como se mostró en la sección previa. Para la entrada hosts se consultan los mapas hosts.byname y hosts.byaddr.

dns Usa el servidor de nombres DNS. Este tipo de servicio solo es útil con la entrada hosts. Los servidores de nombres consultados siguen estando determinados por el fichero estándar resolv.conf.

files Usa el fichero local. Como el fichero /etc/hosts para la entrada hosts.

dbm Busca la información en ficheros DBM localizados en /var/dbm. El nombre usado para el fichero es el del mapa NIS correspondiente.

_____________________________________________