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.

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.

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:

_____________________________________________
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:

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.

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]).

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.

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:

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.

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í:

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í:

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.

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:

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.

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.

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.

_____________________________________________
9 N. del T.: del inglés Name Service Switch.

Actualmente NYS soporta las siguientes entradas en nsswitch.conf : hosts, networks, passwd, group, shadow, gshadow, services, protocols, rpc y ethers. Es probable que se añadan más entradas.

La figura 10.1 muestra un ejemplo mas completo que introduce otra característica del fichero nsswitch.conf : la palabra clave [NOTFOUND=return] en la entrada hosts indica a NYS que retorne si el elemento deseado no pudo ser encontrado en la base de datos NIS o DNS. Esto es, NYS continuará y buscará en los ficheros locales solo si las llamadas a los servidores NIS y DNS fallaron por alguna otra razón. Los ficheros locales serán usados entonces solo durante el arranque y como copia de respaldo cuando el servidor NIS se haya caído.

Figura 10.1: Fichero nsswitch.conf de ejemplo.

Uno de los usos más importantes de NIS es sincronizar usuarios e información de cuentas en todos los nodos de un dominio NIS. Para este fin, solo se suele mantener un pequeño fichero local /etc/passwd, al que se le añade información de todas las demás cuentas mediante los mapas NIS. Sin embargo, solo con habilitar búsquedas NIS para este servicio en nsswitch.conf no es suficiente.

Cuando se base en la información de contraseñas distribuida por NIS, debe primero cerciorarse de que los números identificadores de cualquier usuario que tenga en su fichero passwd local coincidan con la idea que tiene el servidor NIS de identificadores de usuarios. Usted también deseará esto para otros propósitos, como montar volúmenes NFS de otros nodos de su red.

Si alguno de los números de usuario de /etc/passwd o de /etc/group son distintos de los que aparecen en los mapas, tiene que ajustar el propietario de todos los ficheros que pertenezcan a ese usuario. Primero debería cambiar todos los números de uid y gid en passwd y group a los nuevos valores; después, encontrar todos los ficheros que pertenezcan a los usuarios recién modificados, y finalmente cambiarles el propietario. Supongamos que news tenia un número de usuario de 9, y que okir tenia un número de usuario de 103, y que estos fueron cambiados a algún otro valor; entonces debería teclear los siguientes comandos:

Es importante que ejecute estos comandos con el nuevo fichero passwd ya instalado, y que recoja todos los nombres de ficheros antes de cambiar el propietario de cualquiera de ellos. Para cambiar el grupo propietario de los ficheros, se usará un comando similar.

Una vez hecho esto, los números de uid y gid de su sistema estarán de acuerdo con los de los demás nodos de su dominio NIS. El siguiente paso será añadir las líneas de configuración a nsswitch.conf que habiliten las búsquedas NIS de información de usuario y grupo.

Esto hace que el comando login y otros de esta familia consulten primero los mapas NIS cuando un usuario intenta entrar, y si esta búsqueda falla, sigan con los ficheros locales.

Normalmente usted borrará la mayor parte de los usuarios de sus ficheros locales y solo dejará en ellos entradas para root y para cuentas genéricas como mail. Esto es porque algunas tareas vitales del sistema pueden requerir mapear uids a nombres de usuario o viceversa. Por ejemplo, las tareas cron administrativas pueden ejecutar el comando su para convertirse temporalmente en news, o el subsistema UUCP puede enviar un informe de estado en un mensaje. Si news y uucp no tienen entradas en el fichero passwd local, estas tareas fallarán miserablemente durante un apagón de NIS.

Dos observaciones importantes: por un lado, la configuración descrita hasta aquí solo funciona para sistemas de login que no usan contraseña shadow, como los incluidos en el paquete util-linux. Los intrincados métodos para usar contraseñas shadow con NIS serán cubiertos más adelante. Por otro lado, los comandos login no son los únicos que acceden al fichero passwd - por ejemplo la orden ls que la mayor parte de la gente usa constantemente.

Cada vez que se saca un listado con la opción -l, ls mostrara los nombres simbólicos del propietario y del grupo; esto es, por cada uid y gid que encuentre, deberá hacer una petición al servidor NIS. Esto ralentizará mucho todo el sistema cuando su red local se atasque, o, aun peor, cuando el servidor NIS no esté en la misma red física, de forma que los datagramas tengan que pasar a través de un encaminador o puente.

Y esto no es todo. Imagine lo que pasa si un usuario quiere cambiar su contraseña. Normalmente invocará el comando passwd, que leerá la nueva contraseña y actualizará el fichero passwd local. Esto es imposible con NIS, puesto que ese fichero no está disponible localmente, y tampoco es una opción que los usuarios entren en el servidor NIS cada vez que quieran cambiar la clave. Por ello, NIS proporciona un sustituto para passwd llamado yppasswd, que realiza una tarea análoga en NIS. Para cambiar la contraseña en la máquina servidora, contacta con el demonio yppasswdd en ese nodo mediante RPC, y le proporciona información de la contraseña actualizada. Generalmente, yppasswd se instala sobre el programa normal haciendo algo así:

Al mismo tiempo tendrá que instalar rpc.yppasswdd en el servidor y arrancarlo desde los guiones rc. Esto ocultará de forma efectiva todas las complicaciones de NIS a sus usuarios.

Todavía no existe soporte NIS para instalaciones que usan el conjunto de utilidades shadow password. John F. Haugh, el autor del conjunto shadow, publico recientemente una versión de las funciones de biblioteca shadow en comp.sources.misc, cubiertas por la licencia LGPL de GNU. Ya tiene algún soporte para NIS, pero no está completa, y los ficheros no han sido añadidos todavía a la biblioteca C estándar. Por otro lado, publicar la información de /etc/shadow vía NIS rompe de alguna manera con el propósito del conjunto shadow.

Aunque las funciones de búsqueda de contraseña en NYS no usan un mapa shadow.byname ni nada parecido, NYS soporta el uso de un fichero /etc/shadow local de forma transparente. Cuando la implementación NYS de getpwnam es llamada para buscar información relacionada con un login dado, se consultan las facilidades especificadas por la entrada passwd en nsswitch.conf. El servicio nis seguirá mirando en el mapa passwd.byname del servidor NIS. En cambio, el servicio files mirará si existe /etc/shadow y lo intentará abrir.

Si no existe, o si el usuario no tiene privilegios de root, volverá al comportamiento tradicional de mirar la información del usuario solo en /etc/passwd. Sin embargo, si el fichero shadow existe y puede ser abierto, NYS extraerá la contraseña del usuario de shadow. La función getpwuid se implementa similarmente. De esta forma, los binarios compilados con NYS funcionarán de forma transparente con una instalación shadow local.

Si está usando el código de cliente existente en la libc estándar, la configuración de un cliente NIS es un poco diferente. Por un lado, se usa un demonio ypbind para buscar por la red servidores activos en vez de obtener esta información de un fichero de configuración.

Usted tendrá por ello que cerciorarse de que arranca ypbind durante la inicialización del sistema. Debe ser invocado después de que el dominio NIS haya sido establecido y de que el mapeador de puertos RPC haya sido arrancado. Después podrá invocar ypcat para comprobar el servidor como se mostró mas arriba.

Recientemente ha habido numerosos informes de error indicando que NIS falla con un mensaje de error que dice: "clntudp_create: RPC: portmapper failure - RPC: unable to receive". Estos mensajes de error son debidos a un cambio incompatible en el modo en que ypbind comunica la información de enlazado a las funciones de biblioteca. Con obtener las fuentes más recientes de las utilidades NIS y recompilarlas se debería solucionar este problema.10

Del mismo modo, la forma en que el NIS tradicional decide si hay que mezclar información NIS, y como, con la de los ficheros locales es distinta que la usada por NYS. Por ejemplo, para usar los mapas de contraseña NIS, debe incluir la siguiente línea en algún lugar de su mapa /etc/passwd :

Esto marca el lugar donde las funciones de búsqueda de contraseñas "insertan" los mapas NIS. Insertando una línea similar (menos los dos últimos dos puntos) en /etc/group obtenemos lo mismo para los mapas group.*. Para usar los mapas hosts.* distribuidos por NIS, cambie la línea order del fichero host.conf. Por ejemplo, si desea usar NIS, DNS, y el fichero /etc/hosts (por ese orden), necesita cambiar esa línea por:

La implementación NIS tradicional no soporta ningún otro mapa más por el momento.

_____________________________________________
10 El código fuente de yp-linux puede obtenerse de ftp.uni-paderborn.de, en el directorio /pub/Linux/LOCAL.