[LinuxFocus-icon]
Início  |  Mapa  |  Índice  |  Procura

Novidades | Arquivos | Links | Sobre LF
[an error occurred while processing this directive]
convert to palmConvert to GutenPalm
or to PalmDoc


por Frédéric Raynal
<pappy(at)users.sourceforge.net>

Sobre o autor:
Frederic Raynal prepara uma tese em informática no INRIA. Ele gosta também ler (tanto Tolkien como Balzac) e ouvir musica (de Mozart a Philip Glass e de Led Zeppelin a Massive Attack passando por Björk e Boris Vian, mas evitando cautelosamente o rap, a techno e outros ruídos ;-)

Traduzido para Português por:
Patrick Carpalhoso <carpalhoso(at)mail.telepac.pt>

Conteúdo:

 

Yellow Pages 2 : Do lado do cliente

Abstrato:

O artigo anterior era uma introdução aos conceitos girando a volta das yellow pages (YPs). Neste artigos iramos ver como configurar o cliente, um exemplo pratico de funcionamento do cliente e uma apresentação das diferentes ferramentas que vem juntas. Por fim, veremos um pouco o NIS+



Introdução

O lado cliente dos serviços ligados as yellow pages é baseado essencialmente sobre o demónio ypbind : ele emite os pedidos para o servidor das YPs. Em primeiro veremos ao pormenor o seu funcionamento e explicaremos como configura-lo. Depois veremos também como funciona o protocolo NIS. E na ultima parte deste artigo mostrara as diferentes ferramentas presentes no lado do cliente das YPs (as yp-tools).

Configurar o seu cliente NIS

A única coisa a fazer para por a funcionar um cliente NIS numa maquina é de executar o demónio ypbind.  

ypbind

ypbind estabelece uma ligação entre o cliente e o servidor NIS (to bind significa, entre outra coisa, ligar ou atar em inglês). Essa ligação é visível na directoria /var/yp/binding1 pelo o ficheiro convencional chamado domainname.version. A única versão actualmente suportada é a versão 2. Então se o nome do meu domínio NIS é "messie", o ficheiro sera messie.2

O programa ypbind pertence ao super-utilizador (i.e. root), ele deve de estar então no /sbin, ou no /usr/sbin.

Quando é executado, ypbind vai buscar as suas instruções no ficheiro /etc/yp.conf. As entradas nesse ficheiro são :

Se esse ficheiro de configuração esta incorrecto ou não existe, ypbind broadcast2 sobre toda a rede local a pesquisa de um servidor NIS para o domínio local.

Algumas operações básicas permitam de verificar que ypbind esta correctamente configurado.

  1. criar o seu ficheiro /etc/yp.conf ;
  2. verificar que portmap funciona (ps aux | grep portmap). Se não for o caso, executa-lo. Esse programa associa as ports TCP/IP (ou UDP/IP) do computador aos programas. A inicializações de um servidor RPC, este assinala ao portmap as portas que ele escuta e os números dos programas que ele é susceptível de executar. Quando um cliente faz um pedido RPC para um numero de programa, ele contacta em primeiro portmap para saber a porta para a qual os pacotes RPC devem ser enviados. Como o descreve o funcionamento anterior, é então necessário que portmap seja inicializado antes ypbind ;
  3. criar o directório /var/yp ;
  4. executar ypbind ;
  5. utilizar o comando rpcinfo para se assegurar que ypbind funciona correctamente : ou então em função da versão de ypbind. A mensagem importante é aquela sobre a versão 2.
Agora que ypbind funciona correctamente, a vossa maquina passou a cliente NIS. Você já pode utiliza-lo para efectuar pedidos a vosso servidor. Por exemplo, "ypcat passwd.byname" renvio todas as palavras-chave, ordenado por nome de utilizador presente na map correspondente.  

Ultimos detalhes

Alguns ficheiros devem ainda ser ligeiramente alterados para que as YPs funcionam de maneira eficaz : O que diz respeito as shadow passwords via NIS, o seu suporte só é possível com a glibc2.x. É então necessário pensar a especificá-lo no ficheiro nsswitch.conf

O protocolo NIS

Agora que o nosso cliente NIS esta completamente operacional, vamos ver como ele faz para recuperar as informações que ele necessita.

Quando um cliente necessita uma informação numa map das YPs, ele começa por pesquisar no servidor YP. Para o encontrar, ele abre uma conexão TCP para o ypbind local. O cliente informe-o do domínio (falamos aqui do domínio NIS) onde ele pertence ypbind broadcast via a função RPC YPPROC_DOMAIN_NOACK. Os servidores NIS que servem esse domínio respondem com um ACK, os outros fazem de orelhas surdas.

ypbind reenvia ao cliente o resultado da pesquisa (falhanço ou sucesso) e, se ele a tiver, o endereço do primeiro servidor YP que lhe respondeu. O cliente pode agora fazer o pedido a esse servidor, composto do domínio, da map e da chave.

Esse protocolo é relativamente lente porque ele utiliza as conexões RCP. Ainda mais, ele utiliza também muitas sockets. Para evitar essa situação, ypbind não espera que o cliente o contacta para encontrar os servidores. Na realidade ele guarda no ficheiro /var/yp/binding/. uma lista de servidor para cada domínio e verifica regularmente que eles funcionam correctamente.

As yp-tools

Esta secção apresenta muito rapidamente algumas ferramentas do package yp-tools. Para saber mais, cada uma das instruções dispõem de uma página man muita detalhada ;-P

Algumas palavras sobre NIS+

Ao longo deste artigo, em nenhum momento abordamos uma variante de NIS, a saber NIS+. Numa rede, NIS causa enormes problemas em termo de segurança. Por exemplo, se o servidor NIS esta mal protegido e que uma pessoa mal intencionada descobre :

  1. o nome do domínio NIS
  2. o endereço IP de um cliente NIS
só lhe resta então fazer passar-se por a maquina com o IP do cliente e enviar um ypcat passwd para recuperar de uma forma descansada o ficheiro das palavras-chave :-(

NIS+ ofereça uma camada suplementar de segurança integrando um protocolo de autentificação baseado sobre uma troca de chaves e suportando a numeração dos dados.

Os dados são armazenados em tabelas, que são por elas colocadas em directorias diferentes. Cada coluna de uma tabela dispõem de um qualificativo definindo, por exemplo, se os dados são "case sensitive", em formato binário, etc ...

A estrutura descrita permita simplesmente gerir os direitos de acceso sobre as directorias e as tabelas, mas também sobre as colunas das tabelas. Isso implica que podemos proibir o acesso a tabelas das palavras-chaves a todos os utilizadores que não são autenticados no servidor NIS+, mas autorizar a todos os utilizadores certificados a aceder a toda a tabela das palavras-chaves, excepto os campos "passwd". Só o proprietário do campo "passwd" podera vê-lo.

Existem 4 niveis de direitos :

  1. Nobody (ninguém) : o utilizador não é autenticado ;
  2. Owner (proprietário) : o utilizador é autenticado e ele é o proprietario ;
  3. Group (groupe) : o utilizador é autenticado e ele esta no grupo para esse objecto ;
  4. World (mondo) : o utilizador é autenticado mas ele não é nem proprietatio, nem no grupo para esse objecto.

Nessa configuração, root é um utilizador como os outros ... enfim, quase ;-) Se ele não tiver as permissões adequadas, ele não pode mais ver as palavras-chaves dos outros utilizadores. Ele não poderá mais se autentificar como um outro utilizador ... mas, ele poderá sempre fazer descansadamente um su :)

Os dados que transitam pela a rede não serão cryptados, a exepção das palavras-chaves : nenhuma palavra-chave transita em claro sobre a rede.

NIS+ é uma ferramenta potente ... mas complicado a implementar. Como Thorsten Kuduk (ele trabalha sobre NIS, NIS+, NIS-HOWTO ... enfim, uma pessoa que sabe do que se trata ;-) escreve :
"A escolhe emtre NIS e NIS+ é fácil de fazer : utiliza NIS quando não tem necessidade de segurança importante. NIS+ é bem mas problemático a administrar (particularmente do lado do servidor)"

Conclusão

Agora sabemos como inserir uma nova maquina numa rede existente e tendo um servidor NIS. Veremos, no próximo episódio, como configurar o servidor e o seu funcionamento.


Footnotes

... var/yp/binding1
As localizações dos ficheiros são raramente especificadas porque elas varient de uma distribuição a outra. Por exemplo, para ter um demónio ypbind inicializado ao arranque : /etc/init.d/nis, /sbin/init.d/ypclient, /etc/rc.d/init.d/ypbind, /etc/rc.local
... broadcast2
isso significa que a mensagem é emitida sobre todo a sub-rede sem destinatário especifico com um endereço do tipo X.Y.0.0
... netgroup3
O ficheiro /etc/netgroup define os grupos compostos dos triplets (host, user, domain) servem para verificar as permissões quando se utiliza os comandos "a distancia" (remote logins, shells ou mount por exemplo). Ver a página man para mais pormenor.

 

Forma de respostas para este artigo

Todo artigo tem sua própria página de respostas. Nesta página você pode enviar um comentário ou ver os comentários de outros leitores:
 página de respostas 

Páginas Web mantidas pelo time de Editores LinuxFocus
© Frédéric Raynal, FDL
LinuxFocus.org

Clique aqui para reportar uma falha ou para enviar um comentário para LinuxFocus
Informação sobre tradução:
fr --> -- : Frédéric Raynal <pappy(at)users.sourceforge.net>
fr --> pt: Patrick Carpalhoso <carpalhoso(at)mail.telepac.pt>

2001-10-20, generated by lfparser version 2.18