SISTEMA DE INFORMACION DE RED (NIS)

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. 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 aún, si usted solo 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 desarrollo 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 Pages 1, 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.

NIS mantiene informacion 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 es de varias llamadas RPC.

Muy frecuentemente, los mapas se almacenan en cheros DBM.5 Los mapas en s mismos suelen ser generados a partir de fi cheros de texto maestros como /etc/hosts o /etc/passwd. Para algunos cheros se crean varios mapas, uno por cada tipo de clave de búsqueda. Por ejemplo, usted podr a buscar en el chero hosts tanto por un nombre de nodo como por su direcci ón IP. As pues, de el 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 estandar y los ficheros correspondientes.

La gente usa habitulamente apodos para algunos mapas, ya que son mas cortos y por lo tanto más fáciles de escribir. Para obtener una lista completa de los apodos 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"

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.

Queda un misterio por resolver: como sabe un cliente a que servidor conectarse. La solución mas simple sera tener un fichero de conguració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 disponiblidad. 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 cuaquier consulta NIS, debe averiguar primero, a trav es de ypbind, qu e servidor usar.

Ypbind busca los servidores mandando un mensaje de difusion por toda la red IP local. El primero en responder se supone que ser a el más rápido potencialmente y ser a 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 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á 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.