Ontem, configurou os servidores na rede de mostra. Os três servidores UNIX seguiram o mesmo procedimento e tinham arquivos de configuração semelhantes. O servidor de Windows NT configurou-se usando a pilha de TCP/IP construída. Hoje configura alguns clientes da rede. Os clientes comunicam-se com o servidor por uma pilha de TCP/IP carregada em cada máquina. Configura três clientes: um DOS, um Windows 3.x e um Windows 95. Algum dos sistemas operacionais que configurou ontem como servidores também pode atuar como clientes sobre a rede de mostra.
O Windows 95 inclui o software de cliente TCP/IP como parte do pacote de software de distribuição, mas não se configura quando o Windows 95 se instala. Isto é porque o Windows 95 instala protocolos de rede IPX/SPX de NetWare como o default. Hoje vê como modificar o protocolo à revelia a TCP/IP. Para o DOS e máquinas do Windows 3.x, vários produtos estão disponíveis para oferecer protocolos TCP/IP. Selecionei dois dos pacotes mais populares para configurar nestes sistemas. A máquina de DOS configura-se usando o produto de software PC/TCP de software de ftp. A máquina do Windows 3.x, dirigindo o Windows de Microsoft de Grupos de trabalho 3.11, configura-se com ChameleonNFS de NetManage.
Configurar DOS e máquinas de Windows é diferente do que a configuração de sistemas de UNIX por causa das modificações em sistemas de arquivos, arquitetura de sistema operacional e as aproximações de vendedor de software individuais. Contudo, a mesma informação básica necessita-se, e os passos para acrescentar que as máquinas de DOS são análogas àqueles para um sistema UNIX.
Embora hoje use dois pacotes comerciais específicos para o DOS e máquinas do Windows 3.11, o processo é semelhante a produtos TCP/IP de outros vendedores. Os nomes de arquivos e a informação sobre configuração exata poderiam diferenciar-se, mas os mesmos princípios gerais se aplicam.
PC/TCP do software de ftp esteve disponível durante vários anos e tornou-se um padrão de fato de máquinas de DOS que querem unir-se com uma rede TCP/IP. PC/TCP corre tanto abaixo de DOS como abaixo de Windows. Deixa um usuário executar todas as funções de TCP/IP, como ftp e telnet, e inclui o software de vários membros da família TCP de protocolos, inclusive SNMP. Outras máquinas também podem acessar um PC que dirige PC/TCP, copiando os seus arquivos (assunção que o acesso se concedeu). Tenha em mente que configuramos esta máquina como uma plataforma de DOS só, embora PC/TCP ofereça alguns ícones de Windows. A máquina poderia ser um mais velho dispositivo que não apoia o Windows, por exemplo, ou o usuário não poderia querer instalar o Windows 3. X nesta máquina. Algumas aplicações baseadas no DOS não poderiam trabalhar com uma pilha de TCP/IP Baseada em Windows — daqui a necessidade de uma configuração TCP/IP só de DOS.
PC/TCP pode dirigir TCP/IP como o único protocolo de rede no PC, ou pode costas vorazes em cima de outras redes, como Windows de Grupos de trabalho (NetBEUI e NetBIOS) ou Novell NetWare (IPX/SPX). O seu administrador de sistema pode decidir a melhor configuração pela sua máquina, dependendo da natureza da rede. Por exemplo, se um grande Windows da rede de Grupos de trabalho já existe mas um usuário quer o acesso a um TCP/IP UNIX servidor, não poderia fazer sentido para converter a rede inteira em TCP/IP. Neste caso, uma segunda placa de rede pode acrescentar-se especificamente para a rede TCP/IP ou TCP/IP pode coexistir com o Windows do sistema de Grupos de trabalho. (Lembre-se de que TCP/IP não é determinado sobre o tipo de transporte de rede.)
A rede de mostra que configura é TCP/IP-based, portanto PC/TCP se instala para correr naquele protocolo de rede só. Contudo, porque seria útil ser capaz de dirigir o Windows de Grupos de trabalho sobre a rede entre o DOS e máquinas do Windows 3.11, o processo de instalação que toma projeta-se para que tanto NetBEUI como TCP/IP possam residir simultaneamente na rede.
Uma aproximação é fazer que o sistema PC/TCP permita o Windows de Grupos de trabalho e pacotes TCP/IP na mesma rede. Com esta aproximação, TCP/IP distribui pacotes IP, e o Windows de Grupos de trabalho distribui pacotes de NetBEUI (o tipo à revelia). Ambos os protocolos usam drivers de dispositivo NDIS (Network Device Interface Specification) para comunicar-se com a placa de rede. O problema com esta aproximação consiste em que outras máquinas que recebem os pacotes poderiam confundir-se por causa de dois tipos de pacote diferentes, e o sistema não trabalha bem se uma rede externa dever acessar-se (como a Internet), porque os encaminhadores não tratam pacotes de NetBEUI.
A aproximação alternativa é configurar o Windows de Grupos de trabalho para encapsular a sua mensagem dentro de pacotes IP, que então podem enviar-se através das interredes e a rede local entre máquinas TCP/IP sem problemas. Esta aproximação tem um par de vantagens úteis. A rede é completamente baseada em IP, portanto os encaminhadores podem tratar o tráfego por interredes. Também, um Windows do computador de Grupos de trabalho em outra rede pode comunicar-se pelo encaminhador, daqui fazendo o Windows de serviços de Grupos de trabalho mais largamente disponível. Um Windows de recepção da máquina de Grupos de trabalho tem de extrair a informação do pacote IP, mas de outra maneira o sistema trabalha bem.
A rede de mostra que instala configura-se para permitir tanto a PC/TCP como Windows de Grupos de trabalho coexistir usando drivers de NDIS. Isto resulta em duas pilhas de software — um para PC/TCP e um para o Windows de Grupos de trabalho — coexistir-se e comunicar-se com o motorista NDIS. Esta estrutura mostra-se na Figura 10.1. Isto é provavelmente não a melhor escolha da rede de mostra, porque todas as outras máquinas na rede preferem formatos de pacote TCP/IP, mas esta aproximação demonstrações como PC/TCP pode configurar-se para protocolos duais em outras redes.
A figura 10.1. PC/TCP e Windows de pilhas de Grupos de trabalho usando NDIS.
PC/TCP usa um núcleo que se carrega na memória quando botas de DOS. O núcleo é um programa Terminate e Stay Resident (TSR). Para assegurar que a rede está disponível sempre, a ordem de carga central acrescenta-se normalmente ao AUTOEXEC.BAT arquivo. A rede de mostra usa um núcleo chamado ETHDRV.EXE, que é o motorista de Ethernet provisto com PC/TCP. (Um núcleo diferente deve usar-se se a rede for IEEE 802.3 Ethernet, que se diferencia da Ethernet DIX normal.) Além disso, um Convertedor NDIS deve carregar-se no AUTOEXEC.BAT arquivo como um motorista de dispositivo para fornecer pacotes de NDIS-formato ao gerente de protocolo.
PC/TCP inclui um procedimento de instalação automatizado que copia os meios de comunicação de distribuição ao disco rígido e funda alguns arquivos de configuração. Hoje, a maioria do sistema configura-se manualmente para mostrar os passos necessários e permitir-lhe verificar as modificações feitas a arquivos de sistema pelo programa de instalação. Na prática, permitiria a PC/TCP instalar-se e executar a configuração automaticamente, logo verificar os arquivos o conteúdo próprio.
A instalação de PC/TCP necessita a mesma informação básica que TCP/IP abaixo de UNIX: o motorista de dispositivo, o nome do sistema e endereço IP, e os nomes e endereços IP de outros sistemas a acessar-se. O processo começa com uma placa de rede propriamente instalada. O IRQ e o endereço de memória do cartão devem conhecer-se, e um motorista de dispositivo para ele deve estar presente para a inclusão no arquivo CONFIG.SYS. Os motoristas de dispositivo provêem-se normalmente pelo vendedor de placa de rede, mas os drivers genéricos também se incluem com os discos de software PC/TCP. Incluem drivers dos tipos mais populares de sistemas de rede mas não poderiam incluir todos os cartões possíveis.
Depois de copiar todos os arquivos de distribuição à unidade de disco rígido, a configuração pode começar. A máquina de mostra dirige o DOS 6.22 e Windows de Grupos de trabalho 3.11, embora esteja configurando o sistema operacional de DOS especialmente nesta seção. As modificações no número do lançamento de software DOS poderiam afetar os seguintes detalhes, mas as instruções de instalação PC/TCP se atualizam para novos lançamentos. Instalando PC/TCP com o Windows de Grupos de trabalho, a rede de Windows deve instalar-se, configurar-se, e correndo propriamente antes que PC/TCP modifique os arquivos de Windows para permitir tanto a DOS como Windows trabalhem sobre a rede.
Durante o processo de instalação, PC/TCP necessita um longo número de série e chave de autenticação. Estes verificam o software e impedem uma rede de usar muitas cópias do mesmo software quando só uma licença se comprou.
Quatro arquivos implicam-se na configuração inicial:
No material de ontem, a configuração de parâmetro central de UNIX mencionou-se de passagem como um modo de efetuar o controle detalhado do comportamento do sistema operacional com TCP/IP. Em alguns casos, isto é necessário com o DOS o sistema de PC/TCP, também. Um programa de serviço chamado KAPPCONF permite aos parâmetros centrais alterar-se. As colocações do núcleo salvam-se em um arquivo de configuração chamado PCTCP.INI.
AUTOEXEC.BAT o arquivo necessita que variáveis de ambiente se estabeleçam propriamente para PC/TCP e duas instruções acrescentadas ao arquivo. Uma instrução começa a rede e outras cargas o motorista de Ethernet. A máquina de mostra já tinha o Windows de Grupos de trabalho instalados, portanto uma linha em AUTOEXEC.BAT arquivo lê
C:\WINDOWS\NET START
Esta linha começa a rede. A ordem de PARTIDA LÍQUIDA pode permanecer no lugar ou substituir-se com uma ordem de PC/TCP chamada NETBIND, que realiza a mesma coisa de motoristas NDIS. Se ambas as ordens estiverem no AUTOEXEC.BAT arquivo, uma mensagem de erro resulta quando a segunda ordem de lançamento de rede se realiza. (As nomeações de passeio para todos os exemplos hoje poderiam ser diferentes em outros sistemas, como podia os diretórios de instalação. Os defaults de instalação usaram-se em todas as partes deste capítulo tanto para PC/TCP como para Windows de Grupos de trabalho. Modifique os seus valores como necessário de combinar com o seu sistema.)
Depois da PARTIDA LÍQUIDA ou ordem de NETBIND, a seguinte linha deve acrescentar-se ao AUTOEXEC.BAT arquivo:
C:\PCTCP\ETHDRV
Isto começa o driver de Ethernet PC/TCP. Se outro sistema de rede se está usando, isto iria se substituir com o motorista de dispositivo daquela rede (como IEEEDRV de IEEE 802.3 Ethernet ou SLPDRV do ERRO).
É útil definir duas variáveis de ambiente no AUTOEXEC.BAT arquivo do software PC/TCP para usar procurando o arquivo. Cada um é uma adição simples à ordem de CAMINHO, acrescentando o diretório de instalação PCTCP ao caminho de pesquisa. O segundo é uma variável de ambiente que aponta para o PCTCP.INI arquivo. As duas declarações parecem a isto:
SET PCTCP=C:\PCTCP\PCTCP.INI SET PATH=C:\PCTCP;%PATH%
A última modificação da ordem de CAMINHO acrescenta C:\PCTCP to an already defined PATH. Uma alternativa deveria editar a ordem de CAMINHO de incluir o diretório na mesma linha que o resto da declaração. O software PC/TCP pode dirigir-se sem estas variáveis de ambiente definidas, mas os problemas com posições de arquivo podem resultar se as ordens não se realizarem do diretório de instalação.
Por isso, na máquina de DOS, o concluído AUTOEXEC.BAT o arquivo deve ter uma das seguintes combinações de quatro linhas nele:
SET PCTCP=C:\PCTCP\PCTCP.INI SET PATH=C:\PCTCP;%PATH% C:\WINDOWS\NET START C:\PCTCP\ETHDRV
ou
SET PCTCP=C:\PCTCP\PCTCP.INI SET PATH=C:\PCTCP;%PATH% C:\PCTCP\NETBIND C:\PCTCP\ETHDRV
Quando estas linhas se realizam durante o processo de iniciação de sistema, o sistema expõe mensagens de posição quando cada ordem se conclui. A ordem de NETBIND expõe esta mensagem se carregar com sucesso:
MS-DOS LAN Manager v2.1 Netbind Microsoft Netbind version 2.1
Uma terceira linha poderia expor uma mensagem de posição sobre o vetor de interrupção usado pelo sistema. Se NETBIND não pode carregar corretamente, gera uma mensagem como isto:
MS-DOS LAN Manager v2.1 Netbind Error: Making PROTMAN IOCTL call.
Isto normalmente gera-se quando a rede já corre (tal como de emitir uma ordem de PARTIDA LÍQUIDA antes da ordem de NETBIND; poderia lembrar que só um destes dois deve estar no AUTOEXEC.BAT arquivo).
A ordem de ETHDRV expõe uma mensagem com a informação sobre posição quando carrega com sucesso. Parece a isto:
MAC/DIS converterFTP Software PC/TCP Resident Module 2.31 01/07/94 12:38 Copyright 1986-1993 by FTP Software, Inc. All rights reserved. Patch level 17637 Patch time: Fri Jan 07 14:25:09 1994 Kernel interrupt vector is 0x61 Code Segment occupies 49.0K of conventional memory Data Segment occupies 19.5K of conventional memory Packet Driver found at vector 0x60 name: version: 30, class: 1, type: 57, functionality: 6 ifcust (PC/TCP Class 1 packet driver - DIX Ethernet) initialized 5 free packets of length 1514, 5 free packets of length 160 The Resident Module occupies 68.7K of conventional memory
Se houver um erro quando o programa ETHDRV carrega, gera uma mensagem de erro (da utilidade variada para depurar objetivos). Um erro de mostra mostra-se aqui:
FTP Software PC/TCP Resident Module 2.31 01/07/94 12:38 Copyright 1986-1993 by FTP Software, Inc. All rights reserved. Patch level 17637 Patch time: Fri Jan 07 14:25:09 1994 PC/TCP is already loaded (interrupt 0x61). Use 'inet unload' to unload it.
Este erro ocorreu porque um driver PC/TCP se tinha carregado antes da ordem de ETHDRV.
Alguns usuários de DOS gostam de deixar estas ordens fora do AUTOEXEC.BAT arquivo e emiti-los manualmente. Isto tem a vantagem de reduzir o montante da memória ruminada quando as botas de máquina e a rede não se necessitam. Um compromisso útil deve criar um pequeno arquivo de lote que tem estas duas ordens e logo dirija o arquivo de lote só se a rede se usar. Tanto NETBIND como ETHDRV não parecem ser críticos pelo que quando se carregam na sequência de lançamento (ao contrário de algum software que insiste carregar-se primeiro ou último no AUTOEXEC.BAT arquivo).
O arquivo CONFIG.SYS tem de mandar carregar motoristas para o gerente de protocolo, o convertedor de pacote NDIS e o driver de placa de rede. Os sistemas que dirigem Windows de Grupos de trabalho poderiam necessitar motoristas adicionais. O arquivo CONFIG.SYS deve ter uma entrada que determina o número de arquivos abertos um dia para pelo menos 20. Se isto não existe, choques de PC/TCP. Acrescente esta linha:
FILES=20
ao arquivo CONFIG.SYS. Dependendo do montante da memória disponível, o número pode aumentar-se prontamente. Com a memória de acesso aleatório de 8 Mb ou mais, um valor de 40 é satisfatório. Os números acima desta colocação tendem a ser contraprodutivos porque a memória de acesso aleatório se desperdiça sem motivo.
O gerente de protocolo provê-se como parte do Windows de Grupos de trabalho, e cada um inclui-se com o pacote de software PC/TCP. A escolha do qual usar é seu ou o seu administrador de sistema. Se o Windows de Grupos de trabalho 3.1 (não 3.11) já se carregou e funcional, CONFIG.SYS tem uma linha semelhante a isto:
DEVICE=C:\WINDOWS\PROTMAN.DOS /I:C:\WINDOWS
O gerente de protocolo não sempre se usa com o Windows para Grupos de trabalho 3,11 lançamento porque se inclui com outros motoristas dentro do arquivo CONFIG.SYS (como IFSHLP.SYS). Se não houver nenhum gerente de protocolo começado no tempo de inicialização, deve acrescentar-se do software PC/TCP. A entrada dentro do arquivo CONFIG.SYS é
DEVICE=C:\PCTCP\PROTMAN.DOS \I:C:\PCTCP
Isto carrega o gerente de protocolo PC/TCP. O \I no fim da ordem diz ao motorista onde procurar arquivos (neste caso, o diretório de instalação PC/TCP).
Um motorista de placa de rede deve aparecer depois em CONFIG.SYS. Isto diferencia-se para cada placa de rede, mas para a máquina de DOS de rede de mostra placa de rede de Intel EtherExpress 16, a linha é
DEVICE=C:\WINDOWS\EXP16.DOS
Isto carrega o driver EXP16 da placa de rede de Intel. Isto incluiu-se com o Windows do software Workgroups, mas também está disponível como um motorista genérico. Algumas máquinas com o Windows de Grupos de trabalho já instalados poderiam ter esta ordem já no arquivo CONFIG.SYS.
O passo final deve carregar o PC/TCP NDIS Convertedor de Pacote. O lançamento atual de PC/TCP usa um convertedor de pacote chamado DIS_PKT.GUP. A linha parece a isto:
DEVICE=C:\PCTCP\DIS_PKT.GUP
Alguns sistemas que dirigem Windows de Grupos de trabalho 3.1 (e alguns que fizeram um upgrade a 3,11) têm a linha
DEVICE=C:\WINDOWS\WORKGRP.SYS
no arquivo CONFIG.SYS. Isto é para o Windows do uso de Grupos de trabalho e não é necessário se PC/TCP dever usar-se como um sistema baseado no DOS só. Se o arquivo não se instalou pelo Windows de Grupos de trabalho e o sistema trabalha propriamente sem ele, não há necessidade de acrescentá-lo.
Quando as botas de sistema, os drivers de dispositivo se carregam à sua vez. Cada um expõe uma mensagem curta mostrando o seu número da versão. Qualquer erro que ocorre também se expõe. Normalmente os motoristas de dispositivo não causam nenhum problema.
O arquivo CONFIG.SYS propriamente configurado da máquina de DOS deve ter estas linhas nele
DEVICE=C:\WINDOWS\PROTMAN.DOS /I:\C:\WINDOWS DEVICE=C:\WINDOWS\EXP16.DOS DEVICE=C:\PCTCP\DIS_PKT.GUP
se usa o Windows para o gerente de protocolo de Grupos de trabalho. Deve ter as seguintes linhas se estiver usando o gerente de protocolo PC/TCP:
DEVICE=C:\PCTCP\PROTMAN.DOS /I:\C:\PCTCP DEVICE=C:\WINDOWS\EXP16.DOS DEVICE=C:\PCTCP\DIS_PKT.GUP
Como observado antes, o motorista de interface de rede (EXP16) é diferente se a sua máquina não usar a tábua de Intel EtherExpress 16.
A posição destas linhas dentro do arquivo CONFIG.SYS não é crítica, embora pudessem haver problemas se se carregam na alta memória com outros motoristas. A experimentação é o único modo de encontrar a sequência mais eficiente pela memória.
O Windows de Grupos de trabalho tem um PROTOCOL.INI arquivo como parte da sua organização. O arquivo diz o sistema das placas de rede e motoristas no uso. Os PC/TCP PROTOCOL.INI entram faz o mesmo, mas reside no diretório PCTCP.
Os conteúdos de PROTOCOL.INI arquivo são diferentes para cada placa de rede e configuração de motorista. Deve haver [PKTDRV] etiquetado de uma seção (todos na letra maiúscula) que define o nome de driver, a atadura à placa de rede e qualquer informação sobre configuração necessária. A rede de mostra PROTOCOL.INI arquivo parece a isto:
[PKTDRV] drivername=PKTDRV$ bindings=MS$EE16 intvec=0x60 [MS$EE16] DriverName=EXP16$ IOADDRESS=0x360 IRQ=11 IOCHRDY=Late TRANSCEIVER=Thin Net (BNC/COAX)
Isto PROTOCOL.INI arquivo define o motorista de pacote como PKTDRV$, o motorista à revelia com PC/TCP. A atadura ao cartão de Intel EtherExpress 16 usado na máquina de DOS refere-se a outra seção no arquivo que enumera o endereço, IRQ e alguma especificação do cartão de EtherExpress. Estas linhas podem ter-se incluído na [PKTDRV] seção mas separaram-se para a compatibilidade com o Windows de Grupos de trabalho PROTOCOL.INI arquivo, que é semelhante no leiaute. O cartão EtherExpress 16 faz-se para usar IRQ 11, endereço de memória 360, e usar o conector de fio Thin Ethernet. A linha intvec na [PKTDRV] seção não define o IRQ da placa de rede; em vez disso, é uma interrupção do motorista.
PROTOCOL.INI o arquivo de um sistema usando uma placa de rede mais simples do que EtherExpress pode ser mais curto. Uma amostra PROTOCOL.INI arquivo de tal cartão poderia parecer a isto:
[PKTDRV] drivername=PKTDRV$ binding=MS$ELNKII intvec=0x65 chainvec=0x67
Encontrando as colocações próprias das variáveis em PROTOCOL.INI o arquivo pode ser uma experiência angustiante. Se o Windows de Grupos de trabalho se instalar e gerência, o Windows PROTOCOL.INI entra é uma boa fonte de informação e pode copiar-se às vezes sem modificação. De outra maneira, a documentação de placa de rede pode ajudar às vezes.
PCTCP.INI o arquivo mantém a informação sobre configuração central de PCTCP. Na maioria dos casos, pode deixar-se como fornecido com o software. Torcer os parâmetros centrais deve executar-se só depois que a rede instala-se e tem funcionado propriamente durante algum tempo. PCTCP.INI o arquivo é bastante longo, e o cuidado deve tomar-se para evitar modificações acidentais, que podem dar o sistema ineficaz.
Se a escrita de instalação fornecida não se usar para instalar PC/TCP, um mínimo PCTCP.INI o arquivo deve criar-se manualmente. Os exemplos incluem-se com os meios de comunicação de distribuição, normalmente abaixo do nome TEMPLATE.INI. Há dois modos de criar o PCTCP.INI arquivo e configurá-lo propriamente. O primeiro deve usar um editor e modificar o arquivo de padrão. A alternativa deve dirigir a utilidade de configuração central KAPPCONF.
Um mínimo PCTCP.INI arquivo tem de ter o número de série de software e chave de ativação, o endereço IP, endereço de transmissão, endereço de encaminhador, uma máscara de subrede e informação sobre o sistema em geral. O mínimo PCTCP.INI arquivo pareceria a isto:
[pctcp general] domain = tpci.com host-name = sinbad time-zone = EST time-zone-offset = 600 user = tparker [pctcp kernel] serial-number = 1234-5678-9012 authentication-key = 1234-5678-9012 interface = ifcust 0 low-window = 0 window = 2048 [pctcp ifcust 0] broadcast-address = 255.255.255.255 ip-address = 147.120.0.11 router = 147.120.0.1 subnet-mask = 255.255.0.0 [pctcp addresses] domain-name-server = 147.120.0.1 mail-relay = 147.120.0.1
Esta configuração supõe que o SCO UNIX servidor (147.120.0.1) seja o servidor primário da rede. O nome de máquina de DOS (Sinbad) e endereço IP (147.120.0.11) mostra-se no PCTCP.INI arquivo. Como as características diferentes de PC/TCP permitem-se (como SNMP e Kerberos), as novas seções acrescentam-se ao PCTCP.INI arquivo.
Se o Windows de Grupos de trabalho dever usar-se na máquina de DOS e vai usar os drivers PC/TCP em vez de um Windows dedicado de Grupos de trabalho pacote de TCP/IP, o Windows de Grupos de trabalho SYSTEM.INI o arquivo necessita a modificação. O Windows de Grupos de trabalho SYSTEM.INI arquivo deve fazer-se para usar o Windows para o motorista de Grupos de trabalho em vez do motorista PC/TCP.
Quando o processo de instalação automático PC/TCP descobre uma cópia do Windows, faz modificações do SYSTEM.INI arquivo para você. Algumas destas modificações devem verificar-se e modificar-se para permitir o Windows à bota propriamente com os motoristas PC/TCP. Uma das modificações mais importantes é o comento fora do Windows do motorista de rede de Grupos de trabalho e a sua substituição com o motorista PC/TCP:
network.drv=C:\PCTCP\PCTCPNET.DRV
Para o Windows de Grupos de trabalho 3.1, confirme que SYSTEM.INI o arquivo tem estas três seções, com estas ordens mostradas:
[boot] network.drv=wfwnet.drv [boot.description] network.drv=Microsoft Windows for Workgroups (version 3.1) [386Enh] device=c:\pctcp\vpctcp.386 device=c:\pctcp\wfwftp.386
O Windows de Grupos de trabalho 3.11 tem um ligeiramente diferente SYSTEM.INI. Deve parecer a isto:
[boot] network.drv=wfwnet.drv [boot.description] network.drv=Microsoft Windows Network (version 3.11) [386Enh] device=c:\pctcp\vpctcp.386
No fundo do Windows de Grupos de trabalho SYSTEM.INI arquivo, PC/TCP às vezes acrescenta um bloco da informação que parece a isto:
[vpctcp] ; These option settings may be added to SYSTEM.INI, in a ; new section "[vpctcp]". ; The next line tells VPCTCP how much copy space memory to request. ; It is in units of kilobytes (x1024). This value is only a bid, ; as Windows may choose to reduce your allocation arbitrarily. ; This value should be increased if using Windows applications which ; call the PC/TCP DLL from another DLL; suggested value in such ; instances is at least 28. MinimumCopySpace=12 ; The next line tells VPCTCP the segment (paragraph) number of the ; beginning of memory reserved for devices, BIOS, and upper- ; memory blocks (which could contain TSRs). All calls below the ; PSP of Windows or above this parameter are not processed by ; the VxD but rather are passed-thru to the kernel untouched. HiTSRFenceSegment=A000h ; eof
Para a maior parte de instalações, este bloco pode deixar-se como é. As linhas de comentário (os que começam com um ponto-e-vírgula) ignoram-se pelo Windows, ao passo que as duas variáveis estabelecidas nestas seções se usam por PC/TCP. Não há necessidade de eliminar esta informação. Contudo, como a primeira nota indica, os usuários de PC/TCP deveriam aumentar os valores para prestar contas do uso pesado.
Se o sistema de objetivo estiver dirigindo o Windows 3.1 (não Windows de Grupos de trabalho) há mais modificações a fazer-se, porque SYSTEM.INI o arquivo e os arquivos de inicialização dependentes da rede não têm o formato próprio ainda. Para configurar um sistema de Windows, as modificações devem fazer-se ao PROGMAN.INI e SYSTEM.INI arquivos.
O Windows 3.1's PROGMAN.INI arquivo controla o lançamento do Gerenciador de programas de Windows. Normalmente, isto modifica-se pela escrita de instalação PC/TCP, mas se uma instalação manual se tenha executado, as modificações devem fazer-se com um editor de texto. PROGMAN.INI o arquivo deve mandar acrescentar as seguintes linhas:
[Groups] GROUP16 = C:\PCTCP\PCTCPDOS.GRP GROUP17 = C:\PCTCP\PCTCPWIN.GRP
Os números seguintes ao GRUPO devem ser mais altos do que qualquer número existente, normalmente enumerado em sequência para a conveniência. Neste exemplo, a lista de grupos correu ao número 15.
As modificações do Windows 3.1 SYSTEM.INI arquivo devem fazer-se em algumas seções. [No 386Enh] seção, acrescente uma linha do motorista de dispositivo PC/TCP:
device=c:\pctcp\vpctcp.386
Uma [vpctcp] seção deve acrescentar-se com as seguintes entradas:
[vpctcp] MinimumCopySpace=12 HiTSRFenceSegment=A000h
Ver a discussão do Windows de Grupos de trabalho SYSTEM.INI arquivo para obter mais informações sobre estas variáveis.
Algumas entradas adicionais poderiam ser necessárias se o motorista de rede se localiza na alta memória, se houver um conflito com o default o porto serial IRQs, ou se uma rede Anular Simbólica se usar. Ver o manual de instalação PC/TCP da informação sobre modificação completa nestes casos.
Como mencionado antes, o Windows de Grupos de trabalho pode fazer-se para usar pacotes IP. Isto necessita um motorista de NetBIOS tanto do Windows de Grupos de trabalho como de PC/TCP. A arquitetura de como sistema mostra-se na Figura 10.2. O Windows de pacotes de Grupos de trabalho envia-se por NetBIOS de PC/TCP e logo na pilha de PC/TCP normal.
A figura 10.2. Windows de grupos de trabalho com NetBIOS.
Para instalar o Windows de Grupos de trabalho nesta maneira, o Windows deve fundar-se primeiro para usar o Gerente de Microsoft LAN opção. Isto é normalmente uma matéria de selecionar o Gerente de LAN opção da janela Network se já não for a colocação à revelia. (Consulte o Windows da documentação de Grupos de trabalho de mais informação.)
Os arquivos de configuração também devem modificar-se para refletir a nova arquitetura. AUTOEXEC.BAT o arquivo tem a ordem de iniciação de rede, o motorista central de rede e uma ordem de NETBIOS:
C:\WINDOWS\NET START C:\PCTCP\ETHDRV C:\PCTCP\NETBIOS.COM
Um NETBIND pode executar-se em vez de uma ordem de PARTIDA LÍQUIDA, embora o último seja preferível. A ordem de NETBIOS deve vir depois do NETBIND ou ordem de PARTIDA LÍQUIDA.
O arquivo CONFIG.SYS é semelhante a isto visto antes, com os mesmos motoristas. Um arquivo de CONFIG.SYS de mostra deste tipo da arquitetura parece a isto:
DEVICE=C:\WINDOWS\PROTMAN.DOS /I:\C:\WINDOWS DEVICE=C:\WINDOWS\EXP16.DOS DEVICE=C:\PCTCP\DIS_PKT.GUP
Isto começa o gerente de protocolo, o motorista de cartão e o convertedor de pacote NDIS. Este exemplo usa o driver de cartão de Intel EtherExpress 16.
PROTOCOL.INI o arquivo é o mesmo como o exemplo prévio. Uma amostra PROTOCOL.INI arquivo do cartão de Intel EtherExpress 16 parece a isto:
[PKTDRV] drivername=PKTDRV$ bindings=MS$EE16 intvec=0x60 [MS$EE16] DriverName=EXP16$ IOADDRESS=0x360 IRQ=11 IOCHRDY=Late TRANSCEIVER=Thin Net (BNC/COAX)
Finalmente, SYSTEM.INI o arquivo precisa que o Windows do motorista de rede de Grupos de trabalho se use e não o motorista de rede PC/TCP. Isto poderia necessitar a edição o SYSTEM.INI arquivo, como observado antes. SYSTEM.INI o arquivo deve conter as seguintes linhas:
[boot] network.drv=wfwnet.drv [boot.description] network.drv=Microsoft Windows for Workgroups (version 3.1) [386Enh] device=c:\pctcp\vpctcp.386 device=c:\pctcp\wfwftp.386 TimerCriticialSection=50000
A linha última [no 386Enh] seção deveria acrescentar-se manualmente. O número da versão na [boot.description] seção modifica-se para (a versão 3.11) com a versão posterior do Windows de Grupos de trabalho.
Depois de fazer todas as modificações anteriormente mencionou, a máquina de DOS reinicia-se para a prova. Se nenhuma mensagem de erro se expuser quando as novas ordens se realizam, o sistema está pronto para testar a pilha de protocolo TCP/IP. O teste mais simples deve usar o silvo para assegurar que o software TCP/IP fala com a máquina local, logo use-o para testar as máquinas remotas.
A informação sobre nome sobre máquina de outras máquinas ainda não se acrescentou ao sistema de DOS PC/TCP, portanto os endereços IP devem usar-se com o silvo. O seguinte é um exemplo de uma ordem de silvo da máquina local (147.120.0.11), o SCO UNIX servidor (147.120.0.1) e a máquina do Windows 95 (147.120.0.10) na rede de mostra (que ainda não se instalou e daqui não deve comunicar-se):
C:\> ping 147.120.0.11 host responding, time = 25 ms Debugging information for interface ifcust Addr(6): 00 aa 00 20 18 bf interrupts: 0 (2 receive, 0 transmit) packets received: 2, transmitted: 3 receive errors: 0, unknown types: 0 runts: 0, aligns: 0, CRC: 0, parity: 0, overflow: 0 too big: 0, out of buffers: 0, rcv timeout: 0, rcv reset: 0 transmit errors: 0 collisions: 0, underflows: 0, timeouts: 0, resets: 0 lost crs: 0, heartbeat failed: 0 ARP statistics: arps received: 1 (0 requests, 1 replies) bad: opcodes: 0, hardware type: 0, protocol type: 0 arps transmitted: 2 (2 requests, 0 replies) 5 large buffers; 4 free now; minimum of 3 free 5 small buffers; 5 free now; minimum of 4 free C:\> C:\> ping 147.120.0.1 host responding, time = 25 ms Debugging information for interface ifcust Addr(6): 00 aa 00 20 18 bf interrupts: 0 (5 receive, 0 transmit) packets received: 5, transmitted: 6 receive errors: 0, unknown types: 0 runts: 0, aligns: 0, CRC: 0, parity: 0, overflow: 0 too big: 0, out of buffers: 0, rcv timeout: 0, rcv reset: 0 transmit errors: 0 collisions: 0, underflows: 0, timeouts: 0, resets: 0 lost crs: 0, heartbeat failed: 0 ARP statistics: arps received: 2 (0 requests, 2 replies) bad: opcodes: 0, hardware type: 0, protocol type: 0 arps transmitted: 3 (3 requests, 0 replies) 5 large buffers; 4 free now; minimum of 3 free 5 small buffers; 5 free now; minimum of 4 free C:\> C:\> ping 147.120.0.10 ping failed: Host unreachable: ARP failed Debugging information for interface ifcust Addr(6): 00 aa 00 20 18 bf interrupts: 0 (5 receive, 0 transmit) packets received: 5, transmitted: 7 receive errors: 0, unknown types: 0 runts: 0, aligns: 0, CRC: 0, parity: 0, overflow: 0 too big: 0, out of buffers: 0, rcv timeout: 0, rcv reset: 0 transmit errors: 0 collisions: 0, underflows: 0, timeouts: 0, resets: 0 lost crs: 0, heartbeat failed: 0 ARP statistics: arps received: 2 (0 requests, 2 replies) bad: opcodes: 0, hardware type: 0, protocol type: 0 arps transmitted: 4 (4 requests, 0 replies) 5 large buffers; 4 free now; minimum of 3 free 5 small buffers; 5 free now; minimum of 4 free
O silvo de mensagem falhou: esperam o anfitrião inalcançável para a tentativa última. PC/TCP provê o usuário de mensagens diagnósticas com cada ordem de silvo. Para suprimir estas mensagens e simplesmente adquirir um êxito ou reprovar a mensagem, a opção-z pode usar-se:
C:\> ping -z 147.120.0.11 host responding, time = 25 ms C:\> C:\> ping -z 147.120.0.1 host responding, time = 25 ms C:\> C:\> ping -z 147.120.0.10 ping failed: Host unreachable: ARP failed
Se a ordem de silvo não for bem sucedida com o endereço local, o cartão de interface de rede configura-se incorretamente ou a instalação de software tem parâmetros incorretos. Verifique a placa de rede o IRQ correto e colocações de memória e logo verifique o fio para assegurar que se une propriamente e rede os terminators estão no lugar. O software deve mandar carregar os motoristas corretos, bem como o nome de máquina, endereço IP e informação semelhante.
Se a máquina local responder mas as máquinas remotas não fazem, verifique as conexões de rede. Tente o silvo de uma das máquinas remotas para assegurar que a máquina de DOS pode conseguir-se por outras máquinas. A experiência mostrou que as implementações TCP/IP baseadas no PC podem ser estranhas inicializando. É bastante habitual ter uma ordem de silvo falham quatro ou cinco vezes e logo começam a trabalhar propriamente. Repita as ordens várias vezes, esperando alguns segundos entre cada tentativa.
Uma vez que as máquinas podem responder com sucesso a um pedido de silvo, tentar o ftp ou telnet da máquina baseada no DOS. Uma tentativa de ftp de registrar em log para o SCO UNIX a máquina mostra-se aqui:
FTP Software PC/TCP File Transfer Program 2.31 01/07/94 12:38 Copyright 1986-1993 by FTP Software, Inc. All rights reserved. FTP Trying....Open 220 tpci.tpci.com FTP Server (Version 5.60 #1) ready. Userid for logging in on 147.120.0.1? tparker 331 Password required for tparker. Password for logging in as tparker on 147.120.0.1? abcdefg 230 User tparker logged in. ftp:147.120.0.1> ls .profile .lastlogin .odtpref trash Initial.dt XDesktop3 Transferred 265 bytes in 0 seconds 226 Transfer complete. ftp:147.120.0.1> exit
Esta sessão, que expôs a listagem de arquivos no SCO UNIX servidor, mostra que a ordem de ftp trabalhou propriamente. A sessão de FTP fechou-se com a saída de ordem.
Depois do teste baseado no DOS, comece o Windows (se se instalou) e assegure que as aplicações dentro do grupo de programa PC/TCP Applications estão disponíveis e de trabalho. Se os problemas se encontrarem com o começo de Windows, é provável que um erro se fizesse no SYSTEM.INI arquivo. Verifique as instruções prévias a configuração correta.
No fim de tudo isto, o software de ftp o sistema PC/TCP instala-se e configura-se propriamente. A máquina de DOS pode usar-se agora para aplicações TCP/IP como ftp e telnet. Se algumas características de protocolo mais potentes se instalaram, também são usáveis. A instalação de máquina baseada no DOS conclui-se agora. A documentação PC/TCP contém instruções para usar o sistema, bem como efetuar o controle detalhado do núcleo. Também ajuda usuários a criar portões, encaminhadores, servidores de correio e várias outras características TCP/IP-related.
NetManage produz uma linha do software TCP/IP-based especificamente de Windows, o Windows 95 e Windows de Grupos de trabalho. Estas aplicações projetam-se para fornecer o acesso cheio à utilidade TCP/IP pelo ambiente de Windows. A linha de NetManage de produtos inclui uma pilha de TCP/IP básica (chamou Newt), bem como os pacotes de aplicações TCP/IP cheios em várias formas, todo Cameleão chamado. O sistema também está disponível para o Windows NT. Instala o Cameleão em um Windows de Grupos de trabalho 3,11 máquina na rede de mostra.
O cameleão usa o NDIS padrão (Especificação de Interface de Dispositivo de Rede) ou o ODI (Interface de Conexão de Dados Aberta) para comunicar-se com o cartão de interface de rede. Isto permite qualquer cartão que usa NDIS ou ODI a usar-se com o Cameleão.
Antes da instalação do Cameleão, os mesmos passos executam-se quanto ao pacote TCP/IP baseado no DOS. O cartão de interface de rede deve instalar-se com IRQ conveniente e colocações de endereço de memória. Se o Cameleão se estiver acrescentando a um Windows existente do sistema de Grupos de trabalho, a placa de rede já deve instalar-se e propriamente configurar-se. A mesma informação necessita-se quanto a todas as instalações TCP/IP: o nome do host, endereço IP, transmitiu a máscara, a máscara de subrede e qualquer informação sobre portões ou encaminhadores que tem de incluir-se.
A versão de ChameleonNFS usado para a rede de mostra tinha a sua informação sobre instalação ligeiramente mista por causa de atualizações tanto de Cameleão como de Windows de Grupos de trabalho. A informação fornecida hoje aplica ao Windows de Grupos de trabalho 3.1 e 3.11 e a versão 4.0 de ChameleonNFS, embora outras versões devam ser semelhantes.
O cameleão pode instalar-se sobre um Windows que funciona totalmente ou Windows do sistema de Grupos de trabalho. Se o Windows de Grupos de trabalho se usar, assegure que a rede executa propriamente (se possível) quando falando com outras máquinas NetBEUI-compatíveis. Neste caso, isto não é possível porque a rede de mostra só usa TCP/IP.
O procedimento de instalação para o Cameleão é simples. Do menu Program Manager's File, selecione a Corrida, logo realize o programa SETUP.EXE do primeiro disco de Cameleão. Como com a maior parte de Aplicações para Windows, isto começa o programa de instalação.
As modificações feitas aos arquivos de sistema poderiam causar problemas, afetando a capacidade de Windows de inicializar. Antes de instalar o software Chameleon, faça cópias do AUTOEXEC.BAT, CONFIG.SYS, PROTOCOL.INI, WIN.INI, e SYSTEM.INI arquivos. Se os problemas se encontrarem, estes arquivos podem devolver o sistema ao seu estado original. Deve considerar a criação de um apoio de sistema cheio antes de qualquer principal mudança ao software, naturalmente.
O programa de instalação de Cameleão necessita que um longo número de série e uma chave de ativação assegurem que há só uma tal versão em uma rede (isto deixa na rua múltiplas instalações usando o mesmo número de série e chave de ativação.) A escrita de instalação incita para os discos de distribuição na ordem e copia todos os arquivos necessários.
Depois do processo de instalação, o Cameleão constrói o grupo de programa com as aplicações de Cameleão incluídas. O grupo de programa ChameleonNFS mostra-se na Figura 10.3. Depois de criar o grupo de programa, o Cameleão começa uma tela de fazimento por encomenda que o deixa especificar o seu endereço IP, nome do host, máscara de rede, e transmitir o endereço. Salve esta informação e logo saída fora do Windows ao DOS pronto para concluir o cheque da instalação.
A figura 10.3. O grupo de programa Chameleon.
Por causa das variáveis de instalação diferentes encontradas com motoristas de rede diferentes, é aconselhável verificar os seguintes arquivos de configuração manualmente:
AUTOEXEC.BAT
CONFIG.SYS
PROTOCOL.INI
SYSTEM.INI
As seções seguintes discutem cada um destes arquivos mais detalhadamente. Se os arquivos não mandarem especificar a informação neles, acrescente-os com um editor de texto. O fracasso de verificar os arquivos propriamente pode resultar no Windows que é incapaz à bota propriamente. Se isto acontecer, copie os arquivos de reserva no lugar dos arquivos recentemente modificados, reinicie o Windows, e reinstale ou reconfigure segundo a necessidade.
As modificações de AUTOEXEC.BAT arquivo necessário para permitir a Cameleão correr são a inclusão do diretório de instalação na variável de ambiente de CAMINHO e uma ordem de lançamento de rede. Se o Cameleão se instalar em um Windows do sistema de Grupos de trabalho, a ordem de lançamento de rede já deve existir.
A variável de ambiente de CAMINHO deve modificar-se para incluir o diretório de instalação de Cameleão, que à revelia é C:\NETMANAG. Uma afirmação de CAMINHO existente pode alterar-se, ou uma nova linha pode acrescentar-se em baixo da afirmação de CAMINHO existente que parece a isto:
PATH=C:\NETMANAG;%PATH%
Naturalmente, o passeio correto e o subdiretório devem substituir-se. Este capítulo assume valores à revelia em todas as partes.
A ordem
C:\WINDOWS\NET START
já está no AUTOEXEC.BAT arquivo se um Windows do sistema de Grupos de trabalho se usar (qualquer versão 3.1 ou 3.11). Se o Cameleão se instalar em um Windows (não Windows de Grupos de trabalho) sistema, a ordem de NETBIND incluída com o software de distribuição deve chamar-se também:
C:\NETMANAG\NETBIND
O cameleão poderia instalar uma ordem de AÇÃO NO AUTOEXEC.BAT arquivo se um não existe. Se um não existir, é aconselhável acrescentá-lo se os outros puderem acessar a máquina. A AÇÃO é uma utilidade de DOS que ativa a repartição do arquivo e o fechamento do registro. Se outras máquinas estarão acessando a máquina, a AÇÃO é necessária para prevenir mensagens de erro e geadas de sistema potenciais quando os conflitos de arquivo ocorrem.
O concluído AUTOEXEC.BAT arquivo parece a isto para um Windows de Grupos de trabalho 3,1 ou 3,11 instalação:
PATH=C:\NETMANAG;%PATH% C:\WINDOWS\NET START SHARE
e como isto para uma instalação de Windows:
PATH=C:\NETMANAG;%PATH% C:\NETMANAG\NETBIND SHARE
Se a ordem de NETBIND ou PARTIDA LÍQUIDA não se realizar propriamente, o Windows expõe uma mensagem de erro quando carrega. Em alguns casos, o Windows pode fechar enquanto tenta acessar os drivers de rede.
O arquivo CONFIG.SYS poderia ser consideravelmente diferente para cada instalação. O motorista de dispositivo de memória HIMEM necessita-se, e o SMARTDRIVE que escondendo de sistema se recomenda. Todas as instalações devem ter valores adequados dos ARQUIVOS e colocações de BUFFERS, que se estabelecem normalmente pelo Windows quando se instala. O CONFIG.SYS deve ter estes valores como um mínimo:
BUFFERS=30 FILES=30 LASTDRIVE=Z STACKS=9,256
Isto cria bastante arquivo e colocações de buffers para permitir a múltiplos arquivos estar abertos ao mesmo tempo. Os valores mais altos são melhores, embora haja uma troca da eficiência uma vez que os valores excedem certo valor (dependendo do montante da memória de acesso aleatório em um sistema). A colocação de LASTDRIVE permite a mais passeios estar abertos do que se une fisicamente ao sistema. Isto é necessário quando os passeios remotos se montam, por Windows de Grupos de trabalho ou por Cameleão.
Para um Windows ou Windows de Grupos de trabalho 3,1 sistema, o Cameleão acrescenta as seguintes ordens ao arquivo CONFIG.SYS:
DEVICE=C:\NETMANAG\PROTMAN.DOS /I:C:\NETMANAG DEVICE=C:\NETMANAG\EXP16.DOS DEVICE=C:\NETMANAG\NETMANAG.DOS
Estes carregam os drivers de dispositivo do gerente de protocolo, o cartão de interface de rede e o protocolo específico do Cameleão. O gerente de protocolo e os motoristas de dispositivo de cartão de interface de rede discutiram-se na seção de DOS antes hoje.
O Windows de Grupos de trabalho 3.11 normalmente tem uma ordem no arquivo CONFIG.SYS que parece a isto:
DEVICE=C:\WINDOWS\IFSHLP.SYS
Isto automaticamente carrega todos os drivers necessários. Em alguns casos, o Cameleão acrescenta a ordem do Windows de motoristas de dispositivo Workgroups 3.1 ao fim do arquivo CONFIG.SYS, mesmo se o motorista IFSHLP.SYS existir. O comentário fora os motoristas de dispositivo acrescentados e tenta o sistema sem eles. O motorista de dispositivo IFSHLP.SYS deve ser suficiente.
O Windows SYSTEM.INI entra necessita que algumas modificações assegurem que o Cameleão se carrega propriamente. Estes devem efetuar-se pela escrita de instalação, mas verificar as linhas cuidadosamente de qualquer maneira.
[Bota] seção de SYSTEM.INI o arquivo deve ter duas seguintes linhas:
[boot] shell=progman.exe network.drv=C:\NETMANAG\MULT400.DRV
A linha de concha poderia ser diferente se o sistema usa um gerenciador de programas de substituição (como Instrumentos de PC de Ponto central do Gerente de Desktop de Windows). O motorista MULT400 apoia várias redes de uma vez. A ordem destas linhas em SYSTEM.INI o arquivo não é importante, enquanto aparecem na seção própria. O motorista MULT400 cuida do carregamento de todos os motoristas necessários de cada rede. O Windows de Grupos de trabalho deve ter esta linha
network.drv=wfwnet.drv
comentou fora com um ponto-e-vírgula na partida da linha ou retirou inteiramente. O motorista WFWNET é o Windows do motorista de rede de Grupos de trabalho, que deve substituir-se por MULT400.
A [boot.description] seção de SYSTEM.INI arquivo modifica-se para
[boot.description] network.drv=NetManage ChameleonNFS
ou uma linha semelhante se outro produto de NetManage se instala.
[O 386Enh] a seção tem várias modificações feitas. Estes são como se segue:
[386Enh] device=C:\netmanag\nmredir.386 network=*vnetbios,*vwc,vnetsup.386,vredir.386,vserver.386 netmisc=ndis.386,ndis2sup.386 netcard= transport=nwlink.386,nwnblink.386,netbeui.386 InDOSPolling=FALSE
A ordem das linhas na seção não importa. Carregam os drivers de dispositivo de rede corretos no núcleo de Windows.
Finalmente, o [motoristas de rede] a seção deve ter estas linhas:
[network drivers] netcard=elnk3.dos devdir=C:\WINDOWS LoadRMDrivers=YES transport=ndishlp.sys,c:\netmanag\netmanag.dos,*netbeui
A linha netcard modifica-se dependendo do cartão de interface de rede usado. A linha de LoadRMDrivers deve modificar-se do Windows do valor à revelia de Grupos de trabalho de NÃO a SIM.
PROTOCOL.INI o arquivo de um Windows da instalação de Grupos de trabalho não necessita muitas modificações. A informação de motorista já deve existir. Uma nova seção acrescentada pelo Cameleão deve parecer a isto:
[NETMANAGE] DRIVERNAME=netmng$ BINDINGS=MS$ELNK3
A linha de BINDINGS modifica-se dependendo do cartão de interface de rede. É o mais fácil copiar a linha de outra seção do PROTOCOL.INI arquivo.
Uma vez que o Cameleão instalou-se e os arquivos de lançamento verificam-se para o conteúdo próprio, pode configurar o software da máquina de mostra. Isto faz-se pela aplicação de COSTUME de Cameleão. Quando começado, o COSTUME expõe uma tela de posição como mostrado na Figura 10.4.
A figura 10.4. A tela Chameleon Custom.
Se a rotina de instalação não acrescentou o nome da máquina e endereço IP à tela Custom, use o item de menu Setup para selecionar os aspectos diferentes da configuração que deve especificar-se. Deve fornecer um nome de máquina, endereço IP, máscara de subrede, e nome de domínio, bem como a interface se não já acrescentado (Ethernet, neste caso).
Para digitar os nomes de outras máquinas na rede e os seus endereços IP, selecione a opção de Mesa de Anfitrião de menu Services de expor a caixa de diálogo Host Table. Para acrescentar outras máquinas na rede de mostra, digite um nome na porção superior da janela no Nome Oficial intitulado do campo e clique no botão Add. Isto mostra uma janela do endereço IP, que deve preencher-se completamente. Então clique em OK. O endereço IP e o nome de máquina introduzem-se agora na mesa de anfitrião. Esta janela mostra-se na Figura 10.5 com o endereço da máquina merlin acrescentada. Se uma máquina tiver mais de um nome, os nomes diferentes podem acrescentar-se como pseudônimos por esta tela, também.
A figura 10.5. A caixa de diálogo Host Table IP Address de cameleão.
Depois que as modificações dos quatro arquivos de configuração concluem-se, reiniciam o Windows de partida e o sistema. Olhe para mensagens de erro como as linhas de Cameleão no CONFIG.SYS e AUTOEXEC.BAT os arquivos realizam-se. Se o Windows de Grupos de trabalho se instalou e trabalhando antes da instalação de Cameleão, não devem haver erros.
O modo mais fácil de testar o novo sistema TCP/IP é usar a utilidade de silvo dentro do grupo de programa Chameleon. Quando selecionado, expõe uma pequena caixa de diálogo. Selecione a opção de Partida, que expõe outra caixa de diálogo que espera por um nome de máquina. Digite o nome da máquina local. Isto mostra-se na Figura 10.6 do pimentão de máquina de Windows de rede de mostra.
A figura 10.6. Usar silvo para testar o anfitrião local.
A janela de silvo deve mostrar um resultado bem sucedido. Isto indica-se por uma mensagem mostrando o número de bytes recebidos, bem como informação de tempo. Uma produção de mostra de uma tentativa bem sucedida de silvar a máquina local mostra-se na Figura 10.7.
A figura 10.7. silve mensagens diagnósticas.
Se a tentativa de silvo não for bem sucedida, o Cameleão expõe uma mensagem sobre os motoristas de rede não instalados ou sobre anfitriões inalcançáveis. Recebendo tal mensagem, verifique as colocações de placa de rede e toda a informação sobre configuração pelo programa CUSTOM.
O seguinte passo deve usar o silvo para enviar a outra máquina na rede. A figura 10.8 mostra a produção de uma tentativa de silvo em freya, o servidor de Linux da rede de mostra e a whitney, a máquina do Windows 95 que não se inicializa (e daqui deve falhar). O sistema acabou na tentativa de whitney, como esperaria.
A figura 10.8. silvo através de uma rede.
Se as tentativas de silvo através da rede falharem em todas as máquinas, o problema é provável com a configuração. Verifique toda a informação sobre configuração (como anteriormente observado), bem como os fios de rede e cartões. Assegure-se que as máquinas a silvar-se estão no fim e dirigindo TCP/IP.
Se a rede estiver funcionando propriamente, tente o ftp e aplicações telnet do grupo de programa Chameleon. As instruções cheias desta utilidade estão na documentação. Enquanto uma entrada na tabela de anfitrião criou-se e o silvo consegue-se, outra utilidade deve funcionar propriamente. Ambos fornecem uma interface gráfica que os usuários de Windows acharão familiar, em vez da interface de linha baseada no caráter encontrado com o DOS. Configurar funções mais complicadas dentro do Cameleão (como SNMP, correio, e encaminhamento de Portão), consultam a documentação de Cameleão.
O cliente final na rede de mostra que necessita a configuração é whitney chamado da máquina, com o endereço IP 147.120.0.10. O Windows 95 é o mais fácil dos três clientes configurar porque tudo tem de fundar TCP/IP abaixo do Windows 95 se inclui com a distribuição de software. O Windows 95 configura-se à revelia para usar NetWare IPX/SPX como o protocolo de rede, mas ligando a TCP/IP é bastante fácil.
Comece o processo de configuração do Windows 95 instalando o cartão de adaptador de rede. Em alguns casos, quando reinicia o Windows 95 o sistema operacional automaticamente reconhece a adição da placa de rede e prossegue às rotinas de configuração para você. Em muitos casos, entretanto, tem de instruir o Windows 95 para procurar o cartão de adaptador de rede.
Para instalar um cartão de adaptador de rede, abra o Painel de controle do Windows 95 e clique duas vezes no ícone Add New Hardware. Isto chama Acrescentar Novo Mago de Hardware. Depois que clica no botão Next no diálogo introdutório, o Windows 95 dá-lhe a opção de ter a tentativa de sistema operacional de descobrir o novo hardware automaticamente.
É normalmente o melhor para deixar o Windows 95 tentar encontrar o adaptador de rede por si mesmo, especialmente se o novo cartão for um tipo de tomada-e-jogo. Se o Windows 95 puder identificar o hardware automaticamente, salva-o tendo necessidade de fornecer a informação sobre configuração. Se quiser que o Windows 95 progrida e procure o adaptador de rede, selecione o botão Yes neste diálogo (o valor à revelia) e clique no botão Next. O Windows 95 começa a procurar o sistema o novo hardware. Se o Windows 95 descobrir uma nova placa de rede, expõe uma tela mostrando os parâmetros descobriu-o e deixa-o confirmar a seleção. Depois de uma reiniciação, a placa de rede deve reconhecer-se propriamente e ativa.
Se o Windows 95 não descobriu o adaptador de rede, tem de instalá-lo e configurá-lo manualmente. O Windows 95 mostra um diálogo como aquele na Figura 10.9. Clicar no botão Next expõe o diálogo mostrado na Figura 10.10, que pede o tipo do novo dispositivo de hardware que instala. Neste caso, clica duas vezes na opção de Adaptadores de rede.
A figura 10.9. Este diálogo expõe-se se o Windows 95 não pode descobrir um novo cartão de adaptador de rede.
A figura 10.10. Este diálogo pede o tipo do hardware que instala.
O seguinte diálogo a aparecer mostra uma lista de fabricantes de cartão de adaptador de rede no lado abandonado e uma lista mais detalhada de modelos de placa de rede do fabricante selecionado à direita. Selecione o fabricante próprio do cartão de adaptador de rede na lista no esquerdo pelo clique único o nome do fabricante, logo selecione o nome na lista de lado direito que combina com o cartão específico.
Deve ser cuidadoso que combina com o nome do cartão de adaptador exatamente com a lista, porque alguns motoristas não trabalham em outros cartões do mesmo fabricante. Se selecionar o cartão de adaptador incorreto, não causará nenhum dano ao cartão ou ao Windows 95, mas a rede não se encontrará propriamente pelo Windows 95. Se não puder encontrar o determinado nome modelar do cartão de adaptador de rede usa, mas manda prover a um motorista no disco, usa o botão Have Disk para ler o driver no Windows 95.
Uma vez que selecionou o nome de placa de rede próprio, o Windows 95 expõe uma janela com a informação sobre configuração mostrada nele. Este diálogo mostra-se na Figura 10.11. O montante da informação sobre configuração mostrada neste diálogo e as colocações que mostra, é diferente para cada cartão de adaptador de rede.
A figura 10.11. O Windows 95 usa este diálogo para pedir as colocações de configuração da placa de rede.
Se o adaptador de rede se encontrou pela autodetecção, as colocações mostradas neste diálogo são aqueles o Windows 95 assumido é correto para o cartão. Se o Windows 95 não pode encontrar a placa de rede, as colocações mostradas são os valores à revelia normalmente usados pelo fabricante. Verifique a documentação fornecida com o cartão de adaptador de rede para confirmar as colocações. Depois que confirma que os valores expostos são corretos, o Windows 95 instala o software necessário para dirigir o cartão de adaptador de rede.
Pode instalar os drivers TCP/IP incluídos com o Windows 95 expondo o diálogo de Rede. Clique no ícone Network no Painel de controle para expor o diálogo de Rede mostrado na Figura 10.12. O diálogo deve mostrar algumas entradas básicas criadas quando o Windows 95 se instalou, bem como o cartão de hardware de rede. À revelia, NetBEUI ou NetWare (IPX) protocolos já poderiam carregar-se.
A figura 10.12. A janela Network mostra todo o hardware configurado e protocolos.
Para acrescentar os motoristas de protocolo TCP/IP ao Windows 95, selecione o botão Add em baixo da lista de componentes instalados para expor o diálogo de Tipo de Componente de Rede Escolhido mostrado na Figura 10.13. Esta janela pede o tipo do componente (cartão de adaptador, protocolo, serviço ou cliente) quer instalar. Como quer instalar os motoristas de protocolo TCP/IP, escolher o Protocolo. O diálogo de Protocolo de Rede Escolhido, mostrado na Figura 10.14, expõe-se.
A figura 10.13. O diálogo de Tipo de Componente de Rede Escolhido deixa-o acrescentar um protocolo, cliente, serviço ou cartão de adaptador.
A figura 10.14. O diálogo de Protocolo de Rede Escolhido deixa-o escolher o tipo do protocolo para acrescentar.
Da janela Select Network Protocol, selecione Microsoft na lista de rolo de papel esquerda, logo mova-se para a janela direita, que enumera todos os protocolos de Microsoft fornecidos com o Windows 95. Escolha a entrada TCP/IP. Devolve-se ao diálogo de Rede, e TCP/IP enumera-se como um protocolo apoiado.
Para começar o processo de configuração, clique duas vezes na entrada de protocolo TCP/IP na lista de diálogo de Rede, ou selecione a entrada de protocolo TCP/IP e clique na janela Properties. O diálogo de Propriedades TCP/IP aparece, como mostrado na Figura 10.15.
A figura 10.15. O diálogo de Propriedades TCP/IP tem seis páginas da informação sobre configuração.
Do diálogo de Propriedades TCP/IP, seis páginas da informação estão disponíveis escolhendo uma das etiquetas através do topo do diálogo. Para a maior parte de instalações tem de fornecer a só uma pequena parte desta informação. Pode começar com a página de Endereço IP, que é a primeira página mostrada sempre que a janela TCP/IP Properties se exponha. Entre no endereço IP e máscara de subrede nos espaços contanto que, assegurando-se para guardar as quatro partes da notação salpicada e de quadrângulo separada.
Algumas redes corporativas maiores fundam-se para destinar endereços IP a clientes se unem que automaticamente usam um protocolo especial. Este protocolo, chamado servidores de Dynamic Host Configuration Protocol (DHCP), usa-se normalmente para máquinas que se unem a uma rede TCP/IP só ocasionalmente. Se a sua rede usar DHCP, pode selecionar o primeiro botão na página de Endereço IP e deixar o Windows 95 obter o seu endereço IP e máscara de subrede para você. A maior parte de redes não usam DHCP.
Depois, move-se para a página Promovida do diálogo de Propriedades TCP/IP selecionando a Folha adicional em cima do diálogo. Este diálogo deixa-o especificar que TCP/IP é o protocolo à revelia usado pela máquina do Windows 95 clicando na opção no fundo da página, como mostrado na Figura 10.16. Se o seu sistema do Windows 95 se anexar a uma rede TCP/IP e usar TCP/IP a maior parte do tempo, assegure-se que seleciona esta opção; de outra maneira, a Janela 95 tenta usar NetBIOS ou IPX/SPX na rede TCP/IP.
A figura 10.16. Selecione a opção à revelia da página Promovida do diálogo de Propriedades TCP/IP.
Para muitas redes TCP/IP simples, isto é toda a informação que tem de fornecer. O Windows 95 agora carrega os drivers próprios no sistema operacional, usando os valores fornecidos para a máscara de subrede e o endereço IP. Depois que o software carregou-se propriamente, o Windows 95 deve reiniciar-se para fazer os motoristas TCP/IP eficazes.
Alguns sistemas TCP/IP necessitam que a extra configuração proveja o Windows 95 do nome dos servidores, portões ou outros detalhes. Pode fazer muitos destes passos de configuração em qualquer momento, mas alguns serviços não poderiam estar disponíveis para você até que faça. Todas destas modificações fazem-se por meio do diálogo de Propriedades TCP/IP usado para estabelecer a máscara de subrede e o endereço IP.
A página de Configuração de VITÓRIAS da janela TCP/IP Properties usa-se para instruir o seu sistema do Windows 95 como falar com um servidor de Windows Internet Naming Service (WINS). As VITÓRIAS deixam-no usar o protocolo de NetBIOS em uma rede TCP/IP. A maior parte de redes não usam VITÓRIAS, portanto pode ignorar provavelmente esta página completamente a menos que saiba que precisará de usar VITÓRIAS na sua rede. Se as VITÓRIAS se necessitarem na sua rede, entre no endereço IP da eleição prévia (e secundário, se usado) GANHA servidores, bem como a carteira de identidade de Alcance. Se as VITÓRIAS não se usarem na sua rede, assegure-se que a opção de Resolução de VITÓRIAS Inutilizar se seleciona.
A página de Portão deixa-o especificar onde os portões da sua rede são. Os portões usam-se para unir-se a outras redes, inclusive a Internet. Se a sua rede usar um portão, entre no endereço IP da máquina de portão de rede primária e clique no botão Add. Pode entrar em muitos portões no Windows 95, mas sempre deve fornecer o endereço IP de portão primário primeiro (porque o Windows 95 procura a lista de portões na ordem).
A página de Configuração DNS deve concluir-se se a sua rede usar Domain Name System (DNS). DNS executa uma conversão entre um endereço IP e um nome simbólico. DNS necessita uma configuração de rede especial e servidor, portanto as pequenas redes improvavelmente usarão DNS. Se a sua rede estiver dirigindo DNS, pode digitar o nome simbólico da sua máquina, o nome de domínio (o nome do seu grupo de trabalho ou companhia inteira), e o endereço IP do seu servidor DNS nesta página. Depois que o Windows 95 uniu-se ao servidor DNS e disse-lhe o seu endereço IP e nome simbólico, outros usuários da rede podem unir-se à sua máquina usando o seu nome simbólico. Semelhantemente se sabe o nome simbólico de uma máquina remota, pode usar isto para unir-se a ele em vez do endereço IP.
A página final da janela TCP/IP Properties é a página de Bindings. Esta página enumera todos os componentes de rede que usam o protocolo TCP/IP. Se instalou outros protocolos de ligação em rede no seu sistema do Windows 95, poderiam haver mais entradas na lista de Bindings. Só selecione aqueles que usam o protocolo TCP/IP. Minimizar o número de bindings de cada protocolo ajuda a melhorar a eficiência do software de ligação em rede do Windows 95.
Uma vez que instalou a placa de rede e software, pode testar o novo protocolo TCP/IP. A melhor utilidade de uma verificação rápida da sua conexão de rede TCP/IP é silvo. A utilidade de silvo fornecida com o Windows 95 é uma aplicação de DOS, não o Windows 95, portanto deve lançar-se em uma janela DOS. Normalmente reside no mesmo diretório que arquivos do Windows 95 (normalmente \windows).
Para usar o silvo, digite o nome ou endereço depois da ordem de silvo no DOS pronto. A utilidade de silvo então envia e recebe pacotes da informação. Se as mensagens como Mau Endereço IP, Pedido Acabado, ou anfitrião Desconhecido se expuserem, o silvo não pode unir ou resolver o nome ou endereço IP que forneceu.
Neste ponto, se com sucesso enviou e recebeu pacotes, tudo é bem com a conexão TCP/IP. Se o silvo expôs mensagens de erro ou não pode enviar e receber pacotes sobre a rede, deve verificar que o endereço IP é válido. Se for, tente outra máquina na rede para silvar a máquina do Windows 95. Se não puder, então o adaptador de rede ou o protocolo na máquina do Windows 95 não se carregam propriamente.
Para algum Windows e usuários do Windows 95, Winsock é o método mais fácil para entrar em TCP/IP porque está disponível de muitos domínio público, sistema de boletins por computador e sítios de serviço online. Há várias versões de Winsock, alguns dos quais são o domínio público ou o shareware. Olharemos para duas versões de Winsock, um para o Windows 3. X e o outro para o Windows 95. Escolhemos a Trompa popular implementações de Winsock de ambos os sistemas operacionais porque são shareware, prontamente disponível, e bem apoiado.
Winsock é curto para Tomadas de Windows, originalmente desenvolvidas por Microsoft. Lançado em 1993, as Tomadas de Windows são uma interface da programação de rede no ambiente de Windows. Microsoft publicou as especificações de Tomadas de Windows, daqui fazendo-o uma interface de programação de aplicação (API) aberta. O Winsock API (chamou WSA) é uma biblioteca de chamadas da função, estruturas de dados e procedimentos de programação que fornecem esta interface estandardizada para aplicações. O segundo lançamento de Winsock, chamado a versão 2 de Winsock, lançou-se a meados de 1995.
A trompa Winsock é uma implementação gratuita de Winsock produzido por Trumpet Software International. A trompa Winsock está disponível para sistemas do Windows 95 e o Windows 3. X. O registro do pacote de Winsock, desenvolvido na Austrália, é os EU de US$ 25. A trompa Winsock deixa-o usar vários protocolos diferentes inclusive PPP e ERRO da conexão à Internet ou redes remotas, conexão direta usando TCP/IP e o protocolo BOOTP. Winsock de trompa permite o endereçamento de IP dinâmico, que é necessário com muitos Fornecedores de serviços de Internet.
A Trompa os arquivos de Winsock fornecem-se normalmente em um arquivo arquivo de CÓDIGO POSTAL e devem extrair-se em um novo subdiretório no seu sistema. Os arquivos primários na Trompa distribuição de Winsock são
Há um número de arquivos de configuração de mostra incluídos no arquivo, bem como utilidade como SILVO e PULO. Alguns arquivos no arquivo de Winsock, como ANFITRIÕES, PROTOCOLO, e SERVIÇOS, refletem arquivos UNIX do mesmo nome.
O processo de instalação da Trompa Winsock é o mesmo se usa SLIP/PPP para a conexão ou um motorista de pacote de operações baseadas na LAN. Comece a instalação acrescentando o diretório mantendo a Trompa arquivos de Winsock ao seu CAMINHO. Os arquivos devem extrair-se, naturalmente, do arquivo de CÓDIGO POSTAL no qual se fornecem normalmente. Depois que o caminho modificou-se, reinicie a sua máquina para efetuar a modificação.
Pode criar um grupo de programa de Windows da Trompa sistema de Winsock acrescentando um novo grupo de programa dos menus Program Manager. (Selecione o menu File, o item de menu New, e logo Program Group.) Criam um título, como Trompa Winsock. do novo grupo de programa.
Depois, crie um Ícone de Programa do programa de TCPMAN (o programa Trumpet Winsock primário) por criação de um novo Item de Programa do Gerenciador de programas ou por abertura do Gerente de Arquivo e arrasto o TCPMAN.EXE entrada do seu diretório ao grupo de programa Trumpet Winsock. O Windows o incitará para qualquer informação da qual precisa. O ícone de programa lê-se nos arquivos de distribuição se o caminho se estabelecer propriamente.
Para testar a instalação do caminho e o ícone de Windows, clique no ícone de TCPMAN. Se receber mensagens de erro, o CAMINHO não se estabelece propriamente ou o ícone de programa não se definiu propriamente. Como se interessa principalmente na utilização de Winsock em uma rede TCP/IP, ignora a configuração PPP e DESLIZA e se concentra na pilha de TCP/IP.
A trompa Winsock confia em um programa chamado WINPKT para fornecer capacidades de pacote TCP/IP abaixo do Windows. Depois de criar um grupo de programa de Winsock, tem de fundar a informação de motorista a pacote nos arquivos de rede.
Precisará de um motorista de pacote do seu sistema, que não se inclui com a maior parte de Trompa distribuições de Winsock. Em muitos casos, o vendedor de placa de rede inclui um disco com um motorista de pacote nele. Se não, uma das melhores fontes de um motorista de pacote é a coleção de Motorista de Pacote Crynwr, uma biblioteca de motoristas de pacote diferentes disponíveis de muitos online, sistema de boletins por computador, FTP e sítios de WWW. As especificações de motorista de pacote acrescentam-se ao seu arquivo de lote de lançamento de rede, normalmente AUTOEXEC.BAT para sistemas baseados no DOS.
Para obter um driver de pacote de Crynwr, use um Navegador da Web para unir-se a http://www.crynwr.com. Há várias dúzias de motoristas de domínio públicos disponíveis deste sítio.
O processo de configurar a Trompa Winsock da operação de LAN é bastante simples. Estabeleça o IRQ e o endereço de entrada-saída do motorista de pacote e acrescente o motorista de pacote ao seu sistema. Uma entrada típica no arquivo de lote de rede parece a isto:
ne2000 0x60 2 0x300 WINPKT 0x60
Isto faz que a rede use um cartão de tipo de NE2000 (Novell), com o endereço de entrada-saída do 300o, IRQ de 2 e um vetor de 60. Várias configurações provêem-se normalmente da Trompa distribuição de Winsock, embora seja fácil conseguir o seu próprio da documentação de fabricante de cartão de interface de rede.
Para fundar a Trompa Winsock de um motorista de pacote, use a tela Setup que aparece quando TCPMAN se lança primeiro, ou use os cardápios dentro de TCPMAN para expor a tela de organização. Exclua tanto ERRO Interno como colocações PPP Internas. Se qualquer deles se verificar, o motorista de pacote não lançará propriamente.
Entre no endereço IP, netmask, denomine o endereço IP de servidor e a informação sobre nome de domínio. Também pode modificar as entradas do Intervalo de Carga de Exigência, MTU, TCP RWIN, TCP SENHORAS e RTO MAX TCP. Ver a seção na configuração SLIP/PPP em cima para obter mais detalhes sobre alguma destas colocações. Os valores à revelia usados para um motorista de pacote são diferentes do que aqueles para uma colocação de SLIP/PPP. Se estiver usando BOOTP ou RARP para determinar o seu endereço IP de máquina, digite o nome de protocolo próprio no campo de endereço IP.
O campo de Vetor de Pacote deve estabelecer-se no vetor que usou na descrição de placa de rede, ou pode deixá-lo como 00 para deixar a Trompa Winsock procuram o motorista de pacote. Depois que a configuração salva-se, reinício TCPMAN e a rede estarão disponíveis (se a configuração e os motoristas de pacote se estabelecerem propriamente). Uma ordem de silvo ou a utilidade semelhante verificarão que a operação de motorista de pacote é correta.
Hoje aprendeu como instalar e configurar três sistemas baseados no PC: um para DOS e dois especificamente para versões de Windows. Unem-se agora à rede de mostra, e os arquivos podem transferir-se entre as máquinas rapidamente e facilmente. As máquinas de DOS também podem dirigir o Windows de Grupos de trabalho vorazes e apoiados na rede TCP/IP.
A soma de outras máquinas normalmente segue o mesmo procedimento. Por exemplo, para acrescentar um Macintosh que dirige Mac TCP/IP, siga o guia de instalação para instalar e configurar o software, e logo usar o silvo para verificar que tudo trabalha corretamente.