Sistema de Información para la Gestión de Bodegas

NIS está basado en RPC y consta de un servidor, una biblioteca cliente y varias herramientas de gestión. Inicialmente, NIS se llamaba Páginas Amarillas o YP, y este nombre todavía se usa informalmente para referirse al servicio. Por otro lado, Yellow Pages es una marca registrada de British Telecom, que ha estado pidiendo a Sun que cambie el nombre. Con el desarrollo de las cosas, algunos nombres se han vuelto inseparables de las personas, por lo que YP continúa existiendo en forma de prefijos con comandos relacionados con NIS, como ypserv, ypbind, etc.

Hoy en día, casi todos los UN*X incluyen NIS, e incluso existen implementaciones gratuitas del mismo. Una es la distribución Net-2 de BSD, derivada de una implementación de referencia de dominio público donada por Sun. Esta versión del código de la biblioteca cliente ha existido en la libc de GNU durante mucho tiempo, y Swen Thümmler [1] portó el hipervisor a Linux recientemente. Falta un programa de servidor NIS en esta implementación de referencia. Tobias Reber ha compilado otro paquete NIS que incluye todas las herramientas y un servidor. Este paquete se llama yps. [2]

Actualmente, Peter Eriksson [3] ha compilado un código NIS completamente reescrito llamado NYS, que admite NIS normal y NIS+ de Sun con muchas modificaciones. NYS no sólo proporciona un conjunto de herramientas NIS y un servidor, sino que también agrega un conjunto completamente nuevo de funciones de biblioteca que eventualmente podrán agregarse a la libc estándar. Esto incluye una nueva configuración que reemplaza la resolución actual del nombre de host usando host.conf. Las propiedades de estas funciones se analizan a continuación.

Este capítulo se centrará en NYS en lugar de en los otros dos paquetes, a los que llamaré código NIS "tradicional". Si realmente desea ejecutar alguno de estos paquetes, las instrucciones de este capítulo pueden ser suficientes o no. Para obtener información adicional, obtenga un libro estándar (autorizado) sobre NIS, como NFS y NIS de Hal Stern (consulte [Stern92]).

Actualmente, NYS todavía se encuentra en la etapa de desarrollo, por lo que las herramientas estándar de Linux, como los programas de red o los programas de inicio de sesión, aún no han notado el esquema de configuración de NYS. Sólo cuando NYS se fusione con la libc principal necesitará volver a compilarlos si desea que todos estos ejecutables utilicen NYS. En los Makefiles de cualquiera de estas aplicaciones, especifique -lnsl como la última opción del vinculador, antes de libc. Esto vinculará las funciones relevantes de la biblioteca libnsl-NYS en lugar de vincularlas desde la biblioteca C estándar.

10.1 Comprender NIS

NIS almacena información de la base de datos en los llamados mapas que contienen pares clave-valor. Los mapas se almacenan en un host central que ejecuta un servidor NIS, desde el cual los clientes pueden recuperar información a través de varias llamadas RPC. Lo más frecuente es que los mapas se almacenen en archivos DBM. [4]

Los mapas en sí se generan a partir de archivos de texto principales (como /etc/hosts o /etc/passwd). Para algunos archivos, se generan varios mapas, uno para cada tipo de clave de búsqueda. Por ejemplo, puede buscar en el archivo de hosts nombres de host y direcciones IP. En consecuencia, a partir de él se generan dos mapas NIS, llamados hosts.byname y hosts.byaddr. La Tabla 10.1 enumera mapas comunes y los archivos que generan.

Mapas de archivos maestros

/etc/hosts

/etc/networks

/etc/passwd

/etc/group

/etc/services

/etc/rpc

/etc/protocols

/usr/ lib/aliases Hosts.por nombre hosts.byaddr

Redes.por nombre redes.byaddr

Contraseña.por nombre contraseña.byuid

Grupo.por nombre grupo.bygid

Servicios.por nombre servicios.por número

Rpc.por nombre rpc.por número

Protocolos.por nombre protocolos.por número

Correo.alias

Tabla 10.1 Algunos mapas NIS estándar y archivos correspondientes.

En algunos paquetes NIS u otro software, hay otros archivos y mapas que pueden resultarle útiles. Estos archivos y mapas pueden contener información para aplicaciones que no se tratan en este libro, como mapas de parámetros de arranque que pueden usarse en algunos servidores BOOTP, o archivos que actualmente no contienen ninguna función en Linux (como los mapas ethers.byname y ethers.byaddr). ).

Para algunos mapas, la gente suele utilizar apodos, que son cortos y fáciles de escribir. Para obtener una lista completa de los apodos que entiende su herramienta NIS, ejecute el siguiente comando:

$ ypcat –x

Tabla de traducción de apodos del mapa NIS:

" contraseña" -> "contraseña.byname"

"grupo" -> "grupo.bynombre"

"redes" -> "redes.byaddr"

"hosts" -> "hosts.por nombre"

"protocolos" -> "protocolos.por número"

"servicios" -> "servicios.por nombre"

"alias" -> "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"

"zona horaria ” -> “timezone.byname”

El servidor NIS se llama tradicionalmente ypserv. Para una red de tamaño mediano, un solo servidor suele ser suficiente; las redes grandes pueden requerir varios servidores ejecutándose en diferentes segmentos de la red y en diferentes máquinas para reducir la carga en las máquinas servidores y los enrutadores.

Estos servidores se sincronizan utilizando uno de ellos como servidor maestro y los otros servidores como servidores esclavos. Los mapas sólo se crearán en el servidor maestro. Distribuirlos desde el servidor primario a todos los servidores secundarios.

Es posible que hayas notado que hemos estado hablando muy vagamente sobre "redes", por supuesto, existe un concepto distinto de NIS que se refiere a dicha red, es decir, compartir partes de sus sistemas a través de una colección de NIS. de datos de configuración para todos los hosts: el dominio NIS. Desafortunadamente, los dominios NIS no se parecen en nada a los dominios que encontramos en DNS. Para evitar ambigüedades en este capítulo, siempre indicaré de qué tipo de dominio estoy hablando.

El dominio NIS sólo tiene funciones puras de gestión. Son principalmente invisibles para los usuarios, excepto cuando se comparten contraseñas entre todas las máquinas del dominio. Por lo tanto, el nombre dado al dominio NIS sólo es relevante para el administrador. En general, puede utilizar cualquier nombre siempre que sea diferente de otros nombres de dominio NIS en su red local. Por ejemplo, el administrador de una bodega virtual puede optar por crear dos dominios NIS, uno para la propia bodega y otro para una bodega, a los que denomina cervecería y bodega respectivamente. Otra solución muy común es simplemente utilizar el nombre de dominio DNS como nombre de dominio NIS. Para configurar y mostrar el nombre de dominio NIS de su host, puede usar el comando dommainname. Cuando se llama sin ningún parámetro, imprime el nombre de dominio NIS actual. Para configurar este nombre de dominio, debe convertirse en superusuario y escribir:

# nombre de dominio cervecería

Determinación del dominio NIS Determinar cuál; Servidor NIS una aplicación consultará. Por ejemplo, el programa de inicio de sesión en el host de la bodega (por supuesto) solo consultará el servidor NIS de la bodega (o uno de ellos, si hay varios servidores) para obtener la información de la contraseña del usuario, mientras que la aplicación del host de la bodega solo consultará el; servidores de la cervecería.

Aún queda una duda por resolver, es decir, cómo sabe un cliente a qué servidor conectarse. La ruta más sencilla es tener un archivo de configuración que proporcione el nombre de host en el que buscar el servidor. Sin embargo, este enfoque es muy inflexible ya que no permite a los clientes utilizar diferentes servidores (del mismo dominio, por supuesto) dependiendo de la presencia o ausencia de estos servidores. Por lo tanto, las implementaciones NIS tradicionales se basan en un demonio especial llamado ypbind para detectar un servidor NIS apropiado en su dominio NIS. Antes de poder realizar cualquier consulta NIS, cualquier aplicación primero averigua en ypbind qué servidor utilizar.

ypbind sondea los servidores transmitiendo a la red IP local; se supone que el primer servidor en responder es esencialmente el más rápido y se utilizará para consultas NIS posteriores. Después de que haya transcurrido un cierto intervalo, o si el servidor no funciona, ypbind detectará nuevamente el servidor en ejecución.

Ahora, el argumento sobre el enlace dinámico es que rara vez lo necesita y crea problemas de seguridad: ypbind confía ciegamente en cualquier contestador que pueda ser un humilde. El servidor NIS también podría ser un intruso con intenciones maliciosas. No hace falta decir que esto puede resultar particularmente problemático si administra su base de datos de contraseñas en NIS. Para evitar este problema, NYS no utiliza ypbind de forma predeterminada, sino que obtiene el nombre de host del servidor de un archivo de configuración.

10.2 NIS y NIS+

NIS y NIS+ tienen poco en común excepto sus nombres y los mismos objetivos. NIS+ se construye utilizando un enfoque completamente diferente. Utiliza un espacio de nombres jerárquico similar al DNS, en lugar de un espacio de nombres plano y dominios NIS poco separados. En lugar de mapas, utiliza las llamadas tablas, que se componen de filas y columnas. Cada fila de la tabla representa un objeto en la base de datos de NIS+, y las columnas representan aquellos atributos del objeto que NIS+ conoce. Cada tabla de un dominio NIS+ determinado consta de las de su dominio principal. Además, una entrada en una tabla puede contener un enlace a otra tabla. Estas propiedades permiten estructurar la información de muchas maneras.

El número de versión RPC del NIS tradicional es 2, mientras que el número de versión RPC de NIS+ es la versión 3.

NIS+ no parece ser muy utilizado todavía y, de hecho, no sé mucho al respecto. (Bueno, casi nada). Por esta razón no lo cubriremos aquí. Si está interesado y desea obtener más información, consulte el Manual de administración de NIS+ de Sun ([NISPlus]).

10.3 NIS en el lado del cliente

Si está familiarizado con la creación o la portabilidad de aplicaciones de red, notará que muchos de los mapas NIS enumerados anteriormente son funciones de biblioteca en la biblioteca C correspondiente. . Por ejemplo, para obtener información de contraseña, normalmente se utilizan las funciones getpwnam(3) y getpwuid(3), que devuelven la información de la cuenta correspondiente a un nombre de usuario o ID de usuario numérico determinado, respectivamente. En circunstancias normales, estas funciones realizarán la búsqueda solicitada en un archivo estándar (como /etc/passwd).

Sin embargo, las implementaciones de estas funciones basadas en NIS (con reconocimiento de NIS) cambiarán este comportamiento y permitirán una llamada RPC al servidor NIS para consultar el nombre de usuario o la identificación. Esta operación es completamente transparente para la aplicación. Esta función puede "añadir" o "reemplazar" el archivo original con un mapa NIS. Por supuesto, esto en realidad no modifica el archivo; simplemente hace que la aplicación parezca que el archivo ha sido reemplazado o agregado.

Con las implementaciones tradicionales de NIS, existían ciertas convenciones para las cuales se reemplazaban los mapas y se agregaban a la información original. Algunos mapas (como los mapas passwd) requieren modificaciones aleatorias en el archivo passwd, que cuando se hacen incorrectamente pueden abrir agujeros de seguridad. Para evitar esta deficiencia, NYS tiene un esquema de configuración convencional que determina si un conjunto particular de funciones de cliente utiliza archivos sin formato, NIS y NIS+, y en qué orden. Esto se discutirá en secciones posteriores de este capítulo.

10.4 Ejecución de un servidor NIS

Después de toda la charla teórica, comencemos con el trabajo de configuración real. En esta sección, discutiremos la configuración del servidor NIS. Si ya tiene un servidor NIS ejecutándose en su red, no necesita configurar su propio servidor; en este caso, puede omitir esta sección de manera segura;

Tenga en cuenta que si solo va a probar el servidor, asegúrese de no configurar un nombre de dominio NIS que ya esté en uso en su red. Porque esto provocará la caída de todo el servicio de red y hará que muchas personas se sientan infelices y molestas.

Actualmente existen dos servidores NIS gratuitos para Linux, uno incluido en el paquete yps de Tobias Reber y el otro en el paquete ypserv de Peter Eriksson. No importa cuál ejecute, ya sea que utilice NYS o el código de cliente NIS estándar actualmente en libc. Al momento de escribir este artículo, el código para el procesamiento del servidor secundario NIS en yps parece ser más completo. Entonces, si se trata de servidores secundarios, yps puede ser una mejor opción.

Después de instalar el programa del servidor (ypserv) en /usr/sbin, debe crear un directorio para almacenar los archivos de mapas distribuidos por su servidor. Cuando se configura un dominio NIS para el dominio de la cervecería, los mapas se almacenarán en /var/yp/brewery. El servidor determina si está prestando servicio a un dominio NIS específico detectando la presencia de un directorio de mapas. Si ha deshabilitado servicios para ciertos dominios NIS, asegúrese de eliminar ese directorio también.

Los mapas suelen almacenarse en archivos DBM para acelerar las consultas. Se crean a partir del archivo maestro usando un programa llamado makedbm (para el servidor de Tobias) o dbmload (para el servidor de Peter). No son intercambiables. Convertir el archivo principal a un formato que dbmload pueda analizar generalmente requiere algunos trucos awk o sed, que pueden ser algo tediosos de escribir y difíciles de recordar. Por lo tanto, el software ypserv de Peter Eriksson incluye un Makefile (llamado ypMakefile) que hará todo este trabajo por usted.

Debe instalarlo como un Makefile en su directorio de mapas y editarlo para reflejar los mapas que desea distribuir. En la parte superior del archivo, encontrará el objetivo completo, que enumera los servicios que proporcionará ypserv. De forma predeterminada, la línea se ve así:

todos: ethers hosts redes protocolos rpc servicios passwd grupo netid

Por ejemplo, si no desea generar ethers.byname y ethers. byaddr maps, simplemente elimine el requisito previo de ethers de esta regla. Para probar su configuración, basta con comenzar con uno o dos mapas, como los mapas de servicios.*.

En el directorio del mapa, después de editar el Makefile, escriba "make". Esto generará e instalará mapas automáticamente. Debes asegurarte de actualizar los mapas cada vez que cambies el archivo principal, de lo contrario los cambios permanecerán invisibles para la red.

La siguiente sección explica cómo configurar el código del cliente NIS. Si la configuración de su instalación no funciona, debe verificar si llega alguna solicitud a su servidor. Si especifica el indicador de línea de comando -D en el servidor NYS, imprimirá información de depuración en la consola sobre todas las consultas NIS entrantes y devolverá los resultados. Estos le darán una pista para determinar exactamente dónde está el problema. El servidor de Tobias no tiene esta opción.

10.5 Configuración de un cliente NIS utilizando NYS

En el resto de este capítulo, analizaremos la configuración de los clientes NIS.

Su primer paso debería ser indicarle a NYS qué servidor usar para el servicio NIS y configurarlo en el archivo de configuración /etc/yp.conf. Un archivo de muestra simple para un host en la red de una bodega se vería así:

# yp.conf – Configuración de YP para la biblioteca del Estado de Nueva York.

#

nombre de dominio bodega

servidor vbardolino

La primera declaración les dice a todos los clientes NIS que pertenecen al dominio NIS de bodega. Si omite esta línea, NYS utilizará el nombre de dominio que asignó a su sistema mediante el comando domainname. La declaración del servidor especifica el servidor NIS utilizado. Por supuesto, la dirección IP correspondiente a vbardolino debe configurarse en el archivo de hosts; además, también puede utilizar la dirección IP en sí en la declaración del servidor;

En la forma que se muestra arriba, el comando del servidor le dice a NYS que use el servidor especificado independientemente del dominio NIS actual. Sin embargo, si mueve con frecuencia su máquina entre diferentes dominios NIS, es posible que desee guardar información para varios dominios en el archivo yp.conf. Puede obtener información del servidor para varios dominios NIS agregando el nombre del dominio NIS a la declaración del servidor. Por ejemplo, podría cambiar el archivo de muestra anterior para que se vea así para una computadora portátil:

# yp.conf – Configuración YP para la biblioteca NYS

#

servidor vbardolino bodega

servidor vstout cervecería

Esto le permite usar una computadora portátil en cualquier dominio configurando el dominio NIS deseado a través del comando nombre de dominio en el momento del arranque del sistema.

Después de crear este archivo de configuración básica y asegurarse de que sea legible, debe ejecutar la primera prueba para comprobar si puede conectarse a su servidor. Asegúrese de seleccionar cualquier mapa distribuido por su servidor, como hosts.byname, e intente recuperarlo usando la herramienta ypcat. ypcat, como todas las demás herramientas de administración de NIS, debería existir en /usr/sbin.

# ypcat hosts.byname

191.72.2.2 vbeaujolais vbeaujolais.linus.lxnet.org

191.72.2.3 vbardolino vbardolino.linus.lxnet.org

p>

191.72.1.1 vlager vlager.linus.lxnet.org

191.72.2.1 vlager vlager.linus.lxnet.org

191.72.1.2 vstout vstout.linus.lxnet .org

191.72.1.3 vale vale.linus.lxnet.org

191.72.2.4 vchianti vchianti.linus.lxnet.org

El resultado que obtenga debería verse como se muestra arriba. Si recibe un mensaje de error que dice "No se puede vincular al servidor que sirve al dominio" o algo similar, entonces el nombre de dominio NIS que configuró no tiene un servidor coincidente en yp.conf o, por alguna razón, no se encontró el servidor. En el último caso, asegúrese de que hacer ping a ese host produzca resultados correctos y que efectivamente esté ejecutando un servidor NIS. Puedes verificar esto último usando rpcinfo, que generará el siguiente resultado:

# rpcinfo –u serverhost ypserv

programa 100004 versión 2 listo y esperando

10.6 Elegir los mapas correctos

Una vez que esté seguro de que puede comunicarse con el servidor NIS, debe decidir qué archivo de configuración reemplazará o agregará a los mapas NIS. Normalmente, utilizará mapas NIS para funciones de búsqueda de host y contraseña. El primero es particularmente útil cuando no se utiliza BIND. Este último permite a todos los usuarios iniciar sesión en sus cuentas en cualquier sistema en el dominio NIS; esto generalmente requiere compartir un directorio central/home entre todos los hosts a través de NFS. Esto se analiza en detalle en la Sección 10.7. Otros mapas, como services.byname, no son tan espectaculares, pero pueden ahorrarle algo de trabajo de edición si instala cualquier aplicación de red que utilice un nombre de servicio que no esté en el archivo de servicios estándar.

En general, desea tener cierta libertad de elección en cuanto a cuándo una función de búsqueda utiliza archivos locales y cuándo consulta un servidor NIS. NYS le permite configurar el orden en que las funciones acceden a estos servicios. Esto se controla a través del archivo /etc/nsswitch.conf, que hace referencia al cambio de servicio de nombres pero no se limita a los servicios de nombres. Para cualquier función de búsqueda de datos admitida por NYS, contiene una fila que especifica el servicio utilizado.

El correcto orden de los servicios está relacionado con el tipo de datos. No es necesario que el mapa services.byname contenga entradas diferentes a las del archivo de servicios local; puede contener más entradas; Por lo tanto, una buena opción podría ser consultar primero los archivos locales y buscar NIS solo si no se encuentra el nombre del servicio. Por otro lado, la información del nombre de host puede cambiar con mucha frecuencia, por lo que el servidor DNS o NIS siempre debe tener información muy correcta, y el archivo de hosts local solo sirve como respaldo en caso de que DNS y NIS no estén disponibles. En este caso, es posible que desee consultar el archivo local en último lugar.

El siguiente ejemplo muestra cómo configurar las funciones gethostbyname(2), gethostbyaddr(2) y getservbyname(2) de la manera descrita anteriormente. Probarán los servicios enumerados en orden; si la búsqueda tiene éxito, se devolverán los resultados; de lo contrario, se probará el siguiente servicio.

# pequeña muestra /etc/nsswitch.conf

#

hosts: archivos nis dns

servicios: archivos nis

A continuación se muestra la lista completa de servicios que pueden tener una entrada en el archivo nsswitch.conf. Los mapas, archivos, servidores y objetos reales consultados dependen del nombre de la entrada.

nisplus o nis+

Utilice el servidor NIS+ para este dominio. La ubicación del servidor se obtiene del archivo /etc/nis.conf.

nis utiliza el servidor NIS actual para este dominio. La ubicación del servidor que se consulta se establece en el archivo yp.conf, como se muestra en la sección anterior. Para las entradas de hosts, consulta los mapas hosts.byname y hosts.byaddr.

dns utiliza servidores de nombres DNS. Este tipo de servicio sólo es útil para entradas de hosts. Los servidores de nombres que se recuperarán todavía están determinados por el archivo estándar resolv.conf.

files utiliza archivos locales, como el archivo /etc/hosts para las entradas de hosts.

dbm busca información de archivos DBM ubicados en /var/dbm. Los nombres utilizados en los archivos corresponden a mapas NIS.

Actualmente, NYS admite las siguientes entradas de nsswitch.conf: hosts, redes, contraseña, grupo, sombra, gshadow, servicios, protocolos, rpc y ethers. Se agregarán más entradas en el futuro.

La Figura 10.1 muestra un ejemplo más completo, que introduce otra característica de nsswitch.conf: la palabra clave [NOTFOUND=return] en la entrada de hosts notifica a NYS si no está presente en la base de datos NIS o DNS. Volver cuando se encuentra el artículo deseado. Es decir, NYS continuará buscando archivos locales sólo si las llamadas a los servidores NIS y DNS fallan por algún otro motivo. Por lo tanto, el archivo local sólo se utiliza durante el arranque y sirve como copia de seguridad cuando se apaga el servidor NIS.

# /etc/nsswitch.conf

#

hosts: nis dns [NOTFOUND=return] archivos

redes: nis [ NOTFOUND=return] archivos

servicios: archivos nis

protocolos: archivos nis

rpc: archivos nis

Figura 10.1 nsswitch.conf Archivos de muestra.

10.7 Uso de contraseña y mapas de grupo

Una aplicación importante de NIS es sincronizar la información de cuentas y usuarios en todos los hosts de un dominio NIS. En este sentido, normalmente simplemente guarda un pequeño archivo local /etc/passwd al que se agrega la información de todo el sitio obtenida de los mapas NIS. Sin embargo, no basta con habilitar la búsqueda NIS para este servicio en nsswitch.conf.

Al hacer referencia a la información de contraseña descrita por NIS, primero debe asegurarse de que el ID de usuario numérico de cualquier usuario en su archivo passwd local coincida con el ID de usuario del servidor NIS. Es posible que también lo necesite para otros fines, como al montar volúmenes NFS desde otros hosts de su red.

Si algún identificador numérico en /etc/passwd o /etc/group se desvía de los de los mapas, debe ajustar la propiedad de todos los archivos que pertenecen a ese usuario. Primero debe cambiar el uid y el gid en passwd y group a un nuevo valor; luego, busque todos los archivos que pertenecen al usuario que acaba de cambiar y, finalmente, cambie la propiedad de estos archivos.

Supongamos que News alguna vez tuvo una identificación de 9 y Okir tuvo una identificación de 103. Se cambiarán a otros valores y luego podrá emitir el siguiente comando:

# find / -uid 9 –print >/; tmp/uid.9

# find / -uid 103 –print >/tmp/uid.103

# cat /tmp/uid.9 |

# cat /tmp/uid.103 | importante. Para actualizar la propiedad del grupo de un archivo, usaría un comando similar.

Después de hacer esto, los uids y gids numéricos de su sistema coincidirán con los de todos los demás hosts de su dominio NIS. El siguiente paso será agregar una línea de configuración a nsswitch.conf que permita búsquedas NIS de información de usuarios y grupos:

# /etc/nsswitch.conf – tratamiento de contraseña y grupo

passwd: archivos nis

grupo: archivos nis

Esto hace que el comando de inicio de sesión y todos los demás comandos similares consulten primero los mapas NIS cuando un usuario intenta iniciar sesión y luego regresen si esto La búsqueda falla. Utilice archivos locales. En términos generales, eliminará a todos los usuarios de sus archivos locales, dejando solo las cuentas raíz y generales como las de correo. Esto se debe a que algunas tareas críticas del sistema pueden requerir asignar uid a nombre de usuario o viceversa. Por ejemplo, un trabajo cron de administración puede ejecutar el comando su para cambiar temporalmente las noticias, o el subsistema UUCP puede enviar por correo un informe de estado. Si news y uucp ya no tienen entradas en el archivo passwd local, estos trabajos fallarán gravemente mientras NIS no esté disponible.

Aquí hay dos grandes advertencias: por un lado, la configuración descrita anteriormente solo se aplica aquí a inicios de sesión que no utilizan contraseñas ocultas, como las incluidas en el paquete util-linux. Las complicaciones del uso de contraseñas ocultas con NIS se analizan a continuación. Por otro lado, el comando login no es el único comando que accede al archivo passwd; consulte el comando ls que mucha gente usa casi todo el tiempo. Cada vez que hace una lista larga, ls mostrará los nombres simbólicos de los usuarios y grupos que alojan un archivo, es decir, consultará al servidor NIS una vez por cada uid y gid que encuentre; Esto retrasará gravemente el trabajo realizado si su red local está bloqueada o, peor aún, cuando el servidor NIS no está en la misma red física, los datagramas aún deben viajar a través del enrutador.

El asunto aún no ha terminado. Imagínese lo que pasaría si un usuario quisiera cambiar su contraseña. Normalmente, ejecutará passwd, que leerá la nueva contraseña y actualizará el archivo passwd local. Con NIS, esto no es posible porque el archivo ya no existe localmente, pero hacer que los usuarios inicien sesión en NIS cada vez que quieran cambiar sus contraseñas tampoco es una opción. Por lo tanto, NIS proporciona un reemplazo directo para passwd llamado yppasswd, que se utiliza para realizar un trabajo similar en el NIS actual. Para cambiar la contraseña en el host de un servidor, se comunica con el demonio yppasswdd en ese host a través de RPC y le proporciona la información de contraseña actualizada. Normalmente, instala yppasswd de forma regular haciendo esto:

# cd /bin

# mv passwd passwd.old

# ln yppasswd passwd

Mientras tanto debes instalar rpc.yppasswdd en el servidor e iniciarlo desde rc.inet2. Esto ocultará eficazmente a sus usuarios cualquier distorsión introducida por NIS.

10.8 Uso de NIS con soporte oculto

Actualmente no hay soporte NIS para sitios que utilizan grupos de programas de inicio de sesión ocultos. John F. Haugh, autor del Grupo de Programas Sombra, publicó recientemente en comp.sources.misc una versión de las funciones de la biblioteca sombra protegidas por la GPL de la Biblioteca GNU. Tiene cierto soporte para NIS, pero no está completo y estas funciones aún no se han agregado a la biblioteca C estándar. Por otro lado, publicar información desde /etc/shadow a través de NIS o similar anula el propósito del componente de sombra.

Aunque la función de búsqueda de contraseñas de NYS no utiliza el mapa shadow.byname ni ningún otro mapa similar, NYS admite el uso transparente de un archivo /etc/shadow local. Cuando se llama a la implementación de getpwnam del Estado de Nueva York para buscar información relacionada con un inicio de sesión determinado, se recupera la función especificada por la entrada passwd en nsswitch.conf. El servicio nis simplemente buscará este nombre en el mapa passwd.byname del servidor NIS. El servicio de archivos comprobará si /etc/shadow existe y, si existe, intentará abrirlo. Si no existe, o si el usuario no tiene privilegios de root, se recurre al enfoque tradicional de simplemente buscar la información del usuario en /etc/passwd. Sin embargo, si el archivo oculto existe y se puede abrir, NYS extraerá la contraseña del usuario del oculto. La función getpwuid también se implementa de esta manera. De esta manera, los ejecutables compilados con NYS manejarán de forma transparente la instalación de componentes ocultos locales.

10.9 Uso de código NIS heredado

La configuración de un cliente NIS es ligeramente diferente si utiliza el código de cliente actualmente en la biblioteca C estándar. Por un lado, utiliza un demonio ypbind para transmitir consultas para servidores en ejecución en lugar de obtener información (del servidor) de un archivo de configuración. Por lo tanto, debes asegurarte de comenzar a ejecutar ypbind durante el inicio. Se debe llamar después de que se haya configurado el dominio NIS y se haya iniciado el mapeador de puertos RPC. En este momento, puede funcionar llamar a ypcat como se muestra arriba para probar el servidor.

Recientemente, ha habido muchos informes de errores sobre NIS y el mensaje de error dice "clntudp_create: RPC: falla del mapeador de puertos – RPC: no se puede recibir". Esto se debe a un cambio incompatible en la forma en que ypbind se comunica con las funciones de la biblioteca sobre la información vinculante. Obtener el código fuente más reciente para la herramienta NIS y recompilarlo puede resolver este problema. [5]

Del mismo modo, el método tradicional de NIS para determinar si y cómo fusionar información de NIS con información de archivos locales se desvía del método utilizado en el Estado de Nueva York. Por ejemplo, para utilizar mapas de contraseñas NIS, debe incluir la siguiente línea en el mapa /etc/passwd:

+:*:O:O:::

Esto marca el búsqueda de contraseña Donde la función "inserta" mapas NIS. Insertar una línea similar en /etc/group (menos los dos últimos dos puntos) hará lo mismo para los mapas group.*. Para utilizar los mapas hosts.* distribuidos por NIS, simplemente cambie la línea de orden en el archivo host.conf. Por ejemplo, si desea utilizar NIS, DNS y el archivo /etc/hosts (en ese orden), debe cambiar esta línea para

order yp bind hosts

Actualmente , la implementación tradicional de NIS no admite ningún otro mapa.