O NIS, que quer dizer Serviços de Informações de Rede (Network Information Services), foi desenvolvido pela Sun Microsystems para centralizar a administração de sistemas UNIX® (originalmente SunOS™). Ele tornou-se, essencialmente, um padrão da indústria; todos os maiores sistemas tipo UNIX (Solaris™, HP-UX, AIX®, Linux, NetBSD, OpenBSD, FreeBSD etc) suportam NIS.
O NIS era anteriormente conhecido por Páginas Amarelas (Yellow Pages), mas por causa de questões de marcas registradas, a Sun trocou o nome. O antigo termo (e yp) ainda é muitas vezes visto e usado.
É um sistema cliente/servidor baseado em RPC que permite a um grupo de máquinas dentro de um domínio NIS, compartilhar um conjunto comum de arquivos de configuração. Isto permite que um administrador de sistemas configure sistemas clientes NIS com um mínimo de dados de configurações a partir de um ponto central.
É similar ai sistema de domínio do Windows NT®; apesar da implementação interna de ambos não ser nada parecida, a funcionalidade básica pode ser comparada.
Existem diversos termos e vários processos de usuário importantes que você vai encontrar quando tentar implementar NIS no FreeBSD, esteja você tentando criar um servidor NIS ou atuando como um cliente NIS:
| Termo | Descrição |
|---|---|
| Nome de Domínio NIS | Um servidor mestre NIS e todos os seus clientes (incluindo seus servidores escravos) possuem um nome de domínio NIS. Similar a um nome de domínio Windows NT, o nome de domínio NIS não tem nada a ver com DNS. |
| portmap | Precisa estar rondando para ativar o RPC (Remote Procedure Call, um protocolo de rede usado pelo NIS). Se o portmap não estiver rodando, será impossível rodar um servidor NIS, ou atuar como um cliente NIS. |
| ypbind | ``Associa'' um cliente NIS a seu servidor. Vai receber o nome de domínio NIS do sistema e, usando RPC, conectará ao servidor. O ypbind é o centro da comunicação cliente-servidor em um ambiente NIS; se o ypbind morrer em uma máquina cliente, ela não será capaz de acessar o servidor NIS. |
| ypserv | Deve ser rodado somente em servidores NIS; este é o próprio processo servidor NIS. Se o ypserv(8) morrer, então o servidor não será mais capaz de responder a solicitações NIS (felizmente, existe um servidor escravo que pode assumir em seu lugar). Existem algumas implementações de NIS (mas não a do FreeBSD), que não tentam reconectar a outro servidor se o servidor anteriormente usado morre. Freqüentemente, a única coisa que ajuda neste caso é reiniciar o processo servidor (ou mesmo o servidor inteiro) ou o processo ypbind no cliente. |
| rpc.yppasswdd | Outro processo que deve rodar somente nos servidores mestre NIS; este é um daemon que permitirá aos clientes NIS mudarem suas senhas NIS. Se este daemon não estiver rodando, os usuários terão que acessar (fazer login) no servidor mestre NIS e mudar suas senhas nele. |
Existem três tipos de sistemas em um ambiente NIS: servidores mestre, servidores escravos e clientes. Servidores atuam como repositórios centrais para informações de configurações de sistemas. Servidores mestres guardam a cópia autoritativa desta informação, enquanto servidores escravos espelham estas informações para redundância. Clientes contam com os servidores para lhes fornecerem estas informações.
Informações em muitos arquivos podem ser compartilhados desta forma. Os arquivos master.passwd, group e hosts são normalmente compartilhados via NIS. Quando um processo em um cliente precisa de informação que normalmente seria encontrada nestes arquivos localmente, em vez disso, ele faz uma pergunta ao servidor NIS ao qual está conectado.
Um servidor NIS mestre. Este servidor, de forma análoga a um controlador primário de domínio Windows NT, mantém os arquivos usados por todos os clientes NIS. Os arquivos passwd, group, e diversos outros usados pelos clientes NIS residem no servidor NIS mestre.
Nota: É possível para uma máquina ser um servidor NIS mestre para mais de um domínio NIS. Entretanto, isto não será abordado nesta introdução, que assume um ambiente NIS de escala relativamente pequena.
Servidores NIS escravos. Similar aos controladores de domínio secundários do Windows NT, o servidores NIS escravos mantêm cópias dos arquivos de dados do mestre. Os servidores NIS escravos fornecem redundância, que é necessária em ambientes importantes. Eles também ajudam a balancear a carga no servidor mestre: os clientes NIS sempre se conectam ao servidor NIS do qual primeiro receberem uma resposta, e isto inclui as respostas do servidor escravo.
Clientes NIS. Clientes NIS, como a maioria das estações de trabalho Windows NT se autenticam contra o servidor NIS (ou o controlador de domínio Windows NT no caso de estações de trabalho Windows NT) para obterem acesso (log on).
Esta seção vai tratar de configurar um ambiente NIS de exemplo.
Nota: Esta seção assume que você está rodando o FreeBSD 3.3 ou mais recente. As instruções aqui mostradas provavelmente funcionarão para qualquer versão do FreeBSD maior que 3.0, mas não há garantias de que isto seja verdadeiro.
Vamos assumir que você é o administrador de um pequeno laboratório universitário. Neste laboratório, que consiste de 15 máquinas FreeBSD, atualmente não há ponto centralizado de administração; cada máquina têm seu próprio /etc/passwd e /etc/master.passwd. Estes arquivos são mantidos em sincronia entre si através de intervenções manuais; atualmente, quando você adiciona um usuário no lab, você precisa rodar adduser em todas as 15 máquinas. Claramente, isto precisa mudar, então você decidiu converter o lab para usar NIS, usando duas das máquinas como servidores.
Então, a configuração do lab agora parece com algo como:
| Nome da máquina | Endereço IP | Papel da máquina |
|---|---|---|
| ellington | 10.0.0.2 | mestre NIS |
| coltrane | 10.0.0.3 | escravo NIS |
| basie | 10.0.0.4 | Estação de trabalho da faculdade |
| bird | 10.0.0.5 | Máquina cliente |
| cli[1-11] | 10.0.0.[6-17] | Outras máquinas clientes |
Se você está configurando um esquema NIS pela primeira vez, é uma boa idéia pensar muito bem como você quer fazer. Não importa qual o tamanho da sua rede, existem algumas poucas decisões que precisam ser tomadas.
Isto pode não ser o ``nome de domínio'' com o qual você está acostumado. Ele é mais corretamente chamado de ``nome de domínio NIS''. Quando um cliente anuncia suas solicitações por informações via broadcasts, ele inclui o nome do domínio NIS ao qual pertence. Assim é como múltiplos servidores em uma rede podem saber qual deve responder qual solicitação. Pense no nome de domínio NIS como o nome de um grupo de sistemas relacionados de alguma forma.
Algumas organizações escolhem usar seu nome de domínio Internet para ser seu nome de domínio NIS. Isto não é recomendado porque pode confundir ao se tentar resolver problemas de rede. O nome de domínio NIS deve ser único dentro de sua rede e é útil que descreva o grupo de máquinas que representa. Por exemplo, o departamento de Arte da Acme Ltda. pode estar no domínio NIS ``acme-arte''. Para este exemplo, assuma que você escolheu o nome domínio-teste.
Entretanto, alguns sistemas operacionais (notadamente o SunOS) usam seu nome de domínio NIS como seu nome de domínio Internet. Se uma ou mais máquinas em sua rede possuem esta restrição, você precisa usar o nome de domínio Internet como seu nome de domínio NIS.
Existem diversas coisas a serem mantidas em mente quando se for escolher uma máquina para usar como servidor NIS. Uma das infelicidades do NIS é o nível de dependência que os clientes têm do servidor. Se um cliente não puder fazer contato com o servidor de seu domínio NIS, muito freqüentemente a máquina se torna inutilizada. A falta de informações de usuários e grupos causa congelamento na maioria dos sistemas. Com isto em mente, você deve se certificar de escolher uma máquina que não estará sujeita a ser reinicializada regularmente, ou uma que pode ser usada para desenvolvimento. O servidor NIS idealmente deve ser uma máquina isolada, cujo único propósito na vida é ser um servidor NIS. Se você tem uma rede que não é pesadamente utilizada, é aceitável colocar o servidor NIS em uma máquina rodando outros serviços, apenas tenha em mente que se o servidor NIS se tornar indisponível, afetará adversamente todos os clientes NIS.
As cópias canônicas de todas as informações NIS são armazenadas em uma única máquina chamada servidor NIS mestre. As bases de dados usadas para armazenar as informações são chamadas de mapas NIS. No FreeBSD, estes mapas são armazenados em /var/yp/[domínio] onde [domínio] é o nome de domínio NIS sendo servido. Um único servidor NIS pode suportar diversos domínios de uma vez, então é possível ter diversos domínios destes diretórios, um para cada domínio suportado. Cada domínio terá seu próprio conjunto independente de mapas.
Os servidores mestre e escravo NIS tratam de todas as solicitações NIS com o daemon ypserv. O ypserv é responsável por receber solicitações entrantes dos clientes NIS, traduzindo o domínio solicitado e mapeando o nome a um caminho para o arquivo de banco de dados correspondente e transmitindo dados da base de volta para o cliente.
Configurar um servidor NIS mestre pode ser relativamente simples, dependendo de suas necessidades. O FreeBSD possui suporte nativo para NIS. Tudo que você precisa é adicionar as seguintes linhas ao /etc/rc.conf, e o FreeBSD irá fazer o resto para você.
nisdomainname="dominio-teste"Esta linha vai configurar o nome de domínio NIS para dominio-teste na configuração de rede (p.ex. depois de uma inicialização).
nis_server_enable="YES"Isto dirá ao FreeBSD para iniciar os processos servidores NIS quando a rede for a próxima a ser ativada.
nis_yppasswdd_enable="YES"Isto vai ativar o daemon rpc.yppasswdd que, como mencionado acima, permitirá aos usuários mudarem suas senhas NIS a partir de uma máquina cliente.
Nota: Dependendo de sua configuração NIS, você pode precisar incluir entradas adicionais. Veja a seção sobre servidores NIS que também são clientes NIS, abaixo, para detalhes.
Agora, tudo que você precisa fazer é rodar o comando /etc/netstart como superusuário. Ele irá configurar tudo para você, usando os valores que você definiu no /etc/rc.conf.
Os mapas NIS são arquivos de bancos de dados, mantidos no diretório /var/yp. Eles são gerados de arquivos de configuração no diretório /etc do servidor NIS mestre, com uma exceção: o arquivo /etc/master.passwd. Isto é por uma boa razão; você não quer propagar senhas de sua conta root e de outras contas administrativas para todos os servidores no domínio NIS. Então, antes de inicializar os mapas NIS, você deve:
# cp /etc/master.passwd /var/yp/master.passwd # cd /var/yp # vi master.passwd
Você deve remover todas as entradas referentes a contas de sistema (bin, tty, kmem, games etc), bem como quaisquer contas que você não quer que sejam propagadas aos clientes NIS (por exemplo, root e qualquer outra conta com UID 0 (superusuário).
Nota: Tenha certeza de que o arquivo /var/yp/master.passwd não pode ser acessado por grupo (group) ou pelo mundo (world) (modo 600)! Use o comando chmod, se necessário.
Quando você tiver terminado, é hora de inicializar os mapas NIS! O FreeBSD inclui um script chamado ypinit para fazer isto por você (veja sua página de manual para mais informações). Note que este script está disponível na maioria dos Sistemas Operacionais UNIX, mas não em todos. No UNIX Digital UNIX/Compaq Tru64 é chamado ypsetup. Porque estamos gerando mapas para um mestre NIS, estamos passando a opção -m ao ypinit. Para gerar estes mapas NIS, assumindo que você já executou os passos acima, rode:
ellington# ypinit -m dominio-teste Server Type: MASTER Domain: dominio-teste 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 you don't, 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.
O ypinit deve ter criado /var/yp/Makefile do /var/yp/Makefile.dist. Quando criado, este arquivo assume que você está operando em um ambiente de servidor único, somente com máquinas FreeBSD. Uma vez que o dominioi-testetambém tem um servidor escravo, você precisa editar o /var/yp/Makefile:
ellington# vi /var/yp/Makefile
Você deve comentar a linha que diz
NOPUSH = "True"
(se ainda não estiver comentada).
configurando um servidor NIS escravo é ainda mais simples que configurar o mestre. Acesse o servidor escravo e edite o arquivo /etc/rc.conf como fez anteriormente. A única diferença é que agora precisamos usar a opção -s quando rodarmos o ypinit. A opção -s requer que o nome do mestre NIS também lhe seja passada, de forma que nossa linha de comando fique parecida com esta:
coltrane# ypinit -s ellington dominio-teste Server Type: SLAVE Domain: dominio-teste 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 you don't, 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. Don't forget to update map ypservers on ellington.
Agora você deve ter um diretório chamado /var/yp/dominio-teste. Cópias dos mapas do servidor mestre NIS devem estar neste diretório. Você vai precisar estar certo de que estes sejam mantidos atualizados. As seguintes entradas no /etc/crontab dos servidores escravos devem resolver:
20 * * * * root /usr/libexec/ypxfr passwd.byname 21 * * * * root /usr/libexec/ypxfr passwd.byuid
Estas duas linhas forçam o escravo a sincronizar seus mapas com os mapas do servidor mestre. Apesar destas entradas não serem obrigatórias, uma vez que o servidor mestre tenta garantir que quaisquer mudanças aos seus mapas NIS sejam comunicadas aos seus escravos e porque a informação de senhas é vital para os sistemas dependentes do servidor, é uma boa idéia forçar as atualizações. Isto é mais importantes em redes com alta utilização, onde atualizações de mapas podem nem sempre ser completadas.
Agora, rode o comando /etc/netstart também no servidor escravo, o qual reinicia o servidor NIS.
Um cliente NIS estabelece o que é chamado de uma associação (ou ligação) a um servidor NIS específico, usando o daemon ypbind. O ypbind verifica o domínio padrão do sistema (como configurado pelo comando domainname), e começa a fazer difusão (envio de broadcasts) de solicitações RPC na rede local. Estas solicitações especificam o nome do domínio para o qual o ypbind está tentando estabelecer uma associação. Se um servidor que foi configurado para atender às solicitações receber um dos broadcasts, ele responderá ao ypbind, que vai gravar o endereço do servidor. Se existirem diversos servidores disponíveis (um mestre e diversos escravos, por exemplo), o ypbind vai usar o endereço do primeiro que lhe responder. Deste ponto em diante, o sistema cliente vai direcionar todas as suas solicitações NIS para aquele servidor. O ypbind irá ocasionalmente fazer ``ping'' no servidor para certificar-se de que ele está ativo e operando. Se houver falha na recepção de uma resposta a um dos pings dentro de um período razoável de tempo, o ypbind marcará o domínio como desassociado (unbound) e vai começar novamente a fazer difusão na esperança de localizar outro servidor.
Configurando uma máquina FreeBSD para ser um cliente NIS é bastante simples.
Edite o arquivo /etc/rc.conf e adicione as seguintes linhas para configurar o nome de domínio NIS e inicie o ypbind durante a inicialização da rede:
nisdomainname="dominio-teste" nis_client_enable="YES"
Para importar todas as possíveis entradas de senhas do servidor NIS, remova todas as contas de usuários de seu arquivo /etc/master.passwd e use o vipw para adicionar a seguinte linha ao final do arquivo:
+:::::::::
Nota: Esta linha irá proporcionar uma conta a qualquer um com uma conta válida nos mapas do servidor NIS. Existem muitas formas de configurar seu cliente NIS alterando esta linha. Veja a seção netgroups abaixo para mais informações. Para leitura mais detalhada veja o livro da O'Reilly sobre Gerenciando NFS e NIS (Managing NFS and NIS).
Nota: Você deve manter pelo menos uma conta local (p.ex. não importada via NIS) em seu /etc/master.passwd e esta conta também deve ser membro do grupo wheel. Se acontecer algo errado com o NIS, esta conta pode ser usada para acessar remotamente, tornar-se root, e fazer manutenções.
Para importar todos as possíveis entradas de grupos do servidor NIS, adicione esta linha ao seu arquivo /etc/group:
+:*::
Após completar estes passos, você deve ser capaz de rodar ypcat passwd e ver o mapa de senhas do servidor NIS.
Em geral, qualquer usuário remoto pode emitir uma RPC ao ypserv(8) e recuperar os conteúdos dos mapas NIS, desde que os usuários remotos saibam o nome do domínio. Para evitar tais transações não-autorizadas, o ypserv(8) suporta uma característica chamada securenets que pode ser usada para restringir acesso a um conjunto de sistemas. Na inicialização, o ypserv(8) irá tentar carregar as informações de securenets de um arquivo chamado /var/yp/securenets.
Nota: Este caminho varia dependendo do caminho especificado com a opção -p. Este arquivo contem entradas que consistem na especificação da rede e de uma máscara de rede separadas por um espaço em branco. Linhas iniciando com ``#'' são consideradas comentários. Um arquivo securenets de amostra se parece com este:
# permite conexoes do sistema local -- obrigatorio 127.0.0.1 255.255.255.255 # permite conexões de qualquer sistema # na rede 192.168.128.0 192.168.128.0 255.255.255.0 # permite conexões de qualquer sistema # entre 10.0.0.0 e 10.0.15.255 # isto inclui as máquinas no laboratório de testes 10.0.0.0 255.255.240.0
Se o ypserv(8) receber uma solicitação de um endereço que se enquadra (match) a uma destas regras, ele irá processar a solicitação normalmente. Se o endereço falhar em se enquadrar a uma das regras, a solicitação será ignorada e uma mensagem de alerta será registrada. Se o arquivo /var/yp/securenets não existir, o ypserv permitirá conexões vindas de qualquer sistema.
O programa ypserv também tem suporte ao pacote tcpwrapper de Wietse Venema. Isto permite ao administrador utilizar os arquivos de configuração do tcpwrapper para controle de acesso, ao invés do /var/yp/securenets.
Nota: Enquanto ambos os mecanismos de controle fornecem alguma segurança, eles, como o teste de porta privilegiada, estão vulneráveis a ataques de ``falsificação de IP (IP spoofing)''. Todo o tráfego relativo a NIS deve ser bloqueado em seu firewall.
Servidores usando /var/yp/securenets podem falhar em atender clientes NIS legítimos com implementações arcaicas de TCP/IP. Algumas destas implementações configuram todos os bits de sistemas (hosts) para zero quando fazem difusão (broadcasts) e/ou falham em observar a máscara de subrede quando calculam o endereço de broadcast. Enquanto alguns destes problemas podem ser consertados mudando a configuração do cliente, outros problemas podem forçar a aposentadoria dos sistemas clientes em questão ou o abandono do /var/yp/securenets.
Usando /var/yp/securenets em um servidor com tal implementação arcaica de TCP/IP é realmente uma má idéia e levará à perda de funcionalidade NIS para grandes partes de sua rede.
O uso do pacote tcpwrapper aumenta a latência no seu servidor NIS. O retardo (delay) adicional pode ser longo o suficiente para causar expiração em programas clientes, especialmente em rede congestionadas ou com servidores NIS lentos. Se um ou mais de seus sistemas clientes sofrerem destes sintomas, você deve converter os sistemas em questão em servidores NIS escravos e forçá-los a associarem-se a si próprios.
Em nosso lab, há uma máquina basie que é suposta para ser uma estação de trabalho somente de professores. Não queremos retirar esta máquina do domínio NIS, ainda assim, o arquivo passwd no servidor NIS mestre contem contas para ambos professores e alunos. O que podemos fazer?
Há uma forma de impedir usuários específicos de acessarem uma máquina, mesmo que estejam presentes na base de dados NIS. Para isto, tudo o que você precisa fazer é adicionar -nome_usuario ao final do arquivo /etc/master.passwd na máquina cliente, onde nome_usuario é o nome de usuário do usuário que você deseja impedir de acessar o sistema. Isto deve ser preferivelmente feito usando o vipw, uma vez que o vipw irá verificar suas alterações no /etc/master.passwd, bem como automaticamente reconstruir a base de dados de senhas quando você terminar a edição. Por exemplo, se nós quisermos impedir o usuário bill de acessar basie faremos:
basie# vipw [adcionar -bill ao final, e sair] vipw: rebuilding the database... vipw: done 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:/sbin/nologin operator:*:2:5::0:0:System &:/:/sbin/nologin bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin tty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin kmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin games:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin news:*:8:8::0:0:News Subsystem:/:/sbin/nologin man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/sbin/nologin bind:*:53:53::0:0:Bind Sandbox:/:/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:/sbin/nologin pop:*:68:6::0:0:Post Office Owner:/nonexistent:/sbin/nologin nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin +::::::::: -bill basie#
O método mostrado na seção anterior funciona razoavelmente bem se você precisa de regras especiais para uma pequena quantidade de usuários e/ou máquinas. Em redes maiores, você vai esquecer de bloquear alguns usuários de acessarem máquinas sensíveis, ou pode até ter que modificar cada máquina separadamente, perdendo assim, o maior benefício do NIS, a administração centralizada.
A solução dos desenvolvedores do NIS para este problema é chamada de netgroups. Seu propósito e semântica podem ser comparados aos grupos normais usados pelos sistemas de arquivos UNIX. As principais diferenças são uma falta de id numérico e a capacidade de definir um netgoup incluindo tanto contas de usuários e outros netgroups.
Os netgroups foram desenvolvidos para lidar com redes grandes e complexas, com centenas de usuários e máquinas. Por um lado, isto é uma Coisa Boa, se você é forçado a lidar com tal situação. Por outro lado, esta complexidade torna quase impossível explicar netgroups com exemplos realmente simples. O exemplo usado no restante desta seção demonstra este problema.
Vamos assumir que sua introdução bem sucedida ao NIS em laboratório chamou a atenção de seus superiores. Seu próximo trabalho será estender seu domínio NIS para cobrir algumas outras máquinas no campus. As duas tabelas contêm os nomes dos novos usuários, bem como novas máquinas e breve descrições delas.
| Nome(s) de Usuário(s) | DescriçÃo |
|---|---|
| alpha, beta | Empregados normais do departamento de TI |
| charlie, delta | Os novos aprendizes do departamento de TI |
| echo, foxtrott, golf, ... | Funcionários comuns |
| able, baker, ... | Os atuais estagiários |
| Nomes das Máquina(s) | Descrição |
|---|---|
| war, death, famine, pollution | Seus servidores mais importantes. Somente os funcionários de TI têm permissão para acessar estas máquinas. |
| pride, greed, envy, wrath, lust, sloth | Servidores menos importantes. Todos os membros do departamento de TI têm permissão de acesso nestes servidores. |
| one, two, three, four, ... | Estações de trabalho ordinárias. Somente os funcionários reais têm permissão para usar estas máquinas. |
| trashcan | Uma máquina muito velha, sem qualquer dado crítico. Mesmo o residente pode acessar esta máquina. |
Se você tentasse implementar estas restrições separadamente bloqueando cada usuário, você teria que adicionar uma linha -usuário no passwd de cada sistema, para cada usuário que não está permitido acessar àquele sistema. Se você esquecer apenas uma entrada, você pode estar em apuros. Pode ser viável fazer isto corretamente durante a configuração inicial, entretanto, você eventualmente vai esquecer de adicionar linhas para novos usuários durante as operações diárias. Apesar de tudo, Murphy era um otimista.
Lidar com esta situação com netgroups oferece diversas vantagens. Cada usuário não precisa ser tratado separadamente; você designa um usuário para um ou mais netgroups e permite ou proíbe logins para todos os membros do netgroup. Se você adicionar uma nova máquina, você terá somente que definir as restrições de acesso para os netgroups. Se um novo usuário for adicionado, você terá somente que adicionar o usuário a um ou mais netgroups. Estas mudanças são independentes umas das outras; nada mais de ``para cada combinação de usuário e máquina, faça...'' se a sua configuração de NIS é cuidadosamente planejada, você somente terá que modificar exatamente um arquivo de configuração central para conceder ou negar acesso às máquinas.
O primeiro passo é a inicialização do mapa NIS do netgroup. O ypinit(8) do FreeBSD não cria este mapa por padrão, mas sua implementação de NIS vai suportá-lo quando for criado. Para criar um mapa vazio, digite
ellington# vi /var/yp/netgroup
e comece a adicionar conteúdo. Para nosso exemplo, precisamos de pelo menos quatro netgroups: Funcionários de TI, aprendizes de TI, funcionários normais e estagiários.
IT_EMP (,alpha,dominio-teste) (,beta,dominio)
IT_APP (,charlie,dominio-teste) (,delta,dominio-teste)
USERS (,echo,dominio-teste) (,foxtrott,dominio-teste) \
(,golf,dominio-teste)
INTERNS (,able,dominio-teste) (,baker,dominio-teste)
IT_EMP, IT_APP etc. são nomes de netgroups. Cada grupo entre colchetes adiciona um ou mais contas de usuário a ele. Os três campos dentro de um grupo são:
O nome do(s) sistema(s) onde os seguintes itens são válidos. Se você não especificar um nome de sistema, a entrada é válida em todos os sistemas (hosts). Se você especificar um sistema, você vai entrar em uma mundo de escuridão, horror e total confusão.
O nome da conta que pertence a este netgroup.
O domínio NIS para a conta. Você pode importar contas de outros domínios NIS para seu netgroup se você é um dos camaradas sem sorte, com mais de um domínio NIS.
Cada um destes campos pode conter curingas. Veja netgroup(5) para detalhes.
Nota: Nomes de netgroup mais longos que 8 caracteres não devem ser usados, especialmente se você tem máquinas rodando outros sistemas operacionais em seu domínio NIS. Os nomes são sensíveis à diferenças entre maiúsculas e minúsculas; usar maiúsculas para nomes de netgroups é uma forma fácil de distinguir entre usuário, máquina e nomes de netgroups.
Alguns clientes NIS (diferentes do FreeBSD) não conseguem lidar com netgroups com grande número de entradas. Por exemplo, algumas antigas versões do SunOS começam a causar problemas se um netgoup contém mais de 15 entradas. Você pode contornar este limite criando vários sub-netgroups com 15 ou menos usuários e um netgroup real que consiste dos sub-netgroups:
BIGGRP1 (,joe1,dominio) (,joe2,dominio) (,joe3,dominio) [...] BIGGRP2 (,joe16,dominio) (,joe17,dominio) [...] BIGGRP3 (,joe31,dominio) (,joe32,dominio) BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3Você pode repetir este processo se precisar de mais que 225 usuários dentro de um único netgroup.
Ativar e distribuir seu novo mapa NIS é fácil:
ellington# cd /var/yp ellington# make
Isto vai gerar os três mapas NIS netgroup netgroup.byhost e netgroup.byuser. Use ypcat(1) para verificar se seus novos mapas 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 parecer-se com o conteúdo do /var/yp/netgroup. O segundo comando não produzirá saída, se você não especificou netgroups específicos para sistemas (hosts). O terceiro comando pode ser usado para obter a lista de netgroups para um usuário.
A configuração do cliente é bem simples. Para configurar o servidor war, você somente terá que iniciar o vipw(8) e substituir a linha
+:::::::::
por
+@IT_EMP:::::::::
Agora, somente o dado para usuários definidos no netgroup IT_EMP é importado na base de dados de war e somente a estes usuários é permitido o acesso (login).
Infelizmente, esta limitação também se aplica à função ~ do shell e todas as rotinas convertendo entre nomes de usuários e IDs numéricos de usuários. Em outras palavras, cd ~usuário não vai funcionar, ls -l vai mostrar o id numérico ao invés do nome do usuário, e find . -user joe -print irá falhar com ``No such user''. Para consertar isto, você vai precisar importar todas as entradas de usuários sem permitir que eles acessem seus servidores.
ISto pode ser feito adicionando outra linha ao /etc/master.passwd. Esta linha deve conter:
+:::::::::/sbin/nologin, significando ``Importe todas as entradas mas substitua o shell por /sbin/nologin nas entradas importadas.'' Você pode substituir qualquer campo na entrada passwd colocando um valor padrão em seu arquivo /etc/master.passwd.
Atenção Certifique-se que a linha +:::::::::/sbin/nologin está após +@IT_EMP:::::::::. Caso contrário, todas as contas de usuários importadas do NIS terão /sbin/nologin como seu shell de acesso.
Após esta mudança, você terá somente que modificar um mapa NIS se um novo funcionário juntar-se ao departamento de TI. Você pode usar uma abordagem similar para os servidores menos importantes substituindo a antiga +::::::::: em sua versão local do /etc/master.passwd por algo como isto:
+@IT_EMP::::::::: +@IT_APP::::::::: +:::::::::/sbin/nologin
As linhas correspondentes para operação normal de estações de trabalho podem ser:
+@IT_EMP::::::::: +@USERS::::::::: +:::::::::/sbin/nologin
E tudo estaria bem até que aconteça uma mudança na política algumas mudanças depois: o departamento de TI começa contratando estagiários. Os estagiários em TI são permitidos de acessarem as estações de trabalho normais e os servidores menos importantes; e os aprendizes de TI são permitidos acessar os servidores principais. Você adiciona um novo netgroup, IT_INTERN, adiciona os novos estagiários a este netgroup e começa a mudar a configuração em cada uma e em todas as máquinas... Como diz o velho ditado: ``Erros no planejamento centralizado levam à bagunça geral''.
A capacidade do NIS de criar netgroups de outros netgroups pode ser usada para evitar situações como esta. Uma possibilidade é a criação de netgroups baseados em atividades. Por exemplo, você pode criar um netgroup chamado BIGSRV para definir as restrições de acesso para os servidores importantes, outro netgroup chamado SMALLSRV para os servidores menos importantes e um terceiro netgroup chamado USERBOX para as estações de trabalho normais. Cada um desses netgroups contêm os netgroups que são permitidos acessarem estas máquinas. As novas entradas para seu mapa NIS do netgroup deve ser parecer com este:
BIGSRV IT_EMP IT_APP SMALLSRV IT_EMP IT_APP ITINTERN USERBOX IT_EMP ITINTERN USERS
Este método de definir restrições para acesso funcionam razoavelmente bem se você puder definir grupos de máquinas com restrições idênticas. Infelizmente, esta é a exceção e não a regra. Na maior parte do tempo, você vai precisar da capacidade de definir acesso (login) em cada máquina.
Definições de netgroup específico por máquina, são a outra possibilidade para tratar com a mudança de política delineada acima. Neste cenário, o /etc/master.passwd de cada caixa contêm duas linhas começando por ``+''. A primeira delas adiciona um netgroup com contas com permissão de acesso nesta máquina, a segunda adiciona todas as demais contas com /sbin/nologin como shell. É uma boa idéia usar a versão em maiúsculas do nome da máquina como nome do netgroup. Em outras palavras, as linhas devem ficar parecidas com estas:
+@BOXNAME::::::::: +:::::::::/sbin/nologin
Uma vez que você tenha completado esta tarefa para todas as suas máquinas, você não terá que modificar as versões locais do /etc/master.passwd nunca mais. Todas as alterações subseqüentes podem ser tratadas modificando o mapa NIS. Eis um exemplo de um possível mapa de netgroup para este cenário com alguns brindes adicionais.
# Primeiro, defina grupos de usuários IT_EMP (,alpha,dominio-teste) (,beta,dominio-teste) IT_APP (,charlie,dominio-teste) (,delta,dominio-teste) DEPT1 (,echo,dominio-teste) (,foxtrott,dominio-teste) DEPT2 (,golf,dominio-teste) (,hotel,dominio-teste) DEPT3 (,india,dominio-teste) (,juliet,dominio-teste) ITINTERN (,kilo,dominio-teste) (,lima,dominio-teste) D_INTERNS (,able,dominio-teste) (,baker,dominio-teste) # # Agora, defina alguns grupos baseados em funções USERS DEPT1 DEPT2 DEPT3 BIGSRV IT_EMP IT_APP SMALLSRV IT_EMP IT_APP ITINTERN USERBOX IT_EMP ITINTERN USERS # # Adicione grupos para tarefas especiais # Permite acesso echo e golf acessarem nossa máquina de antivírus SECURITY IT_EMP (,echo,dominio-teste) (,golf,dominio-teste) # # netgroups baseados em máquinas # Nossos principais servidores WAR BIGSRV FAMINE BIGSRV # Usuário india precisa de acesso a este servidor POLLUTION BIGSRV (,india,dominio-teste) # # Este e' realmente importante e precisa de mais restrições de acesso DEATH IT_EMP # # A maquina antivírus mencionada acima ONE SECURITY # # Restrinja a máquina a um único usuário TWO (,hotel,dominio-teste) # [...more groups to follow]
Se você estiver usando algum tipo de banco de dados para gerenciar suas contas de usuário, você deve ser capaz de criar a primeira parte do mapa com as ferramentas de relatórios de seu banco de dados. Desta forma, novos usuários terão, automaticamente, acesso às máquinas.
Uma última palavra de precaução: Pode nem sempre ser recomendável usar netgroups baseados em máquinas. Se você estiver implantando um par, uma dúzia ou mesmo centenas de máquinas idênticas para laboratórios de estudantes, você deve usar netgroups baseados em funções ao invés de netgroups baseados em máquinas para manter o tamanho dos mapas NIS dentro de limites razoáveis.
Existem ainda um par de coisas que você vai precisar fazer de forma diferente, agora que você está em um ambiente NIS.
Cada vez que você desejar adicionar um usuário ao lab, você precisa adicioná-lo somente no servidor NIS mestre, e você precisa lembrar-se de reconstruir os mapas NIS. Se você esquecer de fazer isto, o novo usuário não será capaz de acessar em nenhum lugar, exceto no mestre NIS. Por exemplo, se precisássemos adicionar um novo usuário ``jsmith'' ao lab, poderíamos fazer:
# pw useradd jsmith # cd /var/yp # make test-domain
Você também pode rodar adduser jsmith ao invés do pw useradd jsmith.
Mantenha as contas de administração fora dos mapas NIS. Você não quer propagar contas administrativas e senhas para as máquinas que vão ter usuários que não devem ter acesso a estas contas.
Mantenha o mestre e o escravo NIS seguros, e minimize seus tempos de paradas. Se alguém invadir ou simplesmente desligar estas máquinas, eles terão efetivamente deixaram muitas pessoas sem a capacidade de acessar o lab.
Este é a principal fraqueza de qualquer sistema de administração centralizada. Se você não proteger seus servidores NIS, você terá muitos usuários zangados!
O ypserv do FreeBSD tem algum suporte para atender clientes NIS v1. A implementação NIS do FreeBSD usa somente o protocolo NIS v2, entretanto, outras implementações incluem suporte para a v1 do protocolo, para manter compatibilidade com sistemas antigos. Os daemons ypbind fornecidos com estes sistemas tentarão estabelecer uma associação (ligação) com um servidor NIS v1 mesmo que eles nunca precisem dele (e eles podem insistir em fazer difusão na busca por um, mesmo depois de terem recebido uma resposta de um servidor v2). Note que enquanto o suporte para chamadas normais de clientes é fornecida, esta versão do ypserv não trata requisições de transferência de mapas v1; conseqüentemente, ele não pode ser usado como um mestre ou escravo em conjunto com servidores NIS mais antigos que suportam somente o protocolo v1. Felizmente, não devem mais haver tais servidores em uso nos dias atuais.
Cuidados devem ser tomados quando rodar o ypserv em um domínio multi-servidor onde as máquinas servidoras também são clientes NIS. Geralmente é uma boa idéia forçar os servidores a associarem-se a si próprios ao invés de permitir que façam difusão (broadcast) de solicitações para associações e possivelmente associem-se mutuamente. Estranhos modos de falhas podem resultar se um servidor sair do ar e outros forem dependentes dele. Eventualmente todos os clientes vão ter seu acesso expirado e tentarão se associar a outros servidores, mas o retardo envolvido pode ser considerável e o modo de falha ainda está presente, uma vez que os servidores podem associar-se mutuamente de novo.
Você pode forçar um sistema a associar-se a um servidor em particular rodando o ypbind com o parâmetro -S. Se você não quiser fazer isto manualmente cada vez que inicializar o seu servidor NIS, você pode adicionar as seguintes linhas ao seu /etc/rc.conf:
nis_client_enable="YES" # run client stuff as well nis_client_flags="-S NIS domain,server"
Veja ypbind(8) para maiores informações.
Uma das questões mais comuns que as pessoas enfrentam quando tentam implementar o NIS, é a compatibilidade de formatos de senhas. Se o seu servidor NIS está usando senhas criptografadas com DES, ele somente suportará clientes que também estejam usando DES. Por exemplo, se você tem clientes NIS Solaris em sua rede, então você quase certamente precisa usar senhas criptografadas com DES.
Para verificar qual o formato seus servidores e clientes estão usando, olhe no /etc/login.conf. Se o sistema (host) está configurado para usar senhas criptografadas com DES, então a classe padrão (default) vai conter uma entrada como esta:
default:\
:passwd_format=des:\
:copyright=/etc/COPYRIGHT:\
[Entradas adicionais omitidas]
Outros possíveis valores para a capacidade passwd_format, incluem blf e md5 (para senhas criptografadas com Blowfish e MD5, respectivamente).
Se você fez mudanças no /etc/login.conf, você também vai precisar reconstruir a base dedados de capacidade de login, a qual é feita executando o seguinte comando como root:
# cap_mkdb /etc/login.conf
Nota: O formato de senhas já presentes no /etc/master.passwd não será atualizado até que um usuário modifique sua senha pela primeira vez depois da reconstrução da base de dados de capacidade.
Em seguida, para garantir que senhas estão criptografadas com o formato que você escolheu, você também deve verificar que o crypt_default no /etc/auth.conf dá precedência para o formato de senha da sua escolha. Para fazer isto, coloque o formato que você escolheu em primeiro na lista. Por exemplo, quando usar senhas criptografadas com DES, a entrada deve ser:
crypt_default = des blf md5
Tendo seguido os passos acima em cada um dos servidores e clientes NIS baseados em FreeBSD, você pode estar certo de que todos eles concordam em qual formato de senha é usado na sua rede. Se você tem problemas com autenticação em um cliente NIS, este é um bom lugar para começar a procurar por possíveis problemas. Lembre-se: se você quer implementar um servidor NIS em uma rede heterogênea, você provavelmente terá que usar DES em todos os seus sistemas, porque é o padrão de menor denominador comum.
Este, e outros documentos, podem ser obtidos em ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
Para perguntas sobre FreeBSD, leia a documentação antes de contatar <questions@FreeBSD.org>.
Para perguntas sobre esta documentação, envie e-mail para <doc@FreeBSD.org>.