[LinuxFocus-icon]
Home  |  Map  |  Index  |  Search

News | Archives | Links | About LF
Este artigo está disponível em: English  Castellano  Deutsch  Francais  Nederlands  Portugues  Russian  Turkce  

convert to palmConvert to GutenPalm
or to PalmDoc

[Photo of the Author]
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:

 

Yellow Pages

[Illustration]

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.



Introdução

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.

Funcionamente

 

Estrutura

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.

 

Os maps

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:

  1. o nome do dominio: é o nome da base de dados no servidor das YPs
  2. o nome da map
  3. a chave desejada
Dessa forma, para que um cliente encontra a palavra-chave de um utilizador Toto no dominio Titi, ele ira ler o ficheiro /var/yp/titi/passwd.byname no servidor YP a procura do utilizador Toto.

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.

As Remote Procedure Calls (RPC)

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.

Conclusão

Agora que o principio geral é conhecido, o proximo artigo desvendera o aspecto cliente das yellow pages : como ele funciona, como configura-lo, as ferramentes que ele utiliza, etc... Veremos igualmente as ferramentas necessarias para assegurar-se da boa configuração do nosso cliente, tanto para as RPCs que para as YPs.  

Talkback form for this article

Every article has its own talkback page. On this page you can submit a comment or look at comments from other readers:
 talkback page 

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:
fr -> -- Frédéric Raynal
fr -> pt Patrick Carpalhoso

2001-09-28, generated by lfparser version 2.17