|
|
Este artigo está disponível em: English Castellano Deutsch Francais Nederlands Portugues Russian Turkce |
by Frédéric Raynal About the author: Frederic Raynal prepara uma tese em informática no INRIA. Ele gosta também ler (tanto Tolkien como Balzac) e ouvir musica (de Mozart a Philip Glass e de Led Zeppelin a Massive Attack passando por Björk e Boris Vian, mas evitando cautelosamente o rap, a techno e outros ruídos ;-) Content: |
Abstract:
O Network Information Service (NIS) gera uma base de dados num servidor. Cada computador da rede onde se executa um cliente NIS pode consultar o servidor para obter informaç�es (nome do login, palavra-chave, informaç�es sobre os grupos de utilizadores, ...). Isso permita uma gestão centralizada e transparente de um grande numero de maquinas (sobretudo quando é, utilizado em associação com um sistema de ficheiros distribuído como NFS) porque as modificaç�es das informaç�es são depois repercutidas via o servidor para todos os seus clientes.
O Network Information Service (NIS) foi inicialmente criado pela Sun e conhecido sobre o nome de Sun Yellow Pages (mais conhecido geralmente e simplesmente como as Yellow Pages ou YP). De qualquer modo, esse termo é uma marca registada da British Telecom e não pode, desse facto, ser utilizado sem os devidos direitos. Essas Yellow Pages fazem referência as mesmas que aquelas que nós conhecemos aqui em França.
Os servidores NIS guardem as copias dos ficheiros de configuração comuns as varias maquinas de uma rede numa base de dados. Os clientes NIS fazem pedidos aos servidores em vez de utilizar os seus próprios ficheiros de configuração.
Vamos supor que somos um utilizador que deseja mudar a sua palavra-chave numa rede. Suponhamos em primeiro que nessa rede os YPs não estão instalados. O utilizador terá de ir a todos os postes da rede para alterar a sua palavra-chave. Em contrapartida, graças aos YPs, ele poderá contentar-se em mudar a sua palavra-chave numa maquina qualquer na qual um cliente NIS esteja a funcionar, a palavra-chave será depois transferida para o servidor que irá actualizar a sua base de dados. Depois, quando esse utilizador desejar conectar-se numa maquina qualquer da rede (na qual existe um cliente NIS como é evidente ;-), a palavra-chave será comparada com aquela que está na base de dados do servidor.
Notamos que existem diferentes variantes aos YPs mas visto este artigo ser uma introdução, veremos unicamente os grandes princípios de funcionamento sem entrar nos pormenores que trataremos mais tarde.
A glibc 2.x (libc6) suporta a utilização de NSS (Name Switch Service) que determina a ordem a qual as informaç�es devem de ser pesquisadas (ver o ficheiro /etc/nsswitch.conf). Ela gera os maps aliases, ethers, group, hosts, netgroups, networks, protocols, publickey, passwd, rpc, services e shadow.Uma rede vai ter uma maquina que desempenha o papel de servidor NIS para um domínio. Esse domínio corresponde, basicamente, ao nome da base de dados que o servidor vai gerir. Ele serve de chave para os clientes NIS para que estes possam encontrar, no servidor NIS, as informaç�es desejadas. Esse nome de domínio não tem estritamente nada a ver com o nome do domínio DNS. Vários servidores NIS podem ser instalados numa mesma rede. Eles poderão cada um gerir um domínio (no ponto visto NIS) diferente, ou então o mesmo domínio (nesse caso teremos um servidos mestre e servidores escravos).
Os servidores escravos só têm uma copia da base de dados do servidor mestre. Esses servidores servem para compensar, a nível dos clientes, o servidor mestre quando este leva muito tempo a responder ou em caso de avaria.
Os servidores escravos são avisados de qualquer alteração da base de dados pelo programa yppush e eles corrigem então a sua própria base de dados de modo a que ela coincida exactamente com a base de dados do servidor mestre.
Do lado dos clientes nenhuma manutenção é necessária porque eles estão em contacto permanente com o servidor NIS para encontrar as informaç�es na sua base de dados.
As bases de dados YP são do formato GDBM, vindo do formato ASCII. Elas são geradas no momento do servidor pelo programa makedbm.
Esses maps (cartas em Inglês - as bases de dados) estabelecem as correspondências entre uma chave e seu valor. Todos os maps das YPs são construídos sobre esse modelo. Do ponto de vista do servidor, o conteudo não tem significado nenhum (alias, com algumas excepç�es sobre o servidor principal ou as datas). Isso significa que, para o servidor, uma map de palavras-chave ou de grupos ou ... só corresponde de facto unicamente a uma serie de pares (chaves, valores). Só o cliente YP sabe como percorrer esses maps em busca da informação desejada.
Essa representação dos dados cria um problema. Como o servidor não sabe "ler" o valor duma chave para pesquisar a segunda chave, somos obrigados a duplicar os dados. Por exemplo, no caso das palavras-chave, podemos querer pesquisar ou por login, ou por "numero de utilizador" (user ID ou UID, identificador proprio a cada utilizador da rede). Isso traduz-se por uma redundancia de informação, visivel pela presença dos ficheiros passwd.byname e passwd.byuid. Criamos então uma nova map para cada chave. Isso significa que os dados devem de ser transmitidos duas vezes no momento de uma mudança.
Tres informaç�es são necessarias para que um cliente encontra o que ele procura numa base de dados:
Isto ofereça uma grande flexibilidade de utilização porque a instalação de um novo dominio resume-se a criar o directorio /var/yp/novo_dominio, copiar la dentro o Makefile e executa-lo com as opç�es desejadas.
O funcionamento das YPs recaie essencialmente sobre as Remote Procedure Calls (RPCs) que permitem pedidos entre o servidor e os clientes.
O RPC portmapper (portmap) é um programa que converte os numeros de programas RPC em numero de portas. Quando um servidor RPC arranqua, ele vai indicar ao portmap qual a porta ele ira utilizar e os numeros de programas RPC que ele gera. Quando um cliente deseja enviar um pedido RPC para um determinado numero de programa, ele contacta em primeiro o servidor portmap para obter o numero da porta sobre a qual funciona o programa desejado. A seguir, ele envia o pacotes RPC a porta correspondente O modelo cliente/servidor das YPs é simplesmente um caso particular de cliente/servidor RPC.
O ficheiro yp_prot.h contem as estruturas e prototipos das 11 funç�es que definem o protocole RPC entre os clientes e o servidor das YPs.
|
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-09-28, generated by lfparser version 2.17