CURSO LINUX Módulo Configuração de Redes TCP/IP por Celso Kopp Webber Curso Linux Básico SUMÁRIO 1 INTRODUÇÃO 1 2 INTERFACE DE COMUNICAÇÃO 3 3 2.1 Reconhecimento das Interfaces de Rede 3 2.2 Configuração as Interfaces 4 2.3 Tabela ARP 6 ROTEAMENTO DE DATAGRAMAS IP 3.1 Tabela de Roteamento Mínimo 3.2 Verificação de Conectividade 10 3.3 Roteamento Dinâmico 11 3.3.1 4 5 6 7 8 8 RIP - Routing Information Protocol 12 DOMAIN NAME SERVICE (DNS) 15 4.1 Configuração do Resolver 16 4.2 Configuração do BIND 17 NETWORK FILE SYSTEM (NFS) 25 5.1 Exportando Arquivos 25 5.2 Montando Diretórios Remotos 27 SESSION MESSAGE BLOCK (SMB) – SAMBA 28 6.1 Resolução de Nomes NetBIOS 28 6.2 Samba – Servidor e Cliente SMB 29 6.2.1 Iniciando o Samba 30 6.2.2 Configuração do arquivo smb.conf 30 NETWORK INFORMATION SERVICE (NIS) Módulo Configuração de Redes TCP/IP 35 i Curso Linux Básico ii Módulo Configuração de Redes TCP/IP Curso Linux Básico 1 INTRODUÇÃO Configurar uma rede TCP/IP envolve conhecer os sistemas operacionais dos computadores envolvidos, bem como dominar os aspectos teóricos da arquitetura de redes TCP/IP. Dessa forma, este texto assume que o leitor possui prévio conhecimento de redes TCP/IP, incluindo: Conceitos básicos de redes de computadores, incluindo a arquitetura IEEE 802 para LANs e MANs; camadas, protocolos, e funcionamento da arquitetura TCP/IP; endereçamento IP; roteamento IP, sendo obrigatórios os conceitos de roteamento mínimo e roteamento estático; noções sobre os serviços mais comuns sobre TCP/IP, como e-mail, WWW, FTP, e DNS; conhecimentos sólidos do sistema operacional UNIX, a nível de usuário. O material descrito a seguir está voltado para o sistema operacional UNIX, tanto a nível de comandos de configuração, como arquivos de configuração. Assim, o objetivo final do texto é apresentar ao leitor um resumo dos pontos chave da configuração de redes TCP/IP utilizando o sistema operacional UNIX, tanto como cliente, como servidor. Já que qualquer teoria sem prática tem seu utilidade reduzida, as explicações a seguir tentam, sempre que possível, apresentar os comandos de forma geral. Quando necessário, diferenças entre sistemas operacionais UNIX diferentes são mostradas. Porém, o sistema operacional Linux é tomado como base durante o texto. A razão do Linux ter sido adotado como exemplo principal é a sua crescente popularidade, o fato de ser gratuito, a grande gama de hardware suportado (desde PCs até processadors RISC de alto desempenho), e sua fácil instalação em relação a alguns UNIX comerciais. Pode-se dizer hoje que é possível que qualquer pessoa com conhecimentos razoáveis de informática consiga instalar o Linux em sua máquina. No decorrer do texto, as seguintes notações são utilizadas: negrito: as palavras em negrito constituem o próprio comando e devem ser digitadas exatamente como estão escritas; normal: o texto normal é usado para opções dos comandos, e também deve ser digitado tal qual está escrito; sublinhado: o texto em sublinhado representa os parâmetros que o usuário especifica, como por exemplo uma opção de um comando; [colchetes]: todo o texto entre colchetes é opcional, e pode ser omitido. Os colchetes não devem ser digitados; ...: as reticências indicam que o item apresentado pode ser repetido uma ou mais vezes. opção1 | opção2: quando opções separadas por uma barra vertical são apresentadas, uma delas deve ser escolhida somente. A figura 1.1 ilustra as notações acima, descrevendo o formato geral de um comando UNIX: Módulo Configuração de Redes TCP/IP 1 Curso Linux Básico $ comando [ -opções ... ] [ argumentos ... ] mais argumentos podem vir em seguida. geralmente são nomes de arquivos ou caminhos. outras opções de uma ou mais letras precedidas de hífen. opções de uma ou mais letras são precedidas de hífen. nome do comando. Para comandos também há distinção entre letras minúsculas e maiúsculas. prompt do shell ($ para Bourne Shell, % para C-Shell e # para usuário root) Figura 1.1 - Formato de comandos UNIX 2 Módulo Configuração de Redes TCP/IP Curso Linux Básico 2 INTERFACE DE COMUNICAÇÃO Configurar máquinas UNIX para operar em uma rede TCP/IP é uma tarefa relativamente fácil. Entretanto, diferentemente de outros sistemas operacionais voltados para uso individual, o UNIX precisa ser configurado por um administrador de sistemas para que seus usuários possam utilizá-los adequadamente. O primeiro passo que um administrador de sistemas deve realizar ao conectar uma máquina UNIX a uma rede TCP/IP é configurar suas interfaces de rede. Para isso é necessário primeiro informar ao sistema operacional as interfaces de rede existentes. 2.1 Reconhecimento das Interfaces de Rede Este tópico é bastante disperso. Um problema grave com o UNIX atualmente é que existem diversos fornecedores. Cada um dá seus próprios nomes para placas de rede, terminais, impressoras, etc. Da mesma forma, cada um implementa um método próprio para operar com o hardware existente, isto é, a implementação dos drivers para dispositivos, incluindo as placas de rede, não é padronizada. Por isso, fazer o sistema operacional (SO) reconhecer todos os dispositivos em uma máquina muitas vezes não é tarefa simples. No caso de interfaces de rede, muitas vezes o fabricante da placa fornece o próprio driver em um disquete que acompanha a placa. Em outros casos, o SO possui suporte nativo para determinadas marcas e modelos de interfaces de rede. A recomendação mais sensata é que antes de decidir por qual computador adquirir para determinada tarefa, conferir qual é o hardware suportado pelo SO. O Linux, apesar de ser de domínio público, possui grande suporte a hardware de diversos fabricantes. Raramente um fabricante de hardware fornece drivers para Linux (apesar que isto está começando a mudar), mas em geral, o sistema suporta as marcas mais comuns de placas diversas. Fazer o SO reconhecer uma placa de rede envolve basicamente três etapas: Configurar a placa através de jumpers, dip switches, etc; instalar fisicamente a placa no computador (e configurá-la via software quando for o caso); instalar o driver correspondente no sistema operacional, informando os parâmetros configurados nos passos anteriores. Em alguns casos, o sistema operacional será capaz de reconhercer automaticamente o hardware do computador. Infelizmente, tecnologias mais antigas como o barramento ISA em PCs não ajuda muito nesta tarefa. Placas que utilizam o barramento PCI resolvem este problema fazendo com que o sistema operacional consiga obter a configuração necessária de todos os dispositivos instalados no barramento. Genericamente, o sistema operacional reconhece as placas de rede de duas maneiras: 1. O driver faz parte do kernel do sistema operacional. Esta abordagem é antiga, estando em desuso pela maioria dos UNIX modernos. Entretanto, pode ser necessário recompilar o kernel de algum sistema mais antigo para incluir o driver do dispositivo que se deseja reconhecer; O driver pode ser carregado separadamente pelo kernel do SO. Assim, o kernel é Módulo Configuração de Redes TCP/IP 3 Curso Linux Básico especializado nas suas funções, e somente os drivers necessários são carregados em memória. Isto reduz seu tamanho e aumenta sua eficiência. A maioria dos UNIX atuais utiliza esta abordagem. Como exemplos, no Linux os comandos: insmod nome-do-driver [ parâmetros ] e modprobe nome-do-driver são usados para inserir um driver (chamado de módulo no Linux) em memória. Os parâmetros podem ser especificados com o comando insmod, ou podem ser “adivinhados” com o comando modprobe. No Solaris da Sun, o comando equivalente é o modload. As páginas de manual on-line (comando man) devem ser consultadas para maiores detalhes. Uma vez que o SO tenha reconhecido as interfaces de rede, sejam elas Ethernet, Token Ring, FDDI, etc., resta-nos saber que nome o SO utiliza para fazer referência a elas sob o diretório /dev. A tabela a seguir mostra como algumas versões de UNIX chamam as interfaces Ethernet (as mais usadas): Sistema Operacional SCO UNIX Linux Digital UNIX Solaris SunOS AIX HP-UX Nome adotado para a primeira interface Ethernet depende do fabricante (ex: e3B0) eth0 ln0, tu0 le0 le0, ie0, ec0 en0 (Ethernet), et0 (802.3) lan0 Outros tipos de interfaces possuem outros nomes sob o diretório /dev, como por exemplo fi0 para interfaces FDDI. A interface loopback, implementada em software, é chamada de lo0 em todos os UNIX, exceto no Linux, que simplesmente a denomina lo. 2.2 Configuração as Interfaces O comando ifconfig é usado para informar ao sistema operacional o endereço IP, a máscara de subrede (netmask), e o endereço de broadcast para cada interface de comunicação. SINOPSE: ifconfig [ interface ] ifconfig interface [ addr_family ] [ address ] [ netmask mask ] [ broadcast address ] [ up | down ] [ [-]arp ] [ metric n ] [ mtu n ] ARGUMENTOS: interface: addr_family: address: netmask mask: 4 nome da interface de rede a ser configurada (eth0, lo, etc); parâmetro opcional que informa o tipo de endereço sendo configurado. Para endereços IP, este parâmetro deve ser inet; especifica address como o endereço IP associado à interface; associa a máscara de rede mask à interface; Módulo Configuração de Redes TCP/IP Curso Linux Básico broadcast address: informa o endereço de broadcast da interface para address. EXPLICAÇÃO: Na primeira forma, o comando apenas mostra a situação da interface especificada, ou de todas as interfaces, caso este parâmetro seja omitido. Na segunda forma, especifica uma interface e seus parâmetros a serem configurados. root@frajola# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:60:52:00:EF:F5 inet addr:10.0.0.254 Bcast:10.0.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:307 errors:0 dropped:0 overruns:0 TX packets:260 errors:0 dropped:0 overruns:0 Interrupt:10 Base address:0x320 EXEMPLO: Na terceira linha aparece uma lista de opções: up: a interface está habilitada para o uso; down: a interface está desabilitada para o uso; broadcast: a interface suporta broadcast; notrailers: a interface não suporta trailers; running: a interface está operacional. Pode-se usar um hostname em vez do endereço IP. Neste caso, o arquivo /etc/hosts deve conter a entrada correspondente ao nome utilizado. venus# cat /etc/hosts 127.0.0.1 localhost loghost # # inf.ufsc.br Subnet # 150.162.60.1 venus loghost 150.162.60.2 apolo 150.162.60.3 vesta 150.162.60.4 atlas 150.162.60.5 ceres 150.162.60.6 baco Usando um hostname, então, o comando poderia ser: venus# ifconfig le0 venus O ifconfig é normalmente executado na hora de inicialização da máquina por um arquivo de boot. Nos sistemas BSD, os comandos do ifconfig geralmente estão localizados nos arquivos /etc/rc.boot e /etc/rc.local. Nos sistemas System V, os comandos do ifconfig geralmente estão localizados em arquivos como /etc/tcp e /etc/init.d/tcp. Módulo Configuração de Redes TCP/IP 5 Curso Linux Básico Os parâmetros adicionais do ifconfig mais utilizados são descritos abaixo: down: desabilita a interface; up: habilita a interface; metric n: define a métrica como sendo n; arp: habilita o uso do protocolo ARP no mapeamento entre os endereços do nível de rede e os endereços do nível de interface de rede; -arp: desabilita o uso do protocolo ARP; mtu n: define o MTU como sendo n. root@frajola# ifconfig eth0 10.3.2.1 netmask 255.255.0.0 broadcast 10.3.255.255 up root@frajola# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:60:52:00:EF:F5 inet addr:10.3.2.1 Bcast:10.3.255.255 Mask:255.255.0.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:307 errors:0 dropped:0 overruns:0 TX packets:260 errors:0 dropped:0 overruns:0 Interrupt:10 Base address:0x320 As páginas de manual sobre o comando ifconfig dão maiores detalhes das opções de configuração. 2.3 Tabela ARP A tabela ARP (Address Resolution Protocol) descreve, para cada interface de uma máquina que roda a protocolo IP, a relação entre endereços lógicos (endereços IP) e endereços físicos (endereços da placa de rede, por exemplo, um endereço MAC Ethernet). Toda vez que uma máquina precisa comunicar-se via protocolo IP com outra, ela precisa descobrir o endereço físico da placa de rede da máquina destino. O protocolo ARP cuida desta função. Como cada tecnologia de rede (Ethernet, FDDI, Token Ring, ATM) possui seu próprio formato de endereço, bem como diferentes métodos de acesso ao meio, o ARP é diferente para cada tipo de placa de rede. No ambiente UNIX, é possível manipular diretamente a tabela ARP, através do comando arp. Em apenas casos muito específicos é necessário adicionar manualmente entradas na tabela ARP, pois durante o funcionamento normal da rede, o próprio protocolo se encarrega da descoberta dinâmica dos endereços físicos associados com os endereços lógicos que a máquina está tentando acessar. arp [ -v ] [ -n ] [ -i interface ] -a [ máquina ] arp [ -v ] [ -i interface ] -s máquina endereço físico [ temp ] arp [ -v ] [ -i interface ] -d máquina ARGUMENTOS: 6 Módulo Configuração de Redes TCP/IP Curso Linux Básico -v -n fornece mensagens detalhadas (verbose) modo numérico, mostra apenas endereços, isto é, não tenta converter um endereço para o nome de uma máquina -i interface especifica o nome da interface de rede cuja table ARP será manipulada; -a máquina a opção “-a” mostra a tabela ARP. Se um nome ou endereço de máquina é especificado, mostra somente as entradas daquela máquina -s máquina end.fís. adiciona uma entrada manualmente à tabela, associando o endereço lógico de uma máquina ao seu endereço físico. Se a opção “temp” é especificada, a entrada é temporária, sendo eliminada após um tempo padrão, caso contrário a entrada é estática (permanente) -d máquina remove a entrada correspondente ao nome ou endereço de uma máquina Módulo Configuração de Redes TCP/IP 7 Curso Linux Básico 3 ROTEAMENTO DE DATAGRAMAS IP Existem 3 tipos básicos de configurações de roteamento: Roteamento mínimo: uma rede completamente isolada de todas as demais redes TCP/IP necessita somente de um roteamento mínimo; Roteamento estático: uma rede com um número limitado de gateways para outras redes TCP/IP pode ser configurada com roteamento estático; Roteamento dinâmico: uma rede com mais de uma possível rota para o mesmo destino deve usar o roteamento dinâmico. Rotas são construídas pelo próprio processo de boot do sistema, baseando-se nas informações usadas para o comando ifconfig, manualmente pelo administrador (através do comando route) ou dinamicamente pelos protocolos de roteamento. As rotas estão sempre organizadas numa tabela própria. 3.1 Tabela de Roteamento Mínimo Uma tabela de roteamento mínimo é construída pelos scripts de boot do sistema operacional após a configuração da interface com o comando ifconfig. O roteamento mínimo é composto de uma rota para cada rede a que pertence cada interface (incluindo a interface loopback), e uma rota default. Com exceção do Linux, todos os UNIX constroem a tabela de roteamento mínimo automaticamente a partir do comando ifconfig. Entretanto, é ainda necessário estabelecer uma rota default. Cada versão de UNIX obtém o roteador default a partir de localizações diferentes. Por exemplo, o Solaris da Sun obtém esta informação do arquivo /etc/defaulroute, enquanto o RedHat Linux obtém do arquivo /etc/sysconfig/network. O comando netstat pode ser usado para mostrar informações sobre conexões da máquina, e também para mostrar a tabela de rotas. SINOPSE: netstat [ -n ] [ -r ] [ -i interface ] ARGUMENTOS: interface: -n: -r: -i interface: nome da interface de rede da qual se deseja obter informações sobre conexões; mostra endereços e portas em modo numérico, isto é, não faz tradução para nomes; mostra a tabela de rotas corrente; mostra somente informações relacionadas à interface especificada; EXPLICAÇÃO: 8 Módulo Configuração de Redes TCP/IP Curso Linux Básico Em geral, o comando netstat é utilizado com as opções –rn para mostrar a tabela de rotas. Adicionalmente, pode ser usado para verificar quais conexões estão atualmente abertas com a máquina. EXEMPLO: apolo# netstat -rn Kernel IP routing table Destination Gateway 255.255.255.255 0.0.0.0 10.0.0.0 0.0.0.0 127.0.0.0 0.0.0.0 0.0.0.0 192.1.2.3 Genmask 255.255.255.255 255.255.255.0 255.0.0.0 0.0.0.0 Flags UH U U UG MSS 1500 1500 3584 1500 Window 0 0 0 0 irtt 0 0 0 0 Iface eth0 eth0 lo ppp0 No campo Flags da saída do comando netstat, temos os significados: U: A rota está no ar (Up); H: A rota é para um host (máquina); G: A rota é estabelecida passando por um gateway; D: Rota aprendida dinamicamente, ou por um daemon de roteamento dinâmico, ou pelo recebimento de um ICMP Redirect. O comando route é usado para a criação de uma tabela estática, adicionando ou removendo rotas manualmente. Rotas adicionadas com o comando route só podem ser removidas com outro comando route. Quando uma máquina não está atuando como um gateway, o roteamento mínimo provido com o comando route é suficiente. Quando um determinado gateway está configurado para um esquema de roteamento simples, também é suficiente estabelecer algumas rotas estáticas com o comando route. Os rotadores principais de uma rede maior são em geral candidatos a utilizar roteamento dinâmico. SINOPSE: route add [ -host | -net ] destination [ netmask mask ] [ gateway router ] [ metric M ] [ mss M ] [ window W ] [ device ] route del [ -host | -net ] destination [ netmask mask ] [ gateway router ] [ device ] ARGUMENTOS: -host ou –net: destination: netmask mask: gateway router: device: metric M: mss M: window W: determina se a rota é para um máquina ou para uma rede. Se este parâmetro for omitido, é assumido o valor “-host”; informa destino da rota; utiliza mask como máscara de subrede para esta rota; utiliza router como o gateway para esta rota. Se for utilizado como gateway um endereço de uma das interfaces da máquina, a rota será estabelecida enviando diretamente por aquela interface; nome da interface de rede que esta rota utilizará como saída; estabelece a métrica para a rota sendo estabelecida; estabelece o MSS – Maximum Segment Size (tamanho máximo do segmento) TCP a usar com esta rota; informa o tamanho da janela TCP a ser usada nessa rota. Módulo Configuração de Redes TCP/IP 9 Curso Linux Básico EXPLICAÇÃO: Algumas versões do comando route entendem que se destination for uma rede à qual uma das interfaces da máquina pertence, uma rota do roteamento mínimo está sendo feita, e por isso os outros parâmetros não precisam ser especificados. É recomendável sempre o uso do parâmetro netmask, caso contrário geralmente o comando assume a máscara padrão (conforme a classe) do endereço destino especificado. EXEMPLO: root@frajola# route add -net 10.3.0.0 netmask 255.255.0.0 root@frajola# route add –net 10.2.1.0 netmask 255.255.255.0 gateway 10.3.0.254 eth0 root@frajola# netstat –rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt 10.3.0.0 0.0.0.0 255.255.0.0 U 1500 0 0 10.2.1.0 10.3.0.254 255.255.255.0 UG 1500 0 0 127.0.0.0 0.0.0.0 255.0.0.0 U 3584 0 0 Iface eth0 eth0 lo Se a palavra chave default for utilizada como destination, route cria uma rota default. Esta rota default é utilizada quando não há uma rota específica para o destino desejado. É possível especificar a rota default estabelecendo uma rota para a rede 0.0.0.0. root@frajola# route add default gateway 10.3.0.252 root@frajola# route add –net 0.0.0.0 gateway 10.3.0.252 root@frajola# netstat -rn Kernel IP routing table Destination Gateway 10.3.0.0 0.0.0.0 10.2.1.0 10.3.0.254 127.0.0.0 0.0.0.0 0.0.0.0 10.3.0.252 Genmask 255.255.0.0 255.255.255.0 255.0.0.0 0.0.0.0 Flags U UG U UG MSS 1500 1500 3584 1500 Window 0 0 0 0 irtt 0 0 0 0 Iface eth0 eth0 lo eth0 Para se colocar as informações de roteamento estático nos arquivos de boot duas modificações são necessárias: Adicionar a rota desejada ao arquivo de boot; Remover (ou comentar) do arquivo de boot comandos que chamem algum protocolo de roteamento. Os arquivos a serem modificados variam conforme a plataforma. Nos UNIX baseados em BSD, geralmente os comandos de adição de rotas estáticas e/ou de execução de protocolo de roteamento estão nos arquivos /etc/rc.*. No System V, geralmente estão sob o diretório /etc/init.d, no arquivo boot, tcp ou inet. 3.2 Verificação de Conectividade Freqüentemente em uma rede é necessário saber se uma máquina “enxerga” outra. A 10 Módulo Configuração de Redes TCP/IP Curso Linux Básico ferramenta de diagnóstico mais popular entre os usuários e administradores de rede é o “ping”. ping é um utilitário onde a máquina origem envia uma mensagem ICMP “echo request” (solicitação de eco) para a máquina destino. Se esta estiver no ar, ao receber o “echo request” ela responde com outra mensagem ICMP “echo reply” (resposta de eco). SINOPSE: ping [ -f ] [ -i tempo espera ] [ -count quantidade ] destino ARGUMENTOS: -f -i tempo espera -count quantidade destino: ` envia um novo “ping” assim que receber a resposta do anteriormente enviado. A comportamento default é enviar uma requisição a cada segundo; informa o tempo entre cada envio de um novo “ping”; informa quantos “pings” devem ser enviados. O comportamento default é enviar “pings” eternamente, até o comando ser cancelado; informa o endereço ou nome da máquina destino. 3.3 Roteamento Dinâmico Todos os protocolos de roteamento possuem a mesma função básica: determinar a melhor rota para cada destino e distribuir informações de roteamento entre os sistemas em uma rede. Protocolos de roteamento são divididos em dois grupos principais: Internos: São protocolos utilizados internamente em uma rede independente. Na terminologia TCP/IP, estes sistemas de redes são chamados de “sistemas autônomos” (AS). Dentro de um AS, as informações de roteamento são trocadas utilizando um protocolo interno escolhido pelo administrador local. Exemplos de protocolos de roteamento internos incluem o RIP (Routing Information Protocol), o IGRP (Internet Gateway Routing Protocol) e o EIGRP (Enhanced IGRP), e o OSPF (Open Shortest Path First); Externos: São protocolos utilizados para trocar informações de roteamento entre sistemas autônomos. As informações de roteamento trocadas entre os AS são chamadas de informações de alcançabilidade. Informação de alcançabilidade é simplesmente a informação sobre quais redes podem ser alcançadas através de um AS. Exemplos destes protocolos são o antigo EGP (Exterior Gateway Protocol), que está em desuso, e o mais recente BGP (Border Gateway Protocol). Módulo Configuração de Redes TCP/IP 11 Curso Linux Básico O figura a seguir mostra um exemplo de vários AS interconectados pelo protocolo BGP. Note que as empresas conectadas aos provedores não utilizam nenhum protocolo de roteamento dinâmico entre elas e os provedores. Isto é bastante fácil de compreender, afinal a empresa possui apenas um canal de saída, que é o provedor, bastando portanto configurar seu roteador para apontar a rota default para o roteador do provedor. Internamente, as empresas utilizam seus próprios protocolos de roteamento. ABC Ltda Cia. das Índias IGRP RIP Provedor Baía Norte BGP EIGRP Provedor Bananal Sul EIGRP BGP Serralheria Metal Sul EIGRP BGP Provedor Manezinho OnLine OSPF BGP Provedor Bananal Sul EIGRP A definição de um AS, de acordo com a RFC 1930, é a seguinte: “Um AS é um grupo conectado de um ou mais prefixos de endereços IP, administrados por um ou mais operadores de rede que possuem uma ÚNICA e CLARAMENTE DEFINIDA política de roteamento.” Assim, um AS é visto como um conjunto de redes cujos endereços IP “começam” com o mesmo prefixo, por exemplo, todas as redes classe C que começam com “200.135”. O protocolo IP, ao decidir por onde enviar um datagrama, consulta uma tabela de roteamento. Com os protocolos de roteamento dinâmicos, esta tabela é constantemente atualizada, de forma automática. Caso mais de uma rota exista para um determinado destino, o campo métrica das rotas é comparado. A rota com a menor métrica é então escolhida. O significado da métrica depende de cada protocolo de roteamento em uso. O protocolo IP simplesmente escolhe a rota com menor métrica. Vejamos a seguir um exemplo de protocolo de roteamento dinâmico, incluindo seu funcionamento básico e suas considerações sobre métricas. 3.3.1 RIP - Routing Information Protocol É o protocolo interno mais utilizado, pois é disponibilizado como parte da maioria dos 12 Módulo Configuração de Redes TCP/IP Curso Linux Básico sistemas UNIX. RIP seleciona a rota com o menor hop count como sendo a melhor. O hop count representa o número de gateways que o pacote passa até chegar ao seu destino final. A melhor rota é aquela que usa o menor número de gateways. Assim, a métrica utilizada pelo RIP é “o número de roteadores” até o destino final. No UNIX, o protocolo RIP é executado através do servidor de roteamento routed. Quando um sistema configurado para prover informação RIP escuta uma requisição, ele responde com um pacote de atualização baseado na sua tabela de roteamento. Este pacote de atualização contém o endereço destino retirado da tabela de roteamento e a métrica associada a cada destino. Pacotes de atualização não são apenas enviados em resposta a solicitações, mas são também enviados periodicamente para manter as informações de roteamento atualizadas. O routed envia periodicamente, a cada 30 segundos, todas as rotas que possui para todas as interfaces configuradas. Quando um pacote de atualização é recebido pelo routed, ele obtém estas informações e atualiza suas tabelas de roteamento. Se a rota recebida não consta da tabela ela é adicionada. Se a rota recebida descreve uma rota para um endereço que já existe, ela somente é usada se possuir um custo (métrica) menor. O protocolo RIP também remove rotas da tabela de roteamento. Existem duas razões para isto acontecer: 1. O gateway para o destino diz que o custo da rota é maior que 15 hops; 2. gateways por onde passam certas rotas não enviaram pacotes de atualização por um dado período, portanto foram considerados fora de serviço. As rotas que passam por eles são consideradas inválidas. O routed vem geralmente incluído nos arquivos de boot. A maioria dos sistemas usa /etc/routed para rodar o servidor, mas os sistemas SunOS usam /usr/etc/in.routed. No Linux, normalmente é encontrado em /usr/sbin/in.routed. Nos UNIX que seguem a linha BSD, o routed é geralmente executado a partir do script de inicialização /etc/rc.local. No System V, normalmente existe um script próprio chamado /etc/init.d/routed para executar este daemon. O routed pode construir uma tabela de roteamento só com as informações recebidas dos pacotes de atualização, mas algumas vezes é necessário alguma forma de complemento, como uma rota default inicial. O arquivo /etc/gateways contém estas informações adicionais de roteamento. routed lê o arquivo /etc/gateways quando é inicializado. O uso mais comum do arquivo /etc/gateways é definir uma rota default ativa, como no exemplo a seguir: # net 0.0.0.0 gateway 150.162.1.1 metric 1 active Todas as entradas do arquivo /etc/gateways começam com a palavra net ou host para indicar quando o endereço que segue é de uma rede ou de um host. No comando route o parâmetro default é utilizado para indicar a rota default, mas no arquivo /etc/gateways a rota default é indicada pelo endereço 0.0.0.0. O parâmetro gateway vem seguido do seu endereço IP e a métrica pelo seu valor. Todas as entradas do arquivo /etc/gateways terminam com o parâmetro passive ou active. SINOPSE: routed [ -q ] [ -g ] [ -s ] ARGUMENTOS: Módulo Configuração de Redes TCP/IP 13 Curso Linux Básico Instrui o routed a apenas “escutar” rotas, sem anunciar as suas próprias rotas (quiet); Anuncia aos demais roteadores uma rota default apontando para si. Geralmente isto é usado em um gateway padrão de uma rede, para que os outros roteadores apontem suas rotas default para ele; Força o routed a anunciar suas rotas. Normalmente, routed apenas anuncia suas rotas a cada 30 segundos se a máquina possuir mais de uma interface de rede configurada (excetuando-se a interface loopback). -q: -g: -s: EXPLICAÇÃO: Normalmente, o backbone de uma rede conterá vários roteadores para redes menores. Um dos roteadores no backbone será o roteador padrão, que fará o roteamento para o mundo externo. Assim, o roteador padrão deveria executar routed com as opções –s e –g, enquanto os demais apenas com a opção –s. EXEMPLOS: NO GATEWAY PADRÃO root@frajola# routed –s –g NOS DEMAIS GATEWAYS root@frajola# routed –s EM GATEWAYS PARA UMA ÚNICA REDE root@frajola# routed -q 14 Módulo Configuração de Redes TCP/IP Curso Linux Básico 4 DOMAIN NAME SERVICE (DNS) Freqüentemente os usuários de uma rede sabem o nome da máquina à qual desejam se conectar na Internet, mas raramente conhecem o endereço IP correspondente. Entretanto, o protocolo IP trabalha com endereços. Assim, uma forma de traduzir nomes em endereços faz-se necessária. No início da utilização do TCP/IP na ARPANET, uma tabela estática com todos os nomes de máquinas e seus endereços era mantida de forma centralizada pelo DOD NIC (Departmento Of Defense Network Information Center). Quando uma máquina era adicionada à rede, as atualizações eram enviadas por e-mail ao DOD NIC, que regularmente atualizava a tabela de hosts. Regularmente, as demais máquinas da ARPANET copiavam através da rede esta tabela, o que com o passar do tempo passou a ser uma tarefa dispendiosa e demorada. A solução rapidamente adotada foi a concepção de um sistema de resolução de nomes com as seguintes características principais: provê um serviço de tradução de nomes para endereços (e endereços para nomes) automatizado; utiliza uma base de dados distribuída hierarquicamente, evitando centralizar informações em um único ponto; cada organização que registra um nome no sistema é responsável pelo gerenciamento dos nomes abaixo de seu domínio; é mantido um cache atualizável das informações obtidas, desta forma eliminando-se a necessidade de se obter a mesma informação repetidamente. Este sistema foi batizado de DNS (Domain Name Services) e divide o espaço de nomes em domínios. Cada domínio deve possuir um servidor primário, e no mínimo um servidor secundário para fins de redundância. A implementação do DNS usada na maioria dos sistemas UNIX é a Berkeley Internet Name Domain (BIND). O software do DNS é conceitualmente dividido em duas partes: um resolver e um servidor de nomes. O resolver formula a consulta e solicita uma resposta. O servidor de nomes é o processo que responde às consultas. O servidor de nomes do BIND executa como um processo distinto chamado named. Servidores de nomes são classificados conforme a sua configuração: primary: servidores de onde todos os dados sobre o domínio são derivados. São ditos authoritatives, por terem autoridade para responder a solicitações envolvendo máquinas do seu domínio com informações próprias; secondary: servidores que guardam consigo uma cópia das informações mantidas pelo servidor primary. Também são authoritatives para o domínio; caching-only: servidores caching-only recebem as respostas de todas as consultas de outros servidores de nomes, e guardam em cache para usarem em futuras respostas a solicitações. São chamados de servidores non-authoritatives. Servidores primários e secundários também fazem caching para melhoria de desempenho. Um servidor pode ser enquadrado em mais de uma categoria. Ele pode ser primary para um domínio e secondary para outro, por exemplo. Módulo Configuração de Redes TCP/IP 15 Curso Linux Básico Os nomes do DNS têm uma organização hierárquica, constituindo de domínios aninhados dentro de domínios. Os nomes são escritos da base para o topo, com pontos separando os níveis. www.cade.com.br www.mit.edu mail.hp.com raiz “.” br com edu mit www com arpa hp in-addr mail 200 cade 135 www 250 1 2 Os nós imediatamente abaixo da raiz da árvore (br, edu, com, …) são chamados de domínios top-level. Um desses domínios, chamado arpa possui significado especial. Para que seja possível fazer a tradução reversa de nomes, isto é, traduzir endereços para nomes, o nó arpa contém o nó in-addr, que contém todos os endereços Internet (endereços IP). Na verdade, não existem outros tipos de endereços alocados na árvore, mas o sistema inicialmente previu esta possibilidade. Da mesma forma que um nome como www.cade.com.br é organizado na árvore no sentido inverso, do mais geral (br), até o mais específico (www), os endereços IP também são organizados no sentido inverso, como por exemplo, 1.250.135.200.in-addr.arpa, que representará o nome correspondente ao endereço IP 200.135.250.1. 4.1 Configuração do Resolver Toda máquina que utiliza o sistema DNS, independente de ser servidor DNS ou não, precisa utilizar um resolver para traduzir consultas de nomes em endereços e endereços em nomes. O resolver normalmente é uma biblioteca de funções ligada aos programas executáveis, como telnet, ftp, etc. No UNIX, a configuração do resolver é feita no arquivo /etc/resolv.conf .As cláusulas permitidas no arquivo resolv.conf são: 16 Módulo Configuração de Redes TCP/IP Curso Linux Básico nameserver address: identifica o servidor do qual o resolver pode solicitar informações sobre domínios. Mais de uma linha (normalmente até 3) podem aparecer com a cláusula nameserver. Os servidores são consultados na ordem em que eles aparecem no arquivo. Se nenhuma reposta é obtida do primeiro, o próximo é tentado e assim por diante; domain domínio: define o nome do domínio default. O resolver adiciona o domínio default a todo nome de host que não contenha um ponto no final. Após isto, ele usa este nome de host expandido para fazer a consulta ao servidor de nomes; search lista: especifica uma lista de domínios que o resolver deve tentar adicionar a nomes que não contenham um ponto no final. Cada entrada da lista é tentada até que uma delas seja encontrada, ou até que tenha sido esgotada. O exemplo a seguir define o domínio minha.rede.com.br, com dois servidores de nomes, e configura o resolver para tentar adicionar os domínios minha.rede.com.br e rede.com.br caso o nome especificado nao termine com um ponto. # cat /etc/resolv.conf domain minha.rede.com.br nameserver 200.135.250.1 nameserver 200.135.250.2 search minha.rede.com.br rede.com.br 4.2 Configuração do BIND Um servidor DNS pode servir vários domínios. Quando necessário, um domínio pode ser subdividido em subdomínios. A parte de um domínio pela qual um servidor é responsável é chamada de zona. Considere o domínio a seguir, subdividido em três zonas: raiz “.” br domínio “rede” com zona “rede” rede zona “minha” minha jurere mole joaca Módulo Configuração de Redes TCP/IP sua fusca www bmw zona “sua” 17 Curso Linux Básico Neste exemplo, toda a Internet enxerga que o servidor responsável pelo domínio rede.com.br é também responsável pelos subdomínios, pois terminam em rede.com.br. Entretanto, o servidor deste domínio pode “delegar” um ramo da árvore de rede.com.br, como por exemplo, minha.com.br a um outro servidor. Assim, um servidor é na verdade responsável por uma ou mais zonas de um domínio. Às vezes um servidor é responsável por todo o domínio, mas ainda assim é importante diferenciar o conceito de domínio de zona. Existem duas versões atualmente em uso do BIND: 4.x e 8.x. Os arquivos com as informações sobre as zonas são idênticos em ambas as versões, mas o arquivo principal de configuração que define quais as zonas de responsabilidade de um servidor possuem formato diferente em cada versão, conforme a tabela a seguir: /etc/named.boot (BIND 4.x) directory caminho cache . arquivo primary zona arquivo secondary zona servidor arquivo forwarders servidor1 servidor2 … slave ; Um comentário é precedido por ; um ponto-e-vírgula 18 /etc/named.conf (BIND 8.x) options { directory “caminho”; }; zone “.” { type hint; file “arquivo”; }; zone “zona” { type master; file “arquivo”; }; zone “zona” { type slave; file arquivo; masters { servidor; }; }; options { forwarders { servidor1; servidor2; … }; }; options { forward only; }; // Um comentário é // precedido por duas // barras Significado Define um caminho de diretório onde os demais arquivos serão armazenados Especifica o arquivo de cache contendo a lista de servidores do domínio “.” (raiz) Configura o servidor como primário da zona especificada, sendo que a base de dados está armazenada em arquivo Configura o servidor como secundário da zona especificada, sendo especificado o servidor primário de onde pegar a base de dados, e gravando-a localmente no arquivo especificado Especifica uma lista de servidores (servidor1, servidor2, …) para repassar o pedido caso não consiga resolver o nome com sua própria base de dados Força o servidor a usar somente os forwarders, sem tentar atender a nenhuma solicitação Comentários devem ser precedidos de caracteres especiais. Deve-se evitar linhas em branco, especialmente com o BIND 4.x Módulo Configuração de Redes TCP/IP Curso Linux Básico Configuração exemplo de um servidor (named.boot): # cat /etc/named.boot ; named.boot – BIND 4.x directory /var/named cache . primary 0.0.127.in-addr.arpa ; primary rede.com.br primary 250.135.200.in-addr.arpa secondary minha.rede.com.br secondary 251.135.200.in-addr.arpa ; forwarders 200.135.15.3 150.162.1.3 named.ca named.local rede.zone rede.revzone 200.135.251.1 200.135.251.1 minha.zone minha.revzone Configuração exemplo de um servidor (named.conf): # cat /etc/named.conf // named.conf – BIND 8.x options { directory “/var/named”; forwarders { 200.135.15.3; 150.162.1.3; }; }; zone “.” { type hint; file “named.ca”; }; zone “0.0.127.in-addr.arpa” { type master; file “named.local”; }; zone “rede.com.br” { type master; file “rede.zone”; }; zone “250.135.200.in-addr.arpa” { type master; file “rede.revzone”; }; zone “minha.rede.com.br” { type slave; file “minha.zone”; masters { 200.135.251.1; }; }; zone “251.135.200.in-addr.arpa” { type slave; file “minha.revzone”; masters { 200.135.251.1; }; }; Módulo Configuração de Redes TCP/IP 19 Curso Linux Básico Os demais arquivos, que especificam as zonas, estão num formado padronizado. Cada arquivo é na verdade um conjunto de Resource Records (RR), onde cada RR possui o seguinte formato: [name] [ttl] [class] type data [;comment] DESCRIÇÃO: Os Resource Records são definidos na RFC 1033. Estes registros possuem a seguinte estrutura: name: este é o nome do objeto do domínio que o Resource Record referencia. Pode ser um host ou um domínio; time-to-live. Define o tempo em segundos que a informação contida neste Resource Record deve ser mantida em cache; identifica o registro como sendo da classe INternet. Na realidade, até hoje não foram criadas outras classes de registros DNS; identifica qual tipo de Resource o registro indica; contém a informação específica para o tipo de Resource Record declarado acima. ttl: IN: type: data: A tabela a seguir mostra os registros padrões disponíveis no BIND: Nome do RR Tipo do Registro Função Start of Authority SOA Marca o início dos dados de uma zona, e define os parâmetros que afetam a zona inteira. Name Server NS Identifica o servidor de nome do domínio. Address A Converte um nome de host em um endereço. Pointer PTR Converte um endereço para um nome de host. Mail Exchanger MX Identifica onde entregar o mail para um nome de domínio dado. Canonical Name CNAME Define um nome alternativo para o host. Host Information HINFO Geralmente descreve o hardware e o sistema operacional de um host. Well Known Service WKS Anuncia os serviços de rede. Text Information TXT Serve para o administrador inserir informações adicionais sobre cada máquina Um arquivo básico named.ca contém registros do tipo NS que nomeiam os servidores raiz. Um exemplo é mostrado a seguir: 20 Módulo Configuração de Redes TCP/IP Curso Linux Básico # cat /var/named/named.ca ; This file is made available by InterNIC registration services ; under anonymous FTP as ; file /domain/named.root ; on server FTP.RS.INTERNIC.NET . 3600000 IN NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4 . 3600000 NS B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107 . 3600000 NS C.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12 . 3600000 NS D.ROOT-SERVERS.NET. D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90 . 3600000 NS E.ROOT-SERVERS.NET. E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10 . 3600000 NS F.ROOT-SERVERS.NET. F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241 . 3600000 NS G.ROOT-SERVERS.NET. G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4 . 3600000 NS H.ROOT-SERVERS.NET. H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53 . 3600000 NS I.ROOT-SERVERS.NET. I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17 . 3600000 NS J.ROOT-SERVERS.NET. J.ROOT-SERVERS.NET. 3600000 A 198.41.0.10 . 3600000 NS K.ROOT-SERVERS.NET. K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129 . 3600000 NS L.ROOT-SERVERS.NET. L.ROOT-SERVERS.NET. 3600000 A 198.32.64.12 . 3600000 NS M.ROOT-SERVERS.NET. M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33 O arquivo named.local é utilizado para converter o endereço 127.0.0.1 (loopback) no nome do localhost. Basicamente, o arquivo named.local é sempre o mesmo em qualquer servidor DNS, apesar de ser possível expressar a mesma coisa de formas diferentes: @ ; 1 IN SOA IN NS localhost. root.localhost. 1997022700 ; 86400 ; 7200 ; 2592000 ; 345600 ) ; localhost. IN PTR localhost. ( Serial Refresh after 24 hours Retry after 2 hours Expire after 30 days Minimum ttl of 4 days Observe o caractere “@” no início do arquivo. Se olharmos para o formato de um RR, o primeiro item define um nome de domínio ou host sobre o qual queremos definir um RR. O caractere “@” especifica para utilizar o próprio domínio definido como “zona” no arquivo /etc/named.boot ou /etc/named.conf. Quando o item “name” do RR não é definido em uma linha, é assumido o valor definido no registro SOA. O registro SOA define um conjunto de valores da zona sendo especificada: Na primeira linha temos o domínio específico desta zona, seguido do endereço de e-mail Módulo Configuração de Redes TCP/IP 21 Curso Linux Básico da pessoa responsável, apenas trocando o caractere especial “@” por um ponto “.”; Serial: número de série do arquivo de zona. É importante incrementar este número sempre que o arquivo for modificado, pois dessa forma os servidores secundários da zona saberão que o arquivo foi alterado. A convenção AAAAMMDDNN, onde AAAA=ano, MM=mês, DD=dia, e NN=número da alteração no dia, garante que o número de série sempre será maior do que o anterior quando for modificado; Refresh: intervalo em segundos que os servidores secundários devem verificar por modificações no servidor primário; Retry: intervalo em segundos que os servidores secundários devem esperar para tentar novamente caso não tenham conseguida conexão para um Refresh; Expire: tempo máximo de validade dos registros no servidor secundário, após não ter conseguido atualizar sua cópia. Após este tempo decorrido sem atualização, o servidor secundário deve parar de responder requisições para a zona; Minimum: tempo default de ttl para os demais registros, quando especificado. O arquivo de inicialização rede.revzone é similar ao arquivo named.local. Ambos os arquivos traduzem endereços IP em nomes de hosts através de registros PTR, como pode-se ver no exemplo: @ IN SOA IN ; 1 2 3 4 IN IN IN IN 250.135.200.in-addr.arpa. root.250.135.200.in-addr.arpa. ( 1998072400 ; Serial 86400 ; Refresh after 24 hours 7200 ; Retry after 2 hours 2592000 ; Expire after 30 days 345600 ) ; Minimum ttl of 4 days NS ns.rede.com.br. PTR PTR PTR PTR ns.rede.com.br. www.rede.com.br. ftp.rede.com.br. mail.rede.com.br. O arquivo de inicialização rede.zone contém a maioria das informações de domínio. Este arquivo converte nomes de hosts em endereços IP, mas também contém registros dos tipos MX, CNAME e outros. 22 Módulo Configuração de Redes TCP/IP Curso Linux Básico @ ; ns IN SOA IN IN NS MX rede.com.br. root.rede.com.br. ( 1998072400 ; Serial 86400 ; Refresh after 24 hours 7200 ; Retry after 2 hours 2592000 ; Expire after 30 days 345600 ) ; Minimum ttl of 4 days ns.rede.com.br. 1 mail.rede.com.br. IN A 200.135.250.1 MX 1 mail.rede.com.br. ; Subdominios - delegation minha IN NS ns.minha.rede.com.br. ns.minha IN A 200.135.251.1 ; www IN A 200.135.250.2 MX 1 mail.rede.com.br. ftp IN A 200.135.250.3 MX 1 mail.rede.com.br. mail IN A 200.135.250.4 MX 1 mail.rede.com.br. O comando nslookup é uma ótima ferramenta para localização de erros no servidor, pois permite que qualquer um realize consultas diretamente ao servidor de nomes e recupere qualquer $ nslookup www.rede.com.br Server: ns.rede.com.br Address: 200.135.250.1 Non-authoritative answer: Name: www.rede.com.br Address: 200.135.250.2 uma das informações conhecidas pelo DNS. Ele pode ser usado diretamente na linha de comando ou através do modo interativo. No modo direto, procede-se como no exemplo: E no modo interativo: Comandos úteis no modo interativo: server server name muda o servidor DNS a ser questionado; set type = type muda o tipo (A, PTR, MX, NS, Any, etc) do registro pesquisado; set domain=domain muda o nome do domínio pesquisado; ls domain recupera o arquivo de zonas do domínio; exit sai do modo interativo. Módulo Configuração de Redes TCP/IP 23 Curso Linux Básico $ nslookup Default Server: ns.rede.com.br Address: 200.135.250.1 > www.rede.com.br Server: ns.rede.com.br Address: 200.135.250.1 Non-authoritative answer: Name: www.rede.com.br Address: 200.135.250.2 > set type=mx > rede.com.br Server: ns.rede.com.br Address: 200.135.250.1 rede.com.br preference = 1, mail exchanger = mail.rede.com.br rede.com.br nameserver = ns.rede.com.br mail.rede.com.br internet address = 200.135.250.4 ns.rede.com.br internet address = 200.135.250.1 24 Módulo Configuração de Redes TCP/IP Curso Linux Básico 5 NETWORK FILE SYSTEM (NFS) O Network File System (NFS) permite o compartilhamento de arquivos através de uma rede. Ele foi desenvolvido pela Sun Microsystems e hoje se encontra disponível em muitas plataformas, sendo o padrão para compartilhamento de arquivos no ambiente UNIX. Existem soluções NFS para ambientes como o MS-DOS e o MS-Windows, o que permite uma integração destes ambientes com o UNIX. Através do NFS, usuários e aplicações podem acessar arquivos remotos como se fossem locais, de forma transparente. As principais vantagens de se usar o NFS são: A possibilidade de se ter estações sem disco; Racionalização do uso dos discos, pois muitos softwares passam a residir exclusivamente em um servidor; Manutenção centralizada dos arquivos do domínio; Transparência perante os usuários. O NFS é constituído de processos servidores e clientes. Um host executando os processos clientes do NFS acessa arquivos remotos como se fizessem parte do sistema de arquivos local. Um host executando os processos servidores do NFS disponibiliza seus arquivos para uso pelos clientes. Um cliente acessa arquivos remotos fazendo um “mount”, da mesma forma que acessa um filesystem local em um disco, por exemplo. Um servidor disponibiliza seus arquivos através de um “export”. Freqüentemente um host executa tanto os processos servidores quanto os clientes. Os principais daemons envolvidos com o NFS são: nfsd: executado pelos servidores para atender às requisições de acesso aos arquivos feitas pelos clientes; biod: executado pelos clientes (Block I/O Daemon); rpc.lockd: executado por clientes e servidores a fim de negociar o fornecimento de locks para arquivos; rpc.statd: executado por clientes e servidores para monitorar o NFS; é utilizado para reestabelecer a comunicação entre clientes e servidores após uma falha de rede; rpc.mountd: executado pelos servidores para atender as requisições de mount feitas pelos clientes; rpc.rquotad: executado pelos servidores para fornecer informações sobre quotas de usuários aos clientes que montam o filesystem exportado. 5.1 Exportando Arquivos O primeiro passo na configuração de um servidor NFS é decidir quais arquivos serão exportados. Exporte apenas os arquivos que realmente serão utilizados pelos clientes. O controle de acesso remoto aos arquivos locais está associado aos diretórios e não aos arquivos em particular. Portanto, não podemos exportar um arquivo de um diretório sem exportar os demais. O arquivo /etc/exports especifica quais diretórios são exportados pelo servidor, quais clientes poderão acessá-los o que poderão fazer com os arquivos. Módulo Configuração de Redes TCP/IP 25 Curso Linux Básico Cada entrada no arquivo /etc/exports segue o formato: diretório [-opção] [,opção] As principais opções são: ro os clientes não podem escrever nos arquivos (read-only); rw = host [:host]: permite que os usuários do(s) host(s) citado(s) escrevam no arquivo; root = host [: host]: dá acesso de root aos usuários root de determinado(s) host(s); access = host [:host]: permite acesso somente a partir do(s) host(s) listado(s). # cat /etc/exports /usr /usr/local /usr/local/tmp /usr/local/www /var/spool/mail /home/venus -access=servidor1:servidor2 -access=servidor1:servidor2 -access=servidor1:servidor2 -access=servidor1:servidor2 -access=servidor1:servidor2 -access=servidor1:servidor2 |No Linux, um novo formato de arquivo é utilizado, que permite mais flexibilidade. Cada entrada do arquivo /etc/exports no Linux segue o formato: diretório [host][(opção, [opção])] … host: um host pode ser especificado por seu endereço IP, pelo seu nome DNS, por uma faixa de IPs (ex: 200.30.40.0/255.255.255.0), ou por uma faixa de domínio (ex: *.rede.com.br). Quando o campo host é vazio, o diretório é exportado para qualquer host; As principais opções são: ro: o diretório é exportado como read-only; rw: o diretório é exportado como read-write (isto é default); noaccess: informa que o diretório não deve ser exportado (útil para exportar um diretório e não permitir acesso a um subdiretório deste diretório); no_root_squash: permite que o usuário root da máquina cliente acesse o diretório montado remotamente com permissão de root. /projects /usr /home/server2 /pub /pub/private proj*.rede.com.br(rw) *.rede.com.br(ro) 10.1.2.0/255.255.255.0(rw) server1(rw,no_root_squash) (ro) (noaccess) O comando exportfs lê o arquivo /etc/exports a fim de exportar um diretório: venus# exportfs /usr venus# exportfs -a 26 Módulo Configuração de Redes TCP/IP Curso Linux Básico 5.2 Montando Diretórios Remotos Um cliente NFS pode acessar apenas os diretórios que lhe foram exportados. O comando showmount verifica quais diretórios estão disponíveis ao cliente em um determinado servidor. apolo$ showmount -e venus export list for venus: /pub/private (everyone) /pub <anon clnt> /home/server2 server1 /usr 10.1.2.3/255.255.255.0,*.rede.com.br /projects proj*.rede.com.br O comando mount é utilizado pelos clientes para montar um diretório remoto: mount - monta um sistema de arquivos. SINOPSE: mount [ -o options ] hostname:filesystem mount-point ARGUMENTOS: hostname: filesystem: mount-point: nome do host servidor; nome do diretório ou sub-diretório exportado pelo servidor; nome do diretório local onde o diretório remoto será montado. DESCRIÇÃO: O comando mount permite que diretórios exportados por um servidor NFS sejam montados localmente. Subdiretórios dos diretórios exportados também podem ser montados. Por exemplo, se um servidor exporta o diretório /usr, um cliente pode decidir montar apenas o diretório /usr/man. venus# mount apolo:/home/apolo /home/apolo Quando se monta um diretório sobre um diretório não vazio, o conteúdo deste, apesar de não ser visível, continua inalterado. Assim que o mount for desfeito o conteúdo original do diretório volta a ser visível. O comando umount desmonta um diretório. venus# umount /home/apolo O arquivo /etc/fstab provê informações sobre os sistemas de arquivos a serem montados na inicialização do sistema. Módulo Configuração de Redes TCP/IP 27 Curso Linux Básico 6 SESSION MESSAGE BLOCK (SMB) – SAMBA O protocolo SMB é um dos protocolos mais “populares” de compartilhamento de arquivos e impressoras atualmente, principalmente no ambiente de microcomputadores. Com o sucesso do sistema operacional Microsoft Windows, o uso do protocolo se tornou praticamente obrigatório nos ambientes onde máquinas com este sistema operacional estão interligadas em rede. O SMB é na verdade o protocolo utilizada pelo NetBIOS, um conjunto de serviços sobre o protocolo SMB que foi padronizada por ocasião das primeiras experiências de ligar PCs em rede. Assim, quanto o termo NetBIOS é usado, na verdade o protocolo que transporta os serviços de compartilhamento de arquivos e impressoras é o SMB. Por isso os dois termos podem ser usados de forma intercambiável. O NetBIOS é um protocolo da camada de aplicação, e define que cada nó da rede possui um nome de até 15 caracteres. Os dois serviços do NetBIOS, serviço de datagrama e serviço de nomes, estão padronizados no RFC 1001 e RFC 1002, respectivamente. O NetBIOS pode operar sobre os seguintes protocolos de transporte (de nível inferior à aplicação): TCP/IP, NetBEUI, e SPX/IPX (da Novell). Enquanto o NetBEUI é apenas uma implementação de NetBIOS direta sobre a subcamada LLC (padrão IEEE), os outros dois (TCP/IP e SPX/IPX) são realmente protocolos de transporte/rede, em relação ao modelo OSI. A desvantagem de utilizar NetBEUI é o que o protocolo exige que todas as máquinas estejam na mesma rede física (porque não utiliza como transporte um protocolo que permita roteamento, como o IP). Dessa forma, quando uma máquina utiliza NetBIOS sobre TCP/IP (NBT) ou NetBIOS sobre IPX, é preciso uma forma de traduzir os nomes NetBIOS para os endereços IP ou IPX, conforme o protocolo utilizado. Os nomes NetBIOS podem ser de dois tipos: UNIQUE e GROUP. Toda máquina rodando NetBIOS em uma rede deve possuir um nome único (UNIQUE), que não pertença a outra máquina na rede. Se necessário, a máquina pode solicitar na rede um nome GROUP, ao qual várias máquinas podem pertencer. 6.1 Resolução de Nomes NetBIOS Como o NetBIOS utiliza nomes para identificar as máquinas, e os protocolos inferiores utilizam endereços numéricos, uma forma de resolução de nomes é necessária. No caso de NetBEUI, a tradução de nomes será diretamente para endereços físicos 802.3 (Ethernet). No caso de IP, a tradução será de nomes para endereços IP (semelhante ao DNS), assim como no caso de IPX a tradução será de nomes para endereços IPX (que são constituídos do endereço 802.3 mais um prefixo que identifica a rede a que pertence a máquina). A resolução de nomes NetBIOS pode ser feita de duas formas: por difusão (broadcast) ou por requisição direta a um servidor de nomes (point-to-point). Na resolução por broadcast, uma máquina simplesmente envia por difusão na rede um anúncio do nome que deseja utilizar. Se não houver objeção por parte de outra máquina que já esteja utilizando o nome, ela então o adota como sendo seu. Quando a máquina deseja transmitir para outra, ela também envia por difusão uma pergunta pelo nome destino. A máquina destino, escutando a requisição, responde com seu endereço, de maneira muito semelhante ao protocolo ARP usado na camada de acesso à rede da arquitetura TCP/IP. 28 Módulo Configuração de Redes TCP/IP Curso Linux Básico A implementação de um servidor de nomes, de acordo com a RFC 1001, é apenas possível quando se utiliza NetBIOS sobre TCP/IP. A implementação de um servidor de nomes point-to-point da Microsoft foi denominada WINS (Windows Internet Name Service). A resolução de nomes NetBIOS através de um servidor WINS resolve o problema de excesso de broadcasts na rede em decorrência da resolução de nomes. Quando uma máquina deseja registrar seu nome, ela contacta o servidor WINS para isso. Desta forma, as máquinas da rede que não se registrarem ao servidor WINS ficarão “invisíveis” pelas demais, quando consultarem o servidor WINS. O processo de registro de nomes das máquinas é feito assim que o protocolo entra no ar. Quando a máquina é desligada, a máquina solicita a retirada do nome do servidor. Caso a máquina seja desligada abruptamente, sem ter a oportunidade de retirar seu nome do registro, o servidor WINS não terá como saber que o nome não está mais associado a uma máquina ativa. Como o protocolo de transporte para o servidor WINS é o TCP/IP, máquinas espalhadas por várias redes, inclusive interconectadas por uma WAN, conseguem se registrar e consultar o servidor de nomes. É possível assim ter um único servidor de nomes na rede, onde todos podem obter informações sobre os endereços das máquinas que rodam NetBIOS, de forma muito semelhante ao DNS. É possível existir mais de um servidor WINS na rede, de forma que a base de dados fique replicada, e caso o servidor principal saia do ar, o servidor secundário assume a responsabilidade. Além disso, o administrador da rede pode incluir entradas estáticas no servidor WINS, por exmeplo, para máquinas servidoras da rede, já que estas normalmente não mudam de endereço IP e de nome. 6.2 Samba – Servidor e Cliente SMB Atualmente, o protocolo nativo de compartilhamento de arquivos e impressoras na família de sistemas operacionais Windows, da Microsoft, é o SMB. Isto abriu várias oportunidade de mercado para desenvolvedores de soluções de conectividade entre plataformas. Por exemplo, vários fornecedores comercializam implementações de NFS para Windows, de forma que os clientes Windows de uma rede enxerguem os diretórios exportados via NFS em servidores UNIX. Para integrar sistemas Windows e UNIX, uma outra abordagem é implementar o protocolo SMB no lado UNIX. Diversos fornecedores independentes, bem como os próprios fornecedores de UNIX possuem suas próprias soluções SMB para integração com máquinas Windows, sem necessidade de adicionar software a elas. Esta solução talvez seja a melhor para integrar sistemas UNIX e sistemas Windows, pois em geral as máquinas Windows existem em maior quantidade do que as máquinas UNIX, e o fato de não ser necessária a instalação de software adicional no lado Windows é uma grande vantagem. Boa parte das implementações dos fornecedores de UNIX é simplesmente um acordo com a Microsoft para licenciarem o código nativo do LanManager, que era antigamente a implementação SMB da Microsoft para UNIX (por ocasião da Microsoft comercializar seu próprio UNIX, o Xenix). Entretanto, existe uma solução de domínio público (freeware), chamada Samba, que foi desenvolvida incialmente por Andrew Tridgell em 1992 quando era um estudante de PhD na Universidade Nacional Australiana, em Canberra, Austrália. Apesar dos primeiros testes e início do desenvolvimento do Samba terem sido no SunOS, da Sun Microsystems, o início de seu desenvolvimento mais sério foi sobre a plataforma Linux, sendo Módulo Configuração de Redes TCP/IP 29 Curso Linux Básico que atualmente já existem versões para diversas plataformas, inclusive não-UNIX, como: Linux, SunOS, Solaris, SVR4, Ultrix, OSF1, AIX, BSDI, NetBSD, Sequent, HP-UX, SGI, FreeBSD, NeXT, ISC, A/UX, SCO, Intergraph, Domain/OS, DGUX, QNX, NetWare, VMS, OS/2, Amiga, e outros que eventualmente são incluídos na lista. Todas as informações sobre o produto, downloads, FAQs, entre outros, está disponível no site http://www.samba.org, além dos mirrors espalhados pelo globo. O primeiro passo é obter o software, preferencialmente pré-compilado para o sistema operacional do servidor a ser utilizado. Após instalado, sua configuração é limitada a apenas um arquivo de configuração, chamado smb.conf, e geralmente encontrado sob o diretório /etc ou sob o diretório /usr/local/samba/lib. Conforme a utilização dada ao servidor Samba, configurações adicionais incluirão criação de diretórios de arquivos compartilhados, ajustes de permissões, etc. 6.2.1 Iniciando o Samba O samba é composto de dois processos: smbd e nmbd. O primeiro é o servidor propriamente dito, enquanto o segundo é responsável pela resolução de nomes (ou via broadcast ou via protocolo WINS). Preferencialmente, o samba deve ser inciado durante o boot do sistema, ficando disponível para conexões assim que a máquina servidora estiver no ar. Este modo coloca os dois processos para rodar como daemons. Entretanto, pode ser que em algumas situações não seja adequado o samba estar todo o tempo rodando, pois é usado raramente, e a máquina possui pouca memória e CPU disponível. Neste caso pode-se iniciar o samba via inetd, que escuta as requisições na rede para vários serviços (telnet, ftp, talk) e dispara o servidor adequado assim que uma requisição chegar pela rede. SINOPSE: smbd [ -D ] [ -d nível ] nmbd [ -D ] [ -d nível ] ARGUMENTOS: -D: -d nível: inicia o processo como daemon. Caso esta opção não seja especificada, o processo somente inicia se tiver sido chamado pelo inetd; especifica o nível de detalhes a ser armazenado no arquivo de logs do sistema. O valor default é 3, a não ser que outro seja especificado no arquivo de configuração smb.conf. 6.2.2 Configuração do arquivo smb.conf A único arquivo de configuração necessário para o Samba é o smb.conf. A localização padrão do arquivo depende dos parâmetros especificados no momento da compilação do programa. O arquivo de configuração é orientado a linhas, sendo composto de seções, e dentro de cada seção, parâmetros. Cada seção especifica um item compartilhado, normalmente chamado de compartilhamento (share). Os parâmetros para cada share podem ser então especificados individualmente. Caso seja necessário que uma linha de configuração continue na linha seguinte, deve-se colocar o caractere “\” (barra invertida) no final da linha a ser continuada. Além disso, toda 30 Módulo Configuração de Redes TCP/IP Curso Linux Básico linha que começa com o caractere “#” ou “;” é considerada um comentário. Dentro do arquivo, as seções são especificados por um nome entre colchetes. Não existe limite no tamanho do nome do compartilhamento, que pode inclusive conter espaços, mas a recomendação é que sejam utilizados no máximo 8 caracteres, sem espaços, para evitar problemas futuros com alguns clientes de rede mais antigos (DOS, Windows for Workgroups, e até mesmo Windows 95). Existem também três seções especiais: [global]: parâmetros nesta seção aplicam-se ao servidor em si, ou definem valores default para os outros compartilhamentos; [homes]: esta seção permite que usuários conectem-se diretamente a seus diretórios home. O Samba automaticamente mapeia o compartilhamento [homes] para o login do usuário que está conectando ao servidor; [printers]: a seção [printers] é um serviço automático, que lê o arquivo /etc/printcap (se impressão estilo BSD estiver em uso), e apresenta todas as impressoras encontradas automaticamente. Os parâmetros são normalmente compostos de uma ou mais palavras, e são especificados no formato: nome-do-parâmetro = valor O valor de cada parâmetro pode ser de um dos seguintes tipos: string: uma seqüência qualquer de caracteres, como por exemplo o parâmetro que especifica o nome do servidor: netbios name = Server1 numérico: um número qualquer decimal, como por exemplo o parâmetro que especifica o tamanho máximo do arquivo de logs, em Kbytes: max log size = 250 booleano: um opção que especifica os valores verdadeiro ou falso. Estes valores podem ser especificados como yes/no, true/false, ou 1/0. Como exemplo, a opção que informa se o nmbd atuará com servidor WINS ou não: wins support = yes Os principais parâmetros são especificados a seguir. À frente de cada nome de parâmetro listado, é mostrado entre parênteses se o parâmetro se aplica à seção global (G), a compartilhamentos (C) específicos. Quando um parâmetro que se aplica a compartilhamentos (C) for encontrado na seção global, ele será interpretado como o valor default para este parâmetro quando ele não for especificado em um determinado compartilhamento. PARÂMETROS: workgroup (G): server string (G): status (G): wins support (G): security (G): parâmetro do tipo string que informa ao servidor a qual workgroup / domínio pertence; string que será mostrada como “comentário” ao lado do nome do servidor em um cliente SMB; parâmetro booleano que configura o servidor para fornecer informações sobre seu status ou não; parâmetro booleano que instrui o nmbd para atuar ou não como um servidor WINS; string que especifica o modelo de autenticação a ser utilizado pelo servidor. No modo “share” a autenticação é como no Windows 3.x/9x, ou seja, um compartilhamento possui uma Módulo Configuração de Redes TCP/IP 31 Curso Linux Básico senha simples para leitura e/ou escrita. No modo “user” a autenticação é feita localmente no arquivo de usuários do UNIX (passwd). No modo “server” a autenticação é feita repassada para um servidor de autenticação Windows NT ou Samba; password server (G): nome da máquina responsável por autenticação. Este parâmetro só é válido se “security = server”; share modes (G): parâmetro booleano que habilita ou não locking em arquivos; comment string (C): string de comentário para um compartilhamento; path (C): string que especifica o diretório que está sendo compartilhado; browseable (C): parâmetro booleano que especifica se o compartilhamento será visível para o cliente (por exemplo, no Ambiente de Rede do Win95); public (C): especifica se o compartilhamento requer que o usuário se identifique e autentique; writable (C): se este parâmetro é true, compartilha em modo read-write; read only (C): se este parâmetro é true, compartilha em modo read-only. Este parâmetro é um sinônimo para “writable”, apenas com o significado invertido; create mode (C): modo numérico (usado pelo comando chmod) com o qual novos arquivos serão criados; valid users (C): lista de usuários separados por vírgula que possuem direito de conexão ao compartilhamento. Grupos podem ser especificados colocando-se um caractere “@” em frente ao nome do grupo na lista; invalid users (C): lista de usuários separados por vírgula que NÃO possuem direito de conexão ao compartilhamento. Grupos podem ser especificados colocando-se um caractere “@” em frente ao nome do grupo na lista; write list (C): lista de usuários separados por vírgula que possuem direto de escrita no compartilhamento. Grupos podem ser especificados colocando-se um caractere “@” em frente ao nome do grupo na lista. 32 Módulo Configuração de Redes TCP/IP Curso Linux Básico EXEMPLO: #==== Opcoes Globais ==== # # Ultima alteracao: 24/07/98, Celso [global] # Opcoes gerais workgroup = CURSO server string = Samba Server # Opcoes de impressao printcap name = /etc/printcap print command = lpr -h -r -P %p %s lprm command = lprm -P %p %j; /usr/local/bin/lpreset /dev/lp1 load printers = yes printing = bsd # Opcoes de log log file = /var/log/samba/log.%m max log size = 50 # Opcoes de seguranca hosts allow = 127. 10.0.0. security = user encrypt passwords = yes smb passwd file = /etc/smbpasswd guest ok = no # Opcoes de rede / desempenho socket options = TCP_NODELAY ; interfaces = 192.168.12.2/24 192.168.13.2/24 # Controle de listas. Este servidor possuira’ a lista de maquinas da rede os level = 33 domain master = yes preferred master = yes # Opcoes de controle de dominio. Este servidor atuara’ como um PDC domain logons = yes domain admin group = @celso logon drive = x: logon script = local.bat logon path = \\%L\profiles\%U # Suporte a WINS wins support = yes dns proxy = no Módulo Configuração de Redes TCP/IP 33 Curso Linux Básico # Convencoes de nomes de arquivos preserve case = yes short preserve case = yes veto files = /lost+found/quota.user/quota.group/ #==== Definicoes de Compartilhamentos ==== [homes] comment = Directorios dos Usuarios browseable = no writable = yes [printers] comment = Todas as impressoras path = /var/spool/samba browseable = no guest ok = yes writable = no printable = yes [FloppyA] comment = Unidade de disquete path = /misc/fd browseable = yes public = yes writable = yes guest ok = yes [Temp] comment = Espaco temporario path = /tmp browseable = yes public = yes writable = yes guest ok = yes Neste exemplo, os parâmetros em negrito são os parâmetros usuais em um arquivo de configuração, que devem ser adaptados para cada caso específico (por ex,: parâmetro workgroup). 34 Módulo Configuração de Redes TCP/IP Curso Linux Básico 7 NETWORK INFORMATION SERVICE (NIS) Freqüentemente, em uma rede de computadores, é desejável que a autenticação de usuários seja centralizada em servidores centrais de autenticação. Este modelo de segurança em redes é adotado por vários produtos, por exemplo, a família Mirosoft Windows. Em UNIX, normalmente a autenticação é feita localmente, consultando o arquivo /etc/passwd. Entretanto, a Sun Microsystems definiu um padrão que serve, entre outras coisas, para este propósito. Inicialmente o produto foi chamado de YP – Yellow Pages (Páginas Amarelas), pois tratava-se de um mecanismo de distribuição centralizada de informações pelas estações da rede. Entretanto YP era já uma marca registrada na Inglaterra, e a Sun rebatizou o produto de NIS – Network Information Service (Serviço de Informações de Rede). O NIS é um banco de dados administrativo utilizado para disseminar informações por todo o domínio (note-se que o conceito de domínio aqui é diferente daquele do DNS. Um domínio NIS está restrito a um conjunto de máquinas sob a mesma administração, e não se enquadra em uma estrutura hierárquica, nem aceita subdivisões). O NIS converte uma série de arquivos administrativos do UNIX em mapas disponíveis pela rede. Os principais arquivos convertidos em mapas pelo NIS são: /etc/passwd: contém informações sobre usuários; /etc/group: contém informações sobre grupos de usuários; /etct/ethers: associa endereços IP a endereços físicos (usado pelo RARP); /etc/hosts: associa nomes de hosts a endereços IP; /etc/networks: associa nomes de redes a endereços IP; /etc/netmasks: associa netmasks às redes; /etc/protocols: contém protocolos suportados pelo host; /etc/services: contém serviços suportados pelo host; /etc/aliases: contém mail aliases; /etc/netgroup: define grupos de hosts e de usuários. O principal motivo para se utilizar NIS é a facilidade administrativa. Com NIS, os arquivos de configuração podem ser mantidos de forma centralizada em um servidor e disponibilizados automaticamente pelo domínio. Um conjunto de máquinas que compartilham os mesmos mapas do NIS formam um domínio NIS. É recomendável que o nome de um domínio NIS coincida com o nome do domínio Internet. O servidor NIS cria um sub-diretório para cada domínio que ele serve no diretório /var/yp. O comando domainname define ou mostra o nome do domínio NIS corrente. venus% domainname inf.ufsc.br venus% domainname inf.ufsc.br O nome do domínio NIS é normalmente configurado na inicialização do sistema a partir do arquivo /etc/defaultdomain. Este é o arquivo utilizado no SunOS e no Solaris durante o boot do sistema para descobrir qual o domínio NIS em uso. Outros UNIX provavelmente irão armazenar o nome do domínio NIS em outros locais. Módulo Configuração de Redes TCP/IP 35 Curso Linux Básico Os principais programas envolvidos com o NIS são: ypserv: daemon servidor do NIS, responsável pelo atendimento às requisições dos clientes; ypbind: daemon cliente do NIS, responsável por encaminhar as requisições ao servidor; ypinit: programa de inicialização do NIS; lê os arquivos de /etc e cria os mapas correspondentes. Este programa normalmente está no diretório /usr/lib/yp; ypxfrd: daemon responsável por transferir os mapas do servidor mestre para os servidores escravos; yppasswdd: daemon responsável por receber notificações de alteração de senha de um usuário em uma máquina cliente. O NIS cria um mapa equivalente ao arquivo /etc/hosts. Logo, ele pode dispensar o uso do DNS para domínios pequenos e isolados da Internet. Entretanto, alguns resolvers, quando configurados para utilizar NIS, ignoram completamente a configuração DNS (/etc/resolv.conf) e passam somente a consultar nomes no mapa hosts do domínio NIS. A solução é fazer com que o servidor NIS, quando receba a consulta por um nome que não está em seu mapa hosts, consulte um servidor DNS. Isto pode ser feito incluindo a cláusula “B=-b” no arquivo de construção dos mapas NIS, localizado em /var/yp/Makefile. venus# vi /var/yp/Makefile # Set the following variable to "-b" to have NIS servers use the domain # name resolver for hosts not in the current domain. B=-b Para garantir o funcionamento do serviço, o NIS define duas classes de servidores: master e slave. Um domínio NIS deve possuir pelo menos um servidor master (mestre), e opcionamente vários servidores slave (escravos), que obterão cópias dos mapas NIS a partir do servidor master. Para inicializar o servidor mestre do domínio e criar os mapas iniciais, os seguintes passos devem ser feitos: Configurar o domínio NIS com o comando domainname; Executar o comando ypinit –m. Este comando lerá os arquivos do diretório /etc e criará os mapas correspondentes no diretório /var/yp/domainname, onde domainname é o nome do domínio ajustado no passo anterior; Dispare os daemons necessários. O daemon ypserv é o servidor em si, portanto deve sempre estar rodando no servidor. Se existem servidores slave que irão se conectar ao servidor master, ele deve rodar também o daemon ypxfrd. Se os clientes precisarem alterar senhas de usuários no servidor NIS, então o daemon yppasswdd também deve ser executado. Por fim, a máquina servidora precisa também ser configurada como cliente NIS, executando o ypbind. babbage# babbage# babbage# babbage# babbage# babbage# domainname servers /usr/lib/yp/ypinit –m ypserv ypxfrd yppasswdd ypbind Para disparar um servidor slave os seguintes passos devem ser seguidos: Configurar o domínio NIS com o comando domainname; 36 Módulo Configuração de Redes TCP/IP Curso Linux Básico Executar o comando ypinit –s master. Este comando fará com que o servidor master seja contactado, e seus mapas copiados; Dispare os daemons necessários. O daemon ypserv é o servidor em si, portanto deve sempre estar rodando no servidor. Por fim, a máquina servidora precisa também ser configurada como cliente NIS, executando o ypbind. pascal# pascal# pascal# pascal# domainname servers /usr/lib/yp/ypinit –s babbage ypserv ypbind Para disparar um cliente NIS, basta configurar o domínio NIS e disparar o daemon cliente: hollerith# domainname servers hollerith# ypbind No servidor NIS mestre, toda vez que um dos arquivos exportados for alterado, é necessário reconstruir o mapa correspondente. Para isso, é necessário executar o comando make dentro do diretório /var/yp. O comando make irá reconstruir os mapas de acordo com as regras do arquivo /var/yp/Makefile existente, deixando-os sincronizados com os arquivos originais. O exemplo a seguir ilustra a situação. babbage# cd /var/yp babbage# make gmake[1]: Entering directory `/var/yp/servers' Updating passwd.byname... Updating passwd.byuid... Updating group.byname... Updating group.bygid... Updating hosts.byname... Updating hosts.byaddr... gmake[1]: Leaving directory `/var/yp/servers' babbage# Módulo Configuração de Redes TCP/IP 37 Curso Linux Básico BIBLIOGRAFIA 1. 2. 3. 4. 5. ALBITZ, Paul; LIU, Cricket. DNS and BIND. O’Reilly & Associates, 1992. FEIT, Sidnie. TCP/IP – Architecture, Protocols, and Implementation with IP v6 and IP Security. 2nd. ed. McGraw-Hill, 1996. FRISCH, Ællen. Essential System Administration. 2nd. ed. O’Reilly & Associates, 1996. HUNT, Craig. TCP/IP Network Administration. 2nd. ed. O’Reilly & Associates, 1997. STERN, Hal. Managing NFS and NIS. O’Reilly & Associates, 1991. Dúvidas, críticas e sugestões sobre esta apostila: mailto:[email protected] 38 Módulo Configuração de Redes TCP/IP