- Propósito general e introducción a los Sistemas de Directorio
El propósito general de los servicios de directorio es la compartición de información, muy necesaria en las redes de ordenadores.
Un ejemplo de un servicio sería el de la correspondencia nombre de máquina-dirección IP, que presta el servicio de DNS, y que se crea precisamente con el objetivo de resolver un problema de compartición de información muy grande que se planteó en la por aquel entonces incipiente Internet. El problema derivaba del sistema anterior empleado para asignar biunívocamente nombre de máquina y dirección IP, que consistía en un fichero "hosts.txt" (de ahí las raíces del fichero local de sistemas Linux /etc/hosts) que se ofrecía a través de la red al resto de equipos. Las máquinas conectadas a Internet se sincronizaban cada cierto periodo de tiempo con un servidor que servía este fichero "hosts.txt" con la nueva asignación de nombres-IPs. Como se puede imaginar, este sistema funcionaba a la perfección con una Internet poco poblada, pero era inviable para el futuro, sobre todo teniendo en cuenta el increíble aumento de hosts en internet (boom de las punto com...). La solución fue idear una base de datos jerarquizada y distribuída, creando dominios que contuvieran la información de las máquinas en su interior, y que supieran alcanzar a otras máquinas en caso de que la asignación máquina-IP solicitada no estuviese en sus manos.
El otro ejemplo, del que nos ocupamos un poco más aquí es el de NIS. Desarrollado por Sun Microsystems en los 80, se ideó con el fin de solucionar la gestión de nombres, usuarios y grupos en redes con gran número de nodos. La idea era crear un sistema cliente-servidor que permitiese almacenar determinada información de configuración en un servidor y que los clientes se pudiesen conectar a él para averiguarla. De esta manera se evitaba tener que hacer tantas actualizaciones como máquinas hubiese en una red después de cada cambio.
En sus primeras versiones se llamaba "Yellow Pages" (Páginas Amarillas), pero esto llevó a toda una serie de demandas por parte de British Telecom que tenía la propiedad de dicha marca, con lo cual después de algunos trajines entre tribunales, acabó por llamarse NIS (Network Information Service). Los restos de su antiguo nombre todavía pueden intuirse en el nombre de los diferentes demonios y scripts que NIS utiliza (ej: ypbind, ypserv...).
Con la evolución de las necesidades de este tipo de servicios, los nuevos requerimientos condujeron a la aparición de un NIS mejorado (NIS+) que permite la administración jerárquica (al estilo de DNS), soporte para un nivel de seguridad mayor (tipos de acceso diferentes en función de la confidencialidad de los datos), sistema de verificación del servidor para los clientes, mejora del proceso de actualización de datos...
Un ejemplo de un servicio sería el de la correspondencia nombre de máquina-dirección IP, que presta el servicio de DNS, y que se crea precisamente con el objetivo de resolver un problema de compartición de información muy grande que se planteó en la por aquel entonces incipiente Internet. El problema derivaba del sistema anterior empleado para asignar biunívocamente nombre de máquina y dirección IP, que consistía en un fichero "hosts.txt" (de ahí las raíces del fichero local de sistemas Linux /etc/hosts) que se ofrecía a través de la red al resto de equipos. Las máquinas conectadas a Internet se sincronizaban cada cierto periodo de tiempo con un servidor que servía este fichero "hosts.txt" con la nueva asignación de nombres-IPs. Como se puede imaginar, este sistema funcionaba a la perfección con una Internet poco poblada, pero era inviable para el futuro, sobre todo teniendo en cuenta el increíble aumento de hosts en internet (boom de las punto com...). La solución fue idear una base de datos jerarquizada y distribuída, creando dominios que contuvieran la información de las máquinas en su interior, y que supieran alcanzar a otras máquinas en caso de que la asignación máquina-IP solicitada no estuviese en sus manos.
El otro ejemplo, del que nos ocupamos un poco más aquí es el de NIS. Desarrollado por Sun Microsystems en los 80, se ideó con el fin de solucionar la gestión de nombres, usuarios y grupos en redes con gran número de nodos. La idea era crear un sistema cliente-servidor que permitiese almacenar determinada información de configuración en un servidor y que los clientes se pudiesen conectar a él para averiguarla. De esta manera se evitaba tener que hacer tantas actualizaciones como máquinas hubiese en una red después de cada cambio.
En sus primeras versiones se llamaba "Yellow Pages" (Páginas Amarillas), pero esto llevó a toda una serie de demandas por parte de British Telecom que tenía la propiedad de dicha marca, con lo cual después de algunos trajines entre tribunales, acabó por llamarse NIS (Network Information Service). Los restos de su antiguo nombre todavía pueden intuirse en el nombre de los diferentes demonios y scripts que NIS utiliza (ej: ypbind, ypserv...).
Con la evolución de las necesidades de este tipo de servicios, los nuevos requerimientos condujeron a la aparición de un NIS mejorado (NIS+) que permite la administración jerárquica (al estilo de DNS), soporte para un nivel de seguridad mayor (tipos de acceso diferentes en función de la confidencialidad de los datos), sistema de verificación del servidor para los clientes, mejora del proceso de actualización de datos...
- El Directorio Standard X.500
A la par que DNS y NIS se estaban definiendo se hizo un esfuerzo especial para estandarizar la estructura de directorios de información, resultando en X.500. Un ejemplo de cómo almacenaría X.500 un dominio n-idea.alcala.com sería
{ Country = ES, Organization = N-Idea. Nuevas Ideas, Organization Unit = Empresa, Location = Alcala la Real }.
El etiquetado de los diferentes niveles de jerarquía aporta la posibilidad de realizar búsquedas inteligentes de información en el servidor.
{ Country = ES, Organization = N-Idea. Nuevas Ideas, Organization Unit = Empresa, Location = Alcala la Real }.
El etiquetado de los diferentes niveles de jerarquía aporta la posibilidad de realizar búsquedas inteligentes de información en el servidor.
- El Protocolo LDAP
LDAP surge como solución a la adaptación de DAP a las redes TCP/IP.
Cuando se definió el estándar de X.500 se creó un protocolo, que se llamó DAP para permitir el acceso a la base de datos a los clientes, pero este protocolo se ideó asumiendo que acabaría reinando la distribución OSI de los niveles de transporte y red y que TCP/IP acabaría desapareciendo. La realidad demostró todo lo contrario, por lo que se hizo imprescindible la adaptación de DAP a los niveles TCP/IP.
Cuando se definió el estándar de X.500 se creó un protocolo, que se llamó DAP para permitir el acceso a la base de datos a los clientes, pero este protocolo se ideó asumiendo que acabaría reinando la distribución OSI de los niveles de transporte y red y que TCP/IP acabaría desapareciendo. La realidad demostró todo lo contrario, por lo que se hizo imprescindible la adaptación de DAP a los niveles TCP/IP.
- ¿Y cómo funciona NIS?
NIS basa su actividad en una estructura cliente-servidor. El servidor (que puede ser maestro o esclavo) contiene unos ficheros de datos (llamados mapas) que el cliente va a buscar. La versión última de la base de datos la posee el servidor maestro y la distribuye a los servidores esclavos de forma perfectamente configurable, tanto al iniciar como al producirse un cambio. Los servidores esclavos sirven información pero no permiten la modificación de ésta.
Un nodo NIS puede ser:
- Cliente: Para minimizar el trabajo de configuración y facilitar la administración del sistema, se procurará maximizar la información distribuída por NIS.
- Servidor: Tiene los mapas, responde a peticiones de clientes, pero su propia configuración local no la obtiene por NIS (Sólo es útil cuando el equipo es servidor únicamente de NIS).
- Cliente y Servidor: La misma máquina, además de responder a las peticiones de los clientes y funcionar como servidor, es cliente de sí mismo, de forma que el tiempo de configuración del servidor también se minimiza.
Como antes dijimos, NIS copió de DNS lo referente a la distribución en dominios, por lo que NIS define también dominios de NIS que permiten que no exista una única información a distribuir a todas las estaciones, sino que se puedan definir zonas para distribuir cada información. Así, un dominio se convierte en un conjunto de mapas de NIS, lo que obliga a un cliente a especificar tanto el dominio como mapa requeridos.
- Del lado del servidor:
Vamos a ponernos a la tarea del lado servidor.
Lo primero es elegir el servidor maestro. Lo que tenemos que tener en cuenta es que ha de ser un equipo con gran estabilidad, capacidad de cálculo y ancho de banda. Dado que distribuye información de configuración vital para los equipos, una parada larga del servidor maestro supondría la parada de toda la red...cosa que no es muy deseable, sobre todo si algún puesto de trabajo depende de ello :). Además, el servidor debe soportar accesos concurrentes a la base de datos.
Instalación del maestro
Primero nos aseguramos de estar corriendo el portmap de RPC (Remote Procedure Call), ya que NIS es un protocolo montado sobre RPC. Normalmente en /etc/init.d/portmap, que podremos hacer que se arranque automáticamente con el inicio del sistema estableciendo un link simbólico en el runlevel 3 de nuestro sistema. (cd /etc/rc3.d en Ubuntu o cd /etc/rc.d/rc3.d en Redhat y luego ln -s ../init.d/portmap S60portmap). Si la posición 60 estuviese ocupada se pueden utilizar las siguientes.
Definimos el dominio de NIS a utilizar mediante el comando domainname (man domainname para más ayuda), que se suele incluir entre los scripts de arranque (/etc/init.d en sistemas Debian). Si existen múltples dominios, se repite la operación para cada dominio.
A continuación instalamos el servidor con el comando ypinit -m (normalmente /usr/lib/yp/ypinit -m). ypinit funciona mediante la invocación a la aplicación make, y en el fichero /var/yp/Makefile se pueden definir y modificar las variables que parametrizan el funcionamiento del servidor maestro.
Una vez parametrizado nuestro servidor maestro, al hacer ypinit -m se nos preguntará por los servidores esclavos. No es necesario que estén configurados mientras instalamos el maestro así que se introducen sin miedo (serán almacenados en el fichero /var/yp/ypservers).
Una vez tenemos el servidor instalado como maestro tenemos que decirle que también sea cliente de sí mismo. Para ello, empezaremos modificando el fichero /etc/nsswitch.conf cambiando el orden en que se consultarán las fuentes dependiendo de qué ficheros queramos que se obtengan por NIS. Un ejemplo podría quedar más o menos así:
"...
passwd: files nis
group: files nis
shadow: files nis
hosts: files dns
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis
.."
A continuación incluiremos en el fichero /etc/hosts las direcciones IP de todos los servidores esclavos para un funcionamiento robusto.
Bien, llegó el momento de arrancar nuestro servidor maestro.
Como queremos que el servidor se arranque siempre con la máquina sin necesidad de hacerlo manualmente, lo incluiremos en el runlevel 3 de la máquina (nótese que ypserv e yppasswdd ya se hallan en /etc/init.d). Lo único que tenemos que hacer es situarnos en la carpeta correspondiente al runlevel 3 (cd /etc/rc3.d en el caso de Ubuntu o cd /etc/rc.d/rc3.d en el caso de Redhat) y desde ahí establecer un link simbólico a los demonios ypserv e yppasswdd (ln -s ../init.d/ypserv S61ypserv y ln -s ../init.d/yppasswdd S62yppasswdd). Nótese que he usado los números 61 y 62, pero que en caso de estar ocupados por las llamadas a otros scripts pueden utilizarse los números siguientes.
La forma manual de arrancar estos demonios sería /etc/init.d/ypserv start y /etc/init.d/yppasswdd start.
Los demonios ypserv e yppasswdd se encargan respectivamente de atender las peticiones NIS de los clientes y de permitir el cambio de contraseña de los clientes NIS.
Instalación de los esclavos
Si el sistema lo requiere, y el número de clientes crece suficientemente o bien queremos repartir carga y evitar que cuando se caiga el maestro nuestra red esté "en bragas", instalaremos también al menos un servidor esclavo. Para hacerlo procederemos de forma similar a la seguida con el maestro.
Primero usamos el comando domainname para definir el dominio.
Hemos de tener claro que el servidor esclavo sólo procesa la información que le llega del maestro y en ningún caso incorpora su información local a los mapas que distribuye.
Lo siguiente a realizar es configurarlo como cliente de NIS (ver más adelante Instalación de los clientes).
A continuación instalamos el servidor como esclavo con el comando ypinit -s maestro siendo maestro el nombre del servidor maestro (normalmente la ruta será /usr/lib/yp/ypinit -s maestro).
Hacemos que cron abra nuestro editor preferido con crontab -e en el servidor esclavo e introducimos las siguientes líneas:
De esta manera estaremos siempre seguros de que nuestros servidores esclavos están al día incluso si un esclavo estuviese caído durante el tiempo en que el maestro servía los mapas.
Instalación de los clientes
La instalación de un cliente de NIS es más fácil que la del servidor.
Primero nos aseguramos de que estamos corriendo el portmap de RPC y que tenemos instalados los paquetes de ypbind e yp-tools de nuestra distribución.
Ahora usaremos el comando domainname para definir el dominio de NIS que está sirviendo el servidor de NIS que hemos configurado previamente.
Acto seguido crearemos el fichero /var/yp en caso de que no exista.
Lo siguiente que tendremos que hacer es modificar el fichero /etc/nsswitch.conf para indicar el orden de las fuentes de las que se extraerán los distintos ficheros de configuración, para luego modificar el fichero /etc/yp.conf indicando los servidores del dominio NIS que se usarán.
Vamos a ver un ejemplo de cómo podría quedar el fichero /etc/yp.conf
# /etc/yp.conf - fichero de configuración de ypbind
#
domain nidea server maquinadelmanolo.n-idea.es
# Usa el servidor maquinadelmanolo.n-idea.es para el dominio nidea
#
domain nideacurreles broadcast
# Hace broadcast en la red local para el dominio nideacurreles
#
Finalmente, sólo nos quedará arrancar el demonio ypbind que realizará las funciones del cliente. Como ya hicimos con el portmap y con las funciones de los servidores, introduciremos la llamada a ypbind en el arranque del sistema (si lo que queremos por el momento es sólo probar, la orden para arrancarlo sería /etc/init.d/ypbind start en sistemas Debian o /etc/rc.d/init.d/ypbind start en sistemas Redhat). Para incluir el demonio en el arranque procedemos como siempre:
- cd /etc/rc3.d (Debian) o cd /etc/rc.d/rc3.d (Redhat).
- ln -s ../init.d/ypbind S61ypbind.
¡Y yastá coleguitas! Vamos a usar las yp-tools del cliente para comprobar que todo está way vaya a ser...que luego tó se sabe.
ypcat passwd (sería el equivalente a cat passwd solo que ypcat busca la información servida por NIS y no la local).
Si el resultado es el fichero passwd que sirve el servidor de NIS (siempre que en nsswitch.conf hayáis definido que el fichero passwd se obtiene por NIS con mayor prioridad que de ficheros locales), entonces ya podéis decir por ahí que sois los mejores administrando con 4 toqueteos de teclado la configuración de cuentas de usuarios, host, rutas, y todos estos tinglaos de toda la red de forma centralizada con un servicio de directorio montado sobre RPC. ¡Ale! ¡a chulear pues!
Demonios:
- ypbind -> demonio del cliente que atiende al servidor.
- ypserv -> demonio del servidor que atiende al cliente.
- yppasswd -> demonio del servidor que permite el cambio de contraseña del cliente.
- ypxfrd -> demonio del servidor maestro que sirve los mapas de NIS a los servidores esclavos.
Aplicaciones:
- ypxfr -> aplicación que ejecuta el servidor esclavo y que contacta con el servidor maestro para bajarse los mapas de NIS.
- yppush -> aplicación del servidor maestro que notifica a los servidores esclavos para que se descarguen los mapas.
- yptools -> herramientas de comunicación NIS de cliente.
yptools:
- ypdomainame -> selecciona el nombre de dominio compartido entre todos.
- yppaswd -> cambia la clave de un usuario (requiere de ypbind y portmapper).
- ypwhich -> muestra el servidor NIS al que está conectado el ypbind.
- ypset -> cambia el servidor NIS al que está conectado ypbind.
- yppoll -> devuelve la versión y servidor maestro de un mapa de NIS.
- yptest -> llama a varias funciones de NIS para comprobar si que configuración es correcta y el sistema funciona como se espera.
- Vale y eso...¿cómo **** se hace?
- Del lado del servidor:
- Instalar la aplicación NIS tanto maestro como esclavo en los servidores.
- Crear la base de datos con los ficheros a distribuir.
- Arrancar el demonio "ypserv" que procesará las peticiones de los clientes.
- Añadir (si procede) los servidores esclavos.
- Instalar la aplicación cliente de NIS.
- Modificar los ficheros de configuración para que las peticiones de información se hagan a través de NIS.
- Arrancar el demonio "ypbind" que realizará las peticiones a los servidores.
Vamos a ponernos a la tarea del lado servidor.
Lo primero es elegir el servidor maestro. Lo que tenemos que tener en cuenta es que ha de ser un equipo con gran estabilidad, capacidad de cálculo y ancho de banda. Dado que distribuye información de configuración vital para los equipos, una parada larga del servidor maestro supondría la parada de toda la red...cosa que no es muy deseable, sobre todo si algún puesto de trabajo depende de ello :). Además, el servidor debe soportar accesos concurrentes a la base de datos.
Instalación del maestro
Primero nos aseguramos de estar corriendo el portmap de RPC (Remote Procedure Call), ya que NIS es un protocolo montado sobre RPC. Normalmente en /etc/init.d/portmap, que podremos hacer que se arranque automáticamente con el inicio del sistema estableciendo un link simbólico en el runlevel 3 de nuestro sistema. (cd /etc/rc3.d en Ubuntu o cd /etc/rc.d/rc3.d en Redhat y luego ln -s ../init.d/portmap S60portmap). Si la posición 60 estuviese ocupada se pueden utilizar las siguientes.
Definimos el dominio de NIS a utilizar mediante el comando domainname (man domainname para más ayuda), que se suele incluir entre los scripts de arranque (/etc/init.d en sistemas Debian). Si existen múltples dominios, se repite la operación para cada dominio.
A continuación instalamos el servidor con el comando ypinit -m (normalmente /usr/lib/yp/ypinit -m). ypinit funciona mediante la invocación a la aplicación make, y en el fichero /var/yp/Makefile se pueden definir y modificar las variables que parametrizan el funcionamiento del servidor maestro.
Una vez parametrizado nuestro servidor maestro, al hacer ypinit -m se nos preguntará por los servidores esclavos. No es necesario que estén configurados mientras instalamos el maestro así que se introducen sin miedo (serán almacenados en el fichero /var/yp/ypservers).
Una vez tenemos el servidor instalado como maestro tenemos que decirle que también sea cliente de sí mismo. Para ello, empezaremos modificando el fichero /etc/nsswitch.conf cambiando el orden en que se consultarán las fuentes dependiendo de qué ficheros queramos que se obtengan por NIS. Un ejemplo podría quedar más o menos así:
"...
passwd: files nis
group: files nis
shadow: files nis
hosts: files dns
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis
.."
A continuación incluiremos en el fichero /etc/hosts las direcciones IP de todos los servidores esclavos para un funcionamiento robusto.
Bien, llegó el momento de arrancar nuestro servidor maestro.
Como queremos que el servidor se arranque siempre con la máquina sin necesidad de hacerlo manualmente, lo incluiremos en el runlevel 3 de la máquina (nótese que ypserv e yppasswdd ya se hallan en /etc/init.d). Lo único que tenemos que hacer es situarnos en la carpeta correspondiente al runlevel 3 (cd /etc/rc3.d en el caso de Ubuntu o cd /etc/rc.d/rc3.d en el caso de Redhat) y desde ahí establecer un link simbólico a los demonios ypserv e yppasswdd (ln -s ../init.d/ypserv S61ypserv y ln -s ../init.d/yppasswdd S62yppasswdd). Nótese que he usado los números 61 y 62, pero que en caso de estar ocupados por las llamadas a otros scripts pueden utilizarse los números siguientes.
La forma manual de arrancar estos demonios sería /etc/init.d/ypserv start y /etc/init.d/yppasswdd start.
Los demonios ypserv e yppasswdd se encargan respectivamente de atender las peticiones NIS de los clientes y de permitir el cambio de contraseña de los clientes NIS.
Instalación de los esclavos
Si el sistema lo requiere, y el número de clientes crece suficientemente o bien queremos repartir carga y evitar que cuando se caiga el maestro nuestra red esté "en bragas", instalaremos también al menos un servidor esclavo. Para hacerlo procederemos de forma similar a la seguida con el maestro.
Primero usamos el comando domainname para definir el dominio.
Hemos de tener claro que el servidor esclavo sólo procesa la información que le llega del maestro y en ningún caso incorpora su información local a los mapas que distribuye.
Lo siguiente a realizar es configurarlo como cliente de NIS (ver más adelante Instalación de los clientes).
A continuación instalamos el servidor como esclavo con el comando ypinit -s maestro siendo maestro el nombre del servidor maestro (normalmente la ruta será /usr/lib/yp/ypinit -s maestro).
Si llegado a este punto obtenemos un error tipo "Trying ypxfrd ... not running", es que no hemos arrancado en el maestro el demonio de transferencia de mapas de NIS (rpc.ypxfrd). Lo hacemos y punto. Es tan fácil como ir al Makefile del maestro, descomentar o poner directamente la siguiente línea NOPUSH="false" y luego ejecutar en el maestro cd /var/yp; make all (que reconstruirá los mapas de NIS)Ahora, si queremos rizar el rizo sería una buena idea automatizar la tarea de solicitar al maestro que nos actualice los mapas de NIS mediante cron.
Hacemos que cron abra nuestro editor preferido con crontab -e en el servidor esclavo e introducimos las siguientes líneas:
30 * * * * /usr/lib/yp/ypxfr_1perhourLa configuración de este fichero de cron es bastante intuitiva (man crontab). Los dígitos significan por orden de izquierda a derecha: minutos, horas, día(s) del mes, mes(es), día(s) de la semana, orden a ejecutar.
0 5 * * * /usr/lib/yp/ypxfr_1perday
0 6,18 * * * /usr/lib/yp/ypxfr_2perday
De esta manera estaremos siempre seguros de que nuestros servidores esclavos están al día incluso si un esclavo estuviese caído durante el tiempo en que el maestro servía los mapas.
Instalación de los clientes
La instalación de un cliente de NIS es más fácil que la del servidor.
Primero nos aseguramos de que estamos corriendo el portmap de RPC y que tenemos instalados los paquetes de ypbind e yp-tools de nuestra distribución.
Ahora usaremos el comando domainname para definir el dominio de NIS que está sirviendo el servidor de NIS que hemos configurado previamente.
Acto seguido crearemos el fichero /var/yp en caso de que no exista.
Lo siguiente que tendremos que hacer es modificar el fichero /etc/nsswitch.conf para indicar el orden de las fuentes de las que se extraerán los distintos ficheros de configuración, para luego modificar el fichero /etc/yp.conf indicando los servidores del dominio NIS que se usarán.
Vamos a ver un ejemplo de cómo podría quedar el fichero /etc/yp.conf
# /etc/yp.conf - fichero de configuración de ypbind
#
domain nidea server maquinadelmanolo.n-idea.es
# Usa el servidor maquinadelmanolo.n-idea.es para el dominio nidea
#
domain nideacurreles broadcast
# Hace broadcast en la red local para el dominio nideacurreles
#
Finalmente, sólo nos quedará arrancar el demonio ypbind que realizará las funciones del cliente. Como ya hicimos con el portmap y con las funciones de los servidores, introduciremos la llamada a ypbind en el arranque del sistema (si lo que queremos por el momento es sólo probar, la orden para arrancarlo sería /etc/init.d/ypbind start en sistemas Debian o /etc/rc.d/init.d/ypbind start en sistemas Redhat). Para incluir el demonio en el arranque procedemos como siempre:
- cd /etc/rc3.d (Debian) o cd /etc/rc.d/rc3.d (Redhat).
- ln -s ../init.d/ypbind S61ypbind.
¡Y yastá coleguitas! Vamos a usar las yp-tools del cliente para comprobar que todo está way vaya a ser...que luego tó se sabe.
ypcat passwd (sería el equivalente a cat passwd solo que ypcat busca la información servida por NIS y no la local).
Si el resultado es el fichero passwd que sirve el servidor de NIS (siempre que en nsswitch.conf hayáis definido que el fichero passwd se obtiene por NIS con mayor prioridad que de ficheros locales), entonces ya podéis decir por ahí que sois los mejores administrando con 4 toqueteos de teclado la configuración de cuentas de usuarios, host, rutas, y todos estos tinglaos de toda la red de forma centralizada con un servicio de directorio montado sobre RPC. ¡Ale! ¡a chulear pues!
- Notas finales
Demonios:
- ypbind -> demonio del cliente que atiende al servidor.
- ypserv -> demonio del servidor que atiende al cliente.
- yppasswd -> demonio del servidor que permite el cambio de contraseña del cliente.
- ypxfrd -> demonio del servidor maestro que sirve los mapas de NIS a los servidores esclavos.
Aplicaciones:
- ypxfr -> aplicación que ejecuta el servidor esclavo y que contacta con el servidor maestro para bajarse los mapas de NIS.
- yppush -> aplicación del servidor maestro que notifica a los servidores esclavos para que se descarguen los mapas.
- yptools -> herramientas de comunicación NIS de cliente.
yptools:
- ypdomainame -> selecciona el nombre de dominio compartido entre todos.
- yppaswd -> cambia la clave de un usuario (requiere de ypbind y portmapper).
- ypwhich -> muestra el servidor NIS al que está conectado el ypbind.
- ypset -> cambia el servidor NIS al que está conectado ypbind.
- yppoll -> devuelve la versión y servidor maestro de un mapa de NIS.
- yptest -> llama a varias funciones de NIS para comprobar si que configuración es correcta y el sistema funciona como se espera.
No hay comentarios:
Publicar un comentario