NIS mantém uma base de dados de informações denominadas mapas, que contém pares de chaves. Mapas são armazenados em uma máquina central que executa o servidor NIS e a partir da qual, os clientes recuperam as informações através de diversas chamadas RPC. Muito freqüentemente, mapas são armazenados no formato DBM.10.5
Os mapas em si são gerados a partir de arquivos textos mestres, como por exemplo os arquivos /etc/hosts ou /etc/passwd. Para alguns arquivos, diversos mapas são criados, um para cada tipo de chave. Por exemplo, pode-se pesquisar o arquivo hosts na busca por um nome de máquina ou por um endereço IP. Neste caso, dois mapas são gerados a partir deste arquivo, os mapas hosts.byname e hosts.byaddr, respectivamente. A tabela ![[*]](cross_ref_motif.gif)
lista os mapas mais comuns e os seus arquivos de origem.
Há outros arquivos e mapas que podem encontrar suporte em um ou outro pacote NIS e que podem conter informações para aplicações não discutidas neste livro, como o mapa bootparams que pode ser usado por alguns servidores BOOTP, ou mapas que não têm atualmente qualquer função no (como os mapas ethers.byname e ethers.byaddr).
Para alguns mapas, as pessoas comumente utilizam nomes curtos, os quais são mais simples de serem memorizados e digitados. Para se obter uma lista completa dos nomes curtos conhecidos pelas ferramentas NIS, deve-se executar o seguinte comando:
O servidor NIS é tradicionalmente chamado de ypserv. Para uma rede média, um único servidor será suficiente, porém redes grandes podem executar diversos servidores em máquinas diferentes e em segmentos diferentes da rede permitindo maior segurança e balanceamento entre servidores e roteadores. Estes servidores são sincronizados definindo-se um como servidor mestre e os demais como servidores escravos. Mapas serão criados somente na máquina onde for executado o servidor mestre. A partir deste, eles serão distribuídos para todos os escravos.
O leitor mais atento pode ter percebido que o termo rede foi colocado de forma muito vaga até aqui e isso se deve ao fato de NIS ter um conceito distinto para se referir a uma rede, ou seja o conjunto de todas as máquinas que compartilham parte de suas informações e dados de configurações de sistema através do NIS, criando o chamado: domínio NIS. Infelizmente, domínios NIS não têm absolutamente nada em comum com os domínios encontrados no DNS. A fim de evitar esta ambigüidade ao longo deste capítulo, sempre especificaremos o tipo de domínio a que se está referindo.
Os domínios NIS têm exclusivamente uma função administrativa. São invisíveis para a maioria dos usuários, exceto para aqueles que compartilham senhas entre todas as máquinas do domínio. Desta forma, o nome dado a um domínio NIS é relevante somente para administradores. Normalmente, qualquer nome servirá, desde que ele seja diferente de qualquer outro nome de domínio NIS existente na rede local. Por exemplo, caso o administrador da rede da Cervejaria Virtual resolva criar dois domínios NIS, um para a Cervejaria e outro para a Vinícola, eles podem chamar-se, por exemplo cervejaria e vinicola, respectivamente. Outro esquema comumente utilizado é o de simplificar o nome do domínio NIS, chamando-o somente de NIS. Para configurar e mostrar o nome do domínio NIS de uma máquina, deve-se utilizar o comando domainname. Ao ser acionado sem argumentos, ele imprime o nome do domínio NIS. Para configurar o nome do domínio deve-se executá-lo como superusuário e digitar-se:
Domínios NIS determinam que servidor NIS deverá ser pesquisado pela aplicação. Por exemplo, o programa login em uma máquina da Vinícola pode, obviamente, somente pesquisar o servidor NIS da Vinícola (ou um deles, caso haja mais de um) para descobrir a informação de senha de um usuário, enquanto uma aplicação em uma máquina da Cervejaria deve pesquisar o servidor NIS da Cervejaria.
Um mistério porém permanece sem solução: como os clientes descobrem a qual servidor eles devem se conectar. A abordagem mais simples poderia ser um arquivo de configuração que define o nome da máquina onde o servidor é executado. De qualquer forma, esta abordagem é pouco flexível, porque não permite que os clientes usem diferentes servidores (para o mesmo domínio), dependendo de sua disponibilidade. De qualquer forma, implementações tradicionais do NIS baseiam-se em um servidor especial chamado ypbind para detectar um servidor NIS adequado para o seu domínio NIS. Antes de estar apta a executar quaisquer pesquisas NIS, uma aplicação deve encontrar qual servidor ypbind pode ser usado.
O servidor ypbind testa os servidores através da propagação na rede local. O primeiro servidor que responder é assumido como sendo o potencialmente mais rápido e será usado nas pesquisas NIS subseqüentes. Após um certo intervalo ou se o servidor se tornar indisponível, ypbind irá repetir o teste para servidores ativos novamente.
Agora o ponto de discórdia sobre a definição dinâmica do servidor NIS reside no fato de ela ser raramente utilizada e que introduz um problema sério de segurança: ypbind cegamente acredita em qualquer máquina que responda, o qual pode ser um perfeito servidor NIS, assim como um intruso mal intencionado. Desnecessário dizer que isto se torna especialmente problemático quando se administram bases de dados de senhas sobre NIS. Para proteger-se disso, NYS não usa ypbind por padrão, mas escolhe o nome da máquina servidora a partir de um arquivo de configuração.