Ir ao conteúdo
  • Cadastre-se

Fernando Lozano

Membro VIP
  • Posts

    10
  • Cadastrado em

  • Última visita

    Nunca

Reputação

0

1 Seguidor

Sobre Fernando Lozano

  1. Tópico para a discussão do seguinte conteúdo publicado no Clube do Hardware: Arquitetura de Redes TCP/IP "Conceitos teóricos que o ajudarão a implementar redes TCP/IP no Windows 95, Windows NT, Netware e outros sistemas populares no mercado." Comentários são bem-vindos. Atenciosamente, Equipe Clube do Hardware https://www.clubedohardware.com.br
  2. Tópico para a discussão do seguinte conteúdo publicado no Clube do Hardware: Software Corrompido no PC "Saiba mais sobre softwares corrompidos e nossas sugestões para correção deste problema." Comentários são bem-vindos. Atenciosamente, Equipe Clube do Hardware https://www.clubedohardware.com.br
  3. Tópico para a discussão do seguinte conteúdo publicado no Clube do Hardware: Certificação A+ "Aprenda sobre a certificação A+, destinada a técnicos de hardware." Comentários são bem-vindos. Atenciosamente, Equipe Clube do Hardware https://www.clubedohardware.com.br
  4. Tópico para a discussão do seguinte conteúdo publicado no Clube do Hardware: Controlando o PC Remotamente Com o VNC "Aprendar a controlar computadores remotamente através do programa VNC." Comentários são bem-vindos. Atenciosamente, Equipe Clube do Hardware https://www.clubedohardware.com.br
  5. Tópico para a discussão do seguinte conteúdo publicado no Clube do Hardware: Projeto de Redes TCP/IP "Aprenda a fazer projetos de redes TCP/IP." Comentários são bem-vindos. Atenciosamente, Equipe Clube do Hardware https://www.clubedohardware.com.br
  6. VNC significa Virtual Network Computing e é um programa que permite visualizar e interagir com o desktop de um computador em qualquer parte do mundo. Muito semelhante a programas já conhecidos como o Carbon Copy ou o PC Anywhere, entretanto com algunas vantagens importantes: O VNC é completamente gratuito! Múltiplos usuários podem se conectar ao mesmo desktop, ideal para treinamento (você pode dar aos alunos acesso "read only" ao seu desktop). Se a sua conexão cair, você não perde a sessão do VNC. Basta reconectar e as aplicações remotas estarão exatamente do mesmo jeito que estavam antes da conexão cair. O visualizador do VNC é um programa de menos de 160Kb roda em Windows, OS/2, Linux, Unix, Amiga, Mac e até no Palm Pilot (embora eu acho que seja necessário muita rolagem para ver o desktop de um PC na tela do Pilot...). Não há necessidade de se instalar o visualizador, que pode ser executado diretamente de um diskete. Na verdade você não necessita de visualizador nenhum, qualquer browser com suporte a Java pode ser utilizado como visualizador. O "servidor" do VNC hoje roda em Windows e em Unix (incluindo Linux) e está em desenvolvimento a versão Mac. O Windows pode controlar um desktop Linux e vice-versa, ou um Amiga pode controlar o seu Windows NT Server. O VNC é independente de plataforma. O VNC utiliza TCP/IP, portanto você pode controlar outro computador via Internet. Nem tudo são flores, entretanto. Se você está acostumado a utilizar programas de controle remoto para DOS e Windows, sentirá falta de alguns recursos no VNC: O VNC não é capaz de discar ou de aceitar conexões via modem por si só. Ele funciona via TCP/IP exclusivamente. O VNC não inclui recursos de impressão ou de cópia de arquivos do micro remoto para o micro local. Entretanto, essas deficiências podem ser compensadas pelo próprio TCP/IP. Existem na internet dezenas de servidores e clientes TCP/IP que podem ser utilizados para a cópia de arquivos, ou se você estiver em Linux, OS/2 ou Windows o sistema pode ser configurado para compartilhar arquivos pela conexão TCP/IP sem necessidade de software extra. E os servidores PPP disponíveis no Windows NT, Windows 98 (para o Windows 95 é necessário o Plus!), OS/2 e Linux podem permitir a máquia atender chamadas telefônicas e ser controlada via modem.Por fim, a falta de impressão também pode ser contornada pelos recursos de rede nativos do Windows, OS/2 e Linux, ou configurando um servidor LPD (também existem disponíveis na Internet). O VNC surgiu como um projeto de pesquisa da Olivetti Research Laboratories, hoje propriedade da AT&T, cujo objetivo era criar um "terminal gráfico" de rede extremamente leve. O endereço atual da home-page do VNC é http://www.cl.cam.ac.uk/research/dtg/attarchive/vnc/index.html e neste local você encontra todas as versões do VNC para diversas plataformas, além de documentação e informações sobre como contribuir para o projeto. O VNC utiliza dois componentes independentes, o servidor e o visualizador (cliente). O servidor fornece o desktop ao qual os clientes podem se conectar. Portanto, o computador a ser controlado remotamente tem que ter o VNC instalado e o servidor deve estar executando. Já o cliente necessita somente do visualizador do VNC (VNC Viewer) ou de um browser que suporte Java (Netscape 2.0 em diante, Internet Explorer 3.0 ou superior, Opera 3.0 e outros). Múltiplos clientes (visualizadores) podem se conectar ao mesmo servidor, e no Windows isto significa que eles todos irão interagir com o mesmo desktop. Mas se o servidor for Unix (sempre que falarmos de Unix o Linux está incluído) há a opção de se conectar a um deskop já existente, compartilhado com outros usuários, ou de se conectar a um desktop exclusivo. Como o Unix é um sistema multiusuário podem haver vários desktops independentes sendo utilizados ao mesmo tempo por diferentes usuários. Já o Windows, mesmo o NT Server, é monousuário, e pode ter somente um único desktop ativo em um dado momento. Note que neste ponto o VNC é diferente de produtos como o WinFrame da Citrix ou o Windows NT Terminal Server Edition, que teoricamente permitem a existência de diversos desktops simultâneos em um NT Server. Estes produtos modificam o kernel do NT na tentativa de torna-lo um sistema multiusuário, mas o resultado é instabilidade e incompatibilidade com diversas aplicações. Ocasionalmente você pode corromper o Registry do NT com um produto desses. Por outro lado, o VNC permite que você administre remotamente um servidor NT sem necessidade de estar fisicamente presente. Se o servidor do VNC estiver rodando como um serviço, você pode assumir a tela de logon do console do servidor NT, realizar qualquer tarefa necessária, e depois dar um logoff. Desta forma o seu servidor pode ficar isolado em uma sala trancada, ou em uma bancada ou rack de servidores sem necessidade de um monitor SVGA e de um mouse. É muito fácil instalar o VNC: basta baixar a versão Windows na home-page do VNC, que vem em formato ZIP. Descompacte o arquivo em um diretório temporário e execute o programa SETUP.EXE presente neste diretório. Após as perguntas tradicionais sobre nome do diretório e nome da pasta no menu iniciar, o VNC estará pronto para uso. Na primeira vez que você executar o WinVNC deverá aparecer uma janela como esta: Figura 1: Opções do servidor do VNC. Você não poderá executar o servidor sem que seja fornecida uma senha para os clientes se conectarem. A senha será gravada em um arquivo de configuração do WinVNC e das próximas vezes o servidor VNC será iniciado sem exibir a janela de opções. Entretanto, você pode abrir esta janela a qualquer momento pelo menu iniciar (Figura 2) ou pelo ícone do VNC no System Tray do Windows (Figura 3). A maioria das opções nesta janela se referem a otimizações de baixo nível ou para resolver problemas com aplicações mal-comportadas, em geral aplicações DOS. Na grande maioria das situações você irá modificar somente a opção Disable remote keyboard and pointer. que permite aos clientes visualizarem tudo o que acontece no desktop do servidor mas ignora toda a entrada via teclado ou mouse dos clientes. Figura 2: Pasta do VNC no Menu Iniciar do Windows. Figura 3: Ícone do VNC no System Tray do Windows. Os ícones presentes na figura são, da esquerda para a direita, o Personal Web Server da Microsoft, o 20/20 (editor de imagens freeware, utilizado para as capturas de telas deste artigo) e o WinVNC, que é o servidor do VNC. Depois que tudo estiver ok com o VNC, você irá desejar executa-lo como um serviço de modo que o servidor esteja sempre disponível para conexões remotas. Instruções passo a passo para esta configuração podem ser obtidas no site do VNC em http://www.uk.research.att.com/vnc/winvnc.html. Basicamente, para rodar o VNC com um serviço no Windows NT basta rodar o WinVNC com a opção -install. Você pode então Selecionar a opção Executar... do Menu Iniciar do Windwos NT e digitar o comando: winvnc -install. O serviço estará instalado, mas não iniciado. Para inicia-lo basta selecionar o serviço no ícone de Serviços do Painel de Controle e clicar no botão Iniciar. No Windows 95/98, basta criar um atalho para o WinVNC.exe na pasta Iniciar. Estando o servidor do VNC rodando no PC que você deseja controlar remotamente, e havendo uma conexão TCP/IP entre você e ele, iniciar a sessão de controle remoto é muito fácil. Basta rodar o arquivo VNCVIEWER.EXE (ou executar o atalho correspondente no menu do VNC, se você também tem o servidor instalado na máquina cliente). O cliente do VNC irá iniciar exibindo a seguinte janela (Figura 4): Figura 4: Janela de Conexão do cliente (ou visualizador) do VNC. Você deverá fornecer o nome ou o endereço IP do computador a ser controlado, seguindo por um sinal de dois pontos e pelo número zero. Se você estiver se conectando a um servidor VNC em Unix, o número indica qual dos desktops (no Unix é utilizado o termo display) será utilizado, mas em servidores Windows temos um único desktop que é o número zero. O visualizador do VNC irá requisitar a senha do desktop que será acessado (Figura 5) e então ele estará disponível para uso, como mostra a Figura 6. Figura 5: Visualizador do VNC aguardando pela senha do desktop remoto. Figura 6: Desktop remoto sendo controlado pelo cliente do VNC. Na Figura 5 o desktop remoto estava configurado para uma resolução menor do que o PC onde rodava o visualizador, entretanto isto não é necessário. Caso o desktop remoto tenha resolução maior do que o PC local (que roda o visualizador) aparecerão barras de rolagem na janela do VNC. Também é possível colocar o visualizador em modo full screen através da janela de opções do cliente (Figura 7), para permitir uma melhor visualização do desktop remoto. Figura 7: Janela de opções do visualizador do VNC. A janela de opções do cliente (Figura 7) pode ser acessada pelo botão Options... na janela de conexão ou pelo menu de sistema no canto superior esquedo da janela do visualizador. O menu de sistema também pode ser acessado pela barra de tarefas do Windows. Se o visualizador estiver em modo full screen, Você deve teclar [Ctrl] + [Esc] para exibir a barra de tarefas, e com a barra de tarefas visível você deve clicar em um espaço vazio da barra de tarefas para que ela receba o foco, caso contrário o VNC Viewer em full screen não permitirá que a barra de tarefas receba o click do botão direito do mouse e você não poderá acessar o menu de sistema das janelas. A Figura 8 mostra o menu de sistema do visualizador do VNC, com a opção full screen selecionada. Figura 8: Menu de sistema do visualizador do VNC. Dentre as opções do cliente, as únicas que você vai querer modificar em situações normais são Emulate 3 buttons (necessária caso o desktop remoto esteja seja Unix) e Request shared session (para compartilhar um desktop com outros clientes). Se esta opção não estiver ligada e você se conectar a um desktop Windows que já esteja sendo acessado por outro cliente, ele será desconectado sem dó nem piedade. É possível criar vários atalhos pré-configurados no Windows para chamar o VNC viewer com as opções desjeadas. Basta criar um atalho para o VNCVIEWER.EXE e nas propriedades do atalho inserir como "alvo" as opções desejadas, por exemplo: C:utilvncviewer.exe -shared -viewonly -fullscreen sun:2. Estas opções se conectam a um desktop compartilhado em sun:2 (segundo desktop remoto de um host Unix; o zero é o monitor da estação e não pode ser acessado via VNC, ao contrário do que ocorre no servidor Windows) apenas para visualização. Este seria um atalho para uso em sala de aula ou em uma demonstração de produto. Com a mesma facilidade podemos controlar um PC utilizando apenas um browser web, e o que é surpreendente, com praticamente a mesma velocidade do visualizador Windows nativo. Basta passar para o browser a URL contendo o nome ou o endereço IP do PC a ser controlado e indicar como número de porta o número 5800 + o número do desktop a ser conectado. Por exemplo, para se conectar o primeiro e único desktop do PC cujo nome é NT_1 a URL seria: http:NT_1:5800 . Ou para se conectar ao segundo desktop do servidor Unix cujo endereço IP é 172.16.2.30 a URL seria: http:172.16.2.30:5802. O resultado é uma página HTML contendo somente um Applet Java, como mostra a Figura 9: Figura 9: Conecando-se a um PC utilizando o Netscape Communicator. Você pode então digitar a senha do desktop remoto, ou clicar no botão Options para ver a janela de opções do applet (Figura 10). Figura 10: Janela de opções do visualizador do VNC dentro do Netscape Communicator. O desktop remoto aparece dentro do applet, como mostra a Figura 11: Figura 11: Desktop remoto via Netscape Communicator. Observe na Figura 11 a URL digitada. Desta vez eu escolhi propositadamente um PC com resolução maior do que do meu PC, só para demonstrar que isso não é problema para o VNC. Muitas vezes você não sabe o endereço IP do desktop ao qual você deseja se conectar, principalmente se ele será utilizado via Internet. A maneira mais fácil de descobrir o IP é, no PC remoto, abrir uma janela do MS-DOS e executar o programa winipcfg (Windows 95/98) ou ipconfig (Windows NT). O WinVNC não prevê criptografia por si só. Isto significa que a senha de conexão ou as telas podem ser alvo de "escuta" pela Internet. Entretanto o VNC pode ser utilizado via SSH (em Unix, pelo menos) ou via algum software de VPN. O RAS do Windows NT Server é capaz de estabelecer conexões de VPN. Tanto o SSH quanto o VPN fornecem conexões seguras, criptografadas. Várias vezes neste artigo falamos da possibilidade de utilizar o VNC também com Unix e outras plataformas, entretanto demonstramos somente a instalação e a configuração do programa somente em plataforma Windows. Não existe grande diferença na utilização do VNC em Unix ou outras plataformas, e só para dar um "gostinho" da coisa a Figura 12 nmostra o desktop de um servidor Sun SPARC rodando Solaris 2.5 (O Unix da Sun), e a Figura 13 mostra o desktop de um Red Hat Linux 5.2 sendo controlado pelo visualizador do VNC rodando em Windows (o oposto também funciona!). Figura 12: Desktop de um serividor RISC da Sun. Figura 13: Desktop padrão do Red Hat Linux 5.2 via VNC. Os "pontilhados" nas figs. 12 e 13 acontecem porque o palete padrão do Netscape e do Explorer para imagens GIF não contém algumas das cores utilizadas pelo Solaris e pelo Linux.. Se você achou o Red Hat muito parecido com o Windows 95, é proposital: o Red Hat Linux procura fornecer uma interface semelhante ao Windows para facilitar o usuário que está iniciando em Linux. Existem outras opções de desktop para o Linux como o KDE e o Gnome, que tem visual completamente diferente. Se você for instalar o VNC no Red Hat Linux uma supresa lhe aguarda: o script padrão de inicialização do servidor (vncserver) tem que ser editado para funcionar corretamente no Linux. Clique aqui para baixar o arquivo vncserver.rhl que contém as alterações necessárias para o Red Hat Linux 5 e 6. (Dica: clique com o botão direito do mouse sobre o link acima e escolha a opção "salvar como" ou similar). Configurei o VNC na rede local e funcionou perfeitamente, mas não funciona via Internet. Tenho uma conexão ADSL (Velox, Speedy) ou Cable Modem. A maioria dos serviços de acesso a Internet de banda disponíveis fornecem apenas endereços IP privativos, que não podem ser endereçados pela Internet, por isso não é possível a conexão ao VNC, pois não há como endereçar o servidor. Alguns modems ADSL e cable modens possuem o recurso de redirecionamento de portas (que pode ser definido como um NAT invertido). Com este recurso seria possível a conexão ao um VNC na rede interna com IP privativo, pois seria utilizado o endereço IP válido para a Internet do modem. Entretanto, em alguns provedores o modem também utiliza um IP privativo, e o NAT é feito nas instalações do provedor e não pelo modem. Neste caso, não há como fazer a conexão ao VNC, a solução seria mudar para outro plano de acesso, que foneça um IP válido. Muitos leitores se esquecem de tentar fazer um "ping" do micro com o VNCviewer para o VNCserver. Se o ping não funcionar, não existe conectividade de rede, portanto não há como fazer a conexão VNC. O VNC não é diferente, para a rede, de um servidor web ou de e-mail. E a maioria dos provedores tem contratos diferenciados para empresas que pretendem hospedar servidores internet utilizando o link de banda larga.
  7. Todos nós já ouvimos falar das certificações oferecidas pela Novell e pela Microsoft. Em muitos casos, possuir ou não uma destas certificações pode significar para um profissional de serviços em Informática ganhar ou perder um cliente (ou um emprego). Estas certificações trazem benefícios para todos: para quem contrata, traz uma segurança de que o profissional possui o conjunto de conhecimentos necessários para desempenhar as suas atribuições com qualidade; para quem é contratado, a certificação vale como um diferencial, demonstrando que ele possui competência e qualificações acima da média do mercado. A Certificação A+ é diferente das certificações mais conhecidas porque não é promovida por um único fornecedor em prol dos seus próprios produtos, mas sim por um consórcio formado for fabricantes de PCs e outras empresas ligadas ao mercado de hardware. Empresas como IBM, Compaq, Dell, Gateway, Lexmark e HP são membros deste consórcio, chamado CompTIA (sigla em inglês para "Associação das Indústrias de Tecnologia da Computação"). Existem hoje cerca de 110.000 profissionais com a Certificação A+ em todo o mundo. Você também pode obter esta certificação: basta comparecer a qualquer centro autorizado Sylvam Prometric (as mesmas empresas que aplicam as provas de certificação da Novell e Microsoft) e se inscrever para fazer dois testes: o 220-101 (A+ Core) e 220-102 (A+ DOS/Windows). Os testes devem ser marcados com três dias úteis de antecedência. Os testes podem feitos em Portugês ou em Inglês, de acordo com a preferência do candidato, que deve porém informar a sua escolha no momento da marcação das provas. Se você optar por fazer as provas em Português, a sua certificação terá o mesmo valor de quem optou por fazer a prova em Inglês. Cada teste custa US$ 132,00. Na verdade este é um preço promocional, pois a CompTIA está em uma campanha para aumentar a quantidade de profissionais certificados fora dos EUA. O valor regular, que voltará a vigorar em 1o. de Janeiro do ano 2000 é de US$ 167,00. O candidato tem um prazo de 90 dias, a contar da data da primeira prova, para obter a aprovação na segunda prova. Caso o candidato estoure este prazo ele volta ao zero, tendo que refazer a primeira prova. Ao contrário de outras certificações da indústria de informática, a certificação A+ exige que o candidato passe primeiro na prova A+ Core para depois poder se inscrever na prova A+ DOS/Windows. Cada prova pode ser repetida quantas vezes o candidato desejar, e obviamente cada nova tentativa implica em novo pagamento. Tendo sido aprovado em ambos os testes, você recebe o certificado reconhecido internacionalmente como o de um especialista em instalação, suporte e manutenção de PCs de qualquer fabricante. Segundo o web site da CompTIA (http://www.comptia.org), em uma tradução livre: "A Certificação A+ é um programa de testes patrocinado pela Associação das Indústrias de Tecnologia da Computação (CompTIA), que certifica a competência de técnicos de suporte e manutenção na indústria de computadores. Qualquer um que deseje uma credencial internacionalmente reconhecida como um técnico competente pode se subeter à Certificação A+. O programa é mantido pelos principais fornecedores de hardware e software, além de distribuidores, revendedores e editoras. O teste, que é administrado pelo Sylvam Prometric, foi disponibilizado pela primeira vez em Julho de 1993, tendo sido completamente revisado em Julho de 1998. Receber uma Certificação A+ significa que o indivíduo possui o conhecimento, experiência e habilidades de relacionamento necessários para um técnico de suporte bem-sucedido, como definido por especialistas de diversas companhias da indústria de Informática. O teste cobre uma vasta gama de tecnologias de hardware e software, mas não é dedicado a nenhum produto em especial e nem a nenhum fabricante em particular." Basicamente, a Certificação A+ procura avaliar se os candidatos possuem bons conhecimentos sobre o hardware do PC. Se você leu o livro ou fez o curso do Gabriel Torres, e se você além disso tem uma boa experiência realizando instalação, manutenção e suporte a usuários de PCs, você deverá estar bem preparado para tentar a Certificação A+ e ter suas habilidades reconhecidas internacionalmente. O exame sobre hardware de PCs é formado por 70 questões de múltipla escolha que devem ser respondidas em 60 minutos. As últimas 7 servem para verificar a capacidade do candidato em prestar um bom atendimento a clientes, e não afetam a condição de aprovado ou reprovado do candidato. Para ser aprovado, o candidato deve responder corretamente a 65% das questões. As questões do exame são sorteadas de modo que a cada tentativa o candidato recebe uma prova diferente. Entretanto, as questões são sempre divididas proporcionalmente dentre os vários tópicos cobertos no exame. A proporção de cada tópico é a seguinte: Tópicos Questões(%) Instalação, configuração e upgrade 30 Diagnóstico e solução de problemas 20 Segurança e manutenção preventiva 10 Placas-mãe, processadores e memória 10 Impressoras 10 Computadores portáteis 5 Conhecimentos básicos de Redes 5 Satisfação do cliente 10 Já a prova sobre DOS e Windows tem os seguintes pesos: Tópicos Questões(%) Funções, estrutura, operação e gerenciamento de arquivos 30 Gerenciamento de memória 10 Instalação, configuração e upgrade 25 Diagnóstico e solução de problemas 25 Redes 10 Aproximadamente 75% das questões são sobre o Windows 95, enquanto que 25% são sobre DOS e Windows 3.x. Para ser aprovado no segundo exame, o candidato deve acertar 66% das questões e a duração do exame é de 75 minutos. A prova é feita on-line em um PC, que fornece imediatamente o resultado (aprovado ou reprovado) do candidato e a sua pontuação final. O candidato recebe também a pontuação discriminada para cada um dos tópicos apresentados acima, entretanto ele não é informado sobre quais foram as questões que ele acertou ou errou. Isto é feito de modo que o candidato não possa refazer o teste contanto que algumas das questões anteriores se repitam (o que geralmente acontece). Para quem gostaria de praticar antes de se submeter ao exame real, a Sylvam Prometric oferece testes exemplo gratuitamente no endereço: http://www.rapidassess.com/test/default.asp Também teremos dentro em breve provas exemplo para a Certificação A+ no site do Clube. Para os interessados na certificação, eis o programa das duas provas, conforme o web site da CompTIA em uma tradução livre. No final deste artigo temos também uma relação dos centros Sylvam Prometric no Brasil, onde os candidatos podem se inscrever e realizar as provas. Tópico 1.0 - Instalação, Configuração e Upgrade Este tópico avalia os conhecimentos necessários para identificar, instalar, configurar e fazer upgrade de microcomputadores e periféricos, seguindo procedimentos básicos para montagem e desmontagem de sistemas e substituição de partes removíveis. Elementos incluem a abilidade de identifiar e configurar IRQs, DMAs, endereços de I/O, switches e jumpers. 1.1 Identificar os termos e conceitos básicos, além das funções relacionadas com os módulos de um sistema, incluindo como cada módulo deve trabalhar em condições normais. 1.2 Identificar procedimentos básicos para adicionar e remover partes substituíveis. 1.3 Identificar IRQs, canais de DMA e endereços de I/O disponíveis e os procedimentos para configura-los na instalação de dispositivos. 1.4 Identificar portas padrão de periféricos, os cabos associados e os seus conectores. 1.5 Identificar os procedimentos adequados para instalar e configurar dispositivos IDE/EIDE. 1.6 Identificar os procedimentos adequados para instalar e configurar dispositivos SCSI. 1.7 Identificar os procedimentos adequados para instalar e configurar dispositivos dispositivos periféricos. 1.8 Identificar conceitos e procedimentos relativos ao BIOS 1.9 Identificar métodos de otimização do hardware do sistema e quando utiliza-los. Tópico 2.0 - Diagnóstico e solução de problemas Este tópico avalia a abilidade de aplicar conhecimentos sobre diagnóstico e solução de problemas comuns de mal-funcionamento de PCs. Isto inclui conhecimentos sobre os sintomas relacionadas com os problemas mais frequentes. 2.1 Identificar sintomas e problemas mais comuns associados com cada módulo (de um PC) e como diagnosticar e isolar os problemas. 2.2 Identificar os procedimentos básicos para diagnóstico e as práticas recomendadas para elucidar problemas dados os sintomas fornecidos pelo cliente. Tópico 3.0 - Segurança e Manutenção Preventiva Este tópico avalia conhecimentos sobre segurança e manutenção preventiva. Quanto à segurança, temos danos em potencial que podem ser causados a pessoas ou equipamentos quando trabalhando com lasers, equipamentos de alta voltagem, eletricidade eletrostática e ítens que requerem cuidados especiais de armazenamento e reciclagem por serem tóxios ou causarem danos ao meio-ambiente. Em relação à manutenção preventiva, temos o conhecimento de produtos para manutenção preventiva, procedimentos, riscos e precauções quando trabalhando com microcomputadores. 3.1 Identificar o propósito dos vários tipos de produtos e procedimentos para manutenção preventiva e quando utilizar cada um deles. 3.2 Identificar procedimentos e dispositivos para proteção contra riscos (choque, arranhões, etc). 3.3 Identificar os danos em potencial e os procedimentos de segurança adequados quanto à lasers e equipamentos de alta-voltagem. 3.4 Identificar itens que requerem cuidados especiais no descarte de acordo com as normas de proteção ambiental. 3.5 Identificar precauções e procedimentos relativos à descargas de eletricidade eletrostática, incluindo o uso de dispositivos de proteção. Tópico 4.0 - Placas-mãe, Processadores e Memória Este tópico requer conhecimento de terminologia específica, especificações, classificações, categorias, arquitetura e princípios de funcionamento de placas-mães, processadores e memórias em microcomputadores. 4.1 Distringuir os chips de CPU mais populares em termos das suas características básicas. 4.2 Identificar as categorias de RAM, terminologia associada, sua localização e características físicas. 4.3 Identificar os tipos mais populares de placas-mães, seus componentes e sua arquitetura (por exemplo, estruturas de barramento e alimentação). 4.4 Identificar o propósito da CMOS, o que ela contém e como modificar os seus parâmetros básicos. Tópico 5.0 - Impressoras Este tópico avalia conhecimentos sobre os tipos básicos de impressoras, conceitos básicos, componentes de uma impressora, como elas funcionam, como elas imprimem em uma página, o caminho do papel, cuidados e técnicas de manutenção e problemas mais comuns. 5.1 Identificar conceitos básicos, funcionamento de vários tipos de impressoras e componentes de uma impressora. 5.2 Identificar cuidados e técnicas de manutenção e problemas mais comuns con os principais tipos de impressoras. 5.3 Identificar os tipos de conexões de impressoeas e suas configurações. Tópico 6.0 - Sistemas Portáteis Este tópico avalia os conhecimentos sobre computadores portáteis e seus componentes e problemas particulares. 6.1 Identificar os componentes particulares (em relação a sistemas de mesa) de sistemas portáteis e seus problemas específicos. Tópico 7.0 - Conhecimentos Básicos de Redes Este tópico avalia os conhecimentos sobre conceitos e terminologia básicos de redes, a abilidade em determinar se um computador está em rede, conhecimentos sobre procedimentos para trocar e configurar placas de rede, e conhecimentos sobre as implicações de reparos quando um computador está em rede. 7.1 Identificar os conceitos básicos de redes, incluindo como uma rede funciona. 7.2 Identificar procedimentos para dustituit e configurar uma placa de rede. 7.3 Identificar as implicações de reparos na rede. Tópico 8.0 - Satisfação do Cliente Este tópico avalia o conhecimento sobre comportamentos que contribuem para a satisfação dos clientes, e a "sensibilidade" e a preocupação do candidato com relação à satisfação dos seus clientes. Mais especificamente, estes comportamentos incluem coisas como: a qualidade das interações entre o técnico e o cliente; a postura do técnico em relação aos negócios do cliente; a credibilidade e a confiança projetados pelo técnico que, por sua vez, fazem com que o cliente confie nele. A resistência, amabilidade e eficiência que podem inesperadamente satisfazer o cliente além da solução do problema técnico. Este tópico NÃO é um teste sobre procedimentos e políticas específicas de uma empresa. 8.1 Diferenciar-se efetivamente de comportamentos ineficientes já que isso contribui para a manutenção ou a conquista da satisfação do cliente. Tópico 1.0 - Funções, Estrutura, Operação e Gerenciamento de Arquivos Este tópico avalia conhecimentos sobre os sistemas operacionais DOS, Windows 3.x e Windows 95 em termos de sua funcionalidade e estrutura, gerenciamento de arquivos e execução de programas. Também espera-se que o candidato seja capaz de navegar pelos sistemas operacionais na linha de comandos do DOS ou seguindo os procedimentos do Windows para acessar e obter informação. 1.1 Identificar as funções, estrutura e principais arquivos do sistema operacional. 1.2 Identificar as maneiras de se navegar pelo sistema operacional e como obter informações técnicas que sejam necessárias.. 1.3 Identificar os conceitos básicos e procedimentos para criar, visualizar e gerenciar arquivos e diretórios, incluindo procedimentos para mudar atributos e as ramificações destas mudanças (por exemplo, questões quanto à segurança). 1.4 Identificar os procedimentos básicos para gerenciamento de discos. Tópico 2.0 - Gerenciamento de Memória Este tópico avalia os conhecimentos relativos aos tipos de memória utilizados pelo DOS e pelo Windows, e os confiltos em potencial de endereçamento de memória. 2.1 Diferenciar entre os diferentes tipos de memória (Convencional, Expandida, Extendida, Alta e Virtual). 2.2 Identificar problemas típicos de conflito de memória e como otimizar a utilização de memória. Tópico 3.0 - Instalação, Configuração e Upgrade Este tópico avalia o conhecimento quanto à instalar, configurar e atualizar o DOS, Windows 3.x e Windows 95, incluindo as sequências de boot desses sistemas. 3.1 Identificar os procedimentos para a instalação do DOS, Windows 3.x e Windows 95, e como deixar o sistema em seu nível básico de operacionalidade.. 3.2 Identificar os passos para realizar um upgrade de sistema operacional. 3.3 Identificar as sequências de boot básicas, e os modos alternativos de se inicializar o sistema, incluindo a geração de disketes de boot de emergência com utilitários instalados. 3.4 Identificar os procedimentos para carregar/adicionar device drivers e o software necessários para determinados dispositivos.. 3.5 Identificar os procedimentos para mudar opções, configurar e utilizar o subsistema de impressão do Windows. 3.6 Identificar os procedimentos para instalar e executar aplicações Windows e não-Windows típicas. Tópico 4.0 -- Diagnóstico e Solução de Problemas Este tópico avalia a capacidade em se aplicar conhecimentos para identificar e isolar problemas comuns relativos ao DOS, Windows 3.x e Windows 95. Isto inclui entendimetno do funcionamento normal do sistema e sintomas dos problemas mais frequentes. 4.1 Reconhecer e interpretar o significado dos códigos de de erro e mensagens de inicialização da sequência de boot, e identificar os passos necessários para corrigir os problemas. 4.2 Reconhecer problemas de impressão específicos do Windows e identificar os procedimentos para corrigi-los. 4.3 Reconhecer os problemas mais frequentes e como resolve-los. 4.4 Identificar conceitos relativos à vírus e tipos de vírus incluindo seu perigo, seus sintomas, origens, como eles infectam o sistema e como se proteger contra eles, além de como identifica-los e remove-los. Tópico 5.0 - Redes Este tópico avalia os conhecimentos relativos às capacidades de rede do DOS e do Windows e como conecta-los a redes, incluindo o que é a Internet, suas capacidades, conceitos básicos relativos ao acesso à Internet e problemas genéricos de configuração do sistema. 5.1 Identificar as capacidades de redes do DOS e Windows incluindo procedimentos para se conectar à rede. 5.2 Identificar conceitos e capacidades relativas à Internet e procedimentos básicos para se configurar um sistema para acesso à Internet. Obs.: os centros Sylvan estão ordenados pelo nome da cidade. Entretanto, agulmas empresas conveniadas podem ter filiais em mais de uma cidade (ex: Netwise, que tem centros no Rio e em São Paulo) e nestes casos somente o endereço da matriz é listado. Br43 - Del-Micro Informática LTDA. Av. Bras de Aguiar 783 Nazaré CEP: 66035-000 Belém - PA Br16 - Tba Informática Rua Outono 259 Savassi CEP: 30310-020 Belo Horizonte - MG Br20 - A & C Training Rua dos Inconfidentes 1051 6º andar CEP: 30140-120 Belo Horizonte - MG Bra - Att Informática,LTDA. Av Barão Homen de Melo 4484 5º-9º andar CEP: 30450-250 Belo Horizonte - MG Br7 - Tba Brasília Informática LTDA. Scrn/Norte 712/713 Bloco D Loja 24 CEP: 70760-790 Brasília - DF Br8 - Lan University Rua. Dr. Miguel Penteado 244 Jd. Chapadão CEP: 13073-180 Campinas - SP Br36 - Westcenter Informática LTDA. Rua Onze de Outubro 840 Cabreuva CEP: 79008-390 Campo Grande Br33 - Compnet Comercial LTDA. Rua Furnas 339 Santa Fé CEP: 79021-300 Campo Grande Br24 - Techworld Training Av. Isaac Povoas 856 2º andar CEP: 78045-640 Cuiabá - MT Br13 - Softsell Rua Presidente Faria 248 3º andar CEP: 80020-290 Curitiba - PR Brq - Geritech Informática LTDA. Rua Marechal Deodoro 630 - Cj 1908 CEP: 80010-912 Curitiba - PR Br32 - Sofhar Informática e elet. LTDA. Av Senador Souza Naves 470 CEP: 80050-040 Curitiba - PR Br19 - Virtual Office Av. Rio Branco 380 Sala 204 CEP: 88015-200 Florianópolis - SC Brp - Dual Line Telematica Rua Deodoro 226 - Sala 501 Centro CEP: 88010-020 Florianópolis - SC Brn - Lanlink Informática LTDA. Av Santos Dumont 1470 1º andar CEP: 60150-160 Fortaleza - CE Brx - Megasisti Inform. e Sistemas 6ª Avenida No. 41 Setor Universitário CEP: 74603-040 Goiânia - DF Br30 - Varella & Gamboa LTDA. Desembargador Tenório 133 Farol CEP: 57050-050 Maceió - AL Br39 - Simed Informática Rua Paraíba, Quadra F Casa 4, Conj Abilio Nery CEP: 69057-020 Manaus - AM Br37 - Senac Alecrim R. Alexandrino de Alencar 556 CEP: 59030-350 Natal - RN Brw - Net House Informática LTDA. Alameda do Inga 650 Vale Do Sereno CEP: 34000-000 Nova Lima - MG Br27 - Infoserver Informática R. Maria de Lourdes Ponce 19 CEP: 06023-170 Osasco - SP Br14 - Quattuor Informática LTDA. Rua Bernardo Pires 280 5º andar CEP: 90620-010 Porto Alegre - RS Brf - Processor Informática Rua Hilário Ribeiro 202/6º andar CEP: 60510-040 Porto Alegre - RS Brv - Sisnema Informática LTDA. Rua Washington Luiz820 Cjto 602 CEP: 90010-460 Porto Alegre - RS Br48 - Awg Integração de Sistemas Ltd R. Carlos Pereira Falcão 121/34 CEP: 51021-350 Recife - PE Bre - Connet Informática LTDA. Rua Cardeal Arcoverde 308 Graças CEP: 52011-240 Recife - PE Br60 - Center Cursos Av. Meira Júnior, 337 CEP: 14085-390 Ribeirão Preto - SP Tel: (16) 632-9650, 632-9716 E-mail: [email protected] Site: http://www.centercuros.com.br Br40 - Tba Informática LTDA. Rua do Mercado 11 16º andar CEP: 20010-120 Rio de Janeiro - RJ Brt - Compucenter Bahia Infotraining Treinamentos esp. A. Tancredo Neves 805 - 3º andar CEP: 41820-021 Salvador - BA Brm - Hcg Engenharia de Sistemas Rua das Paparaubas, Quadra 1 Casas 10 e 11 CEP: 65076-000 Sao Luís - MA Br1 - Netwyse Avenida Paulista 548 5º andar Cerqueira César CEP: 01311-000 São Paulo - SP Br31 - Impacta Tecnologia LTDA. Av Paulista 1106 7º andar CEP: 01310-100 São Paulo - SP Brs - Cnt Informática LTDA. Av. Paulista 925 11º andar CEP: 05409-001 São Paulo - SP Brz - Bras & Figuereido Av. Paulista 2073 Ed. Horsa II 4º andar CEP: 01311-300 São Paulo - SP Br25 - Techne Engenharia e Sistemas Av. Cidade Jardim 400 13º andar CEP: 01454-902 São Paulo - SP Br29 - Netsource Informática LTDA. Av. Dr. Afonso Vergueiro 1663 2º andar CEP: 18010-360 Sorocaba - SP Br34 - Tqi Tec e Qualidade em Inf. Avenida Getúlio Vargas 1130 Centro CEP: 38401-122 Uberlândia - MG Br47 - Metadata Consultoria e Sist. Rua Eduardo Marquez 826 CEP: 38400-442 Uberlândia - MG Bry - Att Informática Rua Abiail Do Amaral Carneiro Ed. Palácio Enseada, nº41 CEP: 29055-220 Vitória - ES
  8. No primeiro tutorial sobre TCP/IP tivemos uma introdução à toda a teoria que governa a arquitetura de uma rede TCP/IP. Como vocês puderam ver, não é pouca teoria. Na verdade as provas sobre TCP/IP são consideradas as mais difícies das certificações CNE da Novell ou MCSE da Microsoft. Mas para montar uma rede local utilizando o TCP/IP, seja para simples compartilhamento de arquivos e impressoras entre estações Windows 95, ou para a construção de uma intranet completa, você não precisa ser um Ph.D. em teoria da ciência da computação. Juntando os conhecimentos teóricos do primeiro tutorial sobre TCP/IP com os as dicas de projeto que forneceremos agora, você poderá criar redes TCP/IP de tamanho pequeno a médio sem problemas. O projeto de uma rede TCP/IP está intimamente relacionado com a sua topologia lógica. Muitas vezes nao é fácil entender a topologia lógica de uma rede, devido em parte à confusão criada pelos fornecedores de produtos (software ou hardware) para redes na divulgação dos seus produtos. Por isso vamos apresentar alguns tipos de topologias físicas mais comuns para redes locais e as topologias lógicas correspondentes, para depois apresentar uma "receita de bolo" para orientar o projeto da rede TCP/IP para essas topologias. Ethernet em cabo coaxial Dispositivos conectados em um mesmo cabo Ethernet possuem conectividade no nível de Enlace (vide o primeiro tutorial sobre TCP/IP). Fisicamente e logicamente eles estão em uma topologia de barramento, o que no TCP/IP corresponde a uma única rede local. Mesmo que adicionemos repetidores ou pontes (bridges) interligando diversos cabos Ethernet. Logicamente continuamos com um único barramento, o que corresponde a uma subnet do TCP/IP. Ethernet em par-trançado Quando utilizamos par-trançado para conectar dispositivos em uma rede ethernet estamos utilizando uma topologia física de estrela. Entretanto, a topologia lógica continua sendo de barramento, pois o hub nada faz além de ecoar o sinal recebido em uma porta para todas as outroas. Assim sendo, o funcionamento lógico do hub é igual ao do cabo coaxial. Se ligarmos vários bubs em cascata, criando uma topologia física de "árvore", continuamos com uma topologia lógica de barramento, equivalente à vários cabos coaxiais interligados por repetidores. Ethernet com switch Um switch Ethernet padrão é uma bridge multiporta. Embora fisicamente ele seja capaz de aumentar bastante o desempenho da rede, por permitir que diversos pares dispositivos se comuniquem simultaneamente, logicamente ele opera somente no nível dois do modelo OSI, que corresponde ao nível de Enlace apresentado no primeiro tutorial sobre TCP/IP. A topologia lógica gerada por um switch ainda é um simples barramento Ethernet, mesmo que tenhamos switches em cascata com outros swtiches ou hubs. Algums switches do mercado incorporam na mesma caixa um roteador. Os fabricantes chamam este projeto de "swtch de nível 3", em referência ao nível 3 do modelo OSI, que corresponde ao nível de rede apresentado no primeiro tutorial sobre TCP/IP. Neste caso, temos que saber qual a configuração específica do switch para determinar qual a topologia lógica implementada por ele. Em linhas gerais esta topologia será um grupo de barramentos Ethernet interconectados por um roteador, que veremos no próximo item: Roteador dedicado Caso a sua rede possua um roteador dedicado, cada porta do roteador gera uma rede local lógica, ou seja, cada porta do roteador corresponde a uma subnet do TCP/P. Não importa que tipo de conexão seja feita por estas portas; pode ser Ethernet, WAN, X.25, etc. Cada porta corresponderá a uma rede lógica independente das outras, e o roteador será capaz de realizar, no nível de rede (IP), a interligação destas redes locais. Dois roteadores em cascata geram redes lógicas diferentes, ao contrário dos hubs e switches Ethernet, que geram uma mesma rede lógica (barramento). Servidor "multihomed" Um servidor multihomed é um computador que possui várias interfaces de rede. Cada interface de rede gera a sua própria rede local lógica, ou subnet para o TCP/IP. Um roteador dedicado é nada mais do que um servidor multihomed especializado. A maioria dos sistemas operacionais para servidor, e alguns sistemas operacionais de estação (como o Warp 4) são capazes de atuar como roteadores para o TCP/IP. Colocar várias placas de rede em um mesmo servidor é uma forma barata e popular de se expandir a capacidade ou aumentar o desempenho de uma rede local Ethernet. A maiora dos PCs, mesmo 486, é capaz de sustentar sem problemas o tráfego de 4 placas Ethernet de 10Mb/s, a um preço bastante inferior a um switch ou roteador dedicado. Redes locais TCP/IP que estejam conectadas na Internet devem utilizar endereços oficiais, atribuídos pelo InternNIC ou por entidades locais autorizadas por este (como a FAPESP para o Brasil). Entretanto a maioria das empresas não necessita nem deve utilizar endereços oficiais, pois isto deixaria a rede inteira vulnerável aos hackers. A partir do momento em que se coloca um firewall protegendo a rede, somente os servidores que serão visíveis publicamente na Internet necessitam de um endereço oficial. Para as redes internas das empresas, que se conectam à Internet por intermédio de um firewall mas não fornecem serviços visíveis para a Internet pública, o InterNIC reservou algumas faixas de endereço a que chamamos de "redes privativas". São muito raros os caos em que uma empresa não deve utilizar uma dessas faixas para a sua rede local, portanto vamos utilizar como primeira regra de projeto de redes TCP/IP a utilização de uma faixa privativa. A faixa escolhida é 172.16.0.0. Vamos utilizar como network mask (netmask ou subnetmask) o valor 255.255.255.0, pois assim o terceiro octedo do endereço TCP/IP pode ser utilizado para diferenciar diversas redes locais lógicas (barramentos Ethernetnet) que a rede local da empresa utilize. Assim a primeria rede local terá como endereço de rede 172.16.1.0, a segunda 172.16.2.0, e assim em diante. O quarto octeto indica o endereço da estação, servidor ou dispositivo nesta rede. Uma rede pequena terá somente endereços IP fixos, configurados manualmente em cada máquina. Já uma rede maior necessitará de um servidor DHCP para aliviar a sobrecarga administrativa. Entretanto, mesmo em uma rede que utilize DHCP teremos alguns endereços IP fixos, configurados manualmente, porque o DNS não sabe trabalhar em conjunto com DHCP. Isto implica em que os servidores da intranet da empresa necessitam ter um endereço IP fixo, para que eles possam ser identificados via DNS. Então vamos separar os endereços de host em três faixas: uma para os servidores (IP fixo), uma para as estações configuradas via DHCP e outra para as estações e outros dispositivos que necessitem de um endereço IP pré-fixado. Nossas faixas serão: Faixa 1 (servidores): 10..99 Faixa 2 (DHCP): 100..199 Faixa 3 (outros dispositivos com IP fixo): 200..250 Outra convenção útil é colocar o default gateway sempre com endereço de host igual a 1. Não há necessidade de se utilizar os endereços IP sequencialmente. Você pode deixar "buracos" na numeração dos endereços de hosts, o que pode ser conveniente se a sua rede já adotar algum padrão de numeração para os equipamentos. Caso a sua rede não utilize DHCP, você irá configurar as estações manualmente com endereços de host da faixa 3 e deixar a faixa 2 reservada para uma futura expansão da rede que venha a necessitar do DHCP. Vamos iniciar por uma rede simples, que consiste em um único barramento Ethernet. Esta rede contém um único servidor, que desempenha todas as funções de servidor da rede, e 15 estações, que receberão os endereços IP manualmente. Os parâmetros gerais de nossa rede são: Então vamos separar os endereços de host em três faixas: uma para os servidores (IP fixo), uma para as estações configuradas via DHCP e outra para as estações e outros dispositivos que necessitem de um endereço IP pré-fixado. Nossas faixas serão: Endereço de Rede: 172.16.1.0 Network Mask: 255.255.255.0 Default Gateway: vazio (não temos necessidade) Servidor DNS: vazio (não estamos utilizando) Configurar via DHCP: não E os enderços IP dos computadoes, segundo a Figura 1, são: WWW: 172.16.1.10 M01: 172.16.1.201 M02: 172.16.1.202 e assim por diante, até o M15: 172.16.1.215 Como não temos um servidor DNS nesta rede, cada estação deve ter um arquivo de hosts para que o servidor Web possa ser localizado. O nome e diretório do arquivo de hosts varia de plataforma para plataforma, mas o seu conteúdo será: 127.0.0.1 localhost 172.16.1.10 www Observe o nome "localhost", que é padrão para o loopback do TCP/IP (vide primeiro tutorial sobre TCP/IP, tópico "Como Testar uma Rede TCP/IP"). Este exemplo difere do primeiro apenas no tamanho da rede. Agora temos 50 estações e dois servidores, um para arquivos e impressão e outro para a intranet, que abrigará os servidores Web, DNS e DHCP. Os parâmetros gerais para esta rede são: Endereço de Rede: 172.16.1.0 Network Mask: 255.255.255.0 Default Gateway: vazio (não temos necessidade) Servidor DNS: 172.16.1.10 (é o servidor da Intranet) Configurar via DHCP: sim (somente para as estações) E os enderços IP dos computadoes, segundo a Figura 2, são: WWW: 172.16.1.10 SERV1: 172.16.1.20 M01..M50: 172.16.1.100..172.16.1.150 (configurados via DHCP) Notem que, no TCP/IP, podemos ter vários servidores com o mesmo endereço IP, pois cada servidor corresponde a um programa diferente, que utiliza o seu próprio número de porta para receber as coenxões dos clientes. No caso, temos um servidor Web e um servidor DNS no endereço 172.16.1.10. Como desta vez temos um servidor DNS, não precisamos criar um arquivo de hosts em cada estação. OBS 1: Nesta série de aulas, não iremos apresentar como é a configuração dos servidores DNS e DHCP. São topicos mais demorados, que exigiriam aulas específicas. Entretanto, caso a sua rede possua esses servidores ou caso você esteja trabalhando junto com outro profissional que saiba configurar esses servidores, estamos incluindo exemplos para mostrar como seria a configuração das estações com os servidores DNS e DHCP presentes. Note que ambos os servidores podem ser utilizados independentemente um do outro, ou seja, eu posso ter um servidor DHCP nas não ter um servidor DNS, e vice-versa. OBS 2: Também não iremos apresentar as configurações do servidor Web, mas consideramos que existe um presente na intranet. A maioria dos servidores web, quando instalados em uma rede TCP/IP corretamente configurada, não necessita de configurações extras: os seus defaults já fornecem uma intranet perfeitamente funcional, basta verificar no manual do servidor web utilizado em qual diretório devem ser instaladas as páginas HTML. Agora temos dois segmentos (barramentos) Ethernet, cada um com 20 estações, interligados por um servidor multihomed. Este servidor deve estar com o roteamento IP habilitado (IP forwarding = on) para que os dois barramentos possam se comunicar. O servidor web está no primeiro barramento, e não temos servidores DNS ou DHCP presentes. Os parâmetros gerais para esta rede são: Endereço da Rede 1: 172.16.1.0 Endereço da Rede 2: 172.16.2.0 Network Mask: 255.255.255.0 Default Gateway da Rede 1: 172.16.1.1 Default Gateway da Rede 1: 172.16.2.1 Servidor DNS: não temos Configurar via DHCP: não E os endereços IP dos computadoes, segundo a Figura 3, são: WWW: 172.16.1.10 GATEWAY: 172.16.1.1 e 172.16.2.1 M101: 172.16.1.201 M102: 172.16.1.202 e assim por diante, até o M120: 172.16.1.220 M201: 172.16.2.201 M202: 172.16.2.202 e assim por diante, até o M220: 172.16.2.220. Observem que um servidor multihomed possui vários endereços IP, um para cada interface de rede presente. Considerando que o servidor multihomed não roda nenhum serviço para a intranet, ele não precisa ser listado no arquivo de hosts, que teria o seguinte conteúdo: 127.0.0.1 localhost 172.16.1.10 www Você poderia, por economia, colocar todos os serviços de rede em uma única máquina, mas ainda assim ter dois segmentos. Digamos que temos poucas estações, porém muito distantes, por isso fomos obrigados a instalar dois segmentos Ethernet. O único servidor fornecerá serviços de arquivos, web e roteamento para a rede inteira. Não temos servidores DNS ou DHCP presentes. Os parâmetros gerais para esta rede são: Endereço da Rede 1: 172.16.1.0 Endereço da Rede 2: 172.16.2.0 Network Mask: 255.255.255.0 Default Gateway da Rede 1: 172.16.1.1 Default Gateway da Rede 1: 172.16.2.1 Servidor DNS: não temos Configurar via DHCP: não E os enderços IP dos computadoes, segundo a Figura 4, são: WWW: 172.16.1.1 GATEWAY: 172.16.1.1 e 172.16.2.1 M101: 172.16.1.201 M102: 172.16.1.202 e assim por diante, até o M110: 172.16.1.210 M201: 172.16.2.201 M202: 172.16.2.202 e assim por diante, até o M205: 172.16.2.205 Quando eu tenho um servidor multihomed que deve ser listado no arquivo de hosts, podemos usar qualquer um dos endereços, mas somente um deles poderá estar no arquivo de hosts: 127.0.0.1 localhost 172.16.1.1 www Digamos que você queira prever o crescimento futuro da rede e a consequente instalação de uma nova máquina para o servidor web. O arquivo de hosts pode listar vários nomes, ou alias, para um mesmo endereço IP, por exemplo: 127.0.0.1 localhost 172.16.1.1 servidor1, www E quando a nova máquina para o servidor web for instalada, você poderia alterar os arquivos de host (em todas as estações) para: 127.0.0.1 localhost 172.16.1.1 servidor1 172.16.1.10 www É claro, a entrada para o "servidor1" só será necessário caso haja algum outro serviço intranet sendo oferecido pela máquina, por exemplo um servidor FTP. Os nomes de hosts fornecidos pelo DNS ou definidos no arquivo de hosts não tem significado para as redes Microsoft e Novell, pelo menos no que diz respeito ao compartilhamento de arquivos e impressoras. Caso eu decida incluir um servidor DHCP nesta rede, eu tenho duas opções: ou eu instalo o servidor DHCP no servidor multihomed, ou eu instalo dois servidores DHCP, um para cada subnet. Como o DHCP opera na fronteira entre o nível de rede e o nivel de enlace, as estações não podem utilizar o roteador para se conectar ao servidor DHCP. Este tutorial poderia ser extendida indefinidamente, demonstrando diversas possibilidades de topologias de rede, servidores presentes e etc. Entretanto acreditamos que as configurações apresentadas como exemplo serão suficientes para a maioria dos casos. Redes maiores nada mais são do que combinações dos casos simples apresentados acima. Caso a sua rede inclua estações ou servidores rodando Windows (3.x, 95, 98 ou NT) você deve tomar cuidado com alguns detalhes. Primeiro, o nome de domínio do DNS não tem nenhuma relação com o nome de domínio do NT, assim como os nomes de host definidos pelo DNS ou pelo arquivo de hosts não tem relação com os nomes dos computadores para a rede Microsoft. Você pode até configura-los para que sejam iguais, mas deve se lembrar que eles estão relacionados com componentes de software diferentes. Segundo, a correta operação de uma rede Microsoft com TCP/IP em uma rede composta por varias subnets exige que seja instalado e configurado um servidor WINS ou NBNS. Muitas pessoas pensam que o WINS e o DNS são equivalentes, ou que um pode substituir o outro, o que não é verdade. O WINS fornece o endereço IP correspondente a um endereço da rede Microsoft (que é um nome NetBIOS), que é uma única palavra de até 14 letras, enquanto que o DNS fornece o endereço IP correspondente a um endereço da Internet ou da intranet, que é um conjunto de palavras separadas por pontos e de compimento virtualmente ilimitado. O DNS não tem conhecimento dos nomes de "workgroups" da rede Microsoft, e a rede Microsoft não tem conhecimento de que o domínio "microsoft" está dentro do domínio ".com". A apresentação de todos os detalhes para a configuração ótima de uma rede Microsoft com TCP/IP seria assunto para uma série de tutoriais à parte, mas o material fornecido nesta série de tutoriais será suficiente para as situações mais corriqueiras de configuração de uma intranet. * Fernando Lozano é analista de sistemas especialista em redes locais e consultor do Clube do Hardware. Seu site pessoal, com várias informações sobre Linux, pode ser acessado em http://www.lozano.eti.br.
  9. No mundo de hoje, não se pode falar de redes sem falar do TCP/IP. O conjunto de protocolos originalmente desenvolvido pela Universidade da Califórnia em Berkeley, sob contrato para o Departamento de Defesa dos EUA, se tornou o conjunto de protocolos padrão das redes locais e remotas, suplantando conjuntos de protocolos bancados por pesos pesados da indústria, como a IBM (SNA), Microsoft (NetBIOS/NetBEUI) e Novell (IPX/SPX). O grande motivo de todo este sucesso foi justamente o fato do TCP/IP não ter nenhuma grande empresa associada ao seu desenvolvimento. Isto possibilitou a sua implementação e utilização por diversas aplicações em praticamente todos os tipos de hardware e sistemas operacionais existentes. Mesmo antes do boom da Internet o TCP/IP já era o protocolo obrigatório para grandes redes, formadas por produtos de muitos fornecedores diferentes, e havia sido escolhido pela Microsoft como o protocolo preferencial para o Windows NT, devido às limitações técnicas do seu próprio conjunto de protocolos, o NetBEUI. Entretanto, ao contrário dos procolos proprietários para redes locais da Microsoft e da Novell, que foram desenhados para serem praticamente "plug and play", as necessidades que orientaram o desenvolvimento do TCP/IP obrigaram ao estabelecimento de uma série de parametrizações e configurações que devem ser conhecidas pelo profissional envolvido com instalação, administração e suporte de redes. Esta primeira aula tem por objetivo passar os conhecimentos teóricos necessários para tornar os alunos aptos a seguirem as aulas seguintes, que explicarão como implementar redes TCP/IP no Windows 95, Windows NT, Netware e outros sistemas populares no mercado. Ao contrário da maioria dos livros "introdutórios" sobre TCP/IP que vemos nas livrarias e universidades, não vamos nos preocupar com os detalhes sobre formatos de pacotes e algoritmos empregados na implementação do protocolo. Vamos nos preocupar sim com os conhecimentos realmente necessários para se trabalhar corretamente com os vários produtos existentes no mercado. Quem já estudou mais a fundo a documentação de produtos de redes ou participou de cursos mais específicos certamente se deparou com o "Modelo OSI de 7 Camadas". Todos os softwares de redes são baseados em alguma arquitetura de camadas, e normalmente nos referimos a um grupo de protocolos criado para funcionar em conjunto como uma pilha de protocolos (em inglês, protocol stack, por exemplo the TCP/IP stack). O termo "pilha" é utilizado porque os protocolos de uma dada camada normalmente interagem somente com os protocolos das camadas imediatamente superior e inferior. O modelo de pilha traz a vantagem de modularizar naturalmente o software de redes, permitindo a sua expansão com novos recursos, novas tecnologias ou aperfeiçoamentos sobre a estrutura existente, de forma gradual. Entretanto, o Modelo OSI é uma modelo conceitual, e não a arquitetura de uma implementação real de protocolos de rede. Mesmo os protocolos definidos como padrão oficial pelo ISO - International Standards Organization - a entidade criadora do modelo OSI, não foram projetados e construídos segundo este modelo. Por isso, vamos utilizar nesta aula uma simplificação do modelo OSI. O importante é entender o conceito de pilhas de protocolos, pelo qual cada camada realiza uma das funções necessárias para a comunicação em rede, tornando possível a comunicação em redes de computadores utilizando várias tecnologias diferentes. O TCP/IP foi desenhado segundo uma arquitetura de pilha, onde diversas camadas de software interagem somente com as camadas acima e abaixo. Há diversas semelhanças com o modelo conceitual OSI da ISO, mas o TCP/IP é anterior à formalização deste modelo e portanto possui algumas diferenças. O nome TCP/IP vem dos nomes dos protocolos mais utilizados desta pilha, o IP (Internet Protocol) e o TCP (Transmission Control Protocol). Mas a pilha TCP/IP possui ainda muitos outros protocolos, dos quais veremos apenas os mais importantes, vários deles necessários para que o TCP e o IP desempenhem corretamente as suas funções. Visto superficialmente, o TCP/IP possui 4 camadas, desde as aplicações de rede até o meio físico que carrega os sinais elétricos até o seu destino: 4. Aplicação (Serviço) FTP, TELNET, LPD, HTTP, SMTP/POP3, NFS, etc. 3. Transporte TCP, UDP 2. Rede IP 1. Enlace Ethernet, PPP, SLIP Além das camadas propriamente ditas, temos uma série de componentes, que realizam a interface entre as camadas: Aplicação / Transporte DNS, Sockets Rede / Enlace ARP, DHCP Vamos apresentar agora uma descrição da função de cada camada do TCP/IP: 1. Os protocolos de enlace tem a função de fazer com que informações sejam transmitidas de um computador para outro em uma mesma mídia de acesso compartilhado (também chamada de rede local) ou em uma ligação ponto-a-ponto (ex: modem). Nada mais do que isso. A preocupação destes protocolos é permitir o uso do meio físico que conecta os computadores na rede e fazer com que os bytes enviados por um computador cheguem a um outro computador diretamente desde que haja uma conexão direta entre eles. 2. Já o protocolo de rede, o Internet Protocol (IP), é responsável por fazer com que as informações enviadas por um computador cheguem a outros computadores mesmo que eles estejam em redes fisicamente distintas, ou seja, não existe conexão direta entre eles. Como o próprio nome (Inter-net) diz, o IP realiza a conexão entre redes. E é ele quem traz a capacidade da rede TCP/IP se "reconfigurar" quando uma parte da rede está fora do ar, procurando um caminho (rota) alternativo para a comunicação. 3. Os protocolos de transporte mudam o objetivo, que era conectar dois equipamentos, para' conectar dois programas. Você pode ter em um mesmo computador vários programas trabalhando com a rede simultaneamente, por exemplo um browser Web e um leitor de e-mail. Da mesma forma, um mesmo computador pode estar rodando ao mesmo tempo um servidor Web e um servidor POP3. Os protocolos de transporte (UDP e TCP) atribuem a cada programa um número de porta, que é anexado a cada pacote de modo que o TCP/IP saiba para qual programa entregar cada mensagem recebida pela rede. 4. Finalmente os protocolos de aplicação são específicos para cada programa que faz uso da rede. Desta forma existe um protocolo para a conversação entre um servidor web e um browser web (HTTP), um protocolo para a conversação entre um cliente Telnet e um servidor (daemon) Telnet, e assim em diante. Cada aplicação de rede tem o seu próprio protocolo de comunicação, que utiliza os protocolos das camadas mais baixas para poder atingir o seu destino. Pela figura acima vemos que existem dois protocolos de transporte no TCP/IP. O primeiro é o UDP, um protocolo que trabalha com datagramas, que são mensagens com um comprimento máximo pré-fixado e cuja entrega não é garantida. Caso a rede esteja congestionada, um datagrama pode ser perdido e o UDP não informa as aplicações desta ocorrência. Outra possibilidade é que o congestionamento em uma rota da rede possa fazer com que os pacotes cheguem ao seu destino em uma ordem diferente daquela em que foram enviados. O UDP é um protocolo que trabalha sem estabelecer conexões entre os softwares que estão se comunicando. Já o TCP é um protocolo orientado a conexão. Ele permite que sejam enviadas mensagens de qualquer tamanho e cuida de quebrar as mensagens em pacotes que possam ser enviados pela rede. Ele também cuida de rearrumar os pacotes no destino e de retransmitir qualquer pacote que seja perdido pela rede, de modo que o destino receba a mensagem original, da maneira como foi enviada. Agora, vamos aos componentes que ficam na interface entre os níveis 3 e 4 e entre os níveis 1 e 2. O Sockets é uma API para a escrita de programas que trocam mensagens utilizando o TCP/IP. Ele fornece funções para testar um endereço de rede, abrir uma conexão TCP, enviar datagramas UDP e esperar por mensagens da rede. O Winsockets, utilizado para aplicações Internet em Windows é nada mais do que uma pequena variação desta API para acomodar limitações do Windows 3.1. No Windows NT e Win95 pode ser usada a API original sem problemas. O Domain Name Service (DNS), que será visto com maiores detalhes mais adiante, fornece os nomes lógicos da Internet como um todo ou de qualquer rede TCP/IP isolada. Temos ainda o ARP realiza o mapeamento entre os endereços TCP/IP e os endereços Ethernet, de modo que os pacotes possam atingir o seu destino em uma rede local (lembrem-se, no final das contas quem entrega o pacote na rede local é o Ethernet, não o TCP ou o IP). Por fim, o DHCP permite a configuração automática de um computador ou outro dispositivo conectado a uma rede TCP/IP, em vez de configurarmos cada computador manualmente. Mas, para entender o porque da necessidade do DHCP, temos que entender um pouco mais do funcionamento e da configuração de uma rede TCP/IP. Em uma rede TCP/IP, cada computador (ou melhor, cada placa de rede, caso o computador possua mais do que uma) possui um endereço numérico formado por 4 octetos (4 bytes), geralmente escritos na forma w.x.y.z. Além deste Endereço IP, cada computador possui uma máscara de rede (network mask ou subnet mask), que é um número do mesmo tipo mas com a restrição de que ele deve começar por uma seqüência contínua de bits em 1, seguida por uma seqüência contínua de bits em zero. Ou seja, a máscara de rede pode ser um número como 11111111.11111111.00000000.00000000 (255.255.0.0), mas nunca um número como 11111111.11111111.00000111.00000000 (255.255.7.0). A máscara de rede serve para quebrar um endereço IP em um endereço de rede e um endereço de host. Todos os computadores em uma mesma rede local (fisicamente falando, por exemplo, um mesmo barramento Ethernet) devem ter o mesmo endereço de rede, e cada um deve ter um endereço de host diferente. Tomando-se o endereço IP como um todo, cada computador em uma rede TCP/IP (inclusive em toda a Internet) possui um endereço IP único e exclusivo. O InterNIC controla todos os endereços IP em uso ou livres na Internet, para evitar duplicações, e reserva certas faixas de endereços chamadas de endereços privativos para serem usados em redes que não irão se conectar diretamente na Internet. Quando o IP recebe um pacote para ser enviado pela rede, ele quebra o endereço destino utilizado a máscara de rede do computador e compara o endereço de rede do destino com o endereço de rede dele mesmo. Se os endereços de rede forem iguais, isto significa que a mensagem será enviada para um outro computador na mesma rede local, então o pacote é repassado para o protocolo de enlace apropriado (em geral o Ethernet). Se os endereços forem diferentes, o IP envia o pacote para o default gateway, que é nada mais do que o equipamento que fornece a conexão da rede local com outras redes. Este equipamento pode ser um roteador dedicado ou pode ser um servidor com múltiplas placas de rede, e se encarrega de encaminhar o pacote para a rede local onde está o endereço IP do destino. É importante que o endereço IP do default gateway esteja na mesma subnet que o a máquina sendo configurada, caso contrário ela não terá como enviar pacotes para o default gateway e assim só poderá se comunicar com outros hosts na mesma subnet. Resumindo um computador qualquer em uma rede TCP/IP deve ser configurado com pelo menos estes três parâmetros: o seu endereço IP exclusivo, a sua máscara de rede (que deve ser a mesma utilizada pelos demais computadores na mesma LAN) e o endereço IP do default gateway. Digamos que o host com o endereço IP é 172.16.1.101 deseje enviar um pacote para o endereço 172.16.2.102. Caso a máscara de rede seja 255.255.0.0, o AND binário do enredeço fonte será 172.16.0.0, e o AND do endereço destino será 172.16.0.0, indicando que ambos possuem o mesmo endereço de rede e portanto estão diretamente conectados no nível de enlace. Neste caso, o nível IP envia um pacote ARP pela rede Ethernet para identificar qual o endereço Ethernet do host cujo IP é 172.16.2.2. Este pacote é enviado como um broadcast, de modo que todos os hosts conectados no mesmo segmento Ethernet receberão o pacote, e o host configurado para o endereço desejado irá responder ao pacote ARP indicando qual o seu endereço Ethernet. Assim o IP pode montar o pacote Ethernet corretamente endereçado e enviar o pacote para o seu destino. Agora digamos que a máscara de rede não fosse 255.255.0.0, mas sim 255.255.255.0. Neste caso, os endereços de rede da origem e destino seriam respectivamente 172.16.1.0 e 172.16.2.0. Como os endereços de rede são diferentes, isto significa que não temos conectividade direta (no nível de enlace) entre os dois hosts, portanto o pacote deverá ser entregue por intermédio de um roteador, que é o default gateway. Digamos que o default gateway seja 172.16.1.1 (observe que o endereço de rede do default gateway é 172.16.1.0, o mesmo do nosso host de origem). Então o host irá enviar um pacote ARP pela rede para descobrir o endereço Ethernet do default gateway, e enviará o pacote para este. Ao receber o pacote, o default gateway irá verificar que o endereço IP de destino é o IP de outro host que não ele, e irá verificar qual o endereço de rede do destino. Pode ser que o pacote esteja endereçado para uma rede local na qual o default gateway tenha uma conexão direta, ou pode ser que o default gateway tenha que direcionar o pacote para um outro roteador mais próximo do destino final. De qualquer forma, o default gateway segue o mesmo processo de gerar o endereço de rede utilizando a netmask, e em seguida enviar um pacote ARP pedindo o endereço Ethernet do próximo host a receber o pacote. A diferença é que um roteador não tem um default gateway, mas sim uma tabela de roteamento, que diz quais endereços de rede podem ser alcançados por quais roteadores. Notem que este exemplo considerou apenas a comunicação entre dois equipamentos, não entre dois programas. O nosso exemplo ficou apenas no nível de rede da pilha TCP/IP, mas acima dela o processo é simples: o IP verifica que tipo de pacote foi recebido (TCP, UDP ou outro) e repassa o pacote para o protocolo apropriado. O protocolo de transporte irá então verificar o número de porta contido no pacote e qual programa está associado aquela porta. Este programa será notificado da chegada de um pacote, e será responsabilidade dele decodificar e utilizar de alguma forma as informações contidas no pacote. Caso você venha a ter problemas de comunicação, todas as pilhas TCP/IP, independente de qual sistema operacional, trazem o utilitário ping para testar a conectividade entre dois hosts TCP/IP. Siga o seguinte procedimento: 1. ping 127.0.0.1. Este endereço IP é um loopback, ou seja, não vai para a rede, fica no computador que originou a mensagem. Se o ping acusar o recebimento da resposta, significa que a pilha TCP/IP está instalada e ativa no computador onde foi realizado o teste. (Somente a título de curiosidade, você pode usar o loopback do TCP/IP para desenvolver aplicações de rede em uma máquina stand-alone, sem nenhum tipo de conexão de rede disponível.) 2. ping meu_ip. Tendo comprovado que o TCP/IP está ativo na máquina origem, vamos enviar uma mensagem para ela mesmo, para verificar se a placa de rede (ou modem) estão ativos no que diz respeito ao TCP/IP. Aqui você testa apenas o driver da sua placa de rede, não a placa em si nem os cabos da rede. 3. ping ip_na_minha_rede. Agora vamos testar a comunicação dentro da rede local onde o computador de origem está localizado. Garanta que o computador dono do ip_na_minha_rede está com o TCP/IP e a sua placa de rede ativos, segundo os dois testes acima. Se não funcionar, você tem um problema de cabos ou em uma placa de rede, ou simplesmente as suas máscaras de rede e endereços IP estão incorretos. 4. ping ip_do_default_gateway. Se a comunicação dentro da minha rede local está OK, temos que verificar se o default gateway da minha rede está no ar, pois todos os pacotes que saem da minha rede local passam por ele. 5. ping ip_do_outro_lado. Digamos que o meu default gateway esteja diretamente conectado na rede destino. Eu tenho que testar se a interface de rede que liga o default gateway a esta rede está no ar. Então eu dou um ping no endereço IP desta placa. Se o default gateway não estiver diretamente conectado na rede destino, eu repito os passos (4) e (5) para cada equipamento que esteja no caminho entre origem e destino. 6. ping ip_do_destino. Sabendo que a outra rede pode ser alcançada via TCP/IP, resta saber se eu consigo me comunicar com o computador desejado. Até agora nós estamos vendo a comunicação em rede utilizando apenas os endereços IP. Imagine o seu cartão de visitas, indicando a sua home-page como: "164.85.31.230". Imagine-se ainda com uma lista contendo dezenas de números como esse pendurada na parede junto ao seu computador, para quando você precisar se conectar a um dos servidores da sua empresa. No início do desenvolvimento do TCP/IP, cada computador tinha um arquivo de hosts que listava os nomes dos computadores e os endereços IP correspondentes. Na Internet, certamente seria inviável manter estes arquivos, não só pelo tamanho que eles teriam mas também pela dificuldade em se manter milhões de cópias atualizadas. Logo foi desenvolvido o DNS, pelo qual diversos servidores mantém um banco de dados distribuído com este mapeamento de nomes lógicos para endereços IP. O DNS funciona de forma hierárquica. Vejam um endereço Internet típico, como www.petrobras.com.br. Inicialmente, separamos o primeiro nome (até o primeiro ponto), "www", que é o nome de um computador ou host, e o restante do endereço, "petrobras.com.br", que é o nome da organização, ou o nome do domínio. Por favor, não confundam o conceito de domínios em endereços Internet com o conceito de domínios em uma Rede Microsoft. Não existe nenhuma relação entre eles. O domínio petrobras.com.br possui o seu servidor DNS, que contém os nomes dos computadores (e endereços IP correspondentes) sob a sua autoridade. E ele sabe o endereço IP do servidor DNS do domínio que está acima dele, .com.br. Os computadores na Petrobras fazem todas as consultas por endereços IP ao servidor do seu domínio, e ele repassa as consultas a outros servidores DNS quando necessário. Os clientes necessitam saber apenas sobre o servidor do seu domínio, e mais nada. Já o servidor DNS do domínio .com.br sabe os endereços IP de todos os servidores dos domínios a ele subordinados (por exemplo, texaco.com.br, mantel.com.br, etc) e o endereço IP do servidor acima dele (domínio .br, o domínio que engloba todo o Brasil). Por fim, o servidor DNS do domínio br sabe os endereços de todos os servidores dos domínios a ele subordinados (.com.br, .gov.br, etc) e o endereço do servidor DNS do InterNIC, que é o servidor DNS raiz de toda a Internet. Uma consulta de uma aplicação por um endereço IP sobe por toda a hierarquia de servidores DNS, até o domínio comum de nível mais baixo que seja comum a origem e destino, ou até chegar ao servidor do InterNIC, e depois desce na hierarquia até o domínio onde está o computador destino. A resposta volta pelo caminho inverso, porém cada servidor DNS mantém um cache das respostas recebidas, de modo que uma nova requisição pelo mesmo nome não necessitará percorrer novamente todos os servidores DNS. Pode parecer que é realizado um trabalho muito grande somente para obter um endereço IP, mas o processo como um todo é rápido (quem navega na Web sabe bem disso), e ele possibilita que milhares de organizações integrem suas redes a um custo aceitável e com grande autonomia. Quando você acrescenta uma máquina no seu domínio, você não precisa comunicar ao InterNIC e às redes vizinhas, basta registrar o novo computador no seu servidor DNS. O protocolo DHCP Recapitulando, cada estação ou servidor em uma rede TCP/IP típica deverá ser configurada com os seguintes parâmetros: Endereço IP Máscara de Rede Default Gateway Além disso, caso a sua rede utilize um servidor DNS o seu endereço IP também deve ser configurado em cada host. Em uma rede com dezenas ou mesmo centenas de computadores, manter o controle dos endereços IP já utilizados pelas máquinas pode ser um pesadelo. É muito fácil errar o endereço IP de uma máquina, ou errar a máscara de rede ou endereço do default gateway, e geralmente é muito difícil identificar qual a máquina onde existe um erro de configuração do TCP/IP. Para resolver esses problemas você poderá instalar um servidor DHCP na sua rede local (ou melhor, um servidor DHCP para cada subnet, logo veremos porque) e deixar que ele forneça estes parâmetros para as estações da rede. Se você tem uma pilha TCP/IP instalada que suporta o protocolo DHCP, você pode configurar cada estação para usar o DHCP e ignorar todos esses parâmetros. Na inicialização da pilha TCP/IP, a estação irá enviar um pacote de broadcast para a rede (um broadcast é um pacote que é recebido por toda a rede) e o servidor DHCP, ao receber este pacote, enviará os parâmetros de configuração para a estação. Aqui temos comunicação apenas no nível de enlace (pois o TCP/IP ainda não foi completamente inicializado), e portanto não temos a função de roteamento habilitada. Por isso o servidor DHCP deve estar na mesma LAN física onde está a estação que será inicializada. Normalmente os servidores tem sua configuração realizada manualmente, pois o endereço IP deve concordar com o endereço IP cadastrado no servidor DNS. O servidor DHCP é configurado com uma faixa de endereços IP que ele pode fornecer aos clientes. Inicialmente, todos os endereços estão disponíveis. Quando uma estação é inicializada, ela envia o broadcast pedindo pela sua configuração, e o servidor DHCP reserva um endereço para ela (que deixa de estar disponível) e registra o endereço Ethernet para o qual o endereço foi reservado. Então ele envia uma resposta contendo este endereço e os demais parâmetros listados acima. O endereço é apenas "emprestado" pelo servidor DHCP, que registra também o momento do empréstimo e a validade deste empréstimo. No próximo boot, a estação verifica se o empréstimo ainda é válido e se não pede um novo endereço (que pode até ser o mesmo, por coincidência). Se o empréstimo estiver em metade da sua validade, o cliente pede uma renovação do empréstimo, o que aumenta a sua validade. E a cada inicialização, o cliente verifica se o endereço emprestado ainda é dela, pois ela pode ter sido deslocada para uma outra LAN, onde a configuração do TCP/IP é diferente, ou por qualquer motivo o Administrador da Rede pode ter forçado a liberação do endereço que havia sido emprestado. O servidor verifica periodicamente se o empréstimo não expirou, e caso afirmativo coloca o endereço novamente em disponibilidade. Desta forma, a não ser que você tenha um número de estações muito próximo ao número de endereços IP reservados para o servidor DHCP, você pode acrescentar, retirar ou mover estações pela sua rede sem se preocupar em configurar manualmente as pilhas TCP/IP a cada mudança. Geralmente o DHCP é utilizado somente para configurar estações cliente da rede, enquanto que os servidores são configurados manualmente. Isso porque o endereço IP do servidor deve ser conhecido previamente (para configuração do default gateway, para configuração do arquivo de hosts, para configuração de DNS, configuração de firewall, etc). Se fosse utilizado o DHCP, o endereço do servidor poderia ser diferente em cada boot, obrigando a uma série de mudanças de configuração em diversos nós da rede. Você também pode configurar o servidor DHCP para entregar aos clientes outras informações de configuração, como o endereço do servidor DNS da rede. O Linux pode operar tanto como cliente quanto como servidor DHCP, entretanto não veremos estas configurações no nosso curso. * Fernando Lozano é analista de sistemas especialista em redes locais e consultor do Clube do Hardware. Seu site pessoal, com várias informações sobre Linux, pode ser acessado em http://www.lozano.eti.br.
  10. A recuperação de instalações corrompidas de softwares e principalmente do sistema operacional/ambiente gráfico na grande maioria dos casos não tem sucesso, resultando em um sistema bastante instável, além do tempo gasto na tentativa de recuperação, bem maior do que o tempo gasto em uma instalação do zero. Isto ocorre porque o DOS/Windows tem muitas dependências. DLLs, Registry, arquivos INI, TypeLibs (para OLE) são compartilhados e atualizados sem nenhum controle por diversos softwares. Após um problema de consistência de disco, nunca se sabe até onde foi o estrago e quais aplicativos foram afetados. Não existe alternativa a não ser reinstalar os aplicativos um-a-um e aguardar que o próximo aplicativo "dê pau" para reinstalar o próximo. Entretanto, muitos aplicativos instalam DLLs e realizam outras modificações no sistema sem verificar se esta modificação pode ser realizada (por exemplo, sobreescrevendo uma DLL já existente por uma de versão mais antiga ou apagando uma sub-árvore inteira do Registry para gravar uma árvore nova, em vez de simplesmente editar as chaves necessárias). Por outro lado, se o instalador foi corretamente escrito, ele nunca irá recuperar as DLLs corrompidas porque não irá sobreescrever arquivos já existentes. Resumindo, em vez de se tentar recuperar uma instalação corrompida, deve-se remover toda a instalação e realizar uma nova do zero. No Windows, a maioria das situações implica em se formatar o HD e reinstalar o Windows, service packs e aplicativos. É um processo muito demorado, mas na maioria das vezes a tentativa de recuperação demora ainda mais. Só que a instalação do zero pode ser acelerada, enquanto que a tentativa de recuperação não pode. Você pode acelerar a reinstalação tendo todos os softwares (ou os principais) disponíveis em local de fácil acesso, como CDs, ZIP Drive ou drive de rede (esta é a mais rápida), escrevendo scripts de instalação automatizada e mantendo uma clara separação dos arquivos de programas, do sistema e de dados do usuário tanto no disco local quanto no de rede, de modo que os dados não necessitem ser sempre reinstalados, e que eles sejam "beckapeados" e restaurados fácil e rapidamente. Outro problema que normalmente acontece é relativo a hardware. O hardware do PC é de muito má qualidade, e existem diversos conflitos entre as diversas PROMs de placa-mãe, placa de vídeo, SCSI, placa de rede, etc. Juntando-se a memórias também de baixa qualidade, é muito difícil estabelecer se a instabilidade de um PC é de software ou de hardware. Entretanto, se pouco após uma instalação do zero os problemas ressurgem, podemos suspeitar de hardware ou de rede elétrica. Problemas de rede elétrica cedo ou tarde danificam o hardware. No Windows, é sempre uma boa idéia trocar a placa de vídeo de um PC instável por outro modelo de outro fabricante, visto que este é o componente mais susceptível a problemas de bugs no device-driver e de conflitos de PROM (esses conflitos de PROM são na verdade bugs no firmware). É procedimento padrão da Microsoft mudar o vídeo para driver VGA ou trocar a placa de uma vez. Persistindo a instabilidade, troque os pentes de memória, depois outras placas como de rede ou SCSI, e por fim troque a placa-mãe. Lembre-se: o fato de um componente funcionar sem problemas em um dado PC não significa que ele irá funcionar ok em outros PCs. Lembre-se também que o fato de um componente funcionar bem em DOS ou Windows 3.x não significa que ele irá funcionar bem em outros sistemas como Windows 95, NT, OS/2, SCO Unix, Linux ou Netware. Além desses sistemas exigirem bem mais do hardware, eles trazem seu próprio conjunto de situações em que bugs de device-drivers e de PROMs se manifestam. Somando-se isto ao fato de que poucas empresas tem pessoal especializado e capacidade de investimento para escrever e depurar os device-drivers e firmware em sistemas que não do DOS/Windows e o Netware (esses são os mais conhecidos, mais simples e conseqüentemente os mais baratos), não espere que um PC DOS/Windows continue funcionando 100% em outros sistemas. Com micros e componentes mais antigos, o Windows 95 também se torna um risco. O problema é tão sério que os maiores fabricantes de PCs dos Estados Unidos (Compaq, HP, IBM, Acer e Gateway) liberaram patches nos seus sites web pouco depois do lançamento do Windows 98. Alguns patches modificavam o próprio Windows 98, enquanto que outros eram fixes para os device-drivers e firmware dos próprios fabricantes. A maioria do pessoal certificado como MCSE que tem também experiência com outros sistemas (Netwre, Unix, OS/2) concorda que o NT é de longe o mais instável de todos em relação a hardware. E tinha que ser, pois o NT, apesar de 8 anos de existência, já teve 3 modelos diferentes de arquitetura de kernel e interface de device-drivers, e terá o quarto modelo quando sair o NT 5.0. Ou seja, a experiência anterior em escrever e depurar hardware para NT será jogada fora. Contraste isto com o modelo de interface e arquitetura de kernel mantidos sem alterações significativas pelo Netware, OS/2 e Unix durante o mesmo período. Esta estabilidade de kernel não impediu que o Netware incorpore o NDS e o HSS, que o OS/2 incorpore novos protocolos de rede e dispositivos de armazenamento ou que o Unix evolua para 64bits. Esta estabilidade é sinal de um bom projeto, enquanto que a instabilidade (das APIs) do kernel do NT demonstra um projeto incompleto seguido por remendos diversos.

Sobre o Clube do Hardware

No ar desde 1996, o Clube do Hardware é uma das maiores, mais antigas e mais respeitadas comunidades sobre tecnologia do Brasil. Leia mais

Direitos autorais

Não permitimos a cópia ou reprodução do conteúdo do nosso site, fórum, newsletters e redes sociais, mesmo citando-se a fonte. Leia mais

×
×
  • Criar novo...