Uma solução econômica e efetiva para a revitalização de laboratórios de informática do Exército Brasileiro

Transcrição

1 MINISTÉRIO DA DEFESA EXÉRCITO BRASILEIRO DEP DEE - DEPA ESCOLA DE ADMINISTRAÇÃO DO EXÉRCITO Uma solução econômica e efetiva para a revitalização de laboratórios de informática do Exército Brasileiro Salvador 2ØØ9

2 MINISTÉRIO DA DEFESA EXÉRCITO BRASILEIRO DEP - DEE - DEPA ESCOLA DE ADMINISTRAÇÃO DO EXÉRCITO 1 Ten Mateus Felipe Tymburibá Ferreira Uma solução econômica e efetiva para a revitalização de laboratórios de informática do Exército Brasileiro Trabalho de Conclusão de Curso apresentado como exigência parcial para obtenção do título de Pós-Graduação latu sensu, nível Especialização em Aplicações Complementares às Ciências Militares. Salvador 2ØØ9

3 DEDICATÓRIA Dedico este trabalho a Deus, fonte inesgotável de renovação, a meus pais, pelo apoio e incentivo incondicionais e à Bia, pelo companheirismo em todos os momentos.

4 AGRADECIMENTOS Agradeço a todos que contribuíram para a concretização desse trabalho, inclusive aqueles que colaboraram de maneira indireta ou que me apoiaram em períodos diversos da redação deste texto. Em especial, agradeço ao Cap Arruda pela paciente revisão e orientação durante o transcorrer do projeto. Agradeço também aos colegas de informática da turma de 2007 da EsAEx, Turma Ana Neri, que me apresentaram a tecnologia do LTSP e ampliaram minha visão quanto ao tema. Aos companheiros de trabalho no 4º Centro de Telemática de Área, meu agradecimento pelo constante aprendizado e compartilhamento de conhecimentos. Espero ter o privilégio de continuar ampliando meus horizontes através do convívio com todos. Mãos à obra!

5 Sumário 1 Introdução Restrições Orçamentárias no Exército Brasileiro Benefícios de plataformas baseadas em Terminais Leves Objetivos Referencial Teórico Software Livre LTSP Características Gerais Serviços-base Casos de sucesso Thin Clients Projeto e implantação de um laboratório de informática Softwares Equipamentos Servidor LTSP Instalação de Pacotes APT DHCP TFTP Portmap e NFS XDMCP LTSP-utils e libwww-perl swap Configurações DHCP TFTP NFS lts.conf XDMCP Swap Configuração dos terminais Boot Contas de usuários Conclusão e Trabalhos Futuros Referências...40 APÊNDICE A Listagem do arquivo de configurações do DHCP...45 APÊNDICE B Listagem do arquivo de configurações do TFTP...46 APÊNDICE C Listagem do arquivo /etc/hosts...46 APÊNDICE D Listagem do arquivo lts.conf...46

6 1 1 Introdução 1.1 Restrições Orçamentárias no Exército Brasileiro Desde o início da década de 1990, quando o governo brasileiro adotou uma postura econômica neoliberal e passou a priorizar o aumento do superávit primário como forma de garantir o pagamento das dívidas estatais, o Exército Brasileiro tem sofrido, assim como todos os demais segmentos da sociedade, sucessivas restrições orçamentárias. Conforme notícia divulgada no jornal Estado de São Paulo (2008), o Brasil acumulou em janeiro de 2008 um valor recorde de economia do setor público para o pagamento dos juros da sua dívida. O resultado desse esforço reflete diretamente na redução dos recursos disponibilizados pelo governo a todos os setores, entre eles as Forças Armadas. O quadro de dificuldades orçamentárias do Exército atingiu seu nível mais dramático em 2002, quando a Força Terrestre se viu obrigada a dispensar com seis meses de antecedência mais de 80% dos recrutas que haviam sido convocados para o serviço militar naquele ano, conforme noticiou a revista Época (2002) naquela ocasião. Outras medidas foram tomadas com o intuito de conter gastos, entre as quais pode-se citar o adiamento da incorporação do segundo grupamento de recrutas, a restrição quanto ao horário de funcionamento de diversas organizações militares e a suspensão do pagamento do auxílio-transporte e do auxílio pré-escolar (DÏB, 2008). Apesar de um pouco menos alarmantes, as dificuldades financeiras ainda são um ponto de constante presença no planejamento das atividades militares, como pode ser observado na Portaria Nº 616, de 11 de setembro de 2007, que aprova a Diretriz Preliminar de Instrução Militar (EXÉRCITO BRASILEIRO, 2007). Nesse documento, as restrições orçamentárias são listadas como um dos itens que compõem as condicionantes da Instrução Militar. Além disso, essa Portaria afirma que O Sistema de Instrução Militar do Exército Brasileiro regulará as prioridades para a aplicação dos recursos em face das restrições orçamentárias (EXÉRCITO BRASILEIRO, 2007, p.5). Atualmente, o próprio site do Exército cita as restrições orçamentárias como uma das premissas básicas consideradas pela Força Terrestre no processo de sua reestruturação (EXÉRCITO BRASILEIRO, 2008). Na contramão dessas dificuldades financeiras vivenciadas pelas Forças Armadas apresentam-se as necessidades tecnológicas dessas instituições, que carecem de constante renovação e atualização tecnológica, tanto de softwares quanto de equipamentos de telecomunicações e informática. Nenhuma unidade do Exército pode funcionar atualmente se não estiver razoavelmente equipada com equipamentos de informática, já que praticamente todo o processo logístico e administrativo da força é disponibilizado por meios digitais. Naturalmente, além de possuir tais equipamentos, as organizações militares requerem treinamento para formação e aperfeiçoamento do seu quadro de profissionais, a fim de habilitá-los a operar os diversos sistemas do EB. Por esse motivo, a maioria das unidades se ressentem por não possuírem laboratórios de informática para uso geral e treinamento de seus funcionários. Para a maior parcela das organizações militares, os custos de montagem e manutenção de um laboratório de informática tornam-se proibitivos, face às restrições orçamentárias mencionadas. Em laboratórios tradicionais, onde cada máquina é

7 2 Requisito mínimo de clock (MHz) equipada com disco rígido adequado para a instalação do sistema, processadores relativamente velozes e memória suficiente para armazenar aplicativos de uso comum, como ferramentas de escritório, o custo mínimo de cada máquina raramente é menor do que R$1.000,00. Podem ser citados os exemplos da Universidade Estadual de Mato Grosso (UNEMAT) e da Conspiração Mineira pela Educação, ONG criada no estado de Minas Gerais, que atua em projetos de melhoria da qualidade de ensino. No primeiro caso, foram cotados 120 computadores a um preço de R$ ,00, segundo notícia divulgada pela Assembléia Legislativa do estado do Mato Grosso (ASSEMBLÉIA LEGISLATIVA DO ESTADO DE MATO GROSSO, 2008). No projeto da Conspiração Mineira pela Educação, previsto para implantação nos meses de abril a julho de 2008, a compra de 19 máquinas foi orçada pelo preço de R$18.981,00 (CONSPIRAÇÃO MINEIRA PELA EDUCAÇÃO, 2008). Além dos custos envolvidos na instalação de um laboratório de informática, os seus gastos de manutenção podem exigir um esforço financeiro tão grande quanto o investimento inicial. O desenvolvimento de softwares que agregam cada vez mais recursos gráficos e funcionalidades tem exigido progressivamente máquinas mais velozes e com mais memória. Um bom exemplo da crescente demanda por recursos físicos de máquinas por parte dos sistemas computacionais são os requisitos mínimos de hardware para o funcionamento do sistema operacional Windows, da Microsoft, ao longo das suas sucessivas versões. Os gráficos 1 e 2 apresentam, respectivamente, o aumento dos requisitos mínimos de processamento e de memória, exigidos pelo Windows em suas versões evolutivas. Evolução dos requisitos de processamento do Windows ME XP Vista Versões do Windows Gráfico 1 Evolução dos requisitos de processamento do Windows (FÓRUM DO BABOO, 2008)

8 Requisitos mínimos de memória (KB) Evolução dos requisitos de memória do Windows ME XP Vista Versões do Windows Gráfico 2 Evolução dos requisitos de memória do Windows (FÓRUM DO BABOO, 2008) Observando-se os gráficos, percebe-se claramente um crescimento exponencial da exigência de recursos de processamento e de memória ao longo das versões do sistema operacional da Microsoft. Essa carência por hardware sucessivamente mais eficiente ocorre de maneira generalizada entre os sistemas, uma vez que todos os softwares buscam aprimorar suas funcionalidades e efeitos gráficos, como forma de atrair usuários com interfaces cada vez mais sofisticadas. A constante demanda por equipamentos de última geração, capazes de prover recursos para o funcionamento adequado dos sistemas computacionais, torna inviável a tarefa de instalar e manter um laboratório de informática para a maior parcela das unidades do Exército. Nesse cenário, surge a necessidade de elaboração de medidas alternativas para a preservação das atividades que dependem dos recursos de informática, em especial a manutenção de laboratórios de informática, já que essas tarefas requerem uma constante atualização e reaparelhamento do parque de máquinas. 1.2 Benefícios de plataformas baseadas em Terminais Leves A estratégia mais empregada em ambientes que requerem uma utilização intensiva de recursos computacionais aliada a uma baixa necessidade de poder de processamento é baseada em Terminais Leves (MOREIRA, 2004). Esse termo se refere a estações de trabalho com supressão de hardware, em geral disco rígido, mas que executam tarefas como uma estação desktop padrão. Para isso, as máquinas clientes

9 4 acessam via rede todos os aplicativos em servidores remotos, que concentram as tarefas de processamento dos sistemas. Em um servidor para terminais leves, os aplicativos usados por todos os clientes rodam no mesmo computador, o que garante o compartilhamento de recursos. A utilização média desse processador é baixa, mesmo com 20 ou 30 terminais pendurados nele, já que tem-se uma máquina relativamente rápida e usuários conectados realizando tarefas simples, como ler s, escrever textos ou navegar na Internet. Isso faz com que quase sempre que um usuário precise executar um programa, ou realizar uma tarefa intensiva, encontre o processador livre, como se ele estivesse sozinho no servidor. Em Servidores Linux (2008), Carlos E. Morimoto aponta que o desempenho ao utilizar um terminal ligado a um servidor com um processador de 3.0 GHz, compartilhado entre 20 terminais, é quase sempre melhor que utilizar um desktop com um processador de 1.5 GHz. A memória RAM também é compartilhada de uma maneira bastante eficiente. Os aplicativos são carregados na memória do servidor apenas uma vez, independente do número de usuários que o utilizarem simultaneamente. O sistema carrega o aplicativo uma vez, e depois passa a abrir diferentes sessões do mesmo programa (como ao abrir uma segunda janela do navegador, por exemplo), o que faz com que o carregamento passe a ser mais rápido (afinal, o aplicativo já está carregado) e o uso de memória seja otimizado. Novamente, Morimoto (2008) indica em seu trabalho que um servidor com 1 GB de memória RAM, dividido entre 20 terminais, executa, em geral, os aplicativos com um desempenho muito melhor que um desktop com 256 MB usado por um único usuário. As características de arquitetura de laboratórios de informática com Terminais Leves garantem a principal vantagem no emprego dessa solução no âmbito do Exército Brasileiro: poder utilizar computadores mais antigos como terminais, já que as exigências para memória RAM e a capacidade do processador são menores. O custo de um terminal é até 60% menor do que um microcomputador comum (DEPARTAMENTO DE CIÊNCIA E TECNOLOGIA, 2005). É possível ainda o remanejamento dos microcomputadores atuais sem necessidade de realizar atualizações. Pode-se, até mesmo, colocar em funcionamento antigos computadores que estejam descarregados e inutilizados. O reaproveitamento, sem perda de qualidade, de equipamentos ora em desuso, pode acarretar considerável economia de recursos, principalmente diante das restrições permanentes de orçamento. Em virtude da configuração exigida para essas máquinas, sua defasagem é extremamente retardada, resultando em considerável economia para o Exército. Além do benefício financeiro, gerado pela economia de recursos com a aquisição de equipamentos, a solução proposta apresenta outros benefícios imediatos: facilita significativamente a administração da rede, pois centraliza no servidor todas as atividades de instalação de softwares e configuração de sistemas; como essa arquitetura trabalha com o compartilhamento de memória RAM, os aplicativos de uso comum nos diversos terminais carregam muito mais rápido, pois na verdade já estarão carregados no servidor quando um usuário necessitar carregá-lo; o armazenamento de dados também é feito todo no servidor, facilitando a definição de uma política de backup que proteja os dados de todos os usuários de forma transparente;

10 5 é possível centralizar as políticas de atualização de anti-vírus, evitando uma sobrecarga no link de acesso externo aos servidores de vacinas, causada pela conexão individual de cada uma das estações de trabalho; a estação de trabalho pode ser desprovida de todos os elementos móveis: disco rígido, unidade de disquete e CD-ROM. Como consequência, observa-se uma durabilidade muito maior do conjunto, além da redução dos gastos com manutenção. 1.3 Objetivos Este projeto propõe uma solução para o desafio de instalação e manutenção de laboratórios de informática em unidades do Exército Brasileiro onde os recursos são escassos, baseada em uma tecnologia livre de terminais leves denominada LTSP (Linux Terminal Server Project). São apresentados, de forma detalhada, todos os procedimentos necessários para a implantação de um laboratório de baixo custo, desde os projetos de hardware e software até a solução de problemas específicos. Além de explicar o funcionamento de cada serviço, são apresentados todos os comandos para que esses utilitários sejam colocados em funcionamento, desde a instalação até a sua configuração final. São discutidas ainda as diversas versões do LTSP disponíveis e os casos de sucesso no emprego dessas versões. Finalmente, indica-se algumas possibilidades de trabalhos para o futuro aprimoramento desta solução. 2 Referencial Teórico 2.1 Software Livre O movimento do Software Livre baseia-se no princípio do compartilhamento do conhecimento e na solidariedade praticada pela inteligência coletiva conectada à rede mundial de computadores. Ele surgiu a partir da criação da Free Software Foundation por Richard Stallman, à época integrante do Massachusetts Institute of Technology (MIT), que indignou-se contra a proibição de se acessar o código fonte de um software. O movimento começou reunindo e distribuindo timidamente programas e ferramentas livres, com o código-fonte aberto. Assim, todas as pessoas podiam ter acesso não só aos programas mas também aos códigos em que foram escritos. O objetivo principal era produzir um sistema operacional livre que funcionasse de forma semelhante ao Unix, sistema proprietário bastante utilizado na época. Em decorrência disso, a maioria dos esforços de programação eram reunidos em torno do projeto do GNU (Gnu Is Not Unix) (ELIAS e MATTOS, 2007). Para evitar que os esforços do movimento fossem apropriados indevidamente e patenteados por algum empreendedor oportunista, a Free Software Foundation idealizou a Licença Pública Geral, GPL em inglês, conhecida como copyleft, em contraposição à lei de copyrigh, que protege os programas de computadores com restrições de direitos autorais. A GPL é aplicável em todos os campos em que os direitos autorais são utilizados: livros, imagens, músicas e softwares.

11 6 Com a difusão da internet, o movimento do Software Livre difundiu-se mundialmente e alcançou a meta de produzir um sistema operacional livre, completo e multifuncional, o GNU/Linux. Em 1991, o finlandês Linus Torvald conseguiu compilar todos os programas e ferramentas do movimento GNU em um kernel, um núcleo central, o que viabilizou tal sistema operacional. Torvald denominou esse seu esforço de Linux, ou seja, Linus for Unix (LINUX ONLINE, 2007). Segundo Sérgio Amadeu da Silveira (2005), em 2005 o GNU/Linux já baseavase nos esforços de mais de 400 mil desenvolvedores espalhados por mais de 90 países. O autor aponta a extrema dificuldade de encontrar desenvolvimentos de engenharia comparáveis em extensão, envolvimento de pessoas e alcance geográfico, como o empreendido pelo projeto do GNU/Linux. Cita ainda que a Microsoft, maior empresa de software do planeta, produz o sistema operacional Windows contando em seu quadro funcional com aproximadamente 30 mil funcionários concentrados em sua sede em Seatle, EUA. Em breve, o desenvolvimento e a melhoria anual do GNU/Linux contará com 1 milhão de programadores, conforme Amadeu. Trata-se de estudantes, especialistas, empresas em busca de lucro e profissionais de altíssimo nível, entre outros. Para Eric Raymond (2001), como qualquer pessoa com acesso à Internet e habilidades de programação pode integrar o processo de desenvolvimento de softwares livres, esses sistemas envolvem um número tão grande de horas de programação qualificada a um custo orçamentário zero que dificilmente uma grande corporação poderia dispor. A vantagem de custo do software livre, imediatamente percebida, não está somente na economia com o pagamento de licenças, já que o software livre também reduz os custos de manutenção e de atualização dos sistemas. A correção de erros e apoio eficiente aos usuários oferecido pelas numerosas e atuantes comunidades de desenvolvedores livres explica o primeiro aspecto. No segundo caso, pode-se argumentar que frequentemente os fabricantes de softwares proprietários deixam de suportar seus antigos sistemas, forçando os compradores a uma atualização. Além disso, existem políticas de licenciamento de programas de computador, como a Software Assurance, da Microsoft, que obrigam os clientes a realizar assinaturas anuais para obter atualizações constantes, mesmo que não possam ou não queiram, perdendo o direito de efetuar atualizações com descontos, conforme suas necessidades (FERRAZ, 2002). Além de menos onerosas, as soluções não proprietárias oferecem outras vantagens irrefutáveis. Em Vantagens estratégicas do software livre para o ambiente corporativo, Ferraz (2002) discorre detalhadamente sobre os motivos que tornam as soluções livres mais diferenciadas (inovadoras), seguras, independentes de fornecedores e confiáveis. Todos esses fatores têm contribuído para um aumento significativo do interesse de grandes corporações na adoção de plataformas livres. Um exemplo disso é o estabelecimento do Open Source Developer Labs (OSDL), uma organização sem fins lucrativos financiada por corporações como IBM, Hewlett-Packard, Intel, AMD, RedHat e Novell, especificamente para desenvolver o Linux para ambientes de grande escala de produção (LINUX ONLINE, 2007). Segundo Jackson (2004), nos últimos anos a maior parte do código do Linux tem sido gerada por programadores profissionais, empregados em corporações, como IBM, Red Hat e SGI, dentro do horário de trabalho. No Brasil, o Governo Federal aprovou em 2003 suas diretrizes para implementação do Software Livre, onde determina que os órgãos públicos federais passem a priorizar, implementar e fomentar o uso de plataformas baseadas em soluções

12 7 livres (COMITÊ TÉCNICO DE IMPLEMENTAÇÃO DO SOFTWARE LIVRE NO GOVERNO FEDERAL, 2003). Alinhado a essa política, o Exército Brasileiro instituiu o Plano de Migração para o Software Livre, tendo como finalidade regular as estratégias para a consolidação da implantação do Software Livre em todos os escalões da Força Terrestre (COMITÊ TÉCNICO DE IMPLEMENTAÇÃO DO SOFTWARE LIVRE NO GOVERNO FEDERAL, 2007). 2.2 LTSP Características Gerais O Linux Terminal Server Project (LTSP) é um pacote adicional que provê utilitários necessários para a conexão de terminais leves a um servidor Linux. Ele permite que estações não apenas rodem aplicativos instalados em um servidor, mas realmente dêem boot via rede, executando todos os softwares que precisam diretamente no servidor. Não é preciso ter disco rígido (HD) nem CD-ROM nas estações de trabalho. O servidor fica com o grosso do trabalho, que é executar os programas e armazenar todos os dados. Ele envia para os clientes apenas instruções para montar as janelas que serão exibidas, e estes enviam de volta os movimentos do mouse e as teclas digitadas no teclado (MCQUILLAN, 2006). Por isso, os requisitos de hardware para as estações de trabalho passam a ser mínimos, permitindo a utilização de equipamentos muito baratos, aparentemente imprestáveis e descartáveis. O LTSP foi concebido por James McQuillan para atender à empresa norte americana de material hospitalar Binson's Hospital Supplies, que buscava uma solução de terminais para comunicação com servidores de várias aplicações, utilizando-se o protocolo TCP/IP, que fosse de fácil gerenciamento e que permitisse ao usuário do terminal navegar na Internet e receber s (FERRETTI, 2004). O projeto não inventou algo novo, mas procurou reunir diversos programas e protocolos para tornar o GNU/Linux um servidor completo de terminais, com alto nível de gerenciamento. A primeira versão do LTSP foi lançada em 1999 e, de lá pra cá, o sistema mostrou-se tão eficiente, flexível e economicamente atraente que tornou-se o projeto de terminais leves mais ativo e popular entre os usuários de soluções livres (MOREIRA, 2004). Ao longo de sua evolução, o LTSP agregou funcionalidades importantes, como o suporte a dispositivos de armazenamento locais, tais como CDs, DVDs, disquetes e cartões de memória USB, ou a compatibilidade com periféricos de áudio e de impressão (MCQUILLAN, 2006). Atualmente disponível na versão 4.2, o LTSP pode ser descarregado gratuitamente da Internet nos formatos de pacotes das distribuições Linux mais utilizadas, mas a partir da versão 4.0 foi desenvolvido um sistema unificado de instalação, que deve ser priorizado por se encarregar de baixar os pacotes e efetuar a instalação automática dos serviços base, evitando conflitos de versões entre bibliotecas necessárias para o funcionamento do sistema. Está em desenvolvimento também a versão 5 do LTSP, que abandonou o uso de pacotes próprios em detrimento de uma integração mais harmoniosa com as diversas distribuições do Linux. Contudo, essa versão ainda não é tão madura e confiável quanto a 4.2, além de funcionar em um número pequeno de distribuições (MORIMOTO, 2008). Existem ainda versões do LTSP adaptadas pelas equipes de desenvolvimento de distribuições Linux e distribuídas como uma distribuição separada, normalmente voltadas para instituições educacionais, como o Edubuntu, o opensuse Education, o

13 8 DebianEdu e o K12-Linux (ASSOCIAÇÃO ENSINO LIVRE, 2008). Naturalmente, essas distribuições facilitam o processo inicial de instalação do sistema para usuários com pouca familiaridade com o LTSP, mas podem dificultar a configuração de recursos avançados, por omitirem determinados parâmetros de configurações. Em função disso, recomenda-se a configuração manual de cada utilitário que compõe o projeto, como será demonstrado neste trabalho Serviços-base O LTSP é carregado nos clientes usando uma série de serviços. Inicialmente, o terminal executa um boot remoto através de um pequeno software que ativa a placa de rede da estação e envia um pacote de broadcast solicitando as configurações de rede da máquina. Um servidor DHCP (Dynamic Host Configuration Protocol), que pode ser instalado junto com o sevidor LTSP, é configurado para responder aos chamados de broadcast dos boots remotos, enviando as configurações da rede, tais como endereço IP, máscara de rede e gateway padrão. O servidor DHCP envia ainda instruções adicionais orientando o terminal a carregar a imagem do Kernel do Linux via TFTP (Trivial File Transfer Protocol) e a acessar os demais arquivos do sistema via NFS (Network File System) (MCQUILLAN, 2005). O TFTP, como o próprio nome diz, é um protocolo bastante simples de transferência de arquivos, onde a estação simplesmente requisita um arquivo e o recebe utilizando o protocolo UDP. Essa simplicidade faz com que ele seja o único sistema de transferência que cabe na imagem de boot das estações e possibilite o seu uso na etapa inicial do boot (FAQS.ORG, 1992). Depois que o kernel é carregado via TFTP, um cliente NFS é usado para montar a pasta "/opt/ltsp/i386/" do servidor como diretório raiz. Essa pasta é compartilhada com a rede no servidor LTSP e acessada via NFS pelos clientes, como se fosse uma partição local. Dentro desse diretório ficam armazenados os arquivos do sistema, responsáveis por detectar o hardware dos terminais e permitir que eles abram seções do ambiente gráfico do Linux (servidor X) (VANGUNDY, 2006). Terminado o boot, o cliente obtém a tela de login do servidor via XDMCP (X Display Manager Control Protocol), um protocolo nativo do servidor X, responsável por atualizar as imagens na tela. A partir daí, o servidor executa os aplicativos e o cliente apenas mostra as imagens geradas na tela, atuando como um "terminal burro". Resumidamente, existem 4 serviços base que se integram para possibilitar o funcionamento do LTSP: DHCP, TFTP, NFS e XDMCP. A instalação e configuração desses serviços será descrita em detalhes na seção Casos de sucesso Existem inúmeros exemplos de casos de sucesso de utilização de soluções baseadas no LTSP. A Coordenadoria de Inclusão Digital da cidade de São Paulo, por exemplo, já instalou mais de 300 Telecentros em áreas de exclusão social da cidade, cada um com cerca de 20 computadores, empregando com êxito a tecnologia proposta para esse projeto. Cada Telecentro funciona com 75% dos terminais dedicados à formação da população, ministrando cursos e oficinas de informática. Os outros 25% são reservados para o uso livre dos cidadãos. Desde o início do Projeto Telecentros, em junho de 2001, mais de 90 mil pessoas já se formaram e receberam certificados. Estima-

14 9 se que no total, mais de 1,5 milhão de pessoas sejam beneficiadas por esse projeto [26]. O projeto LibertasBR, desenvolvido pela UFMG, Faculdades Doctum e Prodabel, também está viabilizando a implantação de Telecentros de Inclusão Digital em comunidades carentes do norte e nordeste de Minas Gerais, em parceria com o governo do estado, através do emprego de terminais com boot remoto em um projeto denominado Cidadão.Net [9]. Em 2004, a Biblioteca Central da Unicamp implantou uma solução baseada no LTSP em 15 microcomputadores, a fim de reaproveitar equipamentos considerados obsoletos. Segundo o técnico em computação Marcelo Franklin da Silva, responsável pela implementação do projeto, com a nova sistemática a biblioteca economizou 80 mil reais, entre hardware, software, consultoria e manutenção [27]. Esses são apenas alguns exemplos do sucesso oferecido pela implantação dessa tecnologia no Brasil, principalmente em ambientes onde os recursos são escassos e a necessidade é urgente. Pode-se conferir outros exemplos recentes ou mais antigos de casos de sucesso utilizando a tecnologia LTSP ao redor do mundo no próprio site do projeto, onde os usuários do sistema comentam suas experiências e trocam opiniões em um ambiente virtual destinado à divulgação de resultados. 2.3 Thin Clients Existem no mercado diversos modelos de hardware específico para projetos de terminais remotos conhecidos como ThinClients (clientes magros). Trata-se de equipamentos especializados para executar boot remoto, projetados especificamente para projetos com arquitetura de terminais leves. Geralmente esses dispositivos são baseados em processadores de baixo desempenho, possuem uma memória RAM bastante limitada e capacidade de armazenamento reduzida ou até mesmo inexistente. A principal vantagem apresentada pelos ThinClients decorre do seu tamanho compacto, como pode ser observado na figura 1, que ilustra seis exemplos desses equipamentos: da esquerda para a direita, o HP Neoware e90, HP t5135, Sun Ray 2 Cliente, Sun Ray 2FS Client, e Fujitsu FUTRO A. Acima, o Fujitsu FUTRO S. Além disso, por integrarem processadores de baixo desempenho, esses equipamentos apresentam um pequeno consumo de energia e uma dissipação de calor mínima, fatores que possibilitam a redução de suas dimensões. Greenberg e Anderson [29] afirmam em seu estudo que, em ambientes reais de utilização, alguns modelos de ThinClients chegam a usar 85% menos energia do que os microcomputadores pessoais. Figura 1 Imagem de ThinClients da HP, Sun e Fujitsu [30][31][32].

15 10 Apesar dos benefícios de economia de espaço físico e redução de consumo energético oferecidos pelos ThinClients, eles não constituem a opção economicamente mais vantajosa. Morimoto [10] comenta que, em geral, utilizar microcomputadores configurados com placas-mãe de baixo custo e sem HD é a opção mais barata, mesmo ao optar-se por empregar computadores novos, já que a configuração do terminal exige apenas que o cliente disponha de 64 MB de memória RAM e de uma placa de vídeo minimamente atual. Os preços dos ThinClients, por sua vez, não são atraentes porque trata-se de projetos especializados, produzidos em pequena quantidade. 3 Projeto e implantação de um laboratório de informática A implantação de um laboratório de informática requer a execução de algumas etapas de planejamento da estrutura de software e hardware a ser utilizada. São descritos a seguir aspectos a serem considerados por ocasião do projeto, levando-se em conta que este trabalho baseou-se em uma rede local, sem acesso à Internet, com as seguintes características: padrão: Ethernet IEE 802.3u 100BASE-TX (Fast Ethernet) cabeamento: par trançado categoria 5e e conectores RJ máquinas com placas de rede 100BASE-TX (100 MBits) e conectores RJ-45 Definidas as configurações da rede local a ser implementada, apresenta-se detalhadamente os passos para a instalação e configuração do servidor LTSP e dos seus terminais. 3.1 Softwares A fim de manter o alinhamento à política de migração para o software livre adotada pelo Exército Brasileiro, recomenda-se a instalação e utilização exclusivamente de programas livres. Baseado nessa estratégia, e em consonância com instruções do Departamento de Ciência e Tecnologia [11], indica-se o uso dos seguintes softwares: gravação de CDs e DVDs: K3B execução de vídeos: Mplayer execução de áudio: XMMS navegação na Internet: Mozilla-Firefox ferramentas de escritório: BrOffice edição de imagens: GIMP cliente de Thunderbird emulador do Windows: Wine criptografia: GnuPG (Gnu Privacy Guard) compactação e backup de arquivos: Bacula firewall: Iptables servidor web: Apache servidor proxy: Squid

16 11 Foi sugerido apenas uma opção de software livre para as aplicações mais utilizadas em trabalhos cotidianos com computadores. Deve-se ressaltar que é possível encontrar e descarregar gratuitamente da Internet diversos aplicativos de alta qualidade para cada uma das categorias mencionadas, de acordo com o gosto e necessidade dos usuários, bem como providenciar sistemas para categorias que não foram abrangidas neste texto. Existem ainda os sistemas corporativos do Exército, que também podem operar de forma eficiente em um ambiente de terminais leves. Em função da opção por empregar sistemas livres neste projeto, dedicados ao sistema operacional Linux, deve-se tratar com especial atenção o caso dos sistemas corporativos da Força desenvolvidos para execução no sistema operacional Windows. A seção de informática da 6ª Brigada de Infantaria Blindada disponibilizou, por intermédio do Departamento de Ciência e Tecnologia, um documento onde descreve a execução com sucesso dos sistema SIMATEx / SISCOFIS, desenvolvido para o sistema operacional da Microsoft, em ambiente Linux dotado com o emulador Wine [11]. No entanto, essa solução deve ser evitada sempre que possível, já que o desempenho de qualquer sistema em emuladores tende a ser pior do que no seu sistema operacional nativo [33]. Além disso, foi documentado o insucesso na tentativa de adotar essa solução com outros sistemas corporativos. Para esses casos, foi adotado o sistema de máquina virtual VMWare, que permite a execução do Windows e dos aplicativos nele instalados em máquina rodando o Linux. No entanto, além de também sofrer de deficiências de desempenho, o VMWare é um sistema comercial, que exige o pagamento de licença de uso, assim como o Windows. Existe ainda uma solução baseada no utilitário rdesktop, onde é possível manter apenas um servidor de terminais executando todos os aplicativos desenvolvidos para Windows e o outro servidor LTSP executando os demais sistemas. Cria-se um ícone na área de trabalho dos terminais que, ao ser acionado, executa remotamente a aplicação que estiver instalada no servidor Windows, de forma análoga ao funcionamento do LTSP. Essa solução é muito utilizada por empresas que migram suas estações de trabalho para o Linux, mas precisam manter alguns aplicativos específicos do Windows [34]. Ao criar os ícones nos desktops dos usuários, é possível disparar um comando com o rdesktop cuidadosamente personalizado, de forma a abrir uma janela de conexão com uma resolução de tela específica e já remetendo o login e senhas utilizados, bem como outros parâmetros para compartilhamento de impressora e pastas. Assim, o usuário tem apenas o trabalho de clicar no ícone disponibilizado. Apesar das facilidades oferecidas pelo rdesktop, deve-se atentar para o fato do licenciamento necessário para a implantação dessa solução. Além da licença necessária para o servidor de aplicações Windows, deve-se adquirir uma liberação para cada máquina cliente que venha a se conectar ao servidor. Além disso, apenas as versões server do Windows oferecem o pacote completo do Windows Terminal Server, onde o número de sessões simultâneas é limitado apenas pelo hardware do servidor e pelo número de licenças para clientes. As máquinas com as versões domésticas do Windows XP e do Windows Vista também podem ser acessadas remotamente, mas não oferecem suporte a conexões simultâneas. Quando o usuário acessa remotamente a máquina, o sistema operacional coloca a sessão local em espera e, ao acessar remotamente, o sistema fecha a conexão remota. Existem soluções para remover as limitações técnicas e destravar o acesso remoto de vários clientes a máquinas rodando o Windows XP, como o XP Unlimited e o Unlimited Remote Desktop Connections. Entretanto, essas alternativas não são recomendadas, principalmente em ambientes empresariais e de produção, já que violam o contrato de licença do Windows [34].

17 Equipamentos O primeiro equipamento necessário para interligar os 20 terminais ao servidor, conforme descrito no modelo de rede a ser trabalhado, é um switch de 100 Mbits, com no mínimo 21 portas. A escolha exata do switch a ser empregado depende diretamente das característica de utilização da rede. Existem, por exemplo, switches gerenciáveis com capacidade de subdividir a rede local em redes virtuais (VLANs), criar rotas baseadas nos endereços MAC das máquinas ou priorizar determinados tipos de pacotes ativando o uso de mecanismos de Qualidade de Serviço (QoS) [35]. Por outro lado, para uma rede com poucas máquinas, como a que pretende-se explorar neste texto, um hubswitch com o número de portas suficiente (21 portas) pode ser empregado com sucesso. É possível até mesmo utilizar vários switches pequenos interconectados (modo daisy chain ), como forma de reaproveitar equipamentos com um número de portas menor do que o necessário. Como já descrito no Capítulo 1 Introdução, as máquinas clientes não precisam ser dotadas de HD ou CD-ROM para que possam ser empregadas em uma arquitetura de terminais leves. Basta que elas possuam um mecanismo para dar boot através da rede. A maioria das placas-mãe fabricadas atualmente, com alguma placa de rede integrada (onboard), suportam boot via rede utilizando o protocolo PXE, um protocolo desenvolvido pela Intel que permite que as estações carreguem todo o software a partir de um servidor [36]. Nesses casos, basta configurar a BIOS da placa indicando que o boot via rede deve ser utilizado no momento de inicialização da máquina. No caso de máquinas antigas, ainda sem suporte ao protocolo PXE, pode-se utilizar o Etherboot, um pequeno software para boot, que precisa ser gravado em um disquete ou CD e disponibilizado durante a inicialização do terminal [37]. Nesse caso, deve-se também acessar a BIOS e certificar-se de que o boot via mídia está definido como primeira opção. Uma outra possibilidade, um pouco mais incomum, é a gravação do Etherboot em um chip específico para boot, que é posteriormente instalado no soquete disponível na maioria das placas de rede PCI. Essa alternativa é menos empregada por necessitar de um hardware específico para gravar o software no chip apropriado. Indicações mais detalhadas de como proceder à configuração do boot nos terminais, de acordo com a opção do projetista da rede, são descritas na seção Boot. Como já mencionado, a maior vantagem da utilização de uma arquitetura de terminais leves decorre do baixo custo dos terminais, já que eles têm exigências de hardware pouco onerosas. Morimoto [10] comenta que a configuração ideal das máquinas cliente para um bom desempenho deve reunir um processador Intel Pentium 1 (60 MHz) com 32 MB de memória RAM, requisitos bastante modestos quando comparados aos componentes instalados nos microcomputadores vendidos atualmente. Além disso, o autor ressalta que o LTSP foi projetado para dar boot em qualquer máquina com a partir de 12MB de memória RAM, o que permite a utilização até mesmo dos antigos Intel i486 (33 MHz). Outro fator que pode acarretar economia de recursos decorre do emprego de processadores de baixo consumo energético nos clientes. Deve-se evitar processadores que não oferecem suporte a gerenciamento avançado de energia, como os Intel Celeron da família 4xx ou processadores que possuem uma dissipação muito alta de calor, como os Intel Pentium D. Atualmente, os AMD Sempron, da família em diante, e os

18 13 AMD Athlon 64, exceto a família X2, são boas escolhas, pois consomem pouco mais de 6 watts por hora quando ociosos, o que permite montar terminais que consumam menos de 20 watts por hora no total (descontando-se o consumo do monitor) [10]. O baixo consumo das máquinas pode se tornar um fator de economia considerável a longo prazo. Considerando-se que um terminal fique ligado 10 horas por dia e que o preço médio do kwh em todo o Brasil atualmente varia em torno de R$0,32 [38], a diferença entre um terminal que consome 20 watts por hora e outro que consome 60 watts aproxima-se de R$50,00 por ano. O valor é pequeno se considerado isoladamente, mas em uma rede com apenas 20 máquinas a diferença já se torna significativa, atingindo um valor próximo de R$1.000,00. Um último fator a ser considerado por ocasião da escolha dos componentes de hardware dos clientes é a estabilidade da placa-mãe, já que placas-mãe instáveis tendem a causar problemas recorrentes de manutenção e muitas vezes obrigam a troca de outros componentes de hardware ou da própria placa-mãe [39]. Quanto à configuração da máquina servidora, recomenda-se equipá-la inicialmente com um processador razoavelmente rápido (em torno de 3.0GHz) e 1 ou 2 GB de memória RAM [10]. A partir daí, deve-se monitorar o consumo de memória e a carga de utilização do processador, afim de verificar a eventual necessidade de adicionar ao equipamento mais memória ou um processador dual core. Um servidor dual oferece uma grande vantagem ao utilizar-se muitos terminais, pois ele pode executar aplicativos separados em cada processador, executando mais tarefas simultaneamente e eliminando o gargalo em momentos em que vários usuários resolvem utilizar aplicativos pesados simultaneamente. [10] Em máquinas desktop convencionais, normalmente apenas um aplicativo pesado é executado de cada vez, deixando o segundo processador ocioso durante a maior parte do tempo. Ao contrário, em um servidor de terminais, em alguns momentos os diversos clientes podem estar executando várias tarefas diferentes, de forma que uma divisão de trabalho ocorre efetivamente entre os dois processadores. Em muitos casos, o desempenho ao utilizar dois processadores aproxima-se do dobro da performance ao empregar-se apenas um processador [10]. Como o servidor armazenará todos os arquivos das máquinas clientes, tanto os dados dos usuários quanto os arquivos de sistema, deve-se dedicar especial atenção à escolha de HDs com boa capacidade e desempenho. A instalação e configuração dos discos rígidos em um sistema RAID, seja via software ou controladora dedicada (hardware), apresenta-se como uma solução interessante, visto que esse mecanismo permite combinar vários HDs, transformando-os em um único disco lógico com a capacidade e o desempenho semelhante à soma da capacidade e desempenho de todos os dispositivos isolados [40]. O melhor desempenho dos discos em modo RAID fará com que os aplicativos sejam carregados mais rapidamente na memória e as operações de cópias de arquivos sejam concluídas em um tempo menor, evitando a saturação do servidor em momentos de pico de utilização. Uma vez que não foi previsto o acesso à Internet através da LAN especificada neste texto, não será descrita nenhuma característica de equipamentos necessários para a conexão dos terminais à web. Na prática, não é necessário adquirir um roteador dedicado para os casos em que esse acesso seja necessário. Pode-se utilizar uma máquina comum rodando o Linux, até mesmo o próprio servidor LTSP, com algumas configurações de filtragem de pacotes (iptables) adicionais, para realizar a função de roteamento e tradução de endereços de rede (NAT Network Address Translation) que seria desempenhada pelo roteador [41]. Uma outra opção, ainda mais vantajosa por

19 14 questões de desempenho e controle dos acessos, é a instalação de um proxy, que realiza funções de cache de páginas e controle do acesso dos usuários a sites específicos, além de gerar logs que permitem a elaboração de relatórios dos acessos dos clientes [42]. Por fugir do escopo deste trabalho, a montagem do cabeamento da rede não será abordado neste texto. No entanto, recomenda-se que os padrões de cabeamento estruturado descritos na vasta literatura de montagem de redes de computadores sejam seguidos como forma de se evitar problemas futuros de manutenção e correção de falhas estruturais. 3.3 Servidor LTSP Atualmente há registro de mais de 300 distribuições Linux ativamente mantidas, embora menos de 20 delas sejam largamente conhecidas [43]. As distribuições do Linux são versões desse sistema operacional que incluem o kernel (núcleo-base) do sistema e outros softwares de aplicação, formando um conjunto. Essas distribuições são mantidas por organizações comerciais, como a Red Hat, Ubuntu, SUSE e Mandriva, bem como projetos comunitários como Debian e Gentoo, que montam e testam seus conjuntos de softwares antes de disponibilizá-los ao público. Desde o início do processo de migração para o software livre, o Exército Brasileiro tem envidado esforços para estabelecer quais as distribuições mais adequadas para o emprego nos diversos ambientes da Força, e desde a primeira edição do Plano de migração para software livre no Exército Brasileiro, a distribuição Debian tem sido indicada como a mais apropriada para instalação em máquinas servidoras [44]. Em seu artigo intitulado Motivos pelos quais o Exército Brasileiro adotou a distribuição Debian para os servidores de rede [45], João Eriberto Mota Filho, à época Capitão do Exército Brasileiro servindo no Gabinete do Comandante do Exército, detalha os fatores considerados determinantes para a escolha da distribuição Debian, dentre os quais destacam-se: maturidade (criada em agosto de 1993) e confiabilidade; comunidade mantenedora ampla e atuante (mais de desenvolvedores); contrato social garante que a distribuição sempre será livre; disponível em várias línguas, inclusive em Português do Brasil; possui ferramenta para instalação e atualização de pacotes de maneira ágil e fácil (APT); integridade, consistência e segurança; abundância de fontes de documentação e consulta; ocupação reduzida de espaço em HD; multiplataformas (arquiteturas de computadores). Por tudo isso, optou-se aqui por orientar todos os procedimentos de instalação e configuração dos serviços considerando-se um ambiente com a distribuição Debian instalada na máquina servidora. A partir deste ponto, portanto, pressupõe-se que todos os passos serão executados em um equipamento com o Linux-Debian instalado. Não serão descritos os passos para a instalação dessa distribuição, por afastar-se do objetivo deste trabalho. No entanto, atualmente a versão estável mais recente dessa distribuição (5.0.0), lançada em 14 de Fevereiro de 2009, apresenta uma instalação bastante intuitiva e na maioria das vezes não impõe dificuldades. De qualquer forma, existe uma vasta documentação disponível para consulta na Internet, orientando todos os passos de

20 15 instalação, incluindo o próprio site ( oficial da distribuição Instalação de Pacotes Conforme mencionado na seção anterior, a distribuição Debian dispõe de uma ferramenta extremamente útil para as tarefas de instalação e atualização de softwares. Na próxima seção, serão descritos sucintamente os principais comandos desse utilitário, utilizados para instalar e gerenciar pacotes em um servidor através do terminal de comandos. Nas seções subseqüentes, esses comandos serão utilizados com freqüência durante a descrição do processo de instalação do LTSP APT O sistema de gerenciamento de pacotes denominado APT (Advanced Packaging Tool) surgiu da necessidade de atenuar as dificuldades de compilação e instalação de dependências de pacotes a cada novo sistema a ser instalado no Linux. Essa ferramenta automatiza o download de arquivos de instalação, a cópia dos arquivos para as devidas pastas no sistema, a configuração padrão dos serviços e a verificação de dependências de pacotes, uma das tarefas mais árduas na instalação de serviços em sistemas Linux [46]. Para que o sistema funcione, é preciso baixar periodicamente da Internet, ou de um servidor local configurado para replicar um servidor da Internet (espelho de repositório ou mirror), uma lista com os pacotes disponíveis nos servidores, permitindo que o apt mantenha seu banco de dados local atualizado. Isso é feito executando como super-usuário (root) o comando: # apt-get update Esse comando deve ser executado preferencialmente antes de qualquer instalação de softwares, já que deve-se trabalhar com as versões mais recentes dos pacotes, devido à questão das atualizações de segurança, especialmente em máquinas servidoras. Uma questão técnica comumente esquecida é a configuração de proxy para a execução de comandos de acesso à Internet via terminal de comandos. Caso a sua máquina acesse a Internet através de um proxy, deve-se configurar a variável de ambiente http_proxy para que os seus pacotes sejam direcionados ao servidor proxy responsável. Para isso, execute antes dos comandos que necessitam acessar a Internet via proxy o seguinte comando [47]: # export http_proxy= Nesse comando, usuario é o nome de usuário e senha é a senha para acesso ao proxy. Os parâmetros usuario:senha@ podem ser omitidos se o servidor proxy não exigir autenticação. O parâmetro servidor refere-se ao nome ou ao endereço IP do servidor proxy (como ou ) e porta é o número da porta onde o servidor recebe as conexões (como 8080 ou 3128). Sem essa configuração, os

21 16 comandos executados no terminal que necessitem acessar a Internet, incluindo os serviços do gerenciador de pacotes apt, não conseguirão concluir suas tarefas. É possível configurar o sistema operacional para que ele carregue o valor correto na variável de ambiente http_proxy durante a inicialização do sistema. Para isso, copie o comando descrito acima que exporta o conteúdo da variável para o final do arquivo /etc/bash.bashrc Retomando a explicação da utilização do apt-get, para a instalação de novos pacotes deve-se usar como root o seguinte comando: # apt-get install pacote Nesse contexto, pacote refere-se ao nome do pacote a ser instalado. Exemplos de nomes de pacotes são apache2, squid e ltsp-server. Para descobrir o nome exato de um pacote a ser instalado, pode-se utilizar o comando: # apt-cache search pacote Esse comando pesquisa por pacote nos nomes e nas descrições dos pacotes cujas informações foram gravadas localmente pelo comando apt-get update. Ele listará na tela todos os pacotes que possuam a palavra pesquisa (no exemplo acima pacote ) em seu nome ou em sua descrição. Para visualizar informações detalhadas de um pacote listado na saída do comando anterior, utiliza-se o comando: #apt-cache show nomepacote nomepacote deve ser um nome real de pacote, como os nomes retornados pelo comando apt-cache search. A saída desse comando exibe a descrição do pacote em questão, além de outras informações tais como versões disponíveis e dependências de outros pacotes, o que pode esclarecer dúvidas quanto a nomes parecidos de pacotes listados com o comando apt-cache search. Finalmente, para remover um pacote instalado, deve-se utilizar o comando: # apt-get remove pacote Novamente, pacote deve ser um nome real de um pacote já instalado na máquina. Existe ainda a opção --purge, que pode ser empregada nesse caso para remover os arquivos de configuração junto com o pacote a ser apagado do sistema. Para listar todos os pacotes instalados no sistema, utilize o comando [48]: # dpkg -l Essa rápida descrição do gerenciamento de pacotes em máquinas com a distribuição Debian será bastante útil na seqüência deste texto, onde serão indicados os procedimentos para a instalação do LTSP. Informações adicionais sobre a administração de softwares instalados podem ser obtidas nas referências anotadas ao longo desta seção DHCP

22 17 Antes de efetuar a instalação do pacote do LTSP é necessário instalar e testar alguns serviços-base utilizados pelo servidor LTSP. O DHCP é o primeiro serviço acessado pela estação, que inicia sem saber quais arquivos carregar. O DHCP responde a um pacote de broadcast emitido pelo terminal, entregando as configurações da rede e informando qual kernel ou cliente PXE deve ser carregado, além de indicar em qual servidor está o sistema a ser carregado pela estação. Para instalar o serviço DHCP no servidor, basta executar o seguinte comando [49]: # apt-get install dhcp3-server TFTP O segundo serviço a ser instalado é o tftpd, um serviço servidor do protocolo TFTP, utilizado para transferir o Kernel (núcleo) do sistema operacional usado pelas estações. Existem duas opções de servidor TFTP disponíveis para máquinas com a distribuição Debian instalada. O pacote tftpd, versão já obsoleta, não suporta boot via PXE e, por isso, não é mais recomendado [10]. A versão mais recente é instalada pelo pacote tftpd-hpa, através do seguinte comando: # apt-get install tftpd-hpa O script de instalação perguntará se o servidor deverá ser iniciado pelo inetd. Responda não para essa pergunta, pois o inetd pode causar conflitos com o tftpd, como será explicado na seção Portmap e NFS Na distribuição Debian, para ativar o servidor NFS, que permitirá o acesso dos terminais à pasta no servidor onde os arquivos do sistema ficam armazenados, é necessário instalar os pacotes portmap, nfs-common e nfs-kernel-server, através do seguinte comando [50]: # apt-get install portmap nfs-common nfs-kernel-server O portmap deve ser iniciado antes dos outros dois serviços, já que ambos dependem dele. Normalmente o portmap é iniciado durante o boot, através do caminho /etc/init.d/rcs.d/sxxportmap, onde XX é o número que exprime a ordem em que o serviço será iniciado (em geral, para o portmap, no lugar de XX encontra-se 43). O nfs-common e o nfs-kernel-server são carregados posteriormente no boot, através de links simbólicos localizados nos diretórios /etc/rc5.d ou /etc/rc3.d. Para corrigir a posição de inicialização do portmap e garantir que o nfscommon e o nfs-kernel-server estejam ativos e configurados para iniciar durante o boot, executa-se os seguintes comandos [51]: # update-rc.d -f portmap remove

23 18 # update-rc.d -f nfs-common remove # update-rc.d -f nfs-kernel-server remove # update-rc.d -f portmap start 43 S. # update-rc.d -f nfs-common start # update-rc.d -f nfs-kernel-server start Caso o gerenciador de nível de execução (runlevel) update-rc.d não esteja instalado, efetua-se a sua instalação antes de executar os comandos acima, através do comando: # apt-get install file-rc update-rc.d XDMCP O XDMCP (X Display Manager Control Prolocol ou Protocolo de controle e gerenciamento do display X), como o próprio nome diz, é um protocolo para exibição das imagens no ambiente gráfico do Linux, através do servidor X. Para funcionar, esse protocolo estabelece que as diretivas para exibição de imagens são enviadas pelos softwares a um gerenciador de ambiente gráfico, como os consagrados KDE (kdm) e GNOME (gdm), para citar apenas os dois mais populares pacotes. Dessa forma, caso a máquina servidora esteja com o ambiente gráfico instalado e funcionando, com qualquer gerenciador, não será necessário instalar novamente o XDMCP. Serão necessárias apenas algumas alterações na configuração do serviço, que serão apresentadas na seção Para os casos em que o servidor LTSP não executa o ambiente gráfico, deve-se instalar o gerenciador de ambientes gráficos escolhido (gdm, kdm ou outro) com o seguinte comando [52]: # apt-get install gerenciador libxdmcp6 No comando acima, a palavra gerenciador deve ser substituída pelo nome do gerenciador de ambientes gráficos desejado, tais como gdm ou kdm LTSP-utils e libwww-perl Até a versão 3.0 do LTSP, a instalação do seu núcleo era realizada através de vários pacotes distintos. Esses pacotes ainda estão disponíveis, mas a partir da versão 4.0 do projeto, foi desenvolvido um sistema unificado de instalação, onde o instalador se encarrega de baixar os pacotes e realizar a instalação. Recentemente foi concluída a versão 5 do LTSP, que abandonou o uso de pacotes próprios em favor de uma melhor integração com as diversas distribuições. No entanto, essa nova versão ainda não é uma solução totalmente madura e não foi destrinchada por uma documentação abundante, como ocorre com a versão 4.2 do sistema, anterior à versão atual. Em função disso, serão tratados aqui os mecanismos para a instalação e configuração do LTSP 4.2. Inicialmente, deve-se descarregar a versão para Debian do pacote ltsp-utils de um servidor de pacotes disponível na Internet. Os pacotes destinados à distribuição Debian são identificados pelo sufixo.deb, concatenado ao nome do pacote. O arquivo

24 19 ltsp-utils_0.25_all.deb pode ser obtido no endereço Para instalá-lo, deve-se executar o seguinte comando [53]: # dpkg -i ltsp-utils_0.25_all.deb Para que o instalador do LTSP funcione, é necessário também instalar o interpretador da linguagem de programação Perl, já que o instalador foi desenvolvido nessa linguagem. Para instalar o interpretador de Perl, executa-se o comando: # apt-get install libwww-perl Instalados os pacotes até aqui mencionados, o servidor LTSP já pode ser configurado, conforme descrito na seção Porém, antes de descrever o processo de configuração do servidor, será mencionado na próxima seção como instalar o pacote ltspswapd, responsável por prover um serviço de memória virtual (swap) via rede para estações com uma quantidade reduzida de memória RAM swap O LTSP inclui um recurso de swap via rede, destinado a terminais com 32MB ou menos de memória RAM. Esse recurso permite que a estação que não possui HD possa realizar a paginação de sua memória virtual usando o HD do servidor. Dessa forma, é possível utilizar micros com no mínimo 12MB de memória RAM como terminais [54]. Para acionar o funcionamento do módulo de swap, deve-se baixar e instalar o pacote ltsp-server, disponível no seguinte endereço: O arquivo com a versão do pacote disponível para a distribuição Debian possui o seguinte nome: ltsp-server-pkg-debian_0.1_i386.deb Depois de baixar o arquivo, deve-se instalá-lo com a execução dos seguintes comandos: # dpkg -i ltsp-server-pkg-debian_0.1_i386.deb # apt-get -f install Deve-se ressaltar que existe a possibilidade de ocorrer um erro durante a instalação desse pacote por faltar o pacote fuse-source. Isso ocorrerá em versões da distribuição Debian mais recentes do que a versão 3.1 Sarge, já que o fuse passou a ser incorporado diretamente ao kernel. Com isso, não está disponível o pacote fusesource para as versões mais recentes do Debian. Caso algum erro referente à falta do pacote fuse-source seja retornado, deve-se instalar um pacote vazio com esse nome, para satisfazer as dependências entre pacotes [10]. Uma versão vazia desse pacote está disponível no seguinte endereço de Internet:

25 20 Após descarregar o pacote, basta instalá-lo através dos seguintes comandos: # dpkg -i fuse-source.deb # apt-get -f install O pacote ltsp-server inclui o serviço ltspswapd, responsável pelo swap via rede no LTSP 4.2. Finalmente, é necessário ativá-lo e configurá-lo para iniciar durante o boot com os seguintes comandos: #/etc/init.d/ltspswapd start #update-rc.d -f ltspswapd defaults Configurações Terminado o processo de instalação de pacotes no servidor LTSP, deve-se passar para a etapa de configuração dos serviços, que será descrita nas seções subseqüentes. Deve-se ressaltar que em qualquer arquivo de configuração, as linhas iniciadas pelo caractere # são ignoradas pelo serviço e servem apenas para que sejam inseridos comentários nos arquivos de configuração dos diversos serviços a serem abordados DHCP As configurações do servidor DHCP ficam armazenadas no arquivo /etc/dhcp3/dhcpd.conf. Esse arquivo é dividido nas seções shared-network WORKSTATIONS e group. A primeira armazena as configurações gerais do servidor, enquanto a segunda guarda as configurações de cada terminal. De acordo com a sintaxe do serviço, as linhas de configuração devem terminar com o caractere ; e cada seção é delimitada pelos caracteres { e }, que marcam respectivamente o começo e o fim de uma seção. Os caracteres de tabulação, espaços e quebras de linha não interferem na interpretação dos dados e podem ser livremente utilizados para organizar o arquivo. Ao reiniciar o serviço com o comando /etc/init.d/dhcp3-server restart, o arquivo de configuração é recarregado e, caso exista algum erro de sintaxe, uma mensagem de erro é exibida na tela informando o provável motivo do problema, de forma análoga a um compilador de linguagens de programação. A listagem do arquivo disponível no Apêndice - A apresenta um exemplo de uma configuração funcional para uma rede com as seguintes características: endereço IP da rede: máscara de rede: endereço IP do servidor LTSP: (dois) terminais com endereço IP fixo A seção shared-network WORKSTATIONS deve conter as configurações da rede, tais como endereço da rede, máscara de sub-rede, endereço do gateway (roteador padrão) e endereço do DNS. Como nas configurações da rede-exemplo a ser estudada

26 21 neste texto, proposta na seção 3, não está previsto o acesso à Internet, o arquivo de exemplo transcrito acima não inclui as diretivas para a configuração do gateway e do DNS. No entanto, para configurar esses serviços de rede basta acrescentar a opção option routers para definir o roteador da rede e a opção option domain-nameservers para indicar o servidor DNS a ser consultado pelas máquinas da rede. Ambas opções devem ser seguidas pelo endereço IP dos respectivos ativos de rede responsáveis pelos serviços, como em option routers e option domain-name-servers [55]. Deve-se ressaltar que, por questões de segurança, não é recomendável que o servidor LTSP seja também o roteador padrão da rede, já que ele irá rodar uma série de serviços necessários para o LTSP que podem abrir brechas de segurança para conexões oriundas da Internet. A opção default-lease-time controla o tempo de renovação dos endereços IP dos clientes. O parâmetro indica que o servidor verifica a cada segundos, ou 8 horas, se as estações ainda estão ativas. Caso um terminal tenha se desconectado da rede, o servidor libera o endereço IP para ser utilizado por outro terminal que venha a se conectar. Se a configuração da rede local dispuser de mais endereços IP do que máquinas, os endereços IP das estações raramente mudarão, mas em redes congestionadas, a opção max-lease-time determina o tempo máximo que uma estação pode usar um endereço IP. Esses parâmetros foram criados para possibilitar o remanejamento de endereços IP em ambientes onde exista uma escassez de tais endereços, como costuma ocorrer em provedores de acesso à Internet, onde existem mais clientes do que endereços IP disponíveis e supõe-se que nem todos os usuários estarão conectados simultaneamente. Para a maioria das redes locais, essas opções não interferem significativamente no desempenho da rede [55]. A opção deny unknown-clients estabelece que apenas os terminais listados na seção group do arquivo estão autorizados a receber as configurações de rede via DHCP. Qualquer máquina não cadastrada que solicitar informações ao servidor DHCP não será atendida. Rivalizando com essa opção, existe a opção range, com a qual é estabelecida uma faixa de endereços a serem distribuídos a qualquer estação que solicitar um endereço ao servidor. A sintaxe exata dessa opção é range , onde os endereços e devem ser substituídos pelo primeiro e último endereços da faixa, respectivamente. A opção range pode ser utilizada em conjunto com a declaração de hosts efetuada na seção group, o que garante que as máquinas listadas sempre receberão o endereço IP especificado. No entanto, a opção deny unknown-clients conflita com a opção range e deve ser removida caso seja utilizada uma faixa de distribuição de endereços IP [56]. A opção option root-path indica para o cliente o endereço IP do servidor e a pasta do servidor que será utilizada como diretório raiz das estações cliente. A pasta /opt/ltsp/i386 é justamente a pasta de instalação do LTSP, que é montada via rede pelos terminais como diretório raiz durante o boot. Caso o LTSP tenha sido instalado em outra pasta, o caminho correto para o diretório de instalação deve ser indicado nessa opção [57]. Nesse ponto, deve-se ressaltar que o endereço IP do servidor LTSP não deve ser atribuído a uma interface de rede virtual, criada como um apelido (alias) para a interface de rede real. No Linux, as interfaces de rede virtuais possuem denominações do tipo ethx:y, como em eth0:1, o que indica, nesse exemplo, que a referida interface é a primeira interface virtual da interface real eth0. Caso seja necessário usufruir de interfaces virtuais, configure a placa de rede principal para usar o endereço IP indicado

27 22 nos arquivos de configuração do LTSP e deixa a interface virtual para a outra necessidade [10]. A opção next-server é utilizada apenas para evitar um erro existente em algumas versões do DHCP, onde os clientes podem não conseguir contactar o servidor DHCP. Basta incluir após essa opção o endereço IP do servidor, como no exemplo do arquivo acima [58]. A seção group agrega a configuração dos terminais, onde é necessário especificar o endereço da interface de rede (MAC - Media Access Control) de cada estação, através da diretiva hardware ethernet. O endereço MAC é um número haxadecimal de 12 dígitos (como 00:E0:4C:FC:50:B8) único para cada placa de rede fabricada, que pode ser identificado entre as mensagens exibidas durante o boot via rede de uma máquina. O nome do terminal, especificado após a palavra host, deve ser o nome configurado para a estação, que deve coincidir com os nomes anotados nos arquivos /etc/hosts e /opt/ltsp/i386/etc/lts.conf, responsáveis pelas configurações do NFS e do LTSP, como será apresentado nas seções e Ainda na seção group, a opção fixed-address é utilizada para indicar o endereço IP a ser fixado para o terminal em questão e o campo filename empregado para apontar o primeiro arquivo que a máquina cliente carregará durante o boot. Esse arquivo constitui um bootstrap, responsável por carregar o kernel nos terminais, já que o cliente PXE consegue carregar apenas arquivos pequenos, com no máximo 32KB de tamanho. O nome da pasta onde o arquivo pxelinux.0 fica armazenado no servidor corresponde à versão do kernel disponível naquela pasta. Os arquivos de boot são instalados por definição na pasta /tftpboot do servidor, dentro de subpastas separadas para cada versão do kernel disponível. No exemplo do arquivo acima, a pasta ltsp-1 corresponde à versão do kernel. No LTSP 4.1 estavam disponíveis um kernel mais leve, da série 2.4, e outro da série 2.6. No LTSP 4.2 passou a ser utilizada apenas a versão do kernel, que é mais atual e otimiza o emprego de recursos de hardware. A pasta ltsp-1 contém um conjunto de arquivos, incluindo o respectivo kernel, um arquivo initrd e o arquivo pxelinux.0, acompanhado do seu arquivo de configuração default, situado na subpasta pxelinux.cfg. Esse arquivo de configuração contém instruções pré-definidas que são executadas pela estação ao carregar o arquivo pxelinux.0, incluindo a localização do kernel e do arquivo initrd correspondente. Como as diferentes versões do LTSP são acompanhadas de mudanças nas versões do kernel, é necessário verificar qual o nome exato da pasta que contém os arquivos para boot, dentro da pasta /tftpboot, antes de anotar o valor do parâmetro para a opção filename [59]. A configuração para PXE que acaba de ser descrita também funciona para terminais que executarão o boot usando os discos de Etherboot, conforme será apresentado na seção 3.4.1, permitindo que a configuração dos clientes seja unificada. Em versões antigas do LTSP, era necessário especificar o caminho direto para uma imagem do kernel, no caso das estações que executavam o boot via Etherboot. Efetuadas as configurações no arquivo /etc/dhcp3/dhcpd.conf, deve-se reiniciar o serviço DHCP com o seguinte comando: # /etc/init.d/dhcp3-server restart Após carregar o novo arquivo de configurações do DHCP, os clientes serão capazes de obter um endereço IP e as demais configurações de rede ao serem iniciados.

28 TFTP O servidor do TFTP é instalado com uma configuração padrão que mantém o serviço desativado. Para habilitá-lo, deve-se alterar no arquivo /etc/default/tftpd-hpa o valor da opção RUN_DAMON de no para yes. Esse arquivo guarda as configurações do TFTP, onde deve ser alterada também a diretiva OPTIONS, que indica os parâmetros iniciais de execução do serviço. No lugar do caminho /var/lib/tftpboot, deve-se relacionar o nome da pasta /tftpboot, que será compartilhada pelo servidor TFTP [60]. O Apêndice B traz um exemplo funcional de um arquivo de configurações do TFTP, com os atributos mencionados devidamente alterados. Para que essas alterações entrem em vigor, deve-se reiniciar o serviço com o seguinte comando: # /etc/init.d/tftpd-hpa restart Para garantir que o serviço estará configurado para iniciar durante os boots da máquina servidora, deve-se executar também os seguintes comandos: # update-rc.d -f tftpd-hpa remove # update-rc.d -f tftpd-hpa defaults Finalmente, para que as requisições de conexão enviadas pelos terminais sejam aceitas pelo servidor, deve-se incluir no arquivo /etc/hosts.allow a seguinte linha: ALL : /24 Essa diretiva explicita que as máquinas da rede local ( /24), assim como os sistemas em execução no próprio servidor ( ), podem enviar livremente solicitações de conexão aos serviços em execução no servidor (ALL). Devese, portanto, alterar o endereço IP da rede local, caso uma outra faixa de endereços IP esteja sendo utilizada [61]. Uma particularidade do servidor TFTP advém do fato de algumas vezes ele apresentar conflitos com o serviço inetd. Caso o serviço tftpd não responda às requisições das estações, deve-se desativar o serviço inetd e reiniciar a máquina servidora através dos seguintes comandos: # /etc/init.d/inetd stop # update-rc.d -f inetd remove # reboot É importante salientar que ao desativar o inetd, o acesso remoto a todos os serviços gerenciados por ele, como os aplicativos vmware-server e swat, caso instalados no servidor, deixarão de funcionar. Caso seja necessário utilizar algum desses serviços, convém reativar momentaneamente o inetd de forma manual, utilizando o comando abaixo: # /etc/init.d/inetd start

29 NFS A configuração do serviço de NFS é realizada no arquivo /etc/exports, que originalmente encontra-se vazio, onde são indicados os diretórios do servidor acessíveis a outras máquinas da rede. Para o correto funcionamento dos terminais, é necessário que o servidor compartilhe a pasta /opt/ltsp/i386/, de onde as estações carregam o seu sistema de arquivos. Isso é feito inserindo-se a seguinte linha ao arquivo /etc/exports original: /opt/ltsp/i386/ / (ro,no_root_squash) A primeira fração do compartilhamento acima, separada pelo caractere de espaço em branco, estabelece que a pasta compartilhada será /opt/ltsp/i386/. O segundo fragmento destina-se a especificar quais máquinas poderão acessar o compartilhamento e inclui o endereço IP da rede local, seguido pela máscara de subrede. Esse campo pode ser representado de outras formas, como *, ou indicando os endereços IP individuais de cada estação, com uma nova linha para cada estação [62]. Na última parcela do trecho acima, indicada entre parênteses, o termo ro (read only) impõe a restrição de permissão apenas de leitura às máquinas remotas, enquanto a expressão no_root_squash determina que o usuário root dos terminais tem permissão para montar o compartilhamento do servidor. Essa opção faz-se necessária uma vez que, por padrão, o usuário root de equipamentos remotos não tem autorização para acessar pastas pelo NFS. Apesar do nome do usuário root representar o administrador do sistema, a opção ro prevalece, indicando que as estações poderão apenas ler o conteúdo da pasta compartilhada. Para que o servidor NFS funcione, é necessário ainda que o arquivo /etc/hosts relacione os nomes das máquinas aos seus endereços IP, evitando a necessidade de instalação e configuração de um servidor de DNS para a resolução dos nomes. A sintaxe das entradas no arquivo requer que seja definido o endereço IP seguido do nome da máquina, separados por um caractere de espaço em branco, como exemplificado no Apêndice C. Devem ser listados os endereços IP e o nome de todas as máquinas da rede, incluindo os terminais e o servidor LTSP [63]. Conforme mencionado na seção , os nomes dos terminais devem ser os mesmos no arquivo de configurações do DHCP (/etc/dhcp3/dhcpd.conf), no arquivo /etc/hosts e no arquivo /opt/ltsp/i386/etc/lts.conf. É possível verificar ou atribuir um nome ao servidor através do comando hostname. Para simplesmente verificar o nome da máquina, execute o comando sem parâmetros e, para alterar o nome, execute o comando seguido do novo nome, como no exemplo abaixo [64]: # hostname servidorltsp Nesse exemplo, o nome da máquina é alterado para servidorltsp lts.conf O arquivo lts.conf, localizado na pasta /opt/ltsp/i386/etc/lts.conf do servidor, corresponde ao mecanismo de configuração mais importante de um servidor LTSP, pois

30 25 é nele que são definidas as configurações do hardware de cada um dos terminais, tais como resolução de vídeo, tipo de mouse e padrão do teclado. Assim como na configuração do serviço de DHCP, o arquivo lts.conf é dividido em duas porções, onde a primeira estabelece as configurações gerais, válidas para todos os clientes, e a segunda complementa a primeira apresentando informações específicas de determinadas estações, que podem até sobrescrever alguma configuração geral estabelecida na fração inicial. Isso permite, por exemplo, que um terminal seja configurado para usar mouse serial e teclado americano, enquanto todos os demais usem mouses do tipo PS/2 e teclados brasileiros. A seção inicial do arquivo é denominada Default e deve ser escrita entre colchetes, conforme indicado no Apêndice D, onde consta um exemplo de um arquivo lts.conf [23]. O primeiro parâmetro dessa seção, demonstrado no arquivo de exemplo, recebe o nome de SERVER e tem a função de apontar o endereço IP do servidor. Abaixo, a partir da opção XSERVER, são definidas as configurações padrão que funcionarão para todos os terminais. Essas configurações somente deixarão de ser aplicadas se forem sobrescritas na sequência do arquivo de configurações, nas seções específicas com os nomes dos terminais. Como as estações executam localmente uma cópia do Kernel do Linux, utilitários básicos e uma instância do servidor gráfico X (no caso de utilizarem o ambiente gráfico), é possível que clientes distintos utilizem configurações diferentes, tais como drivers de vídeo, teclado e mouse, por exemplo. Esse é o principal motivo para a exigência de relacionar o endereço MAC de cada placa de rede atrelado a um nome de terminal e a um endereço IP específico na configuração do DHCP. Assim, o servidor consegue diferenciar as estações e enviar a configuração correta para cada uma. A partir da versão 4.1 do LTSP, o projeto passou a incorporar o servidor gráfico X.org, que possui um sistema de detecção automática para o vídeo de cada cliente, através da opção XSERVER = auto, que aparece no arquivo de exemplo do Apêndice D. No final do processo de boot, o X.org tenta detectar a placa de vídeo e as taxas de atualização suportadas pelo monitor, configurando automaticamente o vídeo da estação. Esse sistema funciona para a maioria das placas de vídeo e monitores atualmente utilizados, mas caso apresente problemas em alguns terminais, piscando a tela algumas vezes e depois voltando ao modo texto, é possível indicar manualmente um driver de vídeo, substituindo a palavra auto por [66]: vesa - ativa driver genérico, um pouco mais lento, mas que funciona na maioria das placas; cirrus - ativa driver para placas da fabricante Cirrus Logic; i810 - ativa driver para placas com vídeo onboard da fabricante Intel; nv - ativa driver 2D (duas dimensões) para placas da fabricante nvidia; r128 - ativa driver para placas modelo 128 da fabricante ATI; radeon - ativa driver para placas modelo Radeon da fabricante ATI; rendtion, s3virge e sis - ativa drivers genéricos para placas onboard e offboard da fabricante SiS; tdfx - ativa driver para placas modelo 3, 4 e Banshee da fabricante Voodoo; trident e via - ativa drivers para placas-mãe com vídeo onboard da fabricante Via Unichrome. Uma lista com a indicação completa de todas as placas suportadas por cada um dos drivers de vídeo pode ser obtida no site do projeto X.org, no endereço Nos casos em que o servidor X chega a ser iniciado, mas o monitor

31 26 fica fora de sintonia, apresentando imagens distorcidas, é viável forçar o terminal a usar uma configuração de resolução de tela e de taxa de atualização dos pixels específica para um determinado monitor. Isso é feito atribuindo valores para os campos X_MODE_0, X_VERTREFRESH e X_COLOR_DEPTH, conforme apresentado no exemplo para os terminais ws001 e ws002, no arquivo lts.conf, que demonstram a configuração de monitores com resolução de 1024 x 768 e 800 x 600, com taxas de atualização vertical de 60Hz e 85Hz, respectivamente [23]. As opções X_MOUSE_PROTOCOL, X_MOUSE_DEVICE, X_MOUSE_RESOLUTION e X_MOUSE_BUTTONS, como o próprio nome sugere, encarregam-se de indicar as configurações do mouse das estações. No arquivo de exemplo listado no Apêndice D, a configuração padrão para os mouses dos terminais, alojada dentro da seção DEFAULT, estabelece que serão utilizados mouses do tipo PS/2 sem roda. Os terminais ws001 e ws002, por sua vez, foram configurados no mesmo arquivo para empregarem respectivamente um mouse do tipo serial e um mouse do tipo PS/2 com roda ou USB. Ressalta-se novamente que pode-se criar uma seção extra para cada cliente, mas essa configuração não é obrigatória, já que as estações que não possuírem seções exclusivas simplesmente seguirão os valores incluídos na fração intitulada DEFAULT. Existe ainda a possibilidade de determinar o modelo de teclado a ser utilizado pela estação, através das diretivas XkbModel, XkbLayout e XkbRules. Para um teclado do tipo Americano Intenacional, por exemplo, deve-se utilizar os parâmetros indicados na configuração do terminal ws001 no arquivo de exemplo do Apêndice D. No entanto, para um teclado do tipo ABNT2, além das diretivas ilustradas na configuração DEFAULT do arquivo lts.conf exemplificado, pode ocorrer uma troca entre as teclas \ e }, dependendo da versão do servidor X instalada. Nesse caso, deve-se adicionar ao arquivo.xmodmap, localizado na pasta /etc/skel/ e na raiz da pasta home de cada usuário (/home/usuario/), as seguintes linhas: keycode 94 = backslash bar keycode 51 = bracketright braceright Concluindo, as linhas SCREEN_01 = startx e RUNLEVEL = 5, incluídas na seção DEFAULT do arquivo lts.conf, estabelecem que os terminais iniciem direto em modo gráfico. Para que uma estação trabalhe apenas em modo texto, basta incluir na seção de configuração da estação desejada a opção RUNLEVEL = 3, que irá sobrescrever a diretiva de mesmo nome existente na seção DEFAULT XDMCP Para que os terminais obtenham a tela de login do servidor e executem os aplicativos gráficos remotamente, é necessário habilitar o serviço XDMCP. Nas distribuições que utilizam o GDM (o gerenciador de login do Gnome), como o Debian, Ubuntu, Fedora, CentOS e muitas outras, o XDMCP pode ser ativado através do configurador da tela de login, denominado gdmsetup [52]. Para iniciá-lo, pode-se executar como root o comando gdmsetup, ou acessálo através dos Menus de navegação do sistema, seguindo o caminho Desktop Administração Janela de início de sessão, no ambiente gráfico do servidor LTSP, conforme a figura 2.

32 27 Figura 2 Acesso ao gerenciador de login pelos Menus de navegação do Gnome no Debian 4 Após abrir a tela do gerenciador de login, deve-se acessar a aba Remoto e, dentro da opção Estilo, mudar o campo Início de sessão remota desabilitada para Simples com o navegador de faces, conforme demonstrado na figura 3.

33 28 Figura 3 Habilitação do XDMCP no gerenciador de login Essa alteração permitirá que o XDMCP seja ativado, exibindo uma tela de login que pode ser configurada de acordo com o gosto do administrador da máquina. Ainda na aba Remoto, a opção Configurar XDMCP dá acesso a uma segunda janela de configurações, que permite definir, entre outras coisas, o número máximo de clientes simultâneos (figura 4). Essa possibilidade é ajustada na opção Máximo de conexões remotas e é útil para limitar acessos em ambientes onde o servidor fica sobrecarregado em momentos de pico de utilização dos terminais.

34 29 Figura 4 Janela de configurações da tela de login para sessões via XDMCP Em distribuições distintas do Debian que utilizam o GDM, os passos para a ativação do XDMCP são os mesmos, diferindo dos procedimentos descritos apenas em função da alteração de alguns nomes de janelas ou opções. Para concretizar as configurações do XDMCP, deve-se reiniciar o serviço gerenciador de logins com o seguinte comando: # /etc/init.d/gdm restart Swap Após a instalação do swap, conforme apontado na seção , a ativação do serviço nas estações é garantida através da simples inclusão da opção USE_NBD_SWAP = Y no arquivo ltsp.conf, conforme ilustrado no arquivo de exemplo disponibilizado no Apêndice D, dentro da seção pertinente ao terminal denominado ws001 [23]. Por padrão, os arquivos de swap são armazenados dentro da pasta /var/spool/ltspswap do servidor, permitindo que cada cliente ocupe no máximo 64MB de espaço em HD. Caso seja necessário alterar essa configuração, deve-se criar o arquivo /etc/sysconfig/ltspswapd contendo a seguinte linha [54]: ARGS= [-s /var/spool/ltspswap] [-z 64mb] Os argumentos aparecem entre colchetes para indicar que eles são optativos. A opção -s, quando utilizada, deve ser seguida pelo caminho completo da pasta no servidor onde os arquivos de swap serão armazenados. Por sua vez, quando empregada,