Durante oito últimos dias olhei para vários aspectos da família de protocolo TCP/IP. Agora é tempo de olhar para como pode fundar de fato TCP/IP em uma rede. Este capítulo explica como os servidores de uma rede TCP/IP se configuram, e o seguinte capítulo examina máquinas de cliente. Tanto em capítulos, tento cobrir uma ampla variação de máquinas como em sistemas operacionais.
Neste capítulo olho para como fundar quatro tipos diferentes de servidores: uma máquina de Santa Cruz Operation (SCO) OpenServer 5, uma máquina de Linux, uma máquina de Windows NT e um sol SPARCstation 5. Os quatro servidores unem-se à rede de mostra, e algum deles pode acessar-se por uma máquina de cliente ou outros servidores. Demasiado não se preocupe se não vou usar a sua determinada versão de UNIX, porque a maioria dos detalhes da configuração TCP/IP são idênticos ou muito semelhantes através de todas as versões UNIX. Normalmente tudo que se modifica é o nome do diretório de alguns arquivos de configuração.
Como sabe de antes neste livro, UNIX e TCP/IP entrelaçam-se estreitamente porque as implementações originais de TCP/IP foram para sistemas UNIX. TCP/IP desenvolveu-se para o BSD UNIX versão que se originou na universidade da Califórnia em Berkeley, e a maior parte da língua de TCP/IP engancha-se nas versões BSD. A maior parte de sistemas UNIX afastaram-se de BSD UNIX e abraçaram o Sistema o V Lançamento 4, originalmente desenvolvido em AT&T e agora possuído pela Fundação de software Aberta. O SCO UNIX e SunSoft Solaris 2.4, ambos os quais uso neste capítulo, usam o Sistema V versão do Lançamento 4 de UNIX, que provê alguma compatibilidade para trás de BSD UNIX.
No seguinte capítulo estendo a cobertura de TCP/IP na rede de mostra olhando para implementações de cliente. Olho especificamente para como pode implementar TCP/IP do DOS, o Windows 3.x e o Windows 95. Algum dos sistemas operacionais mencionados neste capítulo pode atuar como clientes a algum dos servidores, também.
A maioria do material coberto neste capítulo é familiar se tenha lido o livro do princípio ao fim na ordem. Um pouco dele resume-se e mostra-se novamente para a referência rápida, bem como para aqueles que leram os capítulos fora da ordem. Se se perder, pode consultar o índice de um ponteiro para mais informação.
Para este capítulo pretendi uma rede TCP/IP dedicada mostrar os passos que deve seguir para estabelecer-se, configurar, e testar uma implementação TCP/IP. A rede de mostra confia em vários servidores, embora muitas redes tenham só um. Também, uso vários tipos diferentes de servidores para mostrar-lhe como podem configurar-se, ao passo que a maior parte de verdadeiras redes não são isto diverso. Todas as máquinas unem-se sobre uma rede de Ethernet. Em geral, a rede de mostra tem quatro servidores e três clientes.
Cada uma das sete máquinas na rede tem o seu próprio nome e endereço IP. Para esta rede de mostra, a máscara de endereço IP escolheu-se à toa como 147.120. Os nomes das máquinas escolheram-se dos meus animais, embora qualquer nome único fizesse, naturalmente. A configuração de rede de mostra mostra-se na Figura 9.1. Tenha em mente que esta rede se constrói para mostrar os tipos diferentes de sistemas operacionais que examino no material de hoje e de amanhã; é improvável que uma verdadeira rede tivesse uma mistura tão ímpar de servidores e clientes.
A figura 9.1. A rede de TCP/IP de mostra.
A organização física da rede empreende-se primeiro. Implica a instalação de um cartão de interface de rede em cada máquina (exceto o SPARCstation, que tem a placa de rede como parte da placa mãe). Em cada sistema deve assegurar que qualquer saltador de vetores de interrupção e endereços de entrada-saída de memória não está em conflito com nenhum outro cartão naquele sistema. (Alguns cartões são software programável; alguns estabelecem-se por comutadores de MERGULHO ou saltadores.) Todas as tábuas usadas neste sistema são de fabricantes diferentes para mostrar a natureza independente da rede TCP/IP.
O fio deve dirigir-se entre todas as máquinas, unindo os cartões de interface de rede em conjunto. Em caso de Ethernet, os fios devem terminar-se propriamente. A rede de mostra usa Ethernet fina, que estreitamente se parece com o fio coaxial de televisão. BNC conectores de Ethernet Finos parecem-se com um T, com fios anexados a ambos os fins do T e o tronco unido à placa de rede. Duas das máquinas formam os fins do fio e necessitam um resistor que termina como parte do seu T. O SPARCstation normalmente usa um conector RJ45 (que parece a um largo conector telefônico, portanto usei um transceptor para convertê-lo em BNC).
Para testar a rede física, é o mais fácil esperar até que um par de máquinas tenham tido a sua configuração de software básica concluída. Todas as máquinas na rede não têm de ser ativas, enquanto o fio de rede é contíguo de ponta a ponta e cada conector BNC anexa-se a uma placa de rede para fornecer a terminação elétrica. Se os problemas se encontrarem quando a rede se testa, a rede física é o primeiro item a verificar. Alguns dispositivos de monitorização de rede podem fornecer à informação sobre integridade antes da instalação da rede, mas estes dispositivos não estão normalmente disponíveis para administradores de sistema que somente começam a sua instalação, ou quem têm um pequeno número de máquinas para manter (principalmente porque os provadores de rede tendem a ser caros).
Esta seção executa a configuração do software TCP/IP. A discussão aplica-se igualmente ao UNIX, Windows e máquinas de DOS na rede de mostra (como ia a qualquer outro tipo da máquina, como um Macintosh). Os nomes de arquivo podem modificar-se com sistemas operacionais diferentes, mas o acesso geral permanece válido.
A maior parte de sistemas operacionais e os pacotes de software TCP/IP fornecem vária utilidade, inclusive escritas dirigidas pelo cardápio que a ajuda automatiza o processo de instalação das aplicações TCP/IP. Alguns sistemas operacionais (notavelmente mais velhos sistemas UNIX) ainda necessitam a configuração manual de vários arquivos usando um editor de texto. Para configurar o software TCP/IP propriamente, deve saber várias partes da informação antes que comece. A informação necessária da qual precisa para cada máquina na rede segue:
O nome de domínio de sistema é necessário se a rede dever unir-se a outras máquinas do lado de fora da rede local. Os nomes de domínio podem inventar-se pelo administrador de sistema. Se, contudo, a rede dever inter-relacionar com a Internet ou um dos seus fornecedores de serviços, o nome de domínio deve aprovar-se pelo Centro de informação de Rede de Internet (InterNIC). Criar e registrar um novo domínio são tão simples como preencher uma forma (e recentemente, pagando uma pequena taxa de administração). Os nomes de domínio normalmente refletem o nome da empresa, com a extensão que identifica o tipo da organização. A rede de mostra usa o nome tpci.com.
Como visto antes neste livro, o nome de máquina usa-se para a nomeação simbólica de uma máquina em vez de forçar o endereço IP cheio a especificar-se. O nome de sistema deve ser único na rede local. Outras redes poderiam ter máquinas com o mesmo nome, mas as suas máscaras de rede são diferentes, então não há confusão possível durante o encaminhamento de pacote. Na maioria dos casos, os nomes de sistema compõem-se de oito carateres (ou menos) e são normalmente todos os carateres em letras minúsculos (de acordo com a tradição UNIX da letra minúscula). O nome de sistema pode ser uma mistura de carateres e números. As organizações maiores tendem a numerar as suas máquinas, e as pequenas empresas dão às suas máquinas nomes mais familiares.
O motorista de dispositivo instrui o sistema operacional como comunicar-se com o interface de rede (normalmente uma placa de rede ou um porto serial). Cada interface tem o seu próprio motorista de dispositivo específico. A maior parte de sistemas operacionais mandam incluir motoristas de dispositivo no seu software de distribuição, embora alguns necessitem o software fornecido com a placa de rede. Os motoristas genéricos estão disponíveis para a maior parte de placas de rede em sistemas de conselho de boletim.
Com a maior parte de sistemas operacionais, há limites do número de dispositivos semelhantes que se apoiam. O SCO UNIX, por exemplo, permite até quatro cartões de Ethernet, dois adaptadores Anulares Simbólicos, quatro linhas de Serial Line Internet Protocol (SLIP) e quatro linhas de Point-to-Point Protocol (PPP). Estes limites devem ser bastante para uma máquina em qualquer rede!
A configuração de placa de rede deve conhecer-se para instalar o motorista de dispositivo propriamente. As placas de rede normalmente têm várias colocações de configuração, dependendo do sistema para o qual se projetam. Para as máquinas baseadas no PC na rede de mostra, cada cartão deve ter um vetor de interrupção único (chamou um IRQ) e um endereço de memória de entrada-saída único. IRQ e as colocações de endereço em muitos dos mais novos conselhos de rede são configuráveis pelo software, fazendo a instalação e configuração muito mais fáceis.
A maior parte de placas de rede vêm com colocações à revelia que poderiam estar em conflito com outros cartões no sistema. Os usuários devem verificar cuidadosamente conflitos, recorrendo a um programa diagnóstico se disponível. Os usuários de UNIX têm vária utilidade disponível, dependendo do sistema operacional. O SCO UNIX e a maior parte de Sistema V sistemas operacionais do Lançamento 4 têm a utilidade hwconfig, que mostra a configuração de hardware atual. O seguinte exemplo mostra a produção hwconfig e a produção da ordem com a opção-h de prover muito tempo a formatação com cabeçadas (fazendo é mais fácil ler):
$ hwconfig name=fpu vec=13 dma=- type=80387 name=serial base=0x3F8 offset=0x7 vec=4 dma=- unit=0 type=Standard nports=1 name=serial base=0x2F8 offset=0x7 vec=3 dma=- unit=1 type=Standard nports=1 name=floppy base=0x3F2 offset=0x5 vec=6 dma=2 unit=0 type=96ds15 name=floppy vec=- dma=- unit=1 type=135ds18 name=console vec=- dma=- unit=vga type=0 12 screens=68k name=adapter base=0x2C00 offset=0xFF vec=11 dma=- type=arad ha=0 id=7 fts=st name=nat base=0x300 offset=0x20 vec=7 dma=- type=NE2000 addr=00:00:6e:24:1e:3e name=tape vec=- dma=- type=S ha=0 id=4 lun=0 ht=arad name=disk vec=- dma=- type=S ha=0 id=0 lun=0 ht=arad fts=stdb name=Sdsk vec=- dma=- cyls=1002 hds=64 secs=32 $ $ hwconfig -h device address vec dma comment ====== ======= === === ======= fpu - 13 - type=80387 serial 0x3f8-0x3ff 4 - unit=0 type=Standard nports=1 serial 0x2f8-0x2ff 3 - unit=1 type=Standard nports=1 floppy 0x3f2-0x3f7 6 2 unit=0 type=96ds15 floppy - - - unit=1 type=135ds18 console - - - unit=vga type=0 12 screens=68k adapter 0x2c00-0x2cff 11 - type=arad ha=0 id=7 fts=st nat 0x300-0x320 7 - type=NE2000 addr=00:00:6e:24:1e:3e tape - - - type=S ha=0 id=4 lun=0 ht=arad disk - - - type=S ha=0 id=0 lun=0 ht=arad fts=stdb Sdsk - - - cyls=1002 hds=64 secs=32
Esta produção é do SCO UNIX servidores fundados para a rede de mostra. Tem a rede cartão de Ethernet já configurado como dispositivo nat, que usa IRQ 7 (mostrado abaixo do vec ou coluna de vetor de interrupção). A linha nat também mostra o endereço de memória como 300–320 (hexadecimal) e o motorista de dispositivo como NE2000 (um Novell motorista compatível com o Netware). O endereço e as colunas vec não mostram nenhum conflito entre as colocações usadas para o cartão de Ethernet e outros dispositivos no sistema. (A entrada de adaptador é para um cartão SCSI-2 de alta velocidade, que controla tanto a fita como o dispositivo Sdsk, a unidade de disco rígido SCSI primária. Todas outras entradas devem ser evidentes.)
Os usuários de DOS podem usar a utilidade de Microsoft Diagnostic, MSD.EXE, ou um de vários instrumentos da terceira pessoa como Instrumentos de PC de Ponto central ou a Utilidade de Norton para expor vetores IRQ e endereços de memória no uso pelo sistema. Algum software até indica que vetores e os endereços estão disponíveis para o uso.
Não há necessidade de ter o mesmo IRQ e endereço de memória de cada cartão na rede, porque a própria rede não se preocupa com estas colocações. Necessita-se que para a máquina o IRQ e os endereços de memória se comunique com o cartão de interface de rede só. A rede de mostra usou um IRQ diferente e endereço de memória de cada máquina.
IRQ e os endereços de memória estabelecem-se normalmente no próprio cartão de interface de rede usando saltadores em alfinetes ou um bloco de comutador do MERGULHO. A documentação que acompanha o cartão deve fornecer toda a informação necessária para estabelecer estes valores. Alguns cartões de interface de rede recentemente introduzidos podem configurar-se pelo software, permitindo às colocações modificar-se sem retirar o cartão do sistema. Isto pode ser muito prático quando um usuário é inseguro das melhores colocações do cartão.
O endereço IP é um número de 32 bits que deve ser único para cada máquina. Se a rede dever unir-se à Internet, o endereço IP deve destinar-se pelo NIC (dá-se normalmente a você quando registra o seu nome de domínio). Mesmo se nenhum acesso à Internet se esperar, arbitralmente destinar um endereço IP pode causar problemas quando as mensagens se passam com outras redes. Se a rede não se unir ao mundo exterior, um administrador de sistema pode ignorar a numeração do NIC de sistema e adotar qualquer endereço IP. É de mérito, contudo, considerar a futura expansão e a conexão a outras redes.
Como poderia lembrar, o NIC tem quatro classes de endereços IP no uso dependendo do tamanho da rede. Cada classe tem alguns endereços que se restringem. Estes mostram-se na Tabela 9.1. A maior parte de redes são a Classe B, embora algumas grandes corporações necessitem a Classe Umas redes.
|
Classe |
Bytes de máscara de rede |
Número de anfitriões por rede |
Endereços válidos |
|
A |
1 |
16,777,216 |
1.0.0.1 a 126.255.255.254 |
|
B |
2 |
65,534 |
128.0.0.1 a 191.255.255.254 |
|
C |
3 |
254 |
224.0.0.0 a 255.255.255.254 |
|
D |
reservado |
A máscara de rede é o endereço IP tirado dos seus identificadores de rede, deixando só o endereço de máquina local. Para uma Classe Uma rede, isto despe um byte, ao passo que uma rede da Classe B despe dois bytes (partida dois). A pequena rede da Classe C despe três bytes como a máscara de rede, deixando um byte para identificar a máquina local (daqui o limite de 254 máquinas na rede). A rede de mostra configura-se como uma máquina da Classe B com a máscara de rede de endereço IP à toa escolhida de 147,120 (não NIC-destinado).
O endereço de transmissão identifica pacotes que devem enviar-se a todas as máquinas na rede local. Como uma placa de rede normalmente ignora qualquer pacote de entrada que não tem o seu endereço IP específico neles, um endereço de transmissão especial pode estabelecer-se que o cartão pode interceptar além de mensagens localmente destinadas. O endereço de transmissão tem a porção de anfitrião (os identificadores de máquina locais) jogo a todo o 0s ou a todos 1s, dependendo da convenção seguida. Para a conveniência, a máscara de rede de endereço de transmissão é normalmente o mesmo como a máscara de rede local.
Os endereços de transmissão poderiam parecer simples porque há só duas colocações possíveis. Tais endereços, contudo, comumente causam problemas porque as colocações contrárias se usam em uma rede. O BSD UNIX usou a convenção de todo o 0s dos lançamentos 4.1 e 4.2, ao passo que 4.3BSD e SVR4 (Sistema o V Lançamento 4) UNIX movidos para todos 1s para a transmissão se dirigem. O padrão de Internet especifica todos 1s como o endereço de transmissão. Se os problemas se encontrarem na rede com transmissões, verifique todas as configurações para assegurar que usam a mesma colocação. A rede de mostra usa todos 1s máscara do seu endereço de transmissão.
Os passos seguidos para configurar TCP/IP são francos, geralmente depois da informação necessitada para cada máquina. Os passos de configuração são como se segue:
Usará estes passos (não necessariamente na sequência dada) como as máquinas individuais na rede configuram-se. Os processos são diferentes com cada sistema operacional, mas a aproximação total permanece o mesmo.
A maior parte de UNIX TCP/IP sistemas operacionais confiam em vários arquivos da configuração. Estes resumem-se na Tabela 9.2. Lembre-se de que os nomes de arquivo podem modificar-se com implementações diferentes do sistema operacional UNIX, mas a informação sobre configuração é consistente. Olho para cada um destes arquivos mais detalhadamente quando olho para sistemas operacionais específicos depois hoje. Estes arquivos só aplicam-se a UNIX normalmente; o Windows NT, por exemplo, usa um jogo diferente de mesas.
|
Arquivo |
Descrição |
|
/etc/hosts |
Nomes do host |
|
/etc/networks |
Nomes de rede |
|
/etc/services |
Lista de serviços conhecidos |
|
/etc/protocols |
Protocolos apoiados |
|
/etc/hosts.equiv |
Lista de anfitriões confiados |
|
/etc/ftpusers |
Lista de usuários de FTP mal acolhidos |
|
/etc/inetd.conf |
Lista de servidores começados por inetd |
Para a rede de mostra, modificando estes arquivos em algum de três servidores UNIX (SCO UNIX, Linux e SPARCstation) é bastante fácil. Um editor de texto ASCII é tudo que se necessita. A verificação dos conteúdos é normalmente bastante simples, também, porque as mesas em uma máquina são muito semelhantes àqueles em outras máquinas, exceto algumas entradas.
O SCO UNIX e SCO OpenServer 5 incluem vária utilidade de configuração para ajudar a fornecer a informação para TCP/IP e ligar o motorista no núcleo corretamente. Isto não elimina a necessidade de editar muitos arquivos de configuração manualmente e informação sobre provisão sobre outras máquinas na rede. A maioria da informação nesta seção, embora específico para SCO UNIX, é geralmente aplicável à maior parte de sistemas operacionais UNIX, versões especialmente SVR4-complacentes.
A maior parte de redes baseadas em UNIX têm uma máquina de servidor principal que começa os processos de rede. Esta máquina chama-se às vezes um servidor super, porque qualquer máquina que dirige processos de rede e aceita pedidos de outras máquinas é um servidor. UNIX usa o processo inetd (demônio de Internet) como o servidor principal de todos os processos de rede que devem ativar-se (normalmente contido em inetd.conf chamado de um arquivo único.) A configuração de hardware necessita a vinculação de informação sobre a placa de rede e protocolo ao núcleo de sistema operacional. A configuração chama-se às vezes uma cadeia. O processo automatiza-se normalmente por um arquivo de escrita, necessitando usuários fornecer o número de vetor de interrupção, o endereço de memória de entrada-saída e o tipo do cartão. O driver de dispositivo daquela placa de rede então reedifica-se no núcleo portanto o motorista é ativo sempre que as botas de sistema.
Em SCO UNIX sistemas, uma utilidade chamou netconfig usa-se, incitando o usuário das três partes da informação (IRQ, endereço e tipo de cartão) e logo reedificando o núcleo. Abaixo de SCO OpenServer 5, pode executar as mesmas tarefas por uma utilidade GUI-dirigida que executa as mesmas tarefas. Este processo repete-se para cada placa de rede na máquina. (A rede de mostra tem só um cartão em cada máquina, que é a configuração mais comum.) Quando começado, o SCO UNIX netconfig programa presenta-lhe esta tela:
$ netconfig
Currently configured chains:
1. nfs->sco_tcp
nfs SCO NFS Runtime System for SCO Unix
sco_tcp SCO TCP/IP for UNIX
2. sco_tcp->lo0
sco_tcp SCO TCP/IP for UNIX
lo0 SCO TCP/IP Loopback driver
Available options:
1. Add a chain
2. Remove a chain
3. Reconfigure an element in a chain
q. Quit
Select option: Please enter a value between 1 and 3 ('q' to quit):
Como um motorista de dispositivo TCP/IP se está acrescentando, opção 1 (Acrescente uma cadeia) seleciona-se. Alguns usuários confundem a primeira cadeia configurada na lista com um motorista TCP/IP da rede e tentam reconfigurá-lo. O primeiro motorista inclinou-se na produção prévia é um valor à revelia do NFS e deve deixar-se em paz. Não tem nada a ver com a adição de uma placa de rede TCP/IP. A segunda cadeia enumerada na configuração é o motorista de laço de retorno, que deve criar-se automaticamente para todos os sistemas SCO quando o software de sistema operacional se instala.
Depois de indicar que uma nova cadeia deve acrescentar-se, o sistema pede o tipo da cadeia:
Num Name Description 1. lmxc SCO LAN Manager Client 2. nfs SCO NFS Runtime System for SCO UNIX 3. sco_ipx SCO IPX/SPX for UNIX 4. sco_tcp SCO TCP/IP for UNIX Select top level of chain to Add or 'q' to quit:
A opção 4 escolhe-se porque instala TCP/IP. O Gerente de LAN e IPX/SPX usam-se para a integração com redes baseadas no DOS. O Sistema de Tempo de execução de NFS acrescenta-se depois se o NFS dever usar-se na rede. Olho para a configuração de NFS mais detalhadamente no Dia 12, "NFS e NIS".
A utilidade netconfig então apresenta uma lista de várias dúzias de cartões de interface de rede para os quais o sistema tem valores à revelia. Se o cartão instalado no sistema se mostrar, a entrada do cartão escolhe-se. Se o cartão não estiver na lista, uma entrada compatível deve encontrar-se. Isto às vezes necessita a cavagem pela documentação de cartão de interface de rede de emulação ou valores compatíveis ou contatar com o fabricante. Os motoristas estão normalmente disponíveis para cartões de Ethernet.
O sistema então incita para o IRQ para o qual o cartão se estabelece, se segue do endereço de memória. Depois que estes introduzem-se, o sistema operacional cria as entradas necessárias nos seus arquivos de configuração internos para incluir o driver de dispositivo da placa de rede. Como um passo final, o sistema pergunta se o usuário quer reedificar e religar o núcleo. Isto deve fazer-se se os novos motoristas deverem ser eficazes. Depois de uma reiniciação de sistema, os motoristas são ativos e podem testar-se com uma ordem de silvo.
Pode silvar o localhost primeiro, seguido do endereço IP que destinou para a máquina SCO. Isto não testa a conexão de rede, porque o sistema operacional não se preocupa com usar a placa de rede silvando ela mesma. O teste realmente, contudo, verifica que o endereço IP se estabelece propriamente e que o software TCP/IP é introduzido no núcleo de sistema operacional. Um exemplo deste tipo da prova de silvo parece a isto:
# ping -c5 localhost PING localhost (127.0.0.1): 56 data bytes 64 bytes from localhost (127.0.0.1): icmp_seq=0 ttl=64 time=10 ms 64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0 ms 64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0 ms 64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0 ms 64 bytes from localhost (127.0.0.1): icmp_seq=4 ttl=64 time=0 ms --- localhost ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 0/2/10 ms # ping -c5 147.120.0.1 PING 147.120.0.1 (147.120.0.1): 56 data bytes 64 bytes from merlin (147.120.0.1): icmp_seq=0 ttl=64 time=0 ms 64 bytes from merlin (147.120.0.1): icmp_seq=1 ttl=64 time=0 ms 64 bytes from merlin (147.120.0.1): icmp_seq=2 ttl=64 time=0 ms 64 bytes from merlin (147.120.0.1): icmp_seq=3 ttl=64 time=0 ms 64 bytes from merlin (147.120.0.1): icmp_seq=4 ttl=64 time=0 ms --- 147.120.0.1 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 0/0/0 ms
No exemplo precedente, emitido no servidor merlin com o endereço IP 147.120.0.1, usei a ordem de silvo com a opção-c de especificar quantos pacotes para enviar. Como pode ver, tanto o localhost como o endereço IP responderam propriamente, indicando que o software TCP/IP se carrega propriamente e o endereço IP reconhece-se.
Como viu antes hoje, UNIX TCP/IP ligação em rede de software confia em vários arquivos da configuração. Estes resumiram-se na Tabela 9.2. Pode olhar para cada um destes arquivos agora com respeito ao SCO UNIX servidor na rede de mostra.
O arquivo/etc/hosts contém os nomes de outras máquinas na rede e os seus endereços de rede. O arquivo parece a isto:
# @(#)hosts 1.2 Lachman System V STREAMS TCP source # SCCS IDENTIFICATION 127.0.0.1 localhost tpci 147.120.0.1 merlin merlin.tpci.com 147.120.0.2 freya freya.tpci.com 147.120.0.3 brutus brutus.tpci.com 147.120.0.4 megan megan.tpci.com_ 147.120.0.10 whitney whitney.tpci.com 147.120.0.11 sinbad sinbad.tpci.com 147.120.0.12 pepper pepper.tpci.com
Cada linha contém o nome de máquina local e o seu nome completo com o domínio para que qualquer versão se reconheça pelo sistema operacional. Como as novas máquinas acrescentam-se à rede, as novas linhas acrescentam-se ao arquivo. A máquina local tem duas entradas no arquivo: um para o nome local e um para localhost.
O arquivo/etc/networks mantém uma lista de nomes de rede e os seus endereços. Isto é um arquivo opcional pelo que a maior parte de instalações TCP/IP estejam em questão, e a maior parte de administradores de sistema usam-no só quando os usuários precisam dele. O arquivo/etc/networks deixa-o denominar redes do mesmo modo que máquinas. O seguinte exemplo mostra algumas máquinas de rede SCO bem como duas redes que as máquinas locais frequentemente se unem a. Usando o nome maclean_net como a parte de um identificador de máquina fornecido por um usuário é possível agora porque o sistema operacional pode resolvê-lo ao seu endereço IP por este arquivo.
# @(#)networks 1.2 Lachman System V STREAMS TCP source # SCCS IDENTIFICATION loopback 127 sco 132.147 sco-hq 132.147.128 sco-mfg 132.147.64 sco-engr 132.147.192 sco-slip 132.147.32 sco-tcplab 132.147.160 sco-odtlab 132.147.1 maclean_net 147.50.1 bnr.ca 47
No Dia 6 "Telnet e FTP", examinou o arquivo/etc/services. Inclui a informação sobre todo o TCP e serviços UDP apoiados pelo sistema. Para a rede de mostra e as redes mais pequenas, os valores à revelia são aceitáveis. Estas entradas só modificam-se se um serviço se estiver retirando de TCP/IP, como por exemplo prevenir o acesso de Telnet. O arquivo parece a isto:
# @(#)services 5.1 Lachman System V STREAMS TCP source # # System V STREAMS TCP - Release 4.0 # Network services, Internet style # echo 7/tcp echo 7/udp discard 9/tcp sink null discard 9/udp sink null systat 11/tcp users daytime 13/tcp daytime 13/udp netstat 15/tcp qotd 17/tcp quote chargen 19/tcp ttytst source chargen 19/udp ttytst source ftp 21/tcp telnet 23/tcp smtp 25/tcp mail time 37/tcp timserver time 37/udp timserver rlp 39/udp resource # resource location nameserver 42/tcp name # IEN 116 whois 43/tcp nicname domain 53/tcp nameserver # name-domain server domain 53/udp nameserver mtp 57/tcp # deprecated bootps 67/udp bootps # bootp server bootpc 68/udp bootpc # bootp client tftp 69/udp rje 77/tcp netrjs finger 79/tcp link 87/tcp ttylink supdup 95/tcp hostnames 101/tcp hostname # usually from sri-nic tsap 102/tcp osi-tp0 tp0 #csnet-cs 105/? pop 109/tcp postoffice sunrpc 111/tcp sunrpc 111/udp auth 113/tcp authentication sftp 115/tcp uucp-path 117/tcp nntp 119/tcp readnews untp # USENET News Transfer Protocol ntp 123/tcp ntp 123/udp nb-ns 137/udp nbns netbios-nameservice nb-ns 137/tcp nbns netbios-nameservice nb-dgm 138/udp nbdgm netbios-datagram nb-dgm 138/tcp nbdgm netbios-datagram nb-ssn 139/tcp nbssn netbios-session snmp 161/udp snmp-trap 162/udp bgp 179/tcp # # UNIX specific services # exec 512/tcp biff 512/udp comsat login 513/tcp who 513/udp whod shell 514/tcp cmd # no passwords used syslog 514/udp printer 515/tcp spooler # line printer spooler talk 517/udp ntalk 518/udp efs 520/tcp # for LucasFilm route 520/udp router routed # 521 also timed 525/udp timeserver tempo 526/tcp newdate courier 530/tcp rpc conference 531/tcp chat netnews 532/tcp readnews netwall 533/udp # -for emergency broadcasts uucp 540/tcp uucpd # uucp daemon remotefs 556/tcp rfs_server rfs # Brunhoff remote filesystem pppmsg 911/tcp # PPP daemon listen 1025/tcp listener RFS remote_file_sharing nterm 1026/tcp remote_login network_terminal ingreslock 1524/tcp
O arquivo/etc/hosts.equiv controla o acesso de outras máquinas. O arquivo/etc/ftpusers previne senhas de entrada não autorizadas com nomes do usuário específicos. Ambos os arquivos examinam-se mais detalhadamente nas seções depois hoje intituladas "Equivalência de Usuário" e "FTP Anônimo".
O arquivo/etc/inetd.conf, mencionado antes, controla os processos começados pelo demônio inetd quando as botas de sistema. O default inetd.conf arquivo é perfeito para o sistema de mostra e raramente necessita a modificação. O arquivo aparece como se segue:
# @(#)inetd.conf 5.2 Lachman System V STREAMS TCP source # # System V STREAMS TCP - Release 4.0 # # SCCS IDENTIFICATION ftp stream tcp nowait NOLUID /etc/ftpd ftpd telnet stream tcp nowait NOLUID /etc/telnetd telnetd shell stream tcp nowait NOLUID /etc/rshd rshd login stream tcp nowait NOLUID /etc/rlogind rlogind exec stream tcp nowait NOLUID /etc/rexecd rexecd finger stream tcp nowait nouser /etc/fingerd fingerd #uucp stream tcp nowait NOLUID /etc/uucpd uucpd # Enabling this allows public read files to be accessed via TFTP. #tftp dgram udp wait nouser /etc/tftpd tftpd comsat dgram udp wait root /etc/comsat comsat ntalk dgram udp wait root /etc/talkd talkd #bootps dgram udp wait root /etc/bootpd bootpd echo stream tcp nowait root internal discard stream tcp nowait root internal chargen stream tcp nowait root internal daytime stream tcp nowait root internal time stream tcp nowait root internal echo dgram udp wait root internal discard dgram udp wait root internal chargen dgram udp wait root internal daytime dgram udp wait root internal time dgram udp wait root internal smtp stream tcp nowait mmdf /usr/mmdf/chans/smtpd smtpd /usr/mmdf/chans/smtpsrvr smtp
Com os arquivos fundados como mostrado e os demônios que propriamente carregam, TCP/IP e UDP devem ser tanto ativos e disponíveis. A maior parte de sistemas operacionais necessitam uma reiniciação depois de qualquer modificação do núcleo ou alguns arquivos de configuração, portanto as modificações aos arquivos TCP/IP devem seguir-se de recomposições de sistema.
Quando as botas de sistema, os demônios TCP/IP devem enumerar-se nas mensagens de lançamento mostradas no consolo. Qualquer erro nos lançamentos de demônio mostra-se no monitor ou manda-se ao administrador de sistema. Normalmente, estas mensagens de erro são secretas mas pelo menos indicam a presença de um problema (que é melhor do que você incomodando-se com a informação sobre configuração quando o demônio tem culpa).
Linux é um domínio público versão de UNIX que ficou muito popular. Nesta seção configuro o lançamento de SlakWare de Linux na rede de mostra. Muitas outras versões de Linux usam o mesmo processo de configuração TCP/IP que SlakWare, mas deve verificar notas de lançamento da sua versão qualquer modificação. Linux é uma combinação de BSD UNIX e SVR4 UNIX, mas a maioria dos arquivos de configuração de TCP/IP são idênticos àqueles para SCO UNIX e Solaris 2.4. Antes que comece a configurar os arquivos TCP/IP, entretanto, tem de verificar alguns detalhes do seu sistema de Linux.
A maior parte de versões em rede de Linux confiam no sistema de arquivos/proc, que deve criar-se e montar-se antes que a ligação em rede pode configurar-se e testar-se. A maior parte de versões Linux automaticamente criam o sistema de arquivos/proc quando o sistema operacional se instala, portanto não deveria fazer nada mais do que assegurar-se que se monta propriamente pelo núcleo. O sistema de arquivos/proc é essencialmente um ponto de interface rápido do núcleo para obter a informação sobre rede, também mantendo mesas importantes que se guardam normalmente no subdiretório/proc/net, que se cria pela rotina de instalação de rede.
Se o sistema de arquivos/proc não se criar pelo seu núcleo de Linux, tem de reedificar o núcleo e selecionar a opção/proc. Modifique-se para o diretório de fonte (como/usr/src/Linux) e dirija a rotina de configuração com esta ordem:
make config
Quando lhe perguntam se quer o suporte de procfs, responde sim. Se não se tornar perguntado sobre o suporte de sistema de arquivos/proc, e o diretório/proc não se cria no seu sistema de arquivos, tem de fazer um upgrade do seu núcleo para apoiar a ligação em rede.
Pode assegurar-se que o sistema de arquivos/proc se monta automaticamente no seu sistema de Linux examinando o código de lançamento sobre o núcleo. Para forçar o sistema de arquivos/proc a montar-se automaticamente, modifique o arquivo/etc/fstab e acrescente a ordem de monte lá. Verifique as entradas em/etc/fstab para ver se há uma linha como isto:
none /proc proc defaults
Se nenhuma tal linha existir, deve acrescentá-lo aos conteúdos do arquivo/etc/fstab usando um editor ASCII.
Outro passo que deve tomar antes de configurar TCP/IP sob Linux deve estabelecer o hostname. Para estabelecer o hostname, use esta ordem:
hostname name
O nome é o nome de sistema que quer para a sua máquina local. Se um hostname já não se estabelecer, pode estabelecer o nome de domínio cheio usando esta ordem:
hostname freya.tpci.com
Isto estabelece o hostname em freya na rede de mostra. Quando define o nome da máquina local com a ordem de hostname, uma entrada faz-se normalmente no arquivo/etc/hosts. Deve verificar que o seu nome de máquina aparece naquele arquivo.
O seguinte passo na configuração de TCP/IP na sua máquina de Linux deve fazer o interface de rede acessível. Isto faz-se com a ordem de ifconfig. Quando dirigido, ifconfig essencialmente faz a camada de rede do trabalho central com o interface de rede dando-lhe um endereço IP. Quando a interface é ativa, o núcleo pode enviar e receber dados pela interface.
Há várias interfaces que tem de fundar para a sua máquina de Linux, inclusive o motorista de laço de retorno (se já não se criar) e a interface de Ethernet. A ordem de ifconfig usa-se para cada interface à sua vez. O formato geral da ordem de ifconfig é isto:
ifconfig interface_type IP_Address
O interface_type é o nome de driver de dispositivo da interface (como lo do laço de retorno e eth de Ethernet). O IP_Address é o endereço IP usado por aquela interface.
Quando a ordem de ifconfig se dirigiu e a interface é ativa, pode usar a ordem de via de acrescentar ou retirar vias na tabela de roteamento do núcleo. Isto é necessário para permitir à máquina local encontrar outras máquinas. O formato geral da ordem de via é isto:
route add|del IP_Address
Acrescente ou del especifica-se para acrescentar ou retirar a via da tabela de roteamento do núcleo, e IP_Address é a via remota que se afeta.
Pode expor os conteúdos atuais da tabela de roteamento do núcleo em qualquer momento entrando na via de ordem absolutamente sozinho na linha de comando. Por exemplo, se o seu sistema se funda com só o motorista de laço de retorno, vê uma produção como isto:
$ route Kernel Routing Table Destination Gateway Genmask Flags MSS Window Use Iface loopback * 255.0.0.0 U 1936 0 16 lo
As colunas importantes são o nome de destino, que mostra o nome do objetivo configurado (neste caso, laço de retorno), a máscara a usar-se (Genmask), e a interface (Iface, neste caso/dev/lo). Pode forçar a via a expor endereços IP em vez de nomes simbólicos usando a opção-n:
$ route -n Kernel Routing Table Destination Gateway Genmask Flags MSS Window Use Iface 127.0.0.1 * 255.0.0.0 U 1936 0 16 lo
Uma configuração de rede de Linux típica inclui um par de interfaces. A interface de laço de retorno deve existir em cada máquina. Uma vez que o motorista de laço de retorno configura-se, pode acrescentar o motorista de Ethernet da rede. Começa instalando o motorista de laço de retorno.
A interface de laço de retorno deve existir em cada máquina. A interface de laço de retorno sempre tem o endereço IP 127.0.0.1, portanto o arquivo/etc/hosts deve ter uma entrada desta interface. O motorista de laço de retorno poderia ter-se criado pelo núcleo durante a instalação de software, portanto verifique o arquivo/etc/hosts uma linha semelhante a isto:
localhost 127.0.0.1
Se a linha existir, o motorista de laço de retorno está no lugar. Assegure-se que a linha não tem um sinal de libra à frente dele, que comentaria ele fora. Também pode usar a utilidade ifconfig para expor toda a informação que sabe sobre o motorista de laço de retorno. Use esta ordem:
ifconfig lo
Deve ver várias linhas da informação sobre o motorista de laço de retorno. Se adquirir uma mensagem de erro, o motorista de laço de retorno não existe.
Se a interface de laço de retorno não estiver no arquivo/etc/hosts, tem de criá-lo com a ordem de ifconfig. A ordem
ifconfig lo 127.0.0.1
cria a linha necessária em/etc/hosts.
Depois deve acrescentar o motorista de laço de retorno às tabelas de roteamento centrais com uma destas duas ordens:
route add 127.0.0.1
ou
route add localhost
Não importa que ordem usa porque ambos eles se referem à mesma coisa. A ordem essencialmente diz ao núcleo que pode usar a via para dirigir-se 127.0.0.1 ou ao nome localhost.
Como uma verificação rápida que tudo é correto com o motorista de laço de retorno, pode usar a ordem de silvo de verificar o encaminhamento. Se emite qualquer destas duas ordens:
ping localhost
ou
ping 127.0.0.1
deve ver a produção como isto:
PING localhost: 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0. ttl=255 time=1 ms 64 bytes from 127.0.0.1: icmp_seq=1. ttl=255 time=1 ms 64 bytes from 127.0.0.1: icmp_seq=2. ttl=255 time=1 ms 64 bytes from 127.0.0.1: icmp_seq=3. ttl=255 time=1 ms 64 bytes from 127.0.0.1: icmp_seq=4. ttl=255 time=1 ms 64 bytes from 127.0.0.1: icmp_seq=5. ttl=255 time=1 ms 64 bytes from 127.0.0.1: icmp_seq=6. ttl=255 time=1 ms 64 bytes from 127.0.0.1: icmp_seq=7. ttl=255 time=1 ms ^C --- localhost PING Statistics --- 7 packets transmitted, 7 packets received, 0% packet loss round-trip (ms) min/avg/max = 1/1/1
O progresso de ordem de silvo interrompeu-se pelo usuário emitindo um Ctrl+C depois de sete transmissões. Pode deixar tantas transmissões como quer vão por. Se não adquire nenhuma resposta da ordem de silvo, então o endereço 127.0.0.1 ou o nome localhost não se reconheceram e deve verificar os arquivos de configuração e entrada de via novamente.
Se a olhada de arquivos de configuração correta e a ordem de via se aceitou propriamente, mas a ordem de silvo ainda não produz os resultados próprios, tem um problema mais sério. Em alguns casos, o núcleo de rede não se configura propriamente e o processo inteiro deve conduzir-se novamente. Às vezes uma má combinação em versões de motoristas centrais e utilidade de rede pode causar desconexões com a rotina de silvo, também.
Depois, tem de acrescentar os motoristas de Ethernet ao núcleo. Pode executar o mesmo processo de configuração com o motorista de Ethernet. Para começar, funda a interface de Ethernet usando ifconfig. Para fazer a interface ativa, use a ordem de ifconfig com o nome de dispositivo de Ethernet e o seu endereço IP local. Por exemplo, use a ordem
ifconfig eth0 147.120.0.2
fundar a máquina local com o endereço IP 147.120.0.2. A interface é ao dispositivo Ethernet/dev/eth0. Não tem de especificar a máscara de rede com a ordem de ifconfig porque deduz o valor próprio do endereço IP introduzido. Se quiser fornecer o valor de máscara de rede explicitamente, acrescente-o à linha de comando com a palavra-chave netmask:
ifconfig eth0 147.120.0.2 netmask 255.255.255.0
Então pode verificar a interface com a ordem de ifconfig usando o nome de interface:
$ ifconfig eth0
eth0 Link encap 10Mps: Ethernet Hwaddr
inet addr 147.123.20.1 Bcast 147.123.1.255 Mask 255.255.255.0
UP BROADCAST RUNNING MTU 1500 Metric 1
X packets:0 errors:0 dropped:0 overruns:0
TX packets:0 errors:0 dropped:0 overruns:0
Poderia ter notado na produção da ordem que o endereço de transmissão se estabeleceu baseado no endereço IP da máquina local. Isto usa-se por TCP/IP para acessar todas as máquinas na rede local ao mesmo tempo. O tamanho de Message Transfer Unit (MTU) estabelece-se normalmente no valor máximo de 1500 apoiado por redes de Ethernet.
Depois, tem de acrescentar uma entrada nas tabelas de roteamento centrais que avisa o núcleo sobre o endereço de rede da máquina local. Isto deixa-o enviar dados a outras máquinas na mesma rede. O endereço IP que se usa com a ordem de via de fazer isto não é o endereço IP da sua máquina local, mas aquela da rede no conjunto sem o identificador local. Para estabelecer a rede local inteira ao mesmo tempo, o - a opção líquida da ordem de via usa-se. Em caso dos endereços IP mostrados anteriormente, a ordem seria como se segue:
route add -net 147.120.0
Isto acrescenta que todas as máquinas na rede identificada pela rede se dirigem 147.120.0 à lista do núcleo de máquinas acessíveis. Se não o fez este caminho, teria de entrar manualmente no endereço IP de cada máquina na rede. Um método alternativo deve usar o arquivo/etc/networks, que pode conter uma lista de nomes de rede e os seus endereços IP. Se tem uma entrada no arquivo/etc/networks de maclean_net chamado de uma rede, pode acrescentar a rede inteira à tabela de roteamento com esta ordem:
route add maclean_net
Uma vez que a via acrescentou-se às tabelas de roteamento centrais, pode provar a interface de Ethernet silvando outra máquina, como o servidor SCO que configurou antes.
Agora pode configurar os arquivos usados por TCP/IP, como fez para o SCO UNIX o sistema configurado antes. Como muitos dos detalhes destes arquivos são idênticos aos mostrados no SCO UNIX a seção, omito muitos detalhes aqui.
O arquivo/etc/hosts usa-se para manter os endereços de rede e nomes simbólicos, bem como o motorista de laço de retorno. O endereço de conexão de laço de retorno enumera-se normalmente como o laço de retorno de nome de máquina ou localhost. O arquivo/etc/hosts compõe-se do endereço de rede em uma coluna e o nome simbólico no outro. Embora os endereços de rede possam especificar-se no formato decimal, octal, ou hexadecimal, o decimal é a forma o mais comumente usada (e o uso dos outros pode ser francamente confuso). Pode especificar mais de um nome simbólico em uma linha separando os nomes com carateres espaciais brancos (espaços ou etiquetas). O servidor Linux/etc/hosts arquivo na rede de mostra parece a isto (lembre-se de que o servidor de Linux se chama freya e tem um endereço IP de 147.120.0.2):
# network host addresses 127.0.0.1 localhost tpci 147.120.0.2 freya freya.tpci.com 147.120.0.1 merlin merlin.tpci.com 147.120.0.3 brutus brutus.tpci.com 147.120.0.4 megan megan.tpci.com_ 147.120.0.10 whitney whitney.tpci.com 147.120.0.11 sinbad sinbad.tpci.com 147.120.0.12 pepper pepper.tpci.com
Este arquivo é essencialmente idêntico àquele dos SCO UNIX o servidor, porque todas as máquinas na rede têm os mesmos nomes e endereços. Como o nome de localhost se define a freya, o servidor de Linux sabe que entrada no arquivo se refere.
O arquivo/etc/protocols identifica todos os protocolos de transporte disponíveis no servidor de Linux e dá os seus respetivos números de protocolo. Todos os sistemas têm este arquivo, embora algumas entradas pudessem comentar-se fora para prevenir a intrusão não desejada ou o abuso. Com Linux o arquivo/etc/protocols não se modifica normalmente pelo administrador. Em vez disso, o arquivo mantém-se pelo software de ligação em rede e atualiza-se automaticamente como parte de procedimentos de instalação. O arquivo contém o nome de protocolo, o seu número e qualquer pseudônimo que pode usar-se para aquele protocolo. O arquivo/etc/protocols do servidor de Linux mostra-se aqui:
# protocols ip 0 IP # internet protocol, pseudo protocol number icmp 1 ICMP # internet control message protocol igmp 2 IGMP # internet group multicast protocol ggp 3 GGP # gateway-gateway protocol tcp 6 TCP # transmission control protocol pup 12 PUP # PARC universal packet protocol udp 17 UDP # user datagram protocol idp 22 IDP # WhatsThis? raw 255 RAW # RAW IP interface
Os conteúdos exatos do arquivo/etc/protocols no seu sistema poderiam diferenciar-se um pouco do arquivo mostrado aqui, mas os números de protocolo e os nomes são provavelmente o mesmo. Poderiam haver protocolos adicionais enumerados, dependendo da sua versão do software de ligação em rede e Linux.
O arquivo de configuração TCP/IP último usado na maior parte de sistemas de Linux identifica serviços de rede existentes. Isto é/etc/services. Como com o arquivo/etc/protocols, este arquivo não se modifica normalmente por um administrador mas mantém-se pelo software quando instalado ou configurado. O arquivo/etc/services está no formato de ASCII e compõe-se do nome de serviço, um número de porto e o tipo de protocolo. O número de porto e o tipo de protocolo separam-se por um golpe. Qualquer nome de pseudônimo de serviço opcional segue. Um extrato curto de uma amostra/etc/services arquivo (o arquivo é normalmente bastante longo) mostra-se depois:
# network services echo 7/tcp echo 7/udp discard 9/tcp sink null discard 9/udp sink null ftp 21/tcp telnet 23/tcp smtp 25/tcp mail mailx tftp 69/udp # specific services login 513/tcp who 513/udp whod
A maior parte de arquivos/etc/services têm muitas outras linhas, porque um largo número de serviços TCP/IP se apoia pela maior parte de versões de Linux. Como nunca tem de incomodar-se com os conteúdos deste arquivo, não precisa de verificar cada entrada.
SunSoft Solaris 2.4 é um Sistema V versão do Lançamento 4 de UNIX, portanto se configura muito como o SCO UNIX sistema configurado antes. A interface de Ethernet e os drivers ligam-se no núcleo quando o sistema operacional se carrega, portanto nenhuma da configuração de dispositivo deveria modificar-se. Quando o sistema operacional de Solaris se carrega, a parte do procedimento de configuração pede o nome do servidor e o seu endereço IP (na rede de mostra o nome é brutus e o endereço IP é 147.120.0.3).
Estas colocações então colocam-se no arquivo/etc/hosts. Pode usar qualquer editor ASCII para entrar no resto das máquinas na rede de mostra para concluir o arquivo/etc/hosts, como mostrado aqui:
# # Internet Host Table # 127.0.0.1 localhost 147.120.0.3 brutus brutus.tpci.com loghost 147.120.0.1 merlin merlin.tpci.com 147.120.0.2 freya freya.tpci.com 147.120.0.4 megan megan.tpci.com_ 147.120.0.10 whitney whitney.tpci.com 147.120.0.11 sinbad sinbad.tpci.com 147.120.0.12 pepper pepper.tpci.com
O arquivo/etc/networks no servidor SPARCstation é semelhante a isto no SCO UNIX a máquina:
loopback 127 sco 132.147 sco-hq 132.147.128 sco-mfg 132.147.64 sco-engr 132.147.192 sco-slip 132.147.32 sco-tcplab 132.147.160 sco-odtlab 132.147.1 maclean_net 147.50.1 bnr.ca 47
Em alguns casos, as entradas adicionais poderiam existir por razões de compatibilidade para trás. Pode acrescentar tantas entradas como quer ao arquivo/etc/networks.
Como com Linux, o/etc/services e os arquivos/etc/protocols deixam-se em paz, porque se fornecem com todos os detalhes de configuração já introduzidos. Estes arquivos podem modificar-se se tiver de inutilizar um determinado serviço (por razões de segurança, por exemplo), mas na maioria dos casos se deixam melhor não modificados.
O SPARCstation forneceu-se com um conector RJ45 à rede de Ethernet, portanto usei um transceptor para converter de RJ45 a um conector BNC. A passagem pelo transceptor converte a conexão de Ethernet ao modo do qual precisa. Posso ter conectado a rede inteira com conectores RJ45, mas então precisaria de um cubo da roda para unir todos os conectores RJ45 a (como discuti no Dia 1, "Sistemas abertos, Padrões e Protocolos").
Depois que o SPARCstation une-se à rede, pode tentar silvar uma máquina remota. Se adquirir uma resposta própria, tudo é bem e pode mudar à configuração de outras máquinas. Se houver um problema com o silvo, tem de verificar que todos os arquivos são corretos, que o endereço IP é válido, e que o transceptor de rede funciona propriamente.
O Windows NT está disponível tanto em versões de estação de trabalho como em servidor. Hoje configuro a versão de servidor da rede de mostra. Uso o Servidor de Windows NT 3.51 no sistema de mostra embora o Windows NT 4.0 execute em quase exatamente o mesmo caminho. (O Windows NT 4.0 ainda esteve na beta como se escrevia este livro; as únicas modificações evidentes foram por causa das modificações GUI para parecer-se com o Windows 95 GUI.) Embora TCP/IP se proveja do Windows NT, não se instala como o protocolo de rede à revelia. Em vez disso, IPX/SPX e NetBEUI instalam-se como protocolos à revelia. Para configurar TCP/IP, tem de extrair o software TCP/IP dos meios de comunicação de distribuição se já não se tenha instalado.
Pode verificar a presença do software TCP/IP abrindo a janela Network Settings dentro do Painel de controle. Esta janela mostra-se na Figura 9.2. A lista de rolo de papel no fundo partiu a esquina tem uma lista de todos os componentes instalados. Se não incluir uma entrada como Protocolo de TCP/IP, o software TCP/IP não se instala. Para instalar o software TCP/IP, clique no botão Add Software na janela Network Settings.
A figura 9.2. A tela Windows NT Network Settings mostra todos os componentes que se instalam.
Quando seleciona Acrescentam o software, os cheques de sistema de todos os componentes instalados e disponíveis (que pode levar um tempo), logo expõe as janelas mostradas na Figura 9.3. Depois de selecionar TCP/IP a instalar-se, pode selecionar os componentes TCP/IP específicos e qualquer outro serviço TCP/IP que quer instalar da janela mostrada na Figura 9.4.
A figura 9.3. Pode acrescentar o software TCP/IP ao seu sistema de Windows NT por esta janela.
A figura 9.4. Selecione os componentes do software Windows NT TCP/IP que quer instalar desta janela.
A versão de servidor do Windows NT oferece várias opções de configuração TCP/IP e extra serviços. Os mostrados na Figura 9.4 incluem o seguinte:
O clique na Tecla OK começa o processo de instalação, com o Windows NT que o incita para o CD-ROM de distribuição ou discos como necessário. Depois que o software TCP/IP instala-se, tem de reiniciar a máquina e logo a janela Network Settings deve mostrar os protocolos TCP/IP no lugar.
Se instalou um adaptador de rede quando o software de sistema operacional de Windows NT se carregou, o cartão de adaptador de rede também deve mostrar na lista de componentes instalados na janela Network Settings. Se tiver de acrescentar um cartão de adaptador de rede ao sistema, pode acrescentar-se pela janela Network Settings, também. O botão Add Adapter começa a rotina de instalação, que incita para o tipo do cartão de adaptador de rede, então as colocações no cartão do endereço de memória e IRQ. Depois que a placa de rede configurou-se, os drivers carregam-se pelo Windows NT, então uma reiniciação de sistema põe o cartão à disposição.
A janela Network Settings deixa-o configurar cada componente do software TCP/IP instalado no servidor de Windows NT. Pode mudar o nome de máquina e nome de domínio da janela Network Settings clicando no botão Change ao lado daqueles itens em cima da tela. Só um administrador pode modificar a máquina e nomes de domínio.
Se destacar o Protocolo TCP/IP na janela Network Settings, então clique no botão Configure, vê a janela TCP/IP Configuration mostrada na Figura 9.5. Isto deixa-o fornecer o endereço IP da máquina local (assunção que não se destina por meio do uso de outro serviço como DHCP ou VITÓRIAS). Se estiver usando um DHCP ou servidor de VITÓRIAS (outro do que a máquina configura agora), o endereço IP daquele servidor deve introduzir-se nesta tela.
A figura 9.5. O endereço IP da máquina local introduz-se nesta janela.
Se estiver usando DNS na sua rede, selecione o botão DNS na janela TCP/IP Configuration. Isto expõe a janela DNS Configuration. Esta janela deixa-o especificar o hostname e o nome de domínio do servidor DNS bem como qualquer especificação sobre a ordem de pesquisa de servidor DNS. Se não estiver usando DNS, pode deixar esta janela como é. Como não funda um servidor DNS no momento atual, pode deixar esta janela em paz. Finalmente, o botão Advanced na janela TCP/IP Configuration deixa-o selecionar máscaras de subrede e endereços IP de portão, se necessário.
Da janela Network Settings, deve verificar os bindings de rede para assegurar-se que TCP/IP se usa para comunicações sobre a rede local. Selecione o botão de Bindings na janela Network Settings para expor a janela de Network Bindings, mostrada na Figura 9.6.
A figura 9.6. A janela de Network Bindings mostra todos os bindings de rede configurados no sistema.
Se TCP/IP se configurar propriamente, vê o protocolo TCP/IP atado ao cartão de adaptador de rede. A atadura deve permitir-se, como mostrado por um lightbulb amarelo para a esquerda do nome obrigatório. Se não se permitir, clique no botão Enable no fundo da janela. Se outros protocolos, como IPX/SPX, se atarem à mesma placa de rede e se permitirem mas não precisaram, deve inutilizá-los. Só deixe os bindings de que precisa permitiu.
Depois que a informação sobre configuração verificou-se, deve clicar em Update ou OK e permitir a Windows NT concluir a configuração para você. Deveria fornecer os discos de fonte ou CD-ROM se o novo software é necessário. Depois que a configuração é completa, tem de reiniciar a máquina para efetuar qualquer modificação.
Para verificar que a configuração trabalha propriamente, deve dirigir a ordem de silvo e tentar silvar outra máquina na rede. A utilidade de silvo é baseada no DOS e pode encontrar-se normalmente abaixo de WINNT35\SYSTEM32. Comece uma sessão de DOS e emita a ordem de silvo, seguida de um endereço IP conhecido. Se o remoto se silvar com sucesso, a sua instalação e a configuração trabalham.
Testar a configuração TCP/IP em algum de quatro servidores configurados é franco. Comece usando o silvo em cada máquina para assegurar que o software fala com o hardware de rede. Infelizmente, um silvo bem sucedido da máquina local não sempre significa que a rede se está acessando propriamente; simplesmente significa que o software de rede processa o pedido. Para testar o próprio interface de rede, silve outras máquinas na rede. No seguinte exemplo, o merlin é o anfitrião local e o Sinbad é uma máquina de DOS que dirige software de ftp PC/TCP (que vê amanhã):
$ ping merlin PING localhost (147.120.0.1): 56 data bytes 64 bytes from localhost (147.120.0.1): icmp_seq=0 ttl=255 time=0 ms 64 bytes from localhost (147.120.0.1): icmp_seq=1 ttl=255 time=0 ms 64 bytes from localhost (147.120.0.1): icmp_seq=2 ttl=255 time=0 ms 64 bytes from localhost (147.120.0.1): icmp_seq=3 ttl=255 time=0 ms 64 bytes from localhost (147.120.0.1): icmp_seq=4 ttl=255 time=0 ms --- localhost ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 0/0/0 ms $ ping sinbad PING sinbad (147.120.0.11): 56 data bytes 64 bytes from localhost (147.120.0.1): icmp_seq=0 ttl=255 time=20 ms 64 bytes from localhost (147.120.0.1): icmp_seq=1 ttl=255 time=20 ms 64 bytes from localhost (147.120.0.1): icmp_seq=2 ttl=255 time=50 ms 64 bytes from localhost (147.120.0.1): icmp_seq=3 ttl=255 time=30 ms 64 bytes from localhost (147.120.0.1): icmp_seq=4 ttl=255 time=40 ms --- pepper ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 20/32/50 ms
O primeiro teste mostra que o software se configura propriamente. A ordem de silvar merlin resultou em uma conversão dentro do arquivo/etc/hosts para reconhecer a instrução como a entrada localhost. Depois de verificar a conexão local, a máquina remota tenta-se. A viagem de ida e volta bem sucedida dos pacotes indica que o remoto trabalha propriamente, e que a rede é funcional. Naturalmente, isto só trabalha se a máquina remota se tenha carregado com o software TCP/IP e for ativa.
Se a ordem de silvo de localhost falhou, o software configurou-se provavelmente incorretamente, ou o hardware não se acessou propriamente. Em primeiro lugar, verifique os conectores nas placas de rede, porque têm um hábito aborrecido de trabalhar soltos. Depois, verifique a configuração de rede (IRQ, endereço e tipo do adaptador), seguido dos arquivos de configuração, como mostrado antes. Se tudo parecer correto e a máquina remota responde a sua própria ordem de silvo propriamente, há um problema com a compatibilidade de software.
A ordem de posição de rede netstat é útil para controlar a realização da rede e descobrir problemas. Os administradores de sistema de TCP/IP frequentemente usam as opções-i,-m, e-s. Ver o Dia 13, "Arranjando-se e Investigando TCP/IP", para mais informação sobre resolução de problemas.
Um problema comum é a falta de bastantes buffers de CORRENTES, que faz que a um processo suspenda ou uma conexão não para terminar por nenhuma razão evidente. O tamanho do buffer de CORRENTES e a sua posição atual pode verificar-se com a ordem netstat-m:
$ netstat -m
streams allocation:
config alloc free total max fail
streams 292 78 214 145 79 0
queues 1424 360 1064 327 364 0
mblks 5077 197 4880 3189 206 0
dblks 4062 197 3865 3167 205 0
class 0, 4 bytes 652 51 601 357 53 0
class 1, 16 bytes 652 1 651 284 3 0
class 2, 64 bytes 768 8 760 2158 15 0
class 3, 128 bytes 872 104 768 237 106 0
class 4, 256 bytes 548 21 527 90 22 0
class 5, 512 bytes 324 12 312 13 13 0
class 6, 1024 bytes 107 0 107 1 1 0
class 7, 2048 bytes 98 0 98 1 1 0
class 8, 4096 bytes 41 0 41 26 1 0
total configured streams memory: 1183.09KB
streams memory in use: 44.66KB
maximum streams memory used: 58.28KB_
O número na coluna reprovar deve ser 0 em cada linha; de outra maneira, há um problema com o montante do buffer alocado. Para modificar o número de buffers de CORRENTES alocados, as variáveis centrais devem modificar-se e o núcleo religa-se. Como uma regra geral, se houver problemas com as CORRENTES existentes armazenam em buffer tamanhos, aumentam o número em 50 por cento. Se isto não resolve o problema, aumento em mais 50 por cento.
Para testar totalmente o sistema TCP/IP, use Telnet ou FTP para logar e transferir arquivos da máquina à máquina. Como esta duas utilidade é os usuários mais comuns de TCP/IP (a menos que NIS ou o NFS sejam ativos), ajudam a mostrar qualquer problema com as nomeações de porto, serviços contanto que, ou mapeamento de nome.
A maior parte de sistemas UNIX apoiam ttys pseudo (terminais falsos) para permitir a máquinas externas usar Telnet e rlogin do acesso à máquina local. Sem um tty pseudo, a máquina remota não pode estabelecer uma sessão.
O SCO UNIX sistema, por exemplo, configura 32 ttys pseudo à revelia, que devem ser abundância de redes classificadas pequenas e moderadas. (Lembre-se de que 32 ttys pseudo permitem 32 sessões de usuários remotos.) A soma ou a eliminação de ttys pseudo podem fazer-se por uma utilidade de configuração ou, em caso de SCO UNIX, com o mkdev ptty ordem. Não há vantagem útil ganha reduzindo drasticamente o número de ttys pseudo em pequenas redes. ttys pseudo deve reconfigurar-se depois que TCP/IP instalou-se e trabalha corretamente.
A equivalência de usuário deixa um usuário rlogin a outra máquina com a mesma informação sobre conta, sem entrar em uma senha. Isto é útil quando um usuário deve registrar em log em outra máquina frequentemente, evitando o processo de senha de entrada da velocidade e reduzindo o número de processos que correm no remoto.
Para permitir a equivalência de usuário, UNIX precisa que o usuário exista em ambas as máquinas e que as entradas em dois arquivos de configuração combinam. O arquivo/etc/passwd, que controla o acesso total à máquina, deve ter uma entrada do nome do usuário do usuário em ambas as máquinas. Um de dois arquivos de configuração também deve ter informação sobre o usuário.
Se o arquivo .rhosts se usar, a equivalência de usuário só estabelece-se para contas especificamente denominadas no arquivo. O arquivo .rhosts normalmente reside no diretório de raiz e tem uma entrada por linha, especificando o nome de máquina remoto e a carteira de identidade de usuário. Um arquivo .rhosts parece a isto:
# .rhosts file for brutus.com merlin tparker merlin ychow merlin bsmallwood pepper etreijs pepper tparker freya rmaclean
Com esta configuração, o usuário tparker, na máquina remota merlin, pode logar à máquina local como tparker só. Um usuário pode permitir o acesso a uma conta pelo outro criando um arquivo .rhosts no seu diretório padrão.
Se o arquivo hosts.equiv se usar (que normalmente reside no / etc. o diretório), a equivalência de usuário é válida para qualquer conta em ambas as máquinas exceto a raiz. Se o arquivo hosts.equiv contivesse só um nome de máquina, permitiriam a qualquer usuário válido naquela máquina a equivalência de usuário (exceto a raiz). A máquina chama-se um anfitrião confiado.
Infelizmente, este tipo do acesso põe problemas de segurança consideráveis, portanto deve usar-se só abaixo de condições estritamente controladas ou muito fiáveis. Um problema principal consiste em que um usuário pode logar como qualquer outro usuário válido no sistema remoto sem usar uma senha. Uma amostra hosts.equiv arquivo parece a isto:
# hosts.equiv for brutus.com merlin tparker pepper freya rmaclean
Neste exemplo, qualquer usuário no sistema remoto (pimentão) pode logar como qualquer usuário válido (exceto a raiz) na máquina local, sem usar uma senha. Só o usuário tparker, na máquina remota merlin, pode logar como qualquer usuário de sistema válido (exceto a raiz) na máquina local. O potencial do abuso da equivalência de usuário com este tipo do acesso é alto, embora possa ser prático para o acesso a utilidade específica ou aplicações.
Se tanto .rhosts como hosts.equiv existirem com entradas da mesma máquina e carteira de identidade de usuário, a entrada do arquivo hosts.equiv usa-se para determinar a equivalência do usuário. Lembre-se de que tanto para .rhosts como para hosts.equiv, combinando com entradas de usuário deve existir no arquivo/etc/passwd.
A configuração de equivalência de usuário pode causar problemas de administradores de sistema que se culpam frequentemente o software de rede. Também, alguns usuários poderiam querer permitir entradas específicas por um usuário em um sistema remoto sem ter a subvenção de administrador de sistema privilégios abertos.
Para ilustrar as entradas mais claramente, um exemplo concreto poderia ajudar. Suponha que o usuário ychow, no pimentão de máquina, queira acessar a máquina merlin como tanto ychow como shortie sem usar senhas. (Em outras palavras, ychow no pimentão é equivalente a ychow e shortie em merlin.) Há vários métodos de configurar o sistema para permitir isto. O administrador de sistema pode criar um arquivo .rhosts no diretório de raiz que tem as seguintes entradas:
pepper ychow pepper shortie
Isto só permite ychow (no pimentão) logar como ychow, sem acesso como shortie a menos que shortie se logue ao pimentão, também. Isto não é o que se necessita. Uma entrada no arquivo hosts.equiv como isto
pepper ychow
não resolve o problema também porque ychow pode logar agora como qualquer usuário válido em merlin. A solução disto necessita cada usuário que quer permitir a ychow acessar os seus diretórios para colocar um arquivo .rhosts nos seus diretórios padrão. Na rede de mostra, tanto os diretórios padrão de ychow como shortie em merlin teriam as mesmas entradas.
O usuário ychow pode logar agora a merlin a utilização de uma das seguintes ordens:
rlogin merlin
ou
rlogin merlin -l shortie
A última ordem registra em log ychow em como o usuário shortie equivalente. O primeiro conserva a mesma carteira de identidade de senha de entrada. Observe que o arquivo .rhosts reside nos diretórios padrão dos usuários que querem permitir o acesso de usuário remoto.
O FTP anônimo permite a usuários de outras posições acessar um sistema sem logar. Obtêm o FTP pronto como de hábito mas entram anônimo como o nome do usuário. Na maior parte de sistemas, uma senha pode ser algo, embora a convenção dite que o nome do usuário do usuário se forneça para seguir a pista de objetivos. Não há cheque dos nomes, de qualquer modo. Uma vez logou ao FTP anônimo, os usuários podem pesquisar por diretórios públicos e recuperar arquivos que residem lá. O FTP anônimo é excelente para distribuir a informação ao grande público, mas o seu acesso aberto tem preocupações de segurança acompanhantes.
Quando um usuário loga à conta de FTP anônima, UNIX invoca um processo chamou chroot, que restringe o usuário de mover-se fora do diretório padrão. A dependência de chroot precisa que alguns arquivos de configuração de sistema (inclusive uma cópia do/etc/passwd e arquivos/etc/group) residam nos diretórios de FTP anônimos.
Configurar um sistema UNIX do FTP anônimo implica o estabelecimento de um sistema diretivo público e a modificação de permissões de arquivo de prevenir o acesso não desejado a outras partes do sistema de arquivos. Também, uma conta anônima se cria usando o ftp de nome do usuário. O FTP anônimo normalmente usa o diretório padrão de ftp de usuário criado quando o usuário se gera.
Para fundar o acesso a FTP anônimo, crie um usuário chamado ftp. Com sistemas UNIX, isto executa-se normalmente com mkuser chamado de uma escrita ou uma utilidade de sistema. Alternativamente, o usuário pode acrescentar-se ao arquivo/etc/passwd. Um grupo chamou o ftp deve existir ou criar-se. Uma vez que o diretório padrão do ftp de usuário existe, modifique o seu usuário e identidade de grupo ao ftp (usando o mostrado e ordens de chgrp).
A assunção do ftp de carteira de identidade de usuário criou-se e o diretório padrão é/usr/ftp, os passos para seguir mostram-se aqui. (Os comentários mostrados depois do sinal de libra são com objetivos de descrição só e não têm de introduzir-se.)
$ cd /usr/ftp # change to the home directory $ chmod 555 . # set file permissions to r-x $ chown ftp . # change the owner to ftp $ chgrp ftp . # change the group to ftp $ mkdir pub # create public directory (see below) $ chmod 777 pub # set pub dir permissions as rwx $ mkdir bin # create bin dir for executables $ cd bin $ chmod 555 bin # set bin dir to r-x $ cp /bin/sh /bin/ls . $ cd .. $ mkdir etc # create etc dir for passwd file $ chmod 555 etc # set etc dir to r-x $ cd etc $ cp /etc/passwd /etc/group . $ chmod 444 passwd group $ cd ..
Se quiser criar subdiretórios abaixo do diretório padrão do usuário anônimo ao acesso, assegurar que têm a propriedade correta, também. É prática comum para criar um diretório chamado ftp/bar para transferir de arquivos para o sistema. As permissões de arquivo de jogo para que o usuário não possa sair a estrutura de diretório padrão. No exemplo prévio, todos os diretórios exceto o bar fazem-se para ler e só realizar. O exemplo copiou a concha e utilidade que se inclina na estrutura diretiva de FTP portanto o usuário anônimo pode acessá-los. Outra utilidade pode copiar-se se desejado.
O/etc/passwd e os arquivos/etc/group devem copiar-se em um diretório chamado etc. (em baixo do diretório padrão de usuário de ftp) para permitir a chroot funcionar propriamente. Recomenda-se fortemente que estes arquivos se editem para retirar qualquer outra informação de usuário; é possível que um usuário anônimo possa acessar e analisar os arquivos da informação sobre o sistema local, levando a um assalto mal acolhido. Retire todos os usuários do arquivo/etc/passwd exceto raiz, demônio, uucp, e as entradas de ftp. Semelhantemente pode o arquivo/etc/group para retirar todos exceto estas entradas.
Para ajudar a prevenir o acesso não desejado, o arquivo etc/ftpusers pode criar-se para conter nomes do usuário que resultam na desconexão imediata. Este arquivo deve ter entradas da raiz e uucp como um mínimo.
O Servidor de Windows NT permite o FTP anônimo por um mecanismo diferente (porque não é UNIX). Para permitir o FTP anônimo no servidor de Windows NT na rede de mostra, tem de permitir o servidor de FTP. O software do servidor deve instalar-se como mostrado antes. Durante a instalação receberá provavelmente um aviso sobre a insegurança de usar o FTP para transferir senhas sobre a sua rede. Contudo, a menos que possa instalar um esquema de autenticação das suas senhas, isto é uma maldade necessária para permitir o acesso a FTP à máquina de Windows NT.
Para configurar o software de servidor de FTP, seleciona o item de servidor de FTP da janela Network Settings mostrada na Figura 9.2, logo clica no botão Configure. Isto expõe a janela Service de FTP mostrada na Figura 9.7. Pode ajustar o número de sessões permitidas bem como o intervalo de intervalo usando as opções em cima desta janela.
A figura 9.7. Use esta janela para alterar o comportamento do servidor de FTP.
Poderia notar que a parte de fundo da tela o deixa fazer que o servidor de FTP permita conexões anônimas. Pode estabelecer a senha de entrada anônima e senha se quiser. Isto permite a usuários que não estão na lista de Usuários de Windows NT autorizada para transferir arquivos da máquina de Windows NT. É uma boa ideia de restringir o acesso a um subdiretório onde não há arquivos sensíveis disponíveis.
Pode controlar o comportamento do sistema de servidor de FTP pelo ícone Server de FTP no Painel de controle. Isto expõe uma janela como um mostrado na Figura 9.8, que enumera todos os usuários ativos. Os botões Disconnect e Disconnect All no fundo da janela podem usar-se para forçar usuários da máquina de Windows NT.
A figura 9.8. A janela Server de FTP mostra a usuários que usam atualmente o FTP.
Algumas colocações de segurança podem controlar-se pela janela Server de FTP clicando no botão de segurança. Isto expõe a janela mostrada na Figura 9.9. Os Lidos e Escrevem que a opções lhe permitam controlar o acesso a passeios inteiros (todas as unidades de disco rígido e frouxas, bem como qualquer passeio montado como CD-ROMs e meios de comunicação óticos ou removíveis).
A figura 9.9. A janela Server Security de FTP deixa-o estabelecer largos direitos de acesso a passeios.
Serial Line Internet Protocol (SLIP) e Point-to-Point Protocol (PPP) funcionam sobre linhas seriais e necessitam um pouco de informação adicional. Como o ERRO e as conexões PPP estão entre duas máquinas, a fonte e os endereços IP de destino são necessários. Também, o identificador de porto serial é necessário, inclusive o vetor de interrupção que usa. As linhas seriais devem configurar-se propriamente com a sua tarifa de baud. Isto estabelece-se normalmente dentro de outro arquivo no sistema. As conexões de ERRO também necessitam uma colocação de netmask, embora isto não seja necessário para PPP.
PPP é mais versátil do que o ERRO. DESLIZE Apoia comunicações assíncronas só, ao passo que PPP permite síncrono e assíncrono. O ERRO deve ter uma linha dedicada que sempre se amarra, ao passo que PPP pode compartilhar a linha com outros programas como UUCP e libertar a linha segundo a ordem. O ERRO necessita de qualquer detecção de erros, ao passo que PPP o implementa. Considerando a escolha, PPP é a melhor linha serial protocolo de TCP, embora não esteja disponível com todas as implementações de sistema operacional.
DESLIZE e as conexões PPP estabelecem-se normalmente na mesma maneira que os motoristas de Ethernet. O SCO UNIX, por exemplo, usa a utilidade netconfig, mencionada anteriormente. Acrescentando um ERRO ou cadeia PPP, o sistema incita para a linha serial a usar-se, a tarifa de baud, o endereço das máquinas locais e máquinas de destino e o nome da máquina remota. Então configura o sistema para usar aquele porto serial. Depois de religar o núcleo e reinicialização, a linha serial está disponível para o ERRO ou para PPP (dependendo do modo que se configurou).
A impressão remota é uma característica útil que permite a um usuário em uma máquina enviar empregos de impressão a outras máquinas que anexaram impressoras. O sistema chama-se Remote Line Printing (RLP) e usa-se comumente para compartilhar impressoras em um grupo de trabalho. Também é útil para permitir o acesso a impressoras de especialização como raios laser a cores e cartógrafos. RLP não apoia classes de impressora, e alguns sistemas operacionais impõem restrições em opções de linha de comando de impressão apoiadas. A administração remota de impressoras não se apoia.
RLP funciona diferentemente do que a impressão de UNIX normal. Quando um pedido de impressão se emite, o sistema consulta o arquivo de configuração de impressora (normalmente/etc/printcap) para determinar se a impressora é local ou remota. Se o pedido de impressão for para uma impressora local, o processo habitual aplica-se. Se o pedido for para uma impressora remota, os carretéis de sistema locais o pedido de impressão e invocar o demônio lpd, que empacota o pedido de impressão e o envia à máquina remota, onde é spooled da impressora. Um usuário pode estabelecer uma impressora remota como o destino à revelia, como se faz comumente em grupos de trabalho que compartilham uma impressora única.
Várias versões de RLP estão disponíveis com o suporte de sistemas operacionais diferentes em uma rede. O SCO UNIX, por exemplo, apoia duas espécies de clientes: sistemas baseados em SCO e 4.3BSD sistemas. Isto permite estações de trabalho que dirigem Berkeley 4.3BSD a pedidos de impressão de fila a servidores de impressão de SCO. Os clientes de SCO usam RLP com as mesmas ordens que uma impressora local ia (LP e cancele), mas 4.3BSD os clientes têm versões especiais das ordens (lpr e lprm).
Assunção que RLP está disponível com o seu sistema operacional (algumas versões de UNIX não o apoiam), instala-se normalmente e ativa-se com o programa de serviço ou uma escrita. Com SCO UNIX, um mkdev rlp ordem inicia a escrita de instalação. Outros sistemas operacionais usam uma utilidade semelhante. Durante o processo de instalação, um número de diretórios criam-se para tratar o spooling, e as modificações fazem-se aos arquivos de configuração de impressora. As velhas ordens de impressão arquivam-se a um diretório, e as novas versões que apoiam RLP copiam-se no seu lugar.
A impressão remota necessita uma entrada especial no arquivo de configuração de impressora (/etc/printcap). Alguns sistemas operacionais (como SCO UNIX) têm uma escrita que edita o arquivo para você, incitando para a informação sobre configuração. Uma linha de mostra no arquivo de uma impressora remota pareceria a isto:
hplaser::lp=:rm=main_hplaser:rp=hplaser:sd=/usr/spool/lpd/hplaser
O primeiro campo é o nome usado pela máquina local para referir-se à impressora. O segundo campo é normalmente vazio. Define o nome de um arquivo de registro de erros mas não se usa na maior parte de sistemas. O terceiro campo é o nome de dispositivo de uma impressora local. As impressoras remotas deixam o campo como LP = sem impressora especificada. O quarto campo é o nome de rede da impressora. Pode ser o mesmo como o nome local. O quinto campo é o nome os usos de servidor de impressão da impressora (normalmente o mesmo como o nome local). Finalmente, o sexto campo é o nome do diretório de spooling da impressora. Isto é onde os pedidos de impressão são spooled antes de enviar-se à impressora remota.
Para máquinas na rede para acessar a Hewlett-Packard LaserJet que se anexa à máquina principal na rede de mostra, três máquinas remotas devem ter entradas da impressora nos seus arquivos/etc/printcap. A máquina principal também tem uma entrada para ele, mas como uma impressora local.
Administrar uma impressora remota faz-se registrando em log no consolo da máquina à qual a impressora se anexa ou usando vária utilidade RLP de outra máquina. A utilidade dissente com cada sistema operacional.
O Servidor de Windows NT tem TCP/IP remoto impressão de capacidades disponíveis como parte da suite TCP/IP.
A maior parte de redes TCP/IP usam Simple Network Management Protocol (SNMP) para controlar a rede de problemas. Permite a um sistema examinar e alterar a informação sobre ligação em rede mantida por outras máquinas na rede. SNMP é um protocolo simples que usa UDP como um transporte.
Muitos sistemas operacionais UNIX usam um demônio para dirigir SNMP. Quando o sistema corre, SNMP escuta no seu porto dedicado de pedidos de entrada. Três arquivos de configuração também se implicam normalmente.
O arquivo/etc/snmpd.conf contém a informação básica necessitada por SNMP. O arquivo contém identificadores dos tipos do software SNMP e TCP/IP, bem como o nome do responsável do administrador de sistema e a posição do sistema. Um arquivo de mostra parece a isto:
# snmpd.conf configuration file for tpci.com # the first two fields are default value descr=SNMPD Version 4.0 for SCO UNIX objid=SCO.1.0 contact=Tim Parker x53153 location=Network Room
Se SNMP se fizer para enviar mensagens de captura (mensagens de evento assíncronas), envia pacotes introdutórios (chamado capturas de partida fria) a outros sistemas que funciona. Lê os nomes dos sistemas para enviar capturas de partida fria a do arquivo/etc/snmpd.trap, que enumera nomes, endereços IP e números de porto:
# sample snmpd.trap file for tpci.com # lists symbolic name, IP address, and port test1 128.212.64.99 162 merlin 147.120.0.2 162
O arquivo snmpd.comm é uma lista de comunidade e pares de endereço IP que especifica de quem o agente pode aceitar perguntas. Cada linha no arquivo tem o nome da comunidade (às vezes chamava uma sessão), o endereço IP do sítio (um valor de 0.0.0.0 permite a qualquer endereço comunicar-se), e os privilégios pelo que o sítio se permite. Se o privilégio se fizer para LER, só leia as operações permitem-se; ESCREVA permite lido e escreva operações; e NENHUM restringe todo o acesso.
# Copyrighted as an unpublished work. # Copyright 1989 INTERACTIVE Systems Corporation # All rights reserved. # @(#)snmpd.comm 3.1 INTERACTIVE SNMP source test1 128.212.64.99 READ test2 128.212.64.15 WRITE test3 128.212.64.15 READ public 0.0.0.0 read beast 0.0.0.0 read excaliber 0.0.0.0 read
A configuração de SNMP é normalmente por um o shell script interativo. Durante a escrita, o usuário incita-se a toda a informação necessária para os três arquivos de configuração. SCO UNIX usa a ordem mkdev snmp para instalar o sistema.
Este capítulo mostrou como instalar e configurar vários servidores com TCP/IP. Estes métodos testaram-se e trabalham corretamente. No processo, este capítulo mencionou vários serviços alternativos como FTP anônimo e impressão remota. Se estes estão disponíveis na sua rede está à altura de você (ou o administrador de sistema). O seguinte capítulo acrescenta máquinas de cliente à rede de mostra.
Que informação é necessária para configurar o software TCP/IP de uma máquina?
Para uma configuração completa, TCP/IP necessita o nome de domínio, nome de sistema, endereço IP, tipo de motorista, endereço de transmissão, netmask, e colocações de placa de rede de hardware. Alguns sistemas permitem a configuração com só um pouco desta informação.
O que a máscara de rede faz?
A máscara de rede retira o identificador de rede de um endereço IP, deixando só o endereço da máquina local. Por exemplo, um endereço IP de 146.120.94.4 pode ter a máscara de rede 146,120 aplicados para deixar o endereço de máquina local como 94.4.
Que papel o arquivo/etc/inetd.conf joga?
O arquivo/etc/inetd.conf indica os processos começados pelo demônio inetd quando umas botas de sistema.
Explique a equivalência de usuário.
A equivalência de usuário deixa um acesso de usuário outra máquina sem necessitar uma senha durante o processo de senha de entrada. Controla-se pelo grupo de arquivos controlados pelo sistema ou usuários individuais.
