Escolar Documentos
Profissional Documentos
Cultura Documentos
Módulo Configuração
de Redes TCP/IP
por
SUMÁRIO
1 INTRODUÇÃO 1
2 INTERFACE DE COMUNICAÇÃO 3
2.1 Reconhecimento das Interfaces de Rede 3
3 ROTEAMENTO DE DATAGRAMAS IP 8
3.1 Tabela de Roteamento Mínimo 8
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:
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.
memória. Isto reduz seu tamanho e aumenta sua eficiência. A maioria dos UNIX atuais
utiliza esta abordagem.
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 Nome adotado para a primeira interface Ethernet
SCO UNIX depende do fabricante (ex: e3B0)
Linux eth0
Digital UNIX ln0, tu0
Solaris le0
SunOS le0, ie0, ec0
AIX en0 (Ethernet), et0 (802.3)
HP-UX 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.
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.
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.
As páginas de manual sobre o comando ifconfig dão maiores detalhes das opções de
configuração.
3 ROTEAMENTO DE DATAGRAMAS IP
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.
EXEMPLO:
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: determina se a rota é para um máquina ou para uma rede. Se
este parâmetro for omitido, é assumido o valor “-host”;
destination: informa destino da rota;
netmask mask: utiliza mask como máscara de subrede para esta rota;
gateway router: 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;
device: nome da interface de rede que esta rota utilizará como saída;
metric M: estabelece a métrica para a rota sendo estabelecida;
mss M: estabelece o MSS – Maximum Segment Size (tamanho máximo
do segmento) TCP a usar com esta rota;
window W: informa o tamanho da janela TCP a ser usada nessa rota.
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:
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.
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.
SINOPSE:
ping [ -f ] [ -i tempo espera ] [ -count quantidade ] destino
ARGUMENTOS:
-f envia um novo “ping” assim que receber a resposta do
anteriormente enviado. A comportamento default é enviar uma
requisição a cada segundo;
-i tempo espera informa o tempo entre cada envio de um novo “ping”;
-count quantidade informa quantos “pings” devem ser enviados. O comportamento
default é enviar “pings” eternamente, até o comando ser
cancelado;
destino: informa o endereço ou nome da máquina destino.
`
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.
BGP BGP
Provedor
Bananal Sul
EIGRP
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:
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:
NO GATEWAY PADRÃO
root@frajola# routed –s –g
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.
www.cade.com.br
www.mit.edu
mail.hp.com
raiz “.”
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.
# 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
raiz “.”
domínio “rede” br
com
zona “rede”
rede
zona “minha”
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:
# cat /etc/named.boot
; named.boot – BIND 4.x
directory /var/named
cache . named.ca
primary 0.0.127.in-addr.arpa named.local
;
primary rede.com.br rede.zone
primary 250.135.200.in-addr.arpa rede.revzone
secondary minha.rede.com.br 200.135.251.1 minha.zone
secondary 251.135.200.in-addr.arpa 200.135.251.1 minha.revzone
;
forwarders 200.135.15.3 150.162.1.3
# 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;
};
};
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:
DESCRIÇÃO:
Os Resource Records são definidos na RFC 1033. Estes registros possuem a
seguinte estrutura:
Um arquivo básico named.ca contém registros do tipo NS que nomeiam os servidores raiz.
Um exemplo é mostrado a seguir:
# 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
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 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.
$ 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
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.
# cat /etc/exports
/usr -access=servidor1:servidor2
/usr/local -access=servidor1:servidor2
/usr/local/tmp -access=servidor1:servidor2
/usr/local/www -access=servidor1:servidor2
/var/spool/mail -access=servidor1:servidor2
/home/venus -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;
/projects proj*.rede.com.br(rw)
/usr *.rede.com.br(ro) 10.1.2.0/255.255.255.0(rw)
/home/server2 server1(rw,no_root_squash)
/pub (ro)
/pub/private (noaccess)
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.
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.
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.
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
# Suporte a WINS
wins support = yes
dns proxy = no
[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
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.
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# domainname servers
babbage# /usr/lib/yp/ypinit –m
babbage# ypserv
babbage# ypxfrd
babbage# yppasswdd
babbage# ypbind
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.
Para disparar um cliente NIS, basta configurar o domínio NIS e disparar o daemon cliente:
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#
BIBLIOGRAFIA
1. ALBITZ, Paul; LIU, Cricket. DNS and BIND. O’Reilly & Associates, 1992.
2. FEIT, Sidnie. TCP/IP – Architecture, Protocols, and Implementation with IP v6 and IP
Security. 2nd. ed. McGraw-Hill, 1996.
3. FRISCH, Ællen. Essential System Administration. 2nd. ed. O’Reilly & Associates, 1996.
4. HUNT, Craig. TCP/IP Network Administration. 2nd. ed. O’Reilly & Associates, 1997.
5. STERN, Hal. Managing NFS and NIS. O’Reilly & Associates, 1991.