Este documento está disponible en los siguientes idiomas: English Castellano Deutsch Francais Nederlands Portugues Russian Turkce |
by Frédéric Raynal About the author: Actualmente Frédéric Raynal está escribiendo su tesis en informática en INRIA. Le gusta leer (tanto Tolkien com Balzac) y escuchar música (desde Mozart a Philip Glass y desde Led Zeppelin a Massive Attack, pasando por Björk y Boris Vian, pero evitando cuidadosamente el rap, techno y esos tipos de ruido ;-) Content: |
Abstract:
El Servicio de Información de Red (NIS: Network Information Service) almacena una base de datos en un servidor. Cada máquina en la red sobre la que corre un cliente NIS puede lanzar consultas al servidor para obtener información como login, nombre, contraseña, información sobre grupos de usuarios,...Esto permite una gestión centralizada de un gran número de máquinas (especialmente cuando se utilizan conjuntamente con un sistema de archivos en red distribuido como NFS) ya que los cambios en esta información pasará desde el servidor a todos sus clientes.
El Servicio de Información de Red (NIS: Network Information Service) fue inicialmente creado por Sun y conocido como las Páginas Amarillas Sun (más usualmente como simplemente las Páginas Amarillas o YP (Yellow Pages). Esto, sin embargo, es una marca registrada de Brittish Telecom y en consecuencia no puede ser utilizado sin los permisos adecuados. Estas Páginas Amarillas se refieren a las mismas que conocemos para buscar números de teléfono.
Los servidores NIS mantienen copias de los ficheros de configuración comunes de varias de la red en una base de datos. Los clientes NIS dirigen sus peticiones a los servidores en lugar de utilizar sus propios ficheros de configuración.
Supongan que son un usuario en la red que desea cambiar su password. Primero imaginen que YP no está instalado. Este usuario deberá registrarse en todas las máquinas de la red para cambiar su contraseña. Si YP estuviera instalado, sería posible para él/ella cambiar su palabra de paso en una de las máquinas donde corre un cliente NIS. La nueva contraseña será entonces transferida al servidor, donde será modificada en su base de datos. Después de esto, cuando un usuario quiera conectarse desde una máquina de la red (en la que, por supuesto, corre un cliente NIS ;-), la contraseña se comprobará contra aquella registrada en la base de datos del servidor.
Existen diferentes versiones de YP, pero ya que este artículo es una introducción, sólo nos fijaremos en los grandes principios en los que se basa su funcionamiento, sin entrar en los detalles. Ya los veremos más adelante.
glibc 2.x (libc6) soporta el uso de NSS (Name Switch Service) que determina el orden en que una información debe ser buscada (ver el fichero /etc/nsswitch.conf). Mantiene los alias, ethers, grupos, hosts, grupos de red, protocolos, clave pública, contraseña, rpc, servicios y mapas ocultos.Debe haber una máquina en la red funcionando como un servidor NIS para un dominio. Este dominio corresponde, más o menos, al nombre de la base de datos que administra el servidor. Esta es la clave utilizada por los clientes NIS para colocar la información necesaria en el servidor NIS. Este nombre de dominio no tiene absolutamente nada que ver con el nombre de dominio DNS. Puede haber más de un servidor NIS en el mismo dominio. Cada uno puede administrar un dominio diferente (a nivel NIS), o pueden administrar el mismo dominio (en este caso habrá un servidor maestro y servidores esclavos.
Los servidores esclavos sólo tienen una copia de la base de datos de los servidores maestros. Estos servidores complementan al maestro cuando a éste le lleva mucho tiempo responder las peticiones de los clientes o cuando el servidor maestro se cae.
Se notifica a los servidores cualquier cambio en la base de datos con el programa yppush y actualizarán sus propias bases de datos para reflejar el estado exacto de la base de datos en el servidor.
Los clientes, por su parte, no necesitan ningún "mantenimiento" ya que se están conectando continuamente al servidor NIS para buscar información en su base de datos.
Las bases de datos YP están en formato GDBM, derivado del formato ASCII. Son instaladas durante la instalación del servidor por el programa makedbm.
Estos mapas establecen correspondencias entre una clave y su valor. Todos los mapas YP están basados en este modelo. Desde el punto de vista del servidor, los contenidos no tienen significado (bueno, excepto algunos datos sobre el servidor principal o fechas). Esto significa que, para el servidor, un mapa con contraseñas o grupos o ... no es más que un conjunto de parejas (clave, valor). Unicamente el cliente YP cliente sabe cómo recorrer esos mapas para encontrar la información que estaba buscando.
Esta representación de los datos puede ser problemática. Como el servidor no puede "leer" el valor de una clave para encontrar una segunda clave dentro, será necesario duplicar los datos. Por ejemplo, en el caso de las contraseñas, uno puede querer ser capaz de buscarlas utilizando el nombre de login o por el ID de ususario o UID, un identificador único para cada usuario en la red. Esto conduce a información redundante, ua que puede ser vista por la presencia de los ficheros passwd.byname and passwd.byuid. En consecuencia, habrá un nuevo mapa creado para cada nueva clave, significando que los datos deben ser transmitidos dos veces en caso de cambio-
Un cliente necesita tres parámetros para encontrar la información que busca en la base de datos:
Esto conduce a un sistema muy flexible, ya que configurar un nuevo dominio se reduce a la creación del directorio /var/yp/new_domain, copiando el Makefile y ejecutándolo con las opciones correctas.
La funcionalidad de las Páginas Amarillas se basa esencialmente en LLamadas a Procedimientos Remotos (RPCs) aceptando peticiones entre el servidor y sus clientes.
El portmapper RPC (portmap) es un programa que convierte los números de programa RPC a números de puerto. Cuanddo un RPC es arrancado, le dirá al portmap qué puerto va a usar y los números de programa RPC que está administrandol Cuando un cliente quiere hacer una petición RPC a un determinado número de programa, primero contacta con el servidor portmap para obtener el número de puerto en el que el programa está corriendo. Después de obtener el número de puerto, dirige los paquetes RPC al puerto que corresponda El modelo cliente/servidor de las YPs no es más que un caso particular del cliente/servidor RPC.
El fichero yp_prot.h contiene las estructuras y los prototipos del protocolo RPC entre clientes y el servidor YP.
|
Webpages maintained by the LinuxFocus Editor team
© Frédéric Raynal, FDL LinuxFocus.org Click here to report a fault or send a comment to LinuxFocus |
Translation information:
|
2001-07-02, generated by lfparser version 2.9