2008 LTSP - Mateus Felipe Tymburibá Ferreira

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ário
1 – Introdução.......................................................................................................................................1
1.1 – Restrições Orçamentárias no Exército Brasileiro...................................................................1
1.2 – Benefícios de plataformas baseadas em Terminais Leves......................................................4
1.3 – Objetivos.................................................................................................................................6
2 – Referencial Teórico........................................................................................................................6
2.1 – Software Livre........................................................................................................................6
2.2 – LTSP.......................................................................................................................................8
2.2.1 – Características Gerais......................................................................................................8
2.2.2 – Serviços-base .................................................................................................................9
2.2.3 – Casos de sucesso...........................................................................................................10
2.3 – Thin Clients...........................................................................................................................11
3 – Projeto e implantação de um laboratório de informática..............................................................12
3.1 – Softwares..............................................................................................................................12
3.2 – Equipamentos........................................................................................................................14
3.3 – Servidor LTSP......................................................................................................................17
3.3.1 – Instalação de Pacotes.....................................................................................................18
3.3.1.1 – APT.......................................................................................................................18
3.3.1.2 – DHCP....................................................................................................................20
3.3.1.3 – TFTP......................................................................................................................21
3.3.1.4 – Portmap e NFS.....................................................................................................21
3.3.1.5 – XDMCP................................................................................................................22
3.3.1.6 – LTSP-utils e libwww-perl....................................................................................23
3.3.1.7 – swap......................................................................................................................23
3.3.2 – Configurações...............................................................................................................24
3.3.2.1 – DHCP....................................................................................................................25
3.3.2.2 – TFTP......................................................................................................................28
3.3.2.3 – NFS........................................................................................................................29
3.3.2.4 – lts.conf ..................................................................................................................30
3.3.2.5 – XDMCP.................................................................................................................33
3.3.2.6 – Swap......................................................................................................................35
3.4 – Configuração dos terminais..................................................................................................36
3.4.1 – Boot...............................................................................................................................36
3.4.2 – Contas de usuários........................................................................................................37
4 – Conclusão e Trabalhos Futuros....................................................................................................39
5 – Referências...................................................................................................................................40
APÊNDICE A – Listagem do arquivo de configurações do DHCP..................................................45
APÊNDICE B – Listagem do arquivo de configurações do TFTP....................................................46
APÊNDICE C – Listagem do arquivo /etc/hosts...............................................................................46
APÊNDICE D – Listagem do arquivo “lts.conf”...............................................................................46
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
Requisito mínimo de clock (MHz)
equipada com disco rígido adequado para a instalação do sistema, processadores
relativamente velozes e memória suficiente para armazenar aplicativos de uso comum,
como ferramentas de escritório, o custo mínimo de cada máquina raramente é menor do
que R$1.000,00. Podem ser citados os exemplos da Universidade Estadual de Mato
Grosso (UNEMAT) e da Conspiração Mineira pela Educação, ONG criada no estado
de Minas Gerais, que atua em projetos de melhoria da qualidade de ensino. No primeiro
caso, foram cotados 120 computadores a um preço de R$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.
Evolução dos requisitos de
processamento do Windows
1000
900
800
700
600
500
400
300
200
100
0
1.0
2.10
3.1
95
98
2000
ME
XP
Vista
Versões do Windows
Gráfico 1 – Evolução dos requisitos de processamento do Windows (FÓRUM DO
BABOO, 2008)
Requisitos mínimos de memória (KB)
3
1200000
Evolução dos requisitos de
memória do Windows
1000000
800000
600000
400000
200000
0
1.0
2.10
3.1
95
98
2000
ME
XP
Vista
Versões do Windows
Gráfico 2 – Evolução dos requisitos de memória do Windows (FÓRUM DO BABOO,
2008)
Observando-se os gráficos, percebe-se claramente um crescimento exponencial
da exigência de recursos de processamento e de memória ao longo das versões do
sistema operacional da Microsoft. Essa carência por hardware sucessivamente mais
eficiente ocorre de maneira generalizada entre os sistemas, uma vez que todos os
softwares buscam aprimorar suas funcionalidades e efeitos gráficos, como forma de
atrair usuários com interfaces cada vez mais sofisticadas.
A constante demanda por equipamentos de última geração, capazes de prover
recursos para o funcionamento adequado dos sistemas computacionais, torna inviável a
tarefa de instalar e manter um laboratório de informática para a maior parcela das
unidades do Exército.
Nesse cenário, surge a necessidade de elaboração de
medidas alternativas para a preservação das atividades que dependem dos recursos de
informática, em especial a manutenção de laboratórios de informática, já que essas
tarefas requerem uma constante atualização e reaparelhamento do parque de máquinas.
1.2 – Benefícios de plataformas baseadas em Terminais Leves
A estratégia mais empregada em ambientes que requerem uma utilização
intensiva de recursos computacionais aliada a uma baixa necessidade de poder de
processamento é baseada em Terminais Leves (MOREIRA, 2004). Esse termo se refere
a estações de trabalho com supressão de hardware, em geral disco rígido, mas que
executam tarefas como uma estação desktop padrão. Para isso, as máquinas clientes
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á baseavase nos esforços de mais de 400 mil desenvolvedores espalhados por mais de 90 países.
O autor aponta a extrema dificuldade de encontrar desenvolvimentos de engenharia
comparáveis em extensão, envolvimento de pessoas e alcance geográfico, como o
empreendido pelo projeto do GNU/Linux. Cita ainda que a Microsoft, maior empresa de
software do planeta, produz o sistema operacional Windows contando em seu quadro
funcional com aproximadamente 30 mil funcionários concentrados em sua sede em
Seatle, EUA. Em breve, o desenvolvimento e a melhoria anual do GNU/Linux contará
com 1 milhão de programadores, conforme Amadeu. Trata-se de estudantes,
especialistas, empresas em busca de lucro e profissionais de altíssimo nível, entre
outros. Para Eric Raymond (2001), como qualquer pessoa com acesso à Internet e
habilidades de programação pode integrar o processo de desenvolvimento de softwares
livres, esses sistemas envolvem um número tão grande de horas de programação
qualificada a um custo orçamentário zero que dificilmente uma grande corporação
poderia dispor.
A vantagem de custo do software livre, imediatamente percebida, não está
somente na economia com o pagamento de licenças, já que o software livre também
reduz os custos de manutenção e de atualização dos sistemas. A correção de erros e
apoio eficiente aos usuários oferecido pelas numerosas e atuantes comunidades de
desenvolvedores livres explica o primeiro aspecto. No segundo caso, pode-se
argumentar que
frequentemente os fabricantes de softwares
proprietários deixam de suportar seus antigos sistemas, forçando os compradores a uma
atualização. Além disso, existem políticas de licenciamento de programas de
computador, como a Software Assurance, da Microsoft, que obrigam os clientes a
realizar assinaturas anuais para obter atualizações constantes, mesmo que não possam
ou não queiram, perdendo o direito de efetuar atualizações com descontos,
conforme suas necessidades (FERRAZ, 2002).
Além de menos onerosas, as soluções não proprietárias oferecem outras
vantagens irrefutáveis. Em “Vantagens estratégicas do software livre para o ambiente
corporativo”, Ferraz (2002) discorre detalhadamente sobre os motivos que tornam as
soluções livres mais
diferenciadas (inovadoras), seguras, independentes de fornecedores e confiáveis.
Todos esses fatores têm contribuído para um aumento significativo do interesse
de grandes corporações na adoção de plataformas livres. Um exemplo disso é o
estabelecimento do Open Source Developer Labs (OSDL), uma organização sem fins
lucrativos financiada por corporações como IBM, Hewlett-Packard, Intel, AMD,
RedHat e Novell, especificamente para desenvolver o Linux para ambientes de grande
escala de produção (LINUX ONLINE, 2007). Segundo Jackson (2004), nos últimos
anos a maior parte do código do Linux tem sido gerada por programadores
profissionais, empregados em corporações, como IBM, Red Hat e SGI, dentro do
horário de trabalho.
No Brasil, o Governo Federal aprovou em 2003 suas diretrizes para
implementação do Software Livre, onde determina que os órgãos públicos federais
passem a priorizar, implementar e fomentar o uso de plataformas baseadas em soluções
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 “hubswitch” com o número de portas suficiente (21 portas) pode ser empregado com
sucesso. É possível até mesmo utilizar vários switches pequenos interconectados (modo
“daisy chain”), como forma de reaproveitar equipamentos com um número de portas
menor do que o necessário.
Como já descrito no “Capítulo 1 – Introdução”, as máquinas clientes não
precisam ser dotadas de HD ou CD-ROM para que possam ser empregadas em uma
arquitetura de terminais leves. Basta que elas possuam um mecanismo para dar boot
através da rede. A maioria das placas-mãe fabricadas atualmente, com alguma placa de
rede integrada (onboard), suportam boot via rede utilizando o protocolo PXE, um
protocolo desenvolvido pela Intel que permite que as estações carreguem todo o
software a partir de um servidor [36]. Nesses casos, basta configurar a BIOS da placa
indicando que o boot via rede deve ser utilizado no momento de inicialização da
máquina.
No caso de máquinas antigas, ainda sem suporte ao protocolo PXE, pode-se
utilizar o Etherboot, um pequeno software para boot, que precisa ser gravado em um
disquete ou CD e disponibilizado durante a inicialização do terminal [37]. Nesse caso,
deve-se também acessar a BIOS e certificar-se de que o boot via mídia está definido
como primeira opção. Uma outra possibilidade, um pouco mais incomum, é a gravação
do Etherboot em um chip específico para boot, que é posteriormente instalado no
soquete disponível na maioria das placas de rede PCI. Essa alternativa é menos
empregada por necessitar de um hardware específico para gravar o software no chip
apropriado. Indicações mais detalhadas de como proceder à configuração do boot nos
terminais, de acordo com a opção do projetista da rede, são descritas na seção “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
(http://www.debian.org/releases/stable/installmanual).
oficial
da
distribuição
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 “nfscommon” e o “nfs-kernel-server” estejam ativos e configurados para iniciar durante o
boot, executa-se os seguintes comandos [51]:
# update-rc.d -f portmap remove
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 “fusesource” para as versões mais recentes do Debian. Caso algum erro referente à falta do
pacote “fuse-source” seja retornado, deve-se instalar um pacote vazio com esse nome,
para satisfazer as dependências entre pacotes [10]. Uma versão vazia desse pacote está
disponível no seguinte endereço de Internet:
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-nameservers” para indicar o servidor DNS a ser consultado pelas máquinas da rede. Ambas
opções devem ser seguidas pelo endereço IP dos respectivos ativos de rede responsáveis
pelos serviços, como em “option routers 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.3ltsp-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). Devese, portanto, alterar o endereço IP da rede local, caso uma outra faixa de endereços IP
esteja sendo utilizada [61].
Uma particularidade do servidor TFTP advém do fato de algumas vezes ele
apresentar conflitos com o serviço “inetd”. Caso o serviço “tftpd” não responda às
requisições das estações, deve-se desativar o serviço “inetd” e reiniciar a máquina
servidora através dos seguintes comandos:
# /etc/init.d/inetd stop
# update-rc.d -f inetd remove
# reboot
É importante salientar que ao desativar o “inetd”, o acesso remoto a todos os
serviços gerenciados por ele, como os aplicativos “vmware-server” e “swat”, caso
instalados no servidor, deixarão de funcionar. Caso seja necessário utilizar algum desses
serviços, convém reativar momentaneamente o “inetd” de forma manual, utilizando o
comando abaixo:
# /etc/init.d/inetd start
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 bar
keycode 51 = bracketright braceright
Concluindo, as linhas “SCREEN_01 = startx” e “RUNLEVEL = 5”, incluídas
na seção “DEFAULT” do arquivo “lts.conf”, estabelecem que os terminais iniciem
direto em modo gráfico. Para que uma estação trabalhe apenas em modo texto, basta
incluir na seção de configuração da estação desejada a opção “RUNLEVEL = 3”, que
irá sobrescrever a diretiva de mesmo nome existente na seção “DEFAULT”.
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”, certificarse 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,00EXERCITO+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 contrahegemô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-reaproveitacomputadores-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/1245412454-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-serverubuntudebian.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: "nextserver" 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/stadia1178614117-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 DHCP
APÊNDICE B – Listagem do arquivo de configurações do TFTP
APÊNDICE C – Listagem do arquivo /etc/hosts
APÊ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 IP
default-lease-time
28800;
# tempo máximo para liberar IP
max-lease-time
28800;
# Mascara de sub-rede:
option subnet-mask
# Endereço de broadcast
option broadcast-address
255.255.255.0;
192.168.0.255;
# Proibe terminais não declarados
deny unknown-clients;
# Caminho para pasta raiz dos clientes no servidor
option root-path "192.168.0.10:/opt/ltsp/i386";
# Impede bug do dhcpd 3.03
next-server
192.168.0.10;
}
}
group {
# utilizar declaração de nomes dos terminais
use-host-decl-names
on;
# nome do primeiro terminal
host ws001 {
# Endereço MAC da placa de rede do terminal
hardware ethernet 00:E0:7D:B2:E5:83;
# Endereço IP do terminal
fixed-address
192.168.0.11;
# Arquivo para boot
filename "lts/2.6.17.3-ltsp-1/pxelinux.0";
}
# nome do segundo terminal
host ws002 {
# Endereço MAC da placa de rede do terminal
hardware ethernet 00:D0:09:A2:9B:8D;
38
# Endereço IP do terminal
fixed-address
192.168.0.12;
# Arquivo para boot
filename "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
192.168.0.11
192.168.0.12
servidorltsp
ws001
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"