uma solução econômica e efetiva para a revitalização de
TRANSCRIPT
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
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
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.
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!
Sumário1 – Introdução.......................................................................................................................................1
1.1 – Restrições Orçamentárias no Exército Brasileiro...................................................................11.2 – Benefícios de plataformas baseadas em Terminais Leves......................................................41.3 – Objetivos.................................................................................................................................6
2 – Referencial Teórico........................................................................................................................62.1 – Software Livre........................................................................................................................62.2 – LTSP.......................................................................................................................................8
2.2.1 – Características Gerais......................................................................................................82.2.2 – Serviços-base .................................................................................................................92.2.3 – Casos de sucesso...........................................................................................................10
2.3 – Thin Clients...........................................................................................................................113 – Projeto e implantação de um laboratório de informática..............................................................12
3.1 – Softwares..............................................................................................................................123.2 – Equipamentos........................................................................................................................143.3 – Servidor LTSP......................................................................................................................17
3.3.1 – Instalação de Pacotes.....................................................................................................183.3.1.1 – APT.......................................................................................................................183.3.1.2 – DHCP....................................................................................................................203.3.1.3 – TFTP......................................................................................................................213.3.1.4 – Portmap e NFS.....................................................................................................213.3.1.5 – XDMCP................................................................................................................223.3.1.6 – LTSP-utils e libwww-perl....................................................................................233.3.1.7 – swap......................................................................................................................23
3.3.2 – Configurações...............................................................................................................243.3.2.1 – DHCP....................................................................................................................253.3.2.2 – TFTP......................................................................................................................283.3.2.3 – NFS........................................................................................................................293.3.2.4 – lts.conf ..................................................................................................................303.3.2.5 – XDMCP.................................................................................................................333.3.2.6 – Swap......................................................................................................................35
3.4 – Configuração dos terminais..................................................................................................363.4.1 – Boot...............................................................................................................................363.4.2 – Contas de usuários........................................................................................................37
4 – Conclusão e Trabalhos Futuros....................................................................................................395 – Referências...................................................................................................................................40APÊNDICE A – Listagem do arquivo de configurações do DHCP..................................................45APÊNDICE B – Listagem do arquivo de configurações do TFTP....................................................46APÊNDICE C – Listagem do arquivo /etc/hosts...............................................................................46APÊNDICE D – Listagem do arquivo “lts.conf”...............................................................................46
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 é
2
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$180.000,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.
Gráfico 1 – Evolução dos requisitos de processamento do Windows (FÓRUM DO BABOO, 2008)
1.0 2.10 3.1 95 98 2000 ME XP Vista
0100200300400500600700800900
1000
Evolução dos requisitos de processamento do Windows
Versões do Windows
Req
uis
ito m
ínim
o d
e c
lock
(M
Hz)
3
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
1.0 2.10 3.1 95 98 2000 ME XP Vista
0
200000
400000
600000
800000
1000000
1200000
Evolução dos requisitos de memória do Windows
Versões do Windows
Requis
itos
mín
imos
de m
em
óri
a (
KB
)
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 e-mails, 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;
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.
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á baseava-se 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
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
2.2.1 – 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 emails (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
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.
2.2.2 – 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 3.3.
2.2.3 – 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-
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].
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-45• 20 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 email: 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
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].
12
3.2 – 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 “hub-switch” 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 “3.5.1 – 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 3000+ em diante, e os
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
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 1.200 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
15
instalação, incluindo o próprio site oficial da distribuição (http://www.debian.org/releases/stable/installmanual).
3.3.1 – 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.
3.3.1.1 – 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=”http://usuario:senha@servidor:porta”
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 www.proxy.com.br ou 192.168.0.1) e “porta” é o número da porta onde o servidor recebe as conexões (como 8080 ou 3128). Sem essa configuração, os
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.
3.3.1.2 – DHCP
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
3.3.1.3 – 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 3.3.2.2.
3.3.1.4 – 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 “nfs-common” 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
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 20 5 .# update-rc.d -f nfs-kernel-server start 20 5 .
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
3.3.1.5 – 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 3.3.2.5.
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”.
3.3.1.6 – 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
19
“ltsp-utils_0.25_all.deb” pode ser obtido no endereço “http://ltsp.mirrors.tds.net/pub/ltsp/utils/”. 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 3.3.2. 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.
3.3.1.7 – 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:
“http://ltsp.mirrors.tds.net/pub/ltsp/utils/”
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 “fuse-source” 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:
20
http://www.gdhpress.com.br/kurumin/ltsp/fuse-source.deb
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
3.3.2 – 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.
3.3.2.1 – 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: 192.168.0.0• máscara de rede: 255.255.255.0• endereço IP do servidor LTSP: 192.168.0.10• 02 (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
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-name-servers” 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 192.168.0.1” e “option domain-name-servers 192.168.0.1” [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 “28800” indica que o servidor verifica a cada 28800 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 192.168.0.100 192.168.0.200”, onde os endereços 192.168.0.100 e 192.168.0.200 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
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 3.3.2.3 e 3.3.2.4.
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 “2.6.17.3-ltsp-1” corresponde à versão 2.6.17.3 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 2.6.17.3 do kernel, que é mais atual e otimiza o emprego de recursos de hardware.
A pasta “2.6.17.3-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.
23
3.3.2.2 – 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 : 127.0.0.1 192.168.0.0/24
Essa diretiva explicita que as máquinas da rede local (192.168.0.0/24), assim como os sistemas em execução no próprio servidor (127.0.0.1), podem enviar livremente solicitações de conexão aos serviços em execução no servidor (ALL). Deve-se, 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
24
3.3.2.3 – 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/ 192.168.0.0/255.255.255.0 (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 192.168.0.*, 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 3.3.2.1, 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”.
3.3.2.4 – 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
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 http://www.x.org. Nos casos em que o servidor X chega a ser iniciado, mas o monitor
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 barkeycode 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”.
3.3.2.5 – 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.
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.
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.
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
3.3.2.6 – Swap
Após a instalação do swap, conforme apontado na seção 3.3.1.7, 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,
30
o parâmetro -z deve ser acompanhado do tamanho máximo permitido para os arquivos de swap.
3.4 – Configuração dos terminais
A configuração dos terminais, que resume-se à especificação do mecanismo de boot e à criação das contas dos usuários, encerra as tarefas de implantação de um laboratório de informática baseado na arquitetura de terminais leves proporcionada pelo LTSP.
3.4.1 – Boot
Como já mencionado, existem duas opções principais de boot via rede disponíveis para o LTSP: o PXE, que é suportado pela maioria das placas-mãe com rede onboard e o Etherboot, que é gravado em mídias como disquete ou CD.
Para que o terminal efetue o boot via PXE, deve-se acessar o Setup da máquina e, dentro da seção com a configuração de boot, posicionar a opção “Network boot” ou equivalente no topo da lista, antes das opções para boot pelo HD ou CD [36]. Na maioria das placas, é possível também realizar o boot via rede (independente da configuração do Setup), pressionando a tecla F12 durante a inicialização da máquina. O boot via placa de rede oferece grande praticidade, evitando esforços de gravação de mídias ou de chips especiais de memória.
No caso de placas de rede que não suportam boot direto via rede, é possível gravar um Etherboot em disquetes ou CDs, para que dessas mídias sejam carregadas as instruções para o boot via rede [37]. Na página do “rom-o-matic” na Internet (http://rom-o-matic.net/etherboot/etherboot-5.4.4/contrib/rom-o-matic/) é possível descarregar as imagens de boot desejadas, indicando apenas o modelo da placa de rede e o formato de imagem preferido. Estão disponíveis nesse site módulos para várias placas de rede, incluindo modelos das fabricantes 3com, Intel, sis900 (usada em muitas placas de rede onboard) e Encore e Realtek. Uma tabela detalhando os módulos indicados para a maior parte das placas de rede está disponível no endereço “http://www.etherboot.org/db/”.
Para gerar a imagem de um disquete de boot deve-se selecionar a opção “Floppy Bootable ROM Image (.zdsk), enquanto a opção indicada para a gravação de um CD de boot é a “ISO bootable image with legacy floppy emulation (.liso)”. Para gravar os disquetes, deve-se utilizar o seguinte comando:
# cat /var/tmp/eb-5.0.10-rtl8139.lzdsk > /dev/fd0
Nesse caso, “/var/tmp/eb-5.0.10-rtl8139.lzdsk” é o caminho para o arquivo descarregado com a imagem de boot e “/dev/fd0” é o caminho para o dispositivo de disquete.
Para gerar um CD de boot, por sua vez, deve-se gravar a imagem com extensão “.liso” como um arquivo de extensão “.iso” tradicional, através de algum software de gravação de dados em CDs. Para isso, é necessário renomear antes a extensão do arquivo de “.liso” para “.iso”. A letra “l” (do termo em Inglês “legacy”) na extensão do
31
arquivo é utilizada apenas para indicar que trata-se de uma imagem compatível com os BIOS usados em máquinas antigas. Terminada a gravação do CD, resta apenas configurar o Setup do cliente para executar o boot através do dispositivo de CD.
Finalizada a configuração do boot dos terminais, eles poderão inciar o sistema em execução no servidor e usufruir remotamente de todos os aplicativos instalados na máquina servidora, como se fossem vários monitores e teclados ligados a ela.
3.4.2 – Contas de usuários
Em um servidor LTSP, o ideal é que seja criada uma conta para cada usuário, ao invés de uma conta por máquina. Isso permite que cada usuário possa personalizar sua área de trabalho, com as configurações que preferir. Além de melhorar o nível de satisfação dos usuários, essa estratégia reduz bastante os problemas de suporte, já que, se vários usuários compartilham um mesmo ambiente de trabalho, a tendência é de que o desktop torne-se desorganizado com o passar do tempo.
É aconselhável também desabilitar a exibição da lista de usuários existentes na tela de login, o que evita que usuários mal intencionados testem o acesso às contas existentes em busca de senhas fáceis. Para isso, deve-se acessar o gerenciador de logins do GNOME (GDM), conforme descrito na seção 3.3.2.5 e, na aba “Remoto”, certificar-se de que não foi escolhido um estilo com navegador de faces, como exibido na Figura 3.
Outro cuidado importante deve ser tomado para evitar que usuários comuns tenham permissão de desligar a máquina, já que na verdade várias estações estarão compartilhando os recursos de um único equipamento: o servidor LTSP. Ao desligar o computador, um usuário estará desconectando todos os demais clientes do serviço. Em função disso, apenas o administrador do servidor deve ter permissão para desligar a máquina. Para remover a permissão de desligar a máquina de usuários comuns, deve-se editar o arquivo “/etc/gdm/gdm.conf” e acrescentar dentro da seção nomeada “[greeter]” o parâmetro “SystemMenu=false” [67]. Para efetivar essa alteração, basta reiniciar o serviço do gerenciador do Desktop (GDM), com o seguinte comando:
# /etc/init.d/gdm restart
Algumas configurações comuns a todos os usuários dos terminais podem ser feitas pelo administrador do sistema de forma automatizada. Recomenda-se, por exemplo, que sejam removidos da área de trabalho dos usuários os utilitários de administração do sistema, o monitor de bateria e o monitor de rede, já que trata-se de ferramentas desnecessárias em terminais leves. Recomenda-se desativar também os protetores de tela, já que esses sistemas geram um tráfego excessivo na rede por requisitarem um alto volume de dados para a atualização das imagens na tela dos clientes [68].
A forma mais prática de difundir tais configurações a todos os usuários é efetuar as modificações na área de trabalho do primeiro usuário cadastrado no sistema e depois espelhar essas configurações na pasta “/etc/skel/” [69]. Quando um novo usuário é criado, o sistema usa o conteúdo desse diretório como um modelo para a pasta “/home” do novo usuário.
Todas as configurações específicas de um usuário são armazenadas em arquivos e pastas ocultas (cujo nome começa com ponto) espalhadas pelo diretório “/home” do usuário. Para tornar as configurações do primeiro usuário do sistema um padrão para os
32
demais, basta copiar todo o conteúdo da pasta do usuário inicial para a pasta “/etc/skel”. Assumindo que o primeiro usuário criado no sistema recebeu o nome de acesso “mateus”, e que as configurações da sua área de trabalho foram concluídas, para tornar essa configuração padrão, deve-se executar os seguintes comandos:
# rm -rf /etc/skel/*# cp -a /home/mateus/.[a-zA-Z0-9]* /etc/skel/# chown -R root.root /etc/skel/
O primeiro comando limpa a pasta “/etc/skel”, o segundo comando copia todos os arquivos e pastas ocultos do usuário inicial (nesse caso nomeado “mateus”) para o diretório “/etc/skel” e o terceiro comando altera o dono dos arquivos copiados para o usuário “root”. Deve-se atentar para o fato de que essas configurações só terão efeito para os usuários que forem criados após as mudanças, já que a pasta “/etc/skel” serve apenas como um esqueleto para a criação das pastas de novos usuários.
Concluindo, é importante também que cada usuário tenha permissão de acesso apenas ao seu próprio diretório “home”, impedindo que um usuário acesse conteúdos de outro usuário. Para isso, depois de adicionar todos os usuários do sistema, use o comando abaixo, que remove todas as permissões de acesso para quem não for dono dos arquivos:
# chmod -R go-rwx /home/*
Para garantir que, daí em diante, todos os arquivos criados por todos os usuários tenham as permissões corretas, deve-se substituir no arquivo “/etc/profile” a linha “umask 022” por “umask 077” [70]. O comando “umask” configura as permissões padrão para novos arquivos, subtraindo as permissões indicadas. Se o parâmetro utilizado é “077”, significa que são removidas todas as permissões de acesso a todos os usuários, com exceção do dono do arquivo. Na maioria das distribuições Linux, o valor padrão do “umask” é “022”, que retira apenas a permissão de escrita.
4 – Conclusão e Trabalhos Futuros
Neste trabalho buscou-se apresentar de forma detalhada todos os argumentos e procedimentos para a implantação de um laboratório de informática baseado na arquitetura de terminais leves em unidades do Exército Brasileiro, especialmente nas Organizações Militares com restrições financeiras para tal implantação. Foram descritos os principais fatores a serem considerados, desde o projeto do laboratório, abordando a seleção do hardware e equipamentos mais adequados, até os passos e comandos específicos para uma instalação e configuração completa do serviço de LTSP. Estima-se que este texto proporcione condições para que profissionais do Exército na área de informática possam aplicar a tecnologia livre de terminais leves na Força Terrestre. As etapas de instalação e configuração de serviços descritas em detalhe poderão ser empregadas como fonte de consulta por profissionais que almejem consolidar a utilização do LTSP nas redes locais do Exército Brasileiro.
Não foram abordadas neste texto, no entanto, os processos de configuração específicos para a utilização de dispositivos locais disponíveis no hardware dos terminais, tais como mecanismos de armazenamento (HD, CD, Pendrive, etc...), de áudio ou de impressão. Essa configuração adicional de dispositivos disponíveis nas
33
estações de trabalho requer uma ampla discussão dos drivers e utilitários a serem configurados, em função do grande número de modelos atualmente disponíveis no mercado e do estágio de maturidade do projeto LTSP para abarcar tais dispositivos [71]. Todos os procedimentos discutidos foram baseados na versão 4.2 do LTSP, por tratar-se de uma versão totalmente madura, testada exaustivamente por diversos profissionais ao redor do mundo. Um trabalho importante a ser realizado futuramente consiste em adaptar e testar novos caminhos para a configuração da versão mais recente do projeto (LSTP 5), verificando as vantagens e desvantagens decorrentes dessa migração de versão.
No escopo de melhoria de desempenho e aperfeiçoamento do projeto LTSP, podem ser estudados novos mecanismos para o balanceamento de carga de processamento entre terminais que estejam com seu processador ocioso e o servidor, aumentando a disponibilidade e desempenho geral do servidor LTSP. Algumas idéias com esse objetivo já foram elaboradas, como as técnicas desenvolvidas dentro do projeto LibertasBR [9], e podem ser incorporadas a um projeto futuro de terminais leves.
Outro estudo pertinente a melhorias de desempenho do LTSP a ser realizado futuramente, refere-se à substituição do protocolo XDMCP pelo NX. O NX trabalha implementando um conjunto de otimizações para reduzir o tráfego e a latência das conexões, além de prover uma camada de segurança por criptografia [73]. Em função disso, o NX pode ser bastante útil para aprimorar a performance do LTSP em redes congestionadas ou prover maior segurança aos dados em ambientes com tráfego de informações sensíveis. No entanto, por adicionar camadas para reduzir o volume de dados transmitidos, o NX requer uma maior capacidade de processamento dos terminais, devendo ser testado para garantir que não comprometerá o funcionamento de estações com computadores antigos e processadores mais lentos.
5 – Referências
[1] - O ESTADO DE SÃO PAULO. Brasil tem superávit primário recorde em janeiro. Disponível em: <http://www.estadao.com.br/economia/not_eco131394,0.htm>. Acesso em: 13 out. 2008.[2] - ÉPOCA. Exército vai economizar R$ 61 milhões com dispensa de recrutas. Disponível em: <http://revistaepoca.globo.com/Revista/Epoca/0,,EDG49716-6009,00-EXERCITO+VAI+ECONOMIZAR+R+MILHOES+COM+DISPENSA+DE+RECRUTAS.html>. Acesso em: 13 out. 2008. [3] - DÏB, Saïd. O que o Gen. Heleno vem advertindo não é nada novo. É uma velha advertência entre os militares, que deveria ser ouvida com mais atenção. Disponível em: <http://saiddib.blogspot.com/2008/04/o-que-gen-heleno-vem-advertindo-no-nada.html>. Acesso em: 01 out. 2008. [4] - EXÉRCITO BRASILEIRO. Diretriz preliminar de Instrução Militar. Disponível em: <http://www.coter.eb.mil.br/1sch/simeb/DtzPrel.pdf>. Acesso em: 01 out. 08.[5] - EXÉRCITO BRASILEIRO. Evolução da Estrutura Organizacional. Disponível em: <http://www.exercito.gov.br/01inst/Historia/Artigos/0021405.htm>. Acesso em: 01 out. 08.[6] - ASSEMBLÉIA LEGISLATIVA DO ESTADO DE MATO GROSSO. Unemat poderá ganhar computadores para laboratório de informática. Disponível em: <http://www.al.mt.gov.br/V2008/ViewConteudo.asp?no_codigo=18974>. Acesso em: 29 set. 08.[7] - CONSPIRAÇÃO MINEIRA PELA EDUCAÇÃO. A Utilização dos Laboratórios de Informática nas Escolas. Disponível em: <http://www.conspiracaomineira.com.br/Grupo%201.pdf>. Acesso em: 29 set. 08.[8] – FÓRUM DO BABOO. A história dos requisitos de sistema do Windows. Disponível em: <http://www.babooforum.com.br/forum/index.php?showtopic=634935>. Acesso em: 09 out. 08.[9] - MOREIRA, Reinaldo J.. et al. Terminais inteligentes: alternativa estratégica para otimização de recursos computacionais. Disponível em:
34
<http://www.doctumtec.com.br/downloads/artigosepalestras/terminais_inteligentes.pdf>. Acesso em: 25 set. 2008. [10] - MORIMOTO, Carlos Eduardo. Servidores Linux: guia prático. Porto Alegre: Sul Editores, 2008. 735 p. [11] – DEPARTAMENTO DE CIÊNCIA E TECNOLOGIA. Implementação de software livre nas organizações militares do exército brasileiro: Uma solução técnica e economicamente viável. Brasília, 2005. Dispon?vel em: <http://ebnet.eb.mil.br/ti/softwarelivre/umasolucaoviavel.pdf>. Acesso em: 25 set. 2008.[12] - ELIAS, Paulo César; MATTOS, Fernando Augusto M.. INFORMAÇÃO E SOFTWARE LIVRE NO CAPITALISMO CONTEMPORÂNEO. Revista Digital de Biblioteconomia e Ciência da Informação, Campinas, v. 5, n. 1, p.55-76, 2007. Semestral. Disponível em: <http://server01.bc.unicamp.br/seer/ojs/include/getdoc.php?id=464&article=110&mode=pdf>. Acesso em: 07 out. 2008.[13] - LINUX ONLINE. Linus torvalds bio. , 2007. Disponível em: <http://www.linux.org/info/linus.html>. Acesso em: 29 out. 2008. [14] - SILVEIRA, Sérgio Amadeu da. Inclusão digital, software livre e globalização contra-hegemônica. , 2005. Disponível em: <http://www.cidadefutura.org.br/meulugar/arquivos/inclusao_digital.pdf>. Acesso em: 07 out. 2008. [15] - RAYMOND, Eric S.. The Cathedral & the Bazaar The Cathedral & the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary. USA: O'reilly, 2001. 256 p. Disponível em: <http://oreilly.com/catalog/9780596001087/preview.html>. Acesso em: 07 out. 2008. [16] – FERRAZ, Nelson Corrêa de Toledo. Vantagens Estratégicas do Software Livre para o Ambiente Corporativo. 2002. 114 f. Dissertação (Especialização) - Curso de Master Business Information Systems, Puc-sp, São Paulo, 2002. Disponível em: <http://tomar.pm.org/vantagens-sl.pdf>. Acesso em: 30 out. 2008. [17] - JACKSON, J. 2004. Linux now a corporate beast. Disponível em http://gcn.com/Articles/2004/07/19/Linux-now-a-corporate-beast.aspx. Acessado em 28/10/2008.[18] - COMITÊ TÉCNICO DE IMPLEMENTAÇÃO DO SOFTWARE LIVRE NO GOVERNO FEDERAL (Brasil). Diretrizes da Implementação do Software Livre no Governo Federal. Disponível em: <http://www.softwarelivre.gov.br/planejamento-anteriores/DiretrizesPlanejamento/>. Acesso em: 30 out. 2008. [19] - COMITÊ TÉCNICO DE IMPLEMENTAÇÃO DO SOFTWARE LIVRE NO GOVERNO FEDERAL (Brasil). Plano de Migração para Software Livre no Exército Brasileiro. Disponível em: <http://www.softwarelivre.gov.br/casos/exercito-brasileiro>. Acesso em: 30 out. 2008.[20] - MCQUILLAN, James. Linux Terminal Server Project. Disponível em: <http://ltsp.sourceforge.net/>. Acesso em: 03 nov. 2008. [21] - FERRETTI, Carlos. IMPLEMENTAÇÃO DE UMA REDE DE COMPUTADORES BASEADA NO LINUX TERMINAL SERVER PROJECT. 2004. 72 f. Dissertação (Especialização) - Curso de Pós-graduação Lato Sensu em Administração de Redes Linux, Universidade Federal de Lavras, Lavras, 2004. [22] - ASSOCIAÇÃO ENSINO LIVRE. Lista de distribuições educativas. Disponível em: <http://www.escolaslivres.org/?q=node/107>. Acesso em: 03 nov. 2008. [23] - MCQUILLAN, James A.. LTSP − Linux Terminal Server Project − v4.1. Disponível em: <http://ltsp.sourceforge.net/documentation/ltsp-4.1/ltsp-4.1-ptbr.pdf>. Acesso em: 25 set. 2008. [24] - FAQS.ORG. RFC1350 - The TFTP Protocol (Revision 2). Disponível em: <http://www.faqs.org/rfcs/rfc1350.html>. Acesso em: 03 nov. 2008.[25] - VANGUNDY, Paul. Linux Terminal Server Project: From Installation to LTSP Server. Disponível em: <http://www.ltsp.org/twiki/pub/Ltsp/Documentation/ltspguide.pdf>. Acesso em: 03 nov. 2008.[26] - SÃO PAULO. Prefeitura da Cidade de São Paulo. SP. Telecentros - Cidade de São Paulo. Disponível em: <http://www.telecentros.sp.gov.br/>. Acesso em: 04 nov. 2008.[27] - SÃO PAULO. Universidade Estadual de Campinas. Governo do Estado de São Paulo. Biblioteca Central reaproveita computadores com tecnologia Linux. Disponível em: <http://www.unicamp.br/unicamp/en/divulgacao/2004/04/26/biblioteca-central-reaproveita-computadores-com-tecnologia-linux>. Acesso em: 04 nov. 2008.[28] - LTSP.ORG. Linux Terminal Server Project. Disponível em: <http://www.ltsp.org/>. Acesso em: 05 nov. 2008.[29] – GREENBERG, Steve; ANDERSON, Christa. Desktop Energy Consumption: A Comparison of Thin Clients and PCs. Disponível em: <http://www.wyse.co.uk/resources/whitepapers/energy_study.pdf>. Acesso em: 06 nov. 2008.
35
[30] - HP. Thin Clients. Disponível em: <http://h10010.www1.hp.com/wwpc/us/en/sm/WF04a/12454-12454-321959-338927-89307.html>. Acesso em: 10 nov. 2008.[31] - SUN. Sun Ray Clients. Disponível em: <http://www.sun.com/software/index.jsp?cat=Desktop&subcat=Sun%20Ray%20Clients&tab=3>. Acesso em: 10 nov. 2008.[32] - FUJITSU. FUTRO Thin Clients. Disponível em: <http://ts.fujitsu.com/products/deskbound/thin_clients/index.html>. Acesso em: 10 nov. 2008.[33] - SHAFFER, Joshua H.. A Performance Evaluation of Operating System Emulators. 2004. 77 f. Dissertação (Bacharelado) - Curso de Bachelor Of Science With Honors In Computer Science, Faculty Of Bucknell University, Bucknell, 2004. Disponível em: <http://www.bucknell.edu/Documents/Engineering/JoshShaffer-thesis.pdf>. Acesso em: 25 nov. 2008.[34] MORIMOTO, Carlos Eduardo. Redes: guia prático. Porto Alegre: Sul Editores, 2008. 555 p. [35] MORIMOTO, Carlos Eduardo. Hubs, switches, bridges e roteadores. , 2008. Disponível em: <http://www.guiadohardware.net/tutoriais/hubs-switches-bridges-roteadores/>. Acesso em: 11 dez. 2008.[36] INTEL CORPORATION. Preboot Execution Environment (PXE) Specification. Disponível em: <http://www.pix.net/software/pxeboot/archive/pxespec.pdf>. Acesso em: 03 fev. 2009. [37] ETHERBOOT/GPXE WIKI. About Etherboot. Disponível em: <http://etherboot.org/wiki/about>. Acesso em: 03 fev. 2009. [38] BRASIL. Agência Nacional de Energia Elétrica. Ministério Das Minas e Energia. Tarifas Residenciais. Disponível em: <http://www.aneel.gov.br/area.cfm?idArea=493>. Acesso em: 05 fev. 2009. [39] MORIMOTO, Carlos Eduardo. Entendendo os componentes da placa-mãe. Disponível em: <http://www.gdhpress.com.br/blog/componentes-placa-mae/>. Acesso em: 05 fev. 2009. [40] TORRES, Gabriel; LIMA, Cássio. Como Montar um Sistema RAID. Disponível em: <http://www.clubedohardware.com.br/artigos/1296>. Acesso em: 11 fev. 2009. [41] HLBOG. Usando IPTABLES para configurar o Linux como um Roteador. Disponível em: <http://www.sounerd.com.br/index.php/section-blog/93-administracao-e-suporte/29.html>. Acesso em: 11 fev. 2009.[42] COSA, Eduardo Augusto. Controle de acesso através do Squid. Disponível em: <http://www.ginux.ufla.br/files/artigo-EduardoCosa.pdf>. Acesso em: 11 fev. 2009.[43] CAMPOS, Augusto. O que é uma distribuição Linux. BR-Linux. Florianópolis, março de 2006. Disponível em <http://br-linux.org/faq-distribuicao>. Consultado em 12/02/2009.[44] BRASIL. Secretaria-geral Do Exército. Exército Brasileiro. PLANO DE MIGRAÇÃO PARA SOFTWARE LIVRE NO EXÉRCITO BRASILEIRO. Disponível em: <http://ebnet.eb.mil.br/ti/softwarelivre/be08-07.pdf>. Acesso em: 12 fev. 2009. [45] MOTA FILHO, João Eriberto. Motivos pelos quais o Exército Brasileiro adotou a distribuição Debian para os servidores de rede. Disponível em: <http://eriberto.pro.br/artigos/debian_no_exercito.pdf>. Acesso em: 12 fev. 2009. [46] SILVA, Gustavo Noronha. Como usar o APT. Disponível em: <http://www.debian.org/doc/manuals/apt-howto/>. Acesso em: 09 mar. 2009. [47] ISMAIL, Mohammad Hafiz Bin. How to use apt-get behind proxy server (Ubuntu/Debian). Disponível em: <http://blog.mypapit.net/2006/02/how-to-use-apt-get-behind-proxy-server-ubuntudebian.html>. Acesso em: 09 mar. 2009.[48] MELLER, Jonathan. Explicacao do Dpkg e Apt. Disponível em: <http://www.guiaubuntupt.org/wiki/index.php?title=Explicacao_do_Dpkg_e_Apt>. Acesso em: 09 mar. 2009. [49] - FORUM DEBIAN. Instalando um servidor DHCP no Debian. Disponível em: <http://wiki.forumdebian.com.br/index.php/Instalando_um_servidor_DHCP_no_Debian>. Acesso em: 12 mar. 2009. [50] - MORIMOTO, Carlos Eduardo. Terminais leves com o LTSP. Guia do Hardware.net: GdHn, Porto Alegre, v. 1, n. 3, p.51-88, mar. 2007. Disponível em: <http://www.gdhpress.com.br/bookcast/revista/RevistaGdHn_03.pdf>. Acesso em: 12 mar. 2009.[51] - TORRES, Flávio. Trabalhando com init no Debian. Disponível em: <http://www.vivaolinux.com.br/artigo/Trabalhando-com-init-no-Debian/>. Acesso em: 12 mar. 2009. [52] - GATTO, Carlos. O que é o XDMCP? Disponível em: <http://carlosgatto.wordpress.com/2008/02/21/o-que-e-o-xdmcp/>. Acesso em: 04 mar. 2009.[53] -SCHNEEBERGER, Christoph. Linux Terminal Server Setup HowTo on Debian Sarge. Disponível em: <http://www.telemedia.ch/publ/ltsp-howto.html>. Acesso em: 12 mar. 2009.[54] - SHIGORIN, Michael et al. Swap. Disponível em: <http://www.ltsp.org/twiki/bin/view/Ltsp/Swap>. Acesso em: 16 mar. 2009.
36
[55] - ALMEIDA, Rubens Queiroz de. Configuração de Serviços DHCP. Disponível em: <http://www.dicas-l.com.br/dicas-l/20060205.php>. Acesso em: 24 mar. 2009.[56] - STEINKUEHLER, Charles. Dhcpd.conf.5. Disponível em: <http://www.nisi.ab.ca/lrp/Packages/man/dhcpd.conf.5.man.htm>. Acesso em: 24 mar. 2009. [57] - HAAS, Juergen. Linux / Unix Command: dhcp-options. Disponível em: <http://linux.about.com/od/commands/l/blcmdl5_dhcpopt.htm>. Acesso em: 24 mar. 2009.[58] – POLLOCK, Andrew; MITTERRAND, Louis-david. Debian Bug report logs - #327829: "next-server" should default to dhcp server as before (breaks pxe boot). Disponível em: <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=327829>. Acesso em: 19 mar. 2009. [59] - SYSLINUX. PXELINUX. Disponível em: <http://syslinux.zytor.com/wiki/index.php/PXELINUX>. Acesso em: 24 mar. 2009. [60] - FERNANDES, Lucas Souza. LTSP 4.2 + Debian em alguns minutos. Disponível em: <http://osdir.com/ml/culture.publications.dicas/2007-08/msg00008.html>. Acesso em: 24 mar. 2009. [61] - HAAS, Juergen. Linux / Unix Command: hosts.allow. Disponível em: <http://linux.about.com/od/commands/l/blcmdl5_hostsal.htm>. Acesso em: 24 mar. 2009.[62] – LINUX.DIE.NET. Exports(5) - Linux man page. Disponível em: <http://linux.die.net/man/5/exports>. Acesso em: 25 mar. 2009.[63] - SILVA, Gleydson Mazioli da. Guia Foca GNU/Linux: Capítulo 4 - Rede . Disponível em: <http://focalinux.cipsga.org.br/guia/avancado/ch-rede.htm>. Acesso em: 25 mar. 2009. [64] - HAAS, Juergen. Linux / Unix Command: hostname. Disponível em: <http://linux.about.com/od/commands/l/blcmdl1_hostnam.htm>. Acesso em: 02 abr. 2009. [66] - X.ORG. X.Org Manual pages: Section 4. Disponível em: <http://www.x.org/archive/X11R6.8.2/doc/manindex4.html>. Acesso em: 07 maio 2009.[67] – ILLINOIS CENTER FOR INTEGRATED MICROSYSTEMS. Gnome Display Manager Reference Manual: The Configuration File - gdm.conf . Disponível em: <Illinois Center for Integrated Microsystems>. Acesso em: 11 maio 2009. [68] – NOVELL. Miru directory server post install checklist. Disponível em: <http://developer.novell.com/wiki/index.php>. Acesso em: 09 maio 2009.[69] – THE LINUX INFORMATION PROJECT. The /etc/skel Directory. Disponível em: <http://www.linfo.org/etc_skel.html>. Acesso em: 09 maio 2009. [70] – LINUXSECURITY. Linux Security HOWTO: 5. Files and File system Security. Disponível em: <http://www.linuxsecurity.com/docs/LDP/Security-HOWTO/file-security.html>. Acesso em: 09 maio 2009.[71] - TOOMSALU, Andres. LTSP 4 LOCAL DEVICES ACCESS HOWTO v0.3. Disponível em: <http://www.active.ee/download/ltsp4_lda_v0.3_howto.pdf>. Acesso em: 11 maio 2009. [73] - POSKIPARTA, Simo. IMPLEMENTING NX REMOTE DESKTOP TECHNOLOGY IN THE LTSP SYSTEM. Disponível em: <https://oa.doria.fi/bitstream/handle/10024/5803/stadia-1178614117-3.pdf?sequence=1>. Acesso em: 25 set. 2008.
37
RELAÇÃO DE APÊNDICES
APÊNDICE A – Listagem do arquivo de configurações do DHCPAPÊNDICE B – Listagem do arquivo de configurações do TFTPAPÊNDICE C – Listagem do arquivo /etc/hostsAPÊNDICE D – Listagem do arquivo “lts.conf”
APÊNDICE A – Listagem do arquivo de configurações do DHCP
# Arquivo de configuração do servidor DHCP para o LTSP 4.2# /etc/dhcp3/dhcpd.conf
shared-network WORKSTATIONS { subnet 192.168.0.0 netmask 255.255.255.0 {
# tempo para verificar liberação de IPdefault-lease-time 28800;
# tempo máximo para liberar IPmax-lease-time 28800;
# Mascara de sub-rede:option subnet-mask 255.255.255.0;
# Endereço de broadcast option broadcast-address 192.168.0.255;
# Proibe terminais não declaradosdeny unknown-clients;
# Caminho para pasta raiz dos clientes no servidoroption root-path "192.168.0.10:/opt/ltsp/i386";
# Impede bug do dhcpd 3.03next-server 192.168.0.10;
}}group {
# utilizar declaração de nomes dos terminaisuse-host-decl-names on;
# nome do primeiro terminal host ws001 {
# Endereço MAC da placa de rede do terminalhardware ethernet 00:E0:7D:B2:E5:83;
# Endereço IP do terminalfixed-address 192.168.0.11;
# Arquivo para bootfilename "lts/2.6.17.3-ltsp-1/pxelinux.0";
}
# nome do segundo terminal host ws002 {
# Endereço MAC da placa de rede do terminalhardware ethernet 00:D0:09:A2:9B:8D;
38
# Endereço IP do terminalfixed-address 192.168.0.12;
# Arquivo para bootfilename "lts/2.6.17.3-ltsp-1/pxelinux.0";
}}
APÊNDICE B – Listagem do arquivo de configurações do TFTP
# Arquivo de configuração do servidor TFTP para o LTSP 4.2 # /etc/default/tftpd-hpa
RUN_DAEMON="yes" OPTIONS="-l -s /tftpboot"
APÊNDICE C – Listagem do arquivo /etc/hosts
# Arquivo de configuração de nomes das máquinas para o LTSP 4.2 # /etc/hosts
192.168.0.10 servidorltsp192.168.0.11 ws001192.168.0.12 ws002
APÊNDICE D – Listagem do arquivo “lts.conf”
# Arquivo de configuração do hardware dos terminais para o LTSP 4.2 # /opt/ltsp/i386/etc/lts.conf
# ---------------------- Configuração Padrão: ---------------------- [Default] # Endereço IP do servidor LTSP SERVER = 192.168.0.10
# Detecta automaticamente a placa de vídeo dos terminais, utilizando os drivers do X.org XSERVER = auto
# Tipo de mouse que será usado nos terminais (PS/2 sem roda) X_MOUSE_PROTOCOL = "PS/2" X_MOUSE_DEVICE = "/dev/psaux" X_MOUSE_RESOLUTION = 400 X_MOUSE_BUTTONS = 3
# Configuração do teclado (ABNT2): XkbModel = ABNT2 XkbLayout = br
# Carrega o ambiente gráfico nas estações SCREEN_01 = startx RUNLEVEL = 5 # ---------------------- Fim da Configuração Padrão ----------------------
39
# ------------ Configuração específica de cada estação: -------------
# Configuração do terminal de nome “ws001” [ws001] # Detecta automaticamente a placa de vídeo XSERVER = auto
# Força configuração de resolução e taxa de atualização do monitor (vídeo) X_MODE_0 = 1024x768 # (Resolução) X_VERTREFRESH = 60 # (Taxa de atualização) X_COLOR_DEPTH = 16 # (Número de Bits de Cor)
# Habilita o swap via rede USE_NBD_SWAP = Y
# Exemplo para usar um mouse serial na estação: X_MOUSE_PROTOCOL = "Microsoft" X_MOUSE_DEVICE = "/dev/ttyS0" X_MOUSE_RESOLUTION = 50 X_MOUSE_BUTTONS = 2 X_MOUSE_EMULATE3BTN = Y
# Configuração para um teclado US Internacional: XkbModel = pc105 XkbLayout = us_intl XkbRules = xorg
# Configuração do terminal de nome “ws002” [ws002]
# Configura vídeo com driver genérico que funciona com a maioria das placas XSERVER = vesa
# Força configuração de resolução e taxa de atualização do monitor (vídeo) X_MODE_0 = 800x600 # (Resolução) X_VERTREFRESH = 85 # (Taxa de atualização) X_COLOR_DEPTH = 16 # (Número de Bits de Cor)
# Exemplo para usar um mouse PS/2 COM RODA ou mouse USB na estação: X_MOUSE_PROTOCOL = "IMPS/2" X_MOUSE_DEVICE = "/dev/input/mice" X_MOUSE_RESOLUTION = 400 X_MOUSE_BUTTONS = 5 X_ZAxisMapping = "4 5"