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.