29.4. Sistema de Informação de Rede (NIS)

O Network Information System (NIS) foi projetado para centralizar a administração de sistemas UNIX® como Solaris™, HP-UX, AIX®, Linux, NetBSD, OpenBSD e FreeBSD. O NIS era originalmente conhecido como Yellow Pages, mas o nome foi alterado devido a problemas de marca registrada. Esta é a razão pela qual os comandos do NIS começam com yp.

O NIS é um sistema cliente/servidor baseado em Remote Procedure Call (RPC) que permite que um grupo de máquinas dentro de um domínio NIS compartilhe um conjunto de arquivos de configuração. Isso permite que um administrador do sistema configure sistemas clientes NIS com apenas dados mínimos de configuração e adicione, remova ou modifique dados de configuração de um único local.

O FreeBSD usa a versão 2 do protocolo NIS.

29.4.1. Termos do NIS e Processos

A Tabela 28.1 resume os termos e processos importantes usados pelo NIS:

Tabela 29.1. Terminologia do NIS
TermoDescrição
nome de domínio NISOs servidores e clientes do NIS compartilham um nome de domínio NIS. Normalmente, esse nome não tem nada a ver com DNS.
rpcbind(8)Este serviço habilita o RPC e deve estar rodando para rodar um servidor NIS ou atuar como um cliente NIS.
ypbind(8)Este serviço liga um cliente NIS ao seu servidor NIS. Ele levará o nome de domínio NIS e usará RPC para se conectar ao servidor. É o núcleo da comunicação cliente/servidor em um ambiente NIS. Se este serviço não estiver sendo executado em uma máquina cliente, ele não poderá acessar o servidor NIS.
ypserv(8)Este é o processo para o servidor NIS. Se este serviço parar de funcionar, o servidor não poderá mais responder aos pedidos do NIS, portanto, esperamos que exista um servidor slave para assumir o controle. Alguns clientes não-FreeBSD não tentarão se reconectar usando um servidor slave e o processo ypbind pode precisar ser reiniciado nesses clientes.
rpc.yppasswdd(8)Este processo só é executado em servidores principais de NIS. Este daemon permite que clientes NIS alterem suas senhas do NIS. Se este daemon não estiver rodando, os usuários terão que acessar o servidor principal do NIS e alterar suas senhas lá.

29.4.2. Tipos de Máquinas

Existem três tipos de hosts em um ambiente NIS:

  • Servidor NIS master

    Esse servidor atua como um repositório central para as informações de configuração do host e mantém a cópia autoritativa dos arquivos usados por todos os clientes do NIS. O passwd, o group e outros arquivos usados pelos clientes do NIS são armazenados no servidor master. Embora seja possível que uma máquina seja um servidor NIS master para mais de um domínio NIS, esse tipo de configuração não será abordado neste capítulo, pois pressupõe ambiente NIS de pequena escala.

  • Servidores NIS slave

    Os servidores slaves do NIS mantêm cópias dos arquivos de dados do master do NIS para fornecer redundância. Os servidores slaves também ajudam a balancear a carga do servidor master, pois os clientes do NIS sempre se conectam ao servidor do NIS que responde primeiro.

  • Clientes NIS

    Os clientes do NIS autenticam-se contra o servidor NIS durante o logon.

Informações em muitos arquivos podem ser compartilhadas usando o NIS . Os arquivos master.passwd, group e hosts são comumente compartilhados via NIS. Sempre que um processo em um cliente precisa de informações que normalmente seriam encontradas nesses arquivos localmente, ele faz uma consulta ao servidor NIS ao qual está vinculado.

29.4.3. Considerações de Planejamento

Esta seção descreve um ambiente NIS de exemplo que consiste em 15 máquinas FreeBSD sem ponto de administração centralizado. Cada máquina tem seu próprio /etc/passwd e /etc/master.passwd. Esses arquivos são mantidos em sincronia entre si somente por meio de intervenção manual. Atualmente, quando um usuário é adicionado ao laboratório, o processo deve ser repetido em todas as 15 máquinas.

A configuração do laboratório será a seguinte:

Nome da maquinaEndereço IPRole da máquina
ellington10.0.0.2NIS master
coltrane10.0.0.3NIS slave
basie10.0.0.4Estação de Trabalho da Facultativa
bird10.0.0.5Máquina Cliente
cli[1-11]10.0.0.[6-17]Outras Máquinas Clientes

Se esta é a primeira vez que um esquema de NIS está sendo desenvolvido, ele deve ser cuidadosamente planejado através do tempo. Independentemente do tamanho da rede, várias decisões precisam ser tomadas como parte do processo de planejamento.

29.4.3.1. Escolhendo um Nome de Domínio NIS

Quando um cliente transmite suas solicitações de informações, ele inclui o nome do domínio NIS do qual faz parte. É assim que vários servidores em uma rede podem informar qual servidor deve responder a qual solicitação. Pense no nome de domínio NIS como o nome de um grupo de hosts.

Algumas organizações optam por usar o nome de domínio da Internet para o nome de domínio NIS. Isso não é recomendado, pois pode causar confusão ao tentar depurar problemas de rede. O nome de domínio NIS deve ser único dentro da rede e é útil se ele descrever o grupo de máquinas que representa. Por exemplo, o departamento de Arte da Acme Inc. pode estar no domínio NIS acme-art. Este exemplo usará o nome de domínio test-domain.

No entanto, alguns sistemas operacionais não-FreeBSD exigem que o nome de domínio NIS seja o mesmo que o nome de domínio da Internet. Se uma ou mais máquinas na rede tiverem essa restrição, o nome de domínio da Internet deve ser usado como o nome de domínio NIS.

29.4.3.2. Requisitos Físicos do Servidor

Há várias coisas que você deve ter em mente ao escolher uma máquina para usar como um servidor NIS. Como os clientes do NIS dependem da disponibilidade do servidor, escolha uma máquina que não seja reinicializada com freqüência. O servidor do NIS deve idealmente ser uma máquina autônoma cujo único propósito seja ser um servidor NIS. Se a rede não for muito usada, é aceitável colocar o servidor NIS em uma máquina que executa outros serviços. No entanto, se o servidor NIS ficar indisponível, isso afetará negativamente todos os clientes NIS.

29.4.4. Configurando o Servidor NIS Master

As cópias canônicas de todos os arquivos NIS são armazenadas no servidor master. Os bancos de dados usados para armazenar as informações são chamados de mapas de NIS. No FreeBSD, estes mapas são armazenados em /var/yp/[nome_do_domínio] onde [nome_do_dominio] é o nome do domínio NIS. Como vários domínios são suportados, é possível ter vários diretórios, um para cada domínio. Cada domínio terá seu próprio conjunto independente de mapas.

Os servidores master e slave do NIS lidam com todas as requisições NIS através do ypserv(8). Esse daemon é responsável por receber solicitações de entrada de clientes NIS, traduzindo o domínio e o nome do mapa solicitados para um caminho para o arquivo de banco de dados correspondente e transmitindo dados do banco de dados de volta ao cliente.

Configurar um servidor NIS master pode ser relativamente simples, dependendo das necessidades ambientais. Como o FreeBSD oferece suporte a NIS embutido, ele só precisa ser ativado adicionando as seguintes linhas ao arquivo /etc/rc.conf:

nisdomainname="test-domain"	1
nis_server_enable="YES"		2
nis_yppasswdd_enable="YES"	3

1

Esta linha define o nome de domínio NIS para test-domain.

2

Isto automatiza o início dos processos do servidor NIS quando o sistema é inicializado.

3

Isso habilita o daemon rpc.yppasswdd(8) para que os usuários possam alterar sua senha NIS de uma máquina cliente.

É preciso ter cuidado em um domínio com vários servidores, no qual as máquinas do servidor também são clientes NIS. Geralmente, é uma boa ideia forçar os servidores a fazerem bind em si mesmos, em vez de permitir que eles transmitam solicitações de bind e, possivelmente, fiquem vinculados um ao outro. Modos de falha estranhos podem ocorrer se um servidor cair e outros dependerem dele. Eventualmente, todos os clientes terão tempo limite e tentarão fazer bind em outros servidores, mas o atraso envolvido poderá ser considerável e o modo de falha ainda estará presente, uma vez que os servidores podem ligar-se entre si novamente.

Um servidor que também é um cliente pode ser forçado fazer bind em um servidor em particular adicionando estas linhas adicionais ao arquivo /etc/rc.conf:

nis_client_enable="YES"				1
nis_client_flags="-S test-domain,server"	2

1

Isso permite rodar coisas do cliente também.

2

Esta linha define o nome de domínio NIS para test-domain e vincula para si mesmo.

Depois de salvar as edições, digite /etc/netstart para reiniciar a rede e aplicar os valores definidos no arquivo /etc/rc.conf. Antes de inicializar os mapas de NIS, inicie ypserv(8):

# service ypserv start

29.4.4.1. Inicializando os mapas do NIS

Os mapeamentos NIS são gerados a partir dos arquivos de configuração no diretório /etc no NIS master, com uma exceção: /etc/master.passwd. Isso evita a propagação de senhas para todos os servidores no domínio NIS. Portanto, antes de inicializar os mapas do NIS, configure os arquivos de senha primários:

# cp /etc/master.passwd /var/yp/master.passwd
# cd /var/yp
# vi master.passwd

É aconselhável remover todas as entradas de contas do sistema, bem como quaisquer contas de usuário que não precisem ser propagadas para os clientes do NIS, como o root e quaisquer outras contas administrativas.

Nota:

Assegure-se de que o arquivo /var/yp/master.passwd não seja de grupo nem de mundo legível, definindo suas permissões para 600.

Depois de concluir esta tarefa, inicialize os mapas do NIS. O FreeBSD inclui o script ypinit(8) para fazer isso. Ao gerar mapas para o servidor master, inclua -m e especifique o nome de domínio NIS:

ellington# ypinit -m test-domain
Server Type: MASTER Domain: test-domain
Creating an YP server will require that you answer a few questions.
Questions will all be asked at the beginning of the procedure.
Do you want this procedure to quit on non-fatal errors? [y/n: n] n
Ok, please remember to go back and redo manually whatever fails.
If not, something might not work.
At this point, we have to construct a list of this domains YP servers.
rod.darktech.org is already known as master server.
Please continue to add any slave servers, one per line. When you are
done with the list, type a <control D>.
master server   :  ellington
next host to add:  coltrane
next host to add:  ^D
The current list of NIS servers looks like this:
ellington
coltrane
Is this correct?  [y/n: y] y

[..output from map generation..]

NIS Map update completed.
ellington has been setup as an YP master server without any errors.

Isto irá criar /var/yp/Makefile a partir de /var/yp/Makefile.dist. Por padrão, este arquivo assume que o ambiente tem um único servidor NIS com apenas clientes FreeBSD. Como test-domain tem um servidor slave, edite esta linha no arquivo /var/yp/Makefile para que comece com um comentário ( # ) :

NOPUSH = "True"

29.4.4.2. Adicionando novos usuários

Toda vez que um novo usuário é criado, a conta de usuário deve ser adicionada ao servidor mestre NIS e aos mapeamentos do NIS reconstruídos. Até que isso ocorra, o novo usuário não poderá efetuar login em nenhum lugar, exceto no NIS master. Por exemplo, para adicionar o novo usuário jsmith ao domínio test-domain, execute estes comandos no servidor master:

# pw useradd jsmith
# cd /var/yp
# make test-domain

O usuário também pode ser adicionado usando adduser jsmith em vez de pw useradd smith.

29.4.5. Configurando um Servidor NIS Slave

Para configurar um servidor NIS slave, faça o logon no servidor slave e edite o arquivo /etc/rc.conf assim como para o servidor master. Não gere nenhum mapa de NIS, pois estes já existem no servidor master. Ao executar ypinit no servidor slave, use -s (para slave) ao invés de -m (para master). Esta opção requer o nome do NIS master, além do nome do domínio, como visto neste exemplo:

coltrane# ypinit -s ellington test-domain

Server Type: SLAVE Domain: test-domain Master: ellington

Creating an YP server will require that you answer a few questions.
Questions will all be asked at the beginning of the procedure.

Do you want this procedure to quit on non-fatal errors? [y/n: n]  n

Ok, please remember to go back and redo manually whatever fails.
If not, something might not work.
There will be no further questions. The remainder of the procedure
should take a few minutes, to copy the databases from ellington.
Transferring netgroup...
ypxfr: Exiting: Map successfully transferred
Transferring netgroup.byuser...
ypxfr: Exiting: Map successfully transferred
Transferring netgroup.byhost...
ypxfr: Exiting: Map successfully transferred
Transferring master.passwd.byuid...
ypxfr: Exiting: Map successfully transferred
Transferring passwd.byuid...
ypxfr: Exiting: Map successfully transferred
Transferring passwd.byname...
ypxfr: Exiting: Map successfully transferred
Transferring group.bygid...
ypxfr: Exiting: Map successfully transferred
Transferring group.byname...
ypxfr: Exiting: Map successfully transferred
Transferring services.byname...
ypxfr: Exiting: Map successfully transferred
Transferring rpc.bynumber...
ypxfr: Exiting: Map successfully transferred
Transferring rpc.byname...
ypxfr: Exiting: Map successfully transferred
Transferring protocols.byname...
ypxfr: Exiting: Map successfully transferred
Transferring master.passwd.byname...
ypxfr: Exiting: Map successfully transferred
Transferring networks.byname...
ypxfr: Exiting: Map successfully transferred
Transferring networks.byaddr...
ypxfr: Exiting: Map successfully transferred
Transferring netid.byname...
ypxfr: Exiting: Map successfully transferred
Transferring hosts.byaddr...
ypxfr: Exiting: Map successfully transferred
Transferring protocols.bynumber...
ypxfr: Exiting: Map successfully transferred
Transferring ypservers...
ypxfr: Exiting: Map successfully transferred
Transferring hosts.byname...
ypxfr: Exiting: Map successfully transferred

coltrane has been setup as an YP slave server without any errors.
Remember to update map ypservers on ellington.

Isto irá gerar um diretório no servidor slave chamado /var/yp/test-domain que contém cópias dos mapas do servidor principal do NIS. Adicionar estas entradas ao arquivo /etc/crontab em cada servidor slave forçará os slaves a sincronizar seus mapas com os mapas no servidor master:

20      *       *       *       *       root   /usr/libexec/ypxfr passwd.byname
21      *       *       *       *       root   /usr/libexec/ypxfr passwd.byuid

Essas entradas não são obrigatórias porque o servidor master tenta enviar automaticamente quaisquer alterações no mapa para seus escravos. No entanto, como os clientes podem depender do servidor escravo para fornecer informações corretas de senha, recomenda-se forçar atualizações frequentes de mapas de senha. Isso é especialmente importante em redes ocupadas nas quais as atualizações de mapas nem sempre são concluídas.

Para finalizar a configuração, execute /etc/netstart no servidor slave para iniciar os serviços do NIS.

29.4.6. Configurando um cliente NIS

Um cliente NIS é vinculado a um servidor NIS usando ypbind(8). Esse daemon transmite solicitações de RPC na rede local. Essas solicitações especificam o nome do domínio configurado no cliente. Se um servidor NIS no mesmo domínio receber uma das transmissões, ele responderá a ypbind, que registrará o endereço do servidor. Se houver vários servidores disponíveis, o cliente usará o endereço do primeiro servidor para responder e direcionará todas as suas solicitações de NIS para esse servidor. O cliente irá automaticamente pingar o servidor regularmente para garantir que ainda esteja disponível. Se ele não receber uma resposta dentro de um período de tempo razoável, o ypbind marcará o domínio como não acoplado e começará a transmitir novamente na esperança de localizar outro servidor.

Para configurar uma máquina FreeBSD para ser um cliente NIS:

  1. Edite o /etc/rc.conf e adicione as seguintes linhas para definir o nome de domínio NIS e inicie ypbind(8) durante a inicialização da rede:

    nisdomainname="test-domain"
    nis_client_enable="YES"
  2. Para importar todas as possíveis entradas de senha do servidor NIS, use vipw para remover todas as contas de usuário, exceto uma do arquivo /etc/master.passwd. Ao remover as contas, lembre-se de que pelo menos uma conta local deve permanecer e essa conta deve ser membro do grupo wheel. Se houver um problema com o NIS, essa conta local poderá ser usada para efetuar login remotamente, tornar-se o superusuário e corrigir o problema. Antes de salvar as edições, adicione a seguinte linha ao final do arquivo:

    +:::::::::

    Esta linha configura o cliente para fornecer qualquer pessoa com uma conta válida na senha do servidor do NIS mapeia uma conta no cliente. Existem várias maneiras de configurar o cliente NIS modificando essa linha. Um método é descrito em Seção 29.4.8, “Usando Netgroups”. Para uma leitura mais detalhada, consulte o livro Managing NFS and NIS, publicado pela O'Reilly Media.

  3. Para importar todas as entradas de grupo possíveis do servidor NIS, adicione esta linha ao /etc/group:

    +:*::

Para iniciar imediatamente o cliente NIS, execute os seguintes comandos como superusuário:

# /etc/netstart
# service ypbind start

Depois de concluir estas etapas, a execução do ypcat passwd no cliente deve mostrar o mapa passwd do servidor.

29.4.7. Segurança NIS

Como o RPC é um serviço baseado em broadcast, qualquer sistema executando o ypbind dentro do mesmo domínio pode recuperar o conteúdo dos mapas do NIS. Para evitar transações não autorizadas, ypserv(8) suporta um recurso chamado securenets que pode ser usado para restringir o acesso a um dado conjunto de hosts. Por padrão, essas informações são armazenadas no arquivo /var/yp/securenets, a menos que ypserv(8) seja iniciado com -p e um caminho alternativo. Este arquivo contém entradas que consistem em uma especificação de rede e uma máscara de rede separadas por espaço em branco. Linhas iniciando com # são consideradas comentários. Um exemplo de securenets pode ser assim:

# allow connections from local host -- mandatory
127.0.0.1     255.255.255.255
# allow connections from any host
# on the 192.168.128.0 network
192.168.128.0 255.255.255.0
# allow connections from any host
# between 10.0.0.0 to 10.0.15.255
# this includes the machines in the testlab
10.0.0.0      255.255.240.0

Se ypserv(8) receber uma solicitação de um endereço que corresponda a uma dessas regras, ela processará a solicitação normalmente. Se o endereço não corresponder a uma regra, a solicitação será ignorada e uma mensagem de aviso será registrada. Se o securenets não existir, o ypserv permitirá conexões de qualquer host.

Seção 13.4, “TCP Wrapper” é um mecanismo alternativo para fornecer controle de acesso em vez de securenets. Embora o mecanismo de controle de acesso acrescente alguma segurança, ambos são vulneráveis a ataques como IP spoofing. Todo o tráfego relacionado a NIS deve ser bloqueado no firewall.

Servidores que usam securenets podem não servir clientes legítimos de NIS com implementações arcaicas de TCP/IP. Algumas dessas implementações definem todos os bits do host como zero ao fazer transmissões ou não observam a máscara de sub-rede ao calcular o endereço de transmissão. Embora alguns desses problemas possam ser corrigidos alterando a configuração do cliente, outros problemas podem forçar a desativação desses sistemas clientes ou o abandono do securenets.

O uso de TCP Wrapper aumenta a latência do servidor NIS. O atraso adicional pode ser longo o suficiente para causar timeouts em programas clientes, especialmente em redes ocupadas com servidores NIS lentos. Se um ou mais clientes sofrerem de latência, converta esses clientes em servidores de NIS slaves e force-os a se ligarem a eles mesmos.

29.4.7.1. Barrando alguns usuários

Neste exemplo, o sistema basie é uma estação de trabalho da dentro do domínio NIS facultativo. O mapa passwd no servidor NIS master contém contas para professores e alunos. Esta seção demonstra como permitir o login do corpo docente neste sistema e, ao mesmo tempo, recusar logins de alunos.

Para previnir usuários específicos de logar em um sistema, desde que eles estejam presentes no banco de dados do NIS, use vipw para adicionar -username com o numero correto de virgulas em direção ao fim do arquivo /etc/master.passwd no cliente, onde username é o nome de usuário a impedir de logar. A linha com o usuário bloqueado deve estar antes da linha + que permite usuários do NIS. Neste exemplo, bill está impedido de logar no basie:

basie# cat /etc/master.passwd
root:[password]:0:0::0:0:The super-user:/root:/bin/csh
toor:[password]:0:0::0:0:The other super-user:/root:/bin/sh
daemon:*:1:1::0:0:Owner of many system processes:/root:/usr/sbin/nologin
operator:*:2:5::0:0:System &:/:/usr/sbin/nologin
bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/usr/sbin/nologin
tty:*:4:65533::0:0:Tty Sandbox:/:/usr/sbin/nologin
kmem:*:5:65533::0:0:KMem Sandbox:/:/usr/sbin/nologin
games:*:7:13::0:0:Games pseudo-user:/usr/games:/usr/sbin/nologin
news:*:8:8::0:0:News Subsystem:/:/usr/sbin/nologin
man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/usr/sbin/nologin
bind:*:53:53::0:0:Bind Sandbox:/:/usr/sbin/nologin
uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico
xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/usr/sbin/nologin
pop:*:68:6::0:0:Post Office Owner:/nonexistent:/usr/sbin/nologin
nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/usr/sbin/nologin
-bill:::::::::
+:::::::::

basie#

29.4.8. Usando Netgroups

A exclusão de usuários especificados do logon em sistemas individuais torna-se imprestável em redes maiores e perde rapidamente o principal benefício do NIS: administração centralizada.

Os netgroups foram desenvolvidos para lidar com redes grandes e complexas com centenas de usuários e máquinas. Seu uso é comparável aos grupos UNIX®, onde a principal diferença é a falta de um ID numérico e a capacidade de definir um netgroup incluindo contas de usuário e outros netgroups.

Para expandir o exemplo usado neste capítulo, o domínio NIS será estendido para adicionar os usuários e sistemas mostrados nas Tabelas 28.2 e 28.3:

Tabela 29.2. Usuários Adicionais
Nome(s) de usuárioDescrição
alpha, betaFuncionários do departamento de TI
charlie, deltaAprendizes do departamento de TI
echo, foxtrott, golf, ...funcionários
able, baker, ...estagiários

Tabela 29.3. Sistemas Adicionais
Nome(s) de máquinaDescrição
war, death, famine, pollutionSomente funcionários de TI podem fazer logon nesses servidores.
pride, greed, envy, wrath, lust, slothTodos os membros do departamento de TI podem fazer login nesses servidores.
one, two, three, four, ...Estações de trabalho comuns usadas pelos funcionários.
trashcanUma máquina muito antiga sem dados críticos. Até os estagiários podem usar este sistema.

Ao usar netgroups para configurar esse cenário, cada usuário é atribuído a um ou mais netgroups e os logins são permitidos ou proibidos para todos os membros do netgroup. Ao adicionar uma nova máquina, as restrições de login devem ser definidas para todos os netgroups. Quando um novo usuário é adicionado, a conta deve ser adicionada a um ou mais netgroups. Se a configuração do NIS for planejada com cuidado, somente um arquivo de configuração central precisará ser modificado para conceder ou negar acesso a máquinas.

O primeiro passo é a inicialização do mapa do NIS netgroup. No FreeBSD, este mapa não é criado por padrão. No servidor NIS master, use um editor para criar um mapa chamado /var/yp/netgroup.

Este exemplo cria quatro grupos de rede para representar funcionários de TI, aprendizes de TI, funcionários e estagiários:

IT_EMP  (,alpha,test-domain)    (,beta,test-domain)
IT_APP  (,charlie,test-domain)  (,delta,test-domain)
USERS   (,echo,test-domain)     (,foxtrott,test-domain) \
        (,golf,test-domain)
INTERNS (,able,test-domain)     (,baker,test-domain)

Cada entrada configura um netgroup. A primeira coluna em uma entrada é o nome do netgroup. Cada conjunto de colchetes representa um grupo de um ou mais usuários ou o nome de outro grupo de rede. Ao especificar um usuário, os três campos delimitados por vírgula dentro de cada grupo representam:

  1. O nome do(s) host(s) onde os outros campos que representam o usuário são válidos. Se um nome de host não for especificado, a entrada será válida em todos os hosts.

  2. O nome da conta que pertence a este netgroup.

  3. O domínio NIS da conta. As contas podem ser importadas de outros domínios do NIS para um netgroup.

Se um grupo contiver vários usuários, separe cada usuário com espaço em branco. Além disso, cada campo pode conter curingas. Veja netgroup(5) para detalhes.

Nomes de grupos maiores que 8 caracteres não devem ser usados. Os nomes diferenciam maiúsculas de minúsculas e usar letras maiúsculas para nomes de grupos de rede é uma maneira fácil de distinguir entre nomes de usuários, máquinas e grupos de rede.

Alguns clientes não-FreeBSD NIS não podem lidar com netgroups contendo mais de 15 entradas. Esse limite pode ser contornado criando vários grupos de sub-redes com 15 usuários ou menos e um grupo de rede real consistindo dos grupos de sub-redes, como visto neste exemplo:

BIGGRP1  (,joe1,domain)  (,joe2,domain)  (,joe3,domain) [...]
BIGGRP2  (,joe16,domain)  (,joe17,domain) [...]
BIGGRP3  (,joe31,domain)  (,joe32,domain)
BIGGROUP  BIGGRP1 BIGGRP2 BIGGRP3

Repita este processo se mais de 225 (15 vezes 15) usuários existirem dentro de um único netgroup.

Para ativar e distribuir o novo mapa do NIS:

ellington# cd /var/yp
ellington# make

Isso gerará os três mapas NIS, netgroup, netgroup.byhost e netgroup.byuser. Use a opção de chave de mapa ypcat(1) para verificar se os novos mapas de NIS estão disponíveis:

ellington% ypcat -k netgroup
ellington% ypcat -k netgroup.byhost
ellington% ypcat -k netgroup.byuser

A saída do primeiro comando deve lembrar o conteúdo de /var/yp/netgroup. O segundo comando só produz saída se os netgroups específicos do host foram criados. O terceiro comando é usado para obter a lista de netgroups de um usuário.

Para configurar um cliente, use vipw(8) para especificar o nome do netgroup. Por exemplo, no servidor chamado war, substitua esta linha:

+:::::::::

com

+@IT_EMP:::::::::

Isso especifica que apenas os usuários definidos no netgroup IT_EMP serão importados para o banco de dados de senhas deste sistema e somente esses usuários terão permissão para efetuar login nesse sistema.

Essa configuração também se aplica à função ~ do shell e a todas as rotinas que convertem entre nomes de usuário e IDs de usuário numérico. Em outras palavras, cd ~user não funcionará, ls -l mostrará o ID numérico em vez do nome de usuário e find . -user joe -print falhará com a mensagem No such user. Para corrigir isso, importe todas as entradas do usuário sem permitir que elas efetuem login nos servidores. Isto pode ser conseguido adicionando uma linha extra:

+:::::::::/usr/sbin/nologin

Esta linha configura o cliente para importar todas as entradas, mas para substituir o shell nessas entradas com /usr/sbin/nologin.

Certifique-se que a linha extra é colocada após +@IT_EMP:::::::::. Caso contrário, todas as contas de usuário importadas do NIS terão /usr/sbin/nologin como seu shell de login e ninguém poderá efetuar o login no sistema.

Para configurar os servidores menos importantes, substitua o antigo +::::::::: nos servidores com estas linhas:

+@IT_EMP:::::::::
+@IT_APP:::::::::
+:::::::::/usr/sbin/nologin

As linhas correspondentes para as estações de trabalho seriam:

+@IT_EMP:::::::::
+@USERS:::::::::
+:::::::::/usr/sbin/nologin

O NIS suporta a criação de grupos de rede de outros grupos de rede, o que pode ser útil se a política relacionada ao acesso do usuário for alterada. Uma possibilidade é a criação de netgroups baseados em funções. Por exemplo, pode-se criar um netgroup chamado BIGSRV para definir as restrições de login para os servidores importantes, outro grupo de rede chamado SMALLSRV para os servidores menos importantes e um terceiro netgroup chamado USERBOX para as estações de trabalho. Cada um desses netgroups contém os netgroups com permissão para efetuar login nessas máquinas. As novas entradas para o mapa do NIS netgroup seriam assim:

BIGSRV    IT_EMP  IT_APP
SMALLSRV  IT_EMP  IT_APP  ITINTERN
USERBOX   IT_EMP  ITINTERN USERS

Esse método de definir restrições de login funciona razoavelmente bem quando é possível definir grupos de máquinas com restrições idênticas. Infelizmente, esta é a exceção e não a regra. Na maioria das vezes, é necessária a capacidade de definir restrições de login por máquina.

As definições de netgroup específicas da máquina são outra possibilidade para lidar com as mudanças na política. Neste cenário, o /etc/master.passwd de cada sistema contém duas linhas que começam com +. A primeira linha adiciona um netgroup com as contas permitidas para entrar nesta máquina e a segunda linha adiciona todas as outras contas com /usr/sbin/nologin como shell. Recomenda-se usar a versão ALL-CAPS do nome do host como o nome do netgroup:

+@BOXNAME:::::::::
+:::::::::/usr/sbin/nologin

Quando esta tarefa estiver completa em todas as máquinas, não haverá mais a necessidade de modificar as versões locais de /etc/master.passwd novamente. Todas as alterações posteriores podem ser manipuladas, modificando o mapa do NIS. Aqui está um exemplo de um possível mapa netgroup para este cenário:

# Define groups of users first
IT_EMP    (,alpha,test-domain)    (,beta,test-domain)
IT_APP    (,charlie,test-domain)  (,delta,test-domain)
DEPT1     (,echo,test-domain)     (,foxtrott,test-domain)
DEPT2     (,golf,test-domain)     (,hotel,test-domain)
DEPT3     (,india,test-domain)    (,juliet,test-domain)
ITINTERN  (,kilo,test-domain)     (,lima,test-domain)
D_INTERNS (,able,test-domain)     (,baker,test-domain)
#
# Now, define some groups based on roles
USERS     DEPT1   DEPT2     DEPT3
BIGSRV    IT_EMP  IT_APP
SMALLSRV  IT_EMP  IT_APP    ITINTERN
USERBOX   IT_EMP  ITINTERN  USERS
#
# And a groups for a special tasks
# Allow echo and golf to access our anti-virus-machine
SECURITY  IT_EMP  (,echo,test-domain)  (,golf,test-domain)
#
# machine-based netgroups
# Our main servers
WAR       BIGSRV
FAMINE    BIGSRV
# User india needs access to this server
POLLUTION  BIGSRV  (,india,test-domain)
#
# This one is really important and needs more access restrictions
DEATH     IT_EMP
#
# The anti-virus-machine mentioned above
ONE       SECURITY
#
# Restrict a machine to a single user
TWO       (,hotel,test-domain)
# [...more groups to follow]

Pode não ser sempre aconselhável usar netgroups baseados em máquina. Ao implantar algumas dúzias ou centenas de sistemas, grupos de rede baseados em funções em vez de grupos de rede baseados em máquina podem ser usados para manter o tamanho do mapa do NIS dentro de limites razoáveis.

29.4.9. Formatos de Senha

O NIS requer que todos os hosts em um domínio NIS usem o mesmo formato para criptografar senhas. Se os usuários tiverem problemas para autenticar em um cliente NIS, pode ser devido a um formato de senha diferente. Em uma rede heterogênea, o formato deve ser suportado por todos os sistemas operacionais, onde DES é o padrão comum mais baixo.

Para verificar qual formato um servidor ou cliente está usando, veja esta seção do /etc/login.conf:

default:\
	:passwd_format=des:\
	:copyright=/etc/COPYRIGHT:\
	[Further entries elided]

Neste exemplo, o sistema está usando o formato DES. Outros valores possíveis são blf para Blowfish e md5 para senhas criptografadas com MD5.

Se o formato em um host precisar ser editado para corresponder ao que está sendo usado no domínio NIS, o banco de dados de recursos de login deve ser reconstruído após salvar a alteração:

# cap_mkdb /etc/login.conf

Nota:

O formato das senhas das contas de usuários existentes não será atualizado até que cada usuário mude sua senha após o banco de dados de recursos de login ser reconstruído.

All FreeBSD documents are available for download at https://download.freebsd.org/ftp/doc/

Questions that are not answered by the documentation may be sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.