Original in fr Frédéric Raynal
fr to pt Patrick Carpalhoso
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.