Danise Víctor Xavier

Departamento de Informática

Universidade Federal de Pernambuco

e-mail: dvx@di.ufpe.br

Recife, 25 de março de 1996

O NIS (Network Information Service) é um serviço que oferece consistência e transparência aos arquivos e dados compartilhados em sistemas de computação distribuída.

Ele provê um sistema de base de dados que da suporte a um conjunto de arquivos com a mesma configuração. As informações são armazenadas nos mapas NIS seguindo o sistema de base de dados DBM do BSD UNIX. O formato DBM permite uma busca de dados rápida, pois consiste de um conjunto de chaves e seus valores associados organizados em uma tabela.

O NIS está construído sob um modelo cliente/servidor. O servidor NIS mantém as cópias das bases de dados enquanto que o cliente NIS solicita informações do servidor ao invés de utilizar as cópias locais dos arquivos. Por exemplo, uma vez que o NIS está sendo executado, as informações referentes a endereço de hosts serão pesquisadas no mapa hosts contido no servidor NIS ao invés do arquivo /etc/hosts local ao cliente que solicitou tal informação.

Em um ambiente distribuído deve ser preservada a consistência das informações que por ele fluem. Isto significa que as alterações realizadas em cada um dos mapas devem ser propagadas aos demais hosts na rede. O NIS oferece esta consistência com a facilidade de um gerenciamento centralizado. Ao invés de gerenciar um a um os arquivos em cada host, é mantida uma base de dados para cada arquivo em um servidor central. As máquinas solicitam informações das bases conforme delas necessitem.

A estrutura segundo a qual o NIS é implementado segue o modelo cliente/servidor. O servidor NIS pode ser dividido em: servidor mestre (master) e servidor escravo (slave). O servidor master é aquele que mantém as cópias originais dos mapas NIS e é nele onde são realizadas as alterações dos mapas. O servidor slave trata das solicitações vindas dos clientes, pois possui cópias dos mapas que foram para eles propagados do servidor master. Não é possível realizar modificações nos mapas locais aos servidores slave.

A figura 1.1 ilustra como é realizada a troca de informações entre servidores master, slave e clientes NIS.

Como instalar/configurar os elementos do NIS (master, slave e clientes), além da estrutura dos mapas NIS, os daemons que executam o NIS, a atualização dos mapas e a integração do DNS com o NIS, serão descritos em detalhes a seguir.

2.1 Configuração dos servidores NIS

Para que uma máquina na rede funcione como um servidor NIS precisamos realizar estas tarefas:

• Definir os servidores master e slave do novo ambiente NIS;

A escolha dos servidores deve ser feita levando-se em consideração a carga da rede que se está modelando. O cliente NIS solicita muitas informações, até mesmo sobre sua própria configuração. Sendo assim, os servidores devem possuir uma alta disponibilidade em relação a atualização e tratamento de requisições. Se um servidor NIS interrompe sua execução e não mais responde ou opera lentamente, o cliente tenta encontrar outro servidor menos carregado. Esta ação demanda um certo overhead em reconhecer que o servidor corrente está down e recorrer a um outro.

É importante manter os servidores sincronizados, pois os clientes podem buscar informações NIS de qualquer servidor, então, eles devem possuir cópias de cada arquivo mapa para garantir uma operação correta do NIS.

• Inicializar o daemon ypserv que torna o sistema capaz de agir como um servidor NIS;

Instalação do master

1^o Configurar o nome do domínio NIS no servidor master;

ou

domainname `cat /etc/defaultdomain` (/etc/rc.local)

2^o Verificar se os mapas contêm as informações corretas;

3^o Criar um novo servidor master;

O utilitário ypinit cria o subdiretório do domínio /var/yp/sysadm. Depois ele cria um conjunto completo de mapas administrativos e os coloca neste diretório. Um dos mapas é o ypservers que mantém uma relação dos servidores que executam o NIS.

Apenas um servidor master é permitido por domínio NIS. Se para melhorar a performance da rede é necessário adicionar mais servidores, então estes devem ser configurados como servidores slave do mesmo domínio. O utilitário ypinit não verifica a existência de mais que um servidor master por domínio NIS. Porém, a definição errônea de outro servidor master irá causar confusão na execução de procedimentos como atualização de mapas, ou requisição de informações.

4^o Iniciar o serviço NIS:

ou

reinicializar o host servidor (/etc/rc.local)

Instalação do slave

O NIS deve estar executando no servidor master e o domínio deve estar configurado (domainname).

1^o Inicializar o servidor slave;

O servidor master e o slave devem estar na mesma rede IP, de forma que o IP broadcast enviado pelo slave seja ouvido pelo master.

2^o Iniciar o serviço NIS;

Quando o slave é inicializado, ele transfere os arquivos mapas do master e constrói sua própria cópia dos mapas. Se o host antes de se tornar slave possuir informações pertencentes aos mapas NIS, o servidor master deve possuir uma cópia destes dados antes de inicializar o slave. As informações locais ao servidor slave não serão disponibilizadas através do NIS a menos que os arquivos fontes no master as contenha.

• Adicionar novos servidores slave quando do crescimento da rede ou quando da necessidade de melhoria de performance.

1^o Incluir o nome do host no mapa ypservers;

Editar o mapa ypservers faz com que as demais informações sejam excluídas do mapa, portanto o procedimento para incluir um novo host é:

2^o Inicializar o novo slave;

3^o Iniciar o serviço NIS.

Antes de disponibilizar um host como cliente NIS, no mínimo um servidor deve estar ativo.

1^o Verificar se os arquivos de configuração no cliente incluem marcadores indicando que estes dados serão adicionados aos mapas NIS;

2^o Configurar o nome do domínio NIS e inicializar o daemon ypbind.

ou

2.3 Mapas NIS

Nomenclatura e tipos de arquivos

Um mapa NIS é um mecanismo utilizado para acessar as informações contidas em um arquivo. Contudo não há uma correspondência um a um entre mapas e arquivos. Um arquivo pode ser pesquisado de várias maneiras, através de n chaves, sendo assim cada modo de pesquisa se constitui em um mapa NIS.

Para facilitar a administração dos mesmos, se atribui um nome único (apelido) aos arquivos que correspondem diretamente ao arquivo original. Este apelido deve ser reconhecido apenas por dois utilitários NIS: ypmatch e ypcat.

Por exemplo, o arquivo de senhas do usuário, cujo apelido é passwd pode ser pesquisado segundo o nome do usuário e o seu número de identificação. Então, existem dois mapas que acessam o passwd: passwd.byname (nome do usuário) e passwd.byuid (user ID). A convenção para nomear os mapas é: filename.bykeyname

Os mapas NIS podem ser tratados de dois diferentes modos:

• As bases de dados substituem os arquivos;

Alguns arquivos locais são ignorados tão logo o daemon ypbind seja ativado, iniciando o serviço NIS. Estes arquivos estão relacioandos na tabela 2.3.1. Apesar de serem ignorados estes arquivos devem ser mantidos em suas máquinas locais. O arquivo /etc/hosts, por exemplo, é usado durante o processo de boot do cliente NIS, depois o NIS é inicializado e este arquivo é ignorado. Portanto, é importante ajustar o arquivo hosts para conter o mínimo de entradas necessárias.

• Os arquivos são acrescidos pelo NIS.

Outros arquivos são consultados antes dos mapas NIS. A pesquisa de uma certa entrada é feita no arquivo local primeiramente, se não for encontrada é que será consultado o mapa NIS correspondente. Um exemplo deste tipo de arquivo é o /etc/passwd. Quando o usuário entra no sistema é verificado no primeiro momento se ele tem permissão local, caso contrário é pesquisado no mapa NIS passwd. Isto possibilita limitar o acesso de alguns usuários a apenas uma ou outra máquina na rede. Os demais arquivos deste tipo estão relacionados na tabela 2.3.2.

Nestes arquivos são mantidas as entradas mínimas necessárias a inicialização ou a operação no modo single-user. Deve conter ainda as entradas válidas unicamente no host local.

Para identificar que as informações dos mapas NIS devem ser acrescentadas àquelas contidas nos arquivos locais, é utilizado o símbolo "+" no arquivo. Por questões de segurança alguns arquivos incluem a entrada "+" segundo o formato das outras entradas. Por exemplo, no arquivo /etc/group a última linha será "+:*:*" ao invés de "+" impedindo que esta seja uma entrada válida para uso indevido quando o NIS não estiver sendo executado.

Netgroups

É uma base de dados contendo conjuntos de usuários e hosts. Está estruturada na forma de tríplice: (hostname, username, domain name). Onde o nome do domínio é aquele no qual o netgroup é válido. Este campo é utilizado quando existem vários domínios NIS na mesma rede e se faz necessário criar um grupo válido em um ou outro domínio. O netgroup é utilizado para acrescentar informações a outros mapas e arquivos. Por exemplo: adicionar usuários ao arquivo passwd gerenciado pelo NIS. Como na tríplice está relacionando nome do usuário com nome do host, e o mapa passwd não faz referência a hosts, então o nome do host em cada tríplice contida neste netgroup será ignorado. Os netgroups são acessados unicamente através do NIS.

Integração do passwd com o /etc/passwd

Existem várias formas de integrar o mapa NIS passwd com o arquivo /etc/passwd. Isto proporciona maior flexibilidade, contudo corresponde também a maior complexidade.

• root:passwd:0:1:Operator:/:/bin/csh

• daemon:*:1:1::/:

Além das informações no arquivo local acrescenta aquelas contidas no mapa NIS correspondente.

• +stern:*:

Acrescenta informações referentes ao usuário especificado.

• +stern:*:0:0:Hal Stern - Guest :::

Os valores podem ser reunidos, sendo uns definidos no arquivo e outros no respectivo mapa NIS. As definições no arquivo ignoram os valores contidos no mapa NIS.

• +@trusted-users

Inclui no mapa as entradas para os usuários declarados no netgroup. As definições de hostname não têm qualquer efeito nas entradas do arquivo passwd.

• -johnc:*:12389:20::

Remove as entradas referentes ao usuário especificado ou aqueles pertencentes ao netgroup. Deve conter username, UID e GID.

O exemplo abaixo tem outro efeito:

• +@trusted-users

Como o usuário johnc é encontrado no netgroup, o NIS finaliza a busca e não executa a segunda linha.

Estrutura dos Mapas

Os arquivos gerenciados pelo NIS são convertidos em tabelas contendo pares de palavras chave e os valores associados, são os mapas. Os mapas NIS são construídos a partir dos arquivos da base de dados DBM. Como o NIS é construído sobrer o protocolo RPC e utiliza o transporte para transferir requisições do host cliente para o servidor, um overhead é observado pelo fato de serem executadas chamadas de procedimento remoto na rede. O mecanismo de armazenamento dos mapas NIS, DBM proporciona uma melhoria de performance na localização dos dados.

Cada base de dados DBM, ou seja, cada mapa NIS, compreende dois arquivos. Um arquivo de índices (com extensão .dir) e um arquivo de dados (com extensão .pag). Por exemplo:

Os arquivos mapas não são arquivos ASCII, portanto para transferi-los de uma máquina para outra devem ser utilizadas feramentas NIS como: ypxfr e yppush. Elas convertem os arquivos ASCII nos mapas correspondentes segundo o formato DBM e a arquitetura do host local.

Domínio NIS

É um conjunto de mapas e de hosts que utilizam estes mapas. Os hosts podem estar ligados a um ou mais domínios. Quando um host pesquisa por informações NIS ele procura um servidor NIS que tenha os mapas no seu domínio. A definição de múltiplos domínios está condicionada a utilização dos dados contidos nos mapas, se as informações da base de dados se aplicam a todos os hosts do domínio ou se há necessidade de criar outro domínio.

Daemon ypserv

O daemon ypserv trata de todas as requisições dos clientes, assim ele fica em execução nos servidores NIS. O protocolo NIS funciona segundo três conjuntos de chamadas de procedimento remoto:

• Pesquisas dos clientes;

São realizadas através de chaves, e retornam um registro da base de dados DBM. As pesquisas podem ser: combinando uma única chave, get-first e get-next (estas duas requisições são usadas para uma busca linear no mapa NIS) e get-all.

• Manutenção dos mapas;

São usadas na transferência dos mapas entre master e slave. A função get-master retorna o nome do servidor master de um certo mapa e get-order retorna a marcação da última geração do arquivo mapa.

• Chamadas internas do NIS.

Efetuam a transferência dos mapas e respodem as requisições de serviço por um domínio. Se o NIS não puder servir a um certo domínio ele não responde as requisições.

O daemon não conhece quais os mapas estão ou não disponíveis, nem qual o domínio que ele serve. Ele responde as requisições se existir o subdiretório do domínio (/var/yp/sysadm). Mesmo que este subdiretório esteja vazio ou parcialmente completo com os mapas, o servidor ainda irá responder com uma mensagem de erro, por exemplo, no such map. Portanto, é necessário que cada servidor NIS tenha uma conjunto completo de arquivos mapas.

Se o arquivo /var/yp/ypserv.log existir quando o ypserv é inicializado, as mensagens de erro serão escritas neste arquivo.

Daemon ypbind

Este daemon é executado no cliente NIS. O ypbind procura por um servidor ao qual irá se ligar para realizar requisições NIS. Este servidor deve pertencer ao domínio para o qual o processo requisitou o serviço. Se o servidor interrompe sua execução ou processa a solicitação da informação muito lentamente, então o ypbind encerra tal ligação e envia uma outra requisição broadcast. Cada cliente NIS pode estar ligado a vários domínios por vez.

O ypbind mantém a trilha que liga o cliente ao servidor, de modo que uma nova requisição possa ser respondida diretamente sem necessidade que o cliente envie um outro broadcast para o serviço.

O utilitário ypwhich informa a qual servidor o processo cliente está ligado em um certo domínio.

3.1 Rede NIS

A implementação de uma rede NIS implica em decidir o número de domínios, o número de servidores por domínio e os nomes dos domínios.

O número de domínios NIS que se precisa depende da divisão de recursos computacionais. O grau de compartilhamento de informações por certos grupos é que vai decidir se eles devem ou não ser divididos em diferentes domínios NIS.

Grupos de poucos usuários que acessam máquinas em comum, podem ser tratados isoladamente sem a necessidade de realmente dividi-los em domínios diferentes, pode ser utilizado os netgroups que criam um subconjunto de um domínio.

O nome do domínio pode ser o nome do grupo. Se estão sendo definidos vários domínios NIS seguindo uma hierarquia, o esquema de nomes para eles pode ser com múltiplos níveis. Por exemplo:

A quantidade de servidores por domínio NIS é determinada pelo tamanho do domínio e pelo conjunto de serviços requisitados a ele. De um modo geral se adota dois servidores por domínio (um master e um slave). Um modelo com dois servidores oferece uma segurança a mais, pois caso um deles interrompa seu processamento, o outro irá prosseguir com a execução normal. Manter uma rede com um único servidor causa um gargalo na performance e um ponto de falha na rede.

A carga de serviço sobre a rede deve ser dividida entre os vários hosts para evitar queda de algum ponto. Esta carga depende do trabalho executado em cada máquina e da velocidade relativa dos clientes e servidores. O número de servidores também depende da estrutura física da rede.

De forma a manter a base de dados do NIS consistente, ou seja, todas as máquinas na rede provendo as mesmas informações, se faz necessária a atualização dos arquivos mapas em todos os servidores. Existem dois mecanismos que podem ser utilizados para atualizar os mapas: o make e o ypxfr. O make transfere os mapas do master para os servidores slave. O utilitário ypxfr é executado no servidor slave e extrai os mapas do master|.

Quando é necessário realizar uma modificação em um mapa, o arquivo fonte referente ao mapa deve ser editado, no servidro master e em seguida o utilitário o make deve ser executado.

Quando um mapa sofre alguma modificação e portanto deve ser reconstruído, é utilizado o utilitário yppush para verificar a ordem numérica do mapa em cada servidor NIS. Se os mapas não estão atualizados então, o yppush os transfere para os servidores slave. Para identificar o nome dos servidores é utilizado o mapa ypservers.

Para garantir a atualização dos mapas até que novas modificações precisem ser realizadas, o NIS utiliza o utilitário ypxfr para copiar um mapa no slave. Esta ransferência é precedida por uma verificação, feita pelo slave, a fim de comparar a data da última atualização do mapa que ele possui com a cópia do mapa que está no master. Se a cópia do master é mais recente, então a transferência é realizada. Uma vez estando o mapa no slave, ele deve ser reconstruído a fim de incorporar as convenções locais próprias ao servidor.

O ypxfr é uma ferramenta do NIS para executar transferências dos mapas para os servidores slave periodicamente. Sendo assim, os mapas a serem atualizados devem ser escalonados baseado na frequência de sua modificações. Alguns mapas são alterados com maior frequência e portanto o ypxfr deve ser executado sobre eles a cada hora. Já outros podem ser atualizados uma vez ao dia. Para implementar a escala são utilizados um ou mais scripts executando o ypxfr. Por exemplo:

Para registrar a data de atualização de cada mapa, existe um arquivo associado a cada um deles cujo conteúdo é vazio pois, o importante é a data de sua criação. A extensão destes arquivos é .time. Por exemplo: para o mapa NIS construído a partir do arquivo passwd o seu arquivo de tempo é passwd.time. Estes arquivos são armazenados no diretório NIS /var/yp (dependendo do sistema).

Se um mapa não estiver sido transferido com sucesso ou se estiver corrompido, ele pode ser reconstruído e novamente transferido através da remoção do seu arquivo de tempo no servidor master:

Ao reconstruir um mapa deve-se verificar se outros mapas dependem ou não deste a ser modificado. Por exemplo: o mapa netid é usado para determinar usuários credenciados ao sistema, ele possui para cada usuário uma lista com todos os grupos dos quais ele é membro. Portanto, quando um dos arquivos /etc/group ou /etc/passwd for alterado o mapa netid deve ser reconstruído.

SCCS

Em um ambiente de rede pode existir mais de um administrador alterando um mesmo mapa NIS simultaneamente. Isto deve ocorrer de modo coordenado para evitar que um esteja removendo entradas no mapa e outro adicionando. Para solucionar este problema podem ser utilizados sistemas de controle do código fonte como: SCCS ou RCS, juntamente com o NIS.

A melhor maneira de controlar modificações dos mapas e manter um histórico das alterações dos arquivos mapas, é colocá-los cob o controle de um sistema como o SCCS.

O SCCS gerencia qualquer arquivo texto que contenha no mínimo uma macro ou palavra chave que faça referência ao SCCS. Estas informações estão geralmente nos cabeçalhos dos arquivos a serem gerenciados. Por exemplo:

Para colocar os arquivos sob a administração do SCCS é suficiente, uma vez que eles já contêm o cabeçalho, inicializá-lo:

Usando o SCCS cada alteração no arquivo é documentada antes deste arquivo ser colocado de volta ao controle do SCCS. Se o arquivo é retornado ao controle do SCCS antes de ser convertido em mapa NIS, é realizado uma auditoria das alterações de configuração.

Se qualquer alteração para um destes arquivos não ocorrer corretamente, o SCCS pode ser usado para encontrar a linha exata onde a alteração se deu e o tempo em que ela foi realizada.

A principal desvantagem observada com o uso do SCCS é que as alterações devem ser realizadas pelo root, logo não se adequa ao arquivo /etc/passwd, pois o mapa passwd sofre alteração da senha feita diretamente pelo usuário.

O NIS é um serviço de grande funcionalidade em administração de sistemas. As bases de dados gerenciadas pelo NIS não são necessariamente apenas aquelas que se referem a hosts, grupos, senhas, e etc. O NIS também pode gerenciar outros tipos de arquivos, como por exemplo os mapas do BSD Automounter - Amd.

A integração dos mapas NIS com os arquivos permite uma flexibilidade bastante significante. Através desta integração é possível limitar o acesso dos usuários a determinados hosts, a um certo shell, ou ainda a um diretório home, sem que para tanto seja necessário alterar os mapas NIS e então propagá-los.

1. Hal Strern - Managing NFS and NIS - O’Reilly & Associates, Inc. - 1991.
1. Evi Nemeth, Garth Snyder, Scott Seebass, Trent R. Hein - UNIX System Administration Handbook - Prentice Hall PTR - 1995.