Tutorial sobre a configuração do Kurumin Terminal Server

Ele ainda não está bem testado e ainda falta encontrar meios de tornar a instalação mais simples. Mas, apesar disso, muita gente tem demonstrado insteresse, pois apesar da grande utilidade parece que pouca gente consegue instalar e configurar o LTSP sem ajuda. Mesmo neste estágio preliminar o script acionado pelo ícone mágico do Kurumin já facilita bastante o trabalho, então vamos à uma explicação rápida de como você pode configurar sua rede de terminais leves.

O servidor

A configuração recomendada para o servidor é um Pentium III ou Athlon com 256 MB de RAM e mais 64 MB para cada dois terminais que forem ser adicionados. Ou seja, se você vai pendurar 4 terminais nele, seria recomendável ter 512 MB, se você for pendurar 10 terminais ou mais então 1 GB já seria mais apropriado. O processador não precisa ser nenhum topo de linha, o mais importante é ter um HD razoavelmente grande (já que os arquivos de todos os usuários serão armazenados unicamente no servidor) e bastante memória RAM.

Se você quiser ter o melhor desempenho possível, então um dual Athlon viria a calhar, pois como o servidor processará vários aplicativos ao mesmo tempo a divisão entre os dois processadores tornará as respostas bem mais rápidas.

O servidor não precisa ser dedicado, nada impede que você o utilize junto com os terminais, apenas tome o cuidado de não ficar apertando o botão de reset nem ficar dando tapas na CPU… 🙂

Outra configuração importante é desabilitar a opção de desligamento local e remoto no Centro de Controle do KDE > Administração do Sistema > Gerenciador de Login > Sessões > Permitir desligamento (acesse como root). Assim nenhum usuário vai conseguir desligar o servidor por engano. Lembre-se “quem tem HD tem medo”, como as estações não tem HD então não existe necessidade de “desligar o sistema corretamente”, é só dar um logout e depois desligar no botão. Apenas o servidor precisa passar pelo processo normal de desligamento

Os terminais

A configuração mínima para os terminais é um 486 com 8 MB. A configuração ideal é um Pentium 100 com 16 MB. Em teoria você pode utilizar até mesmo um 386 como terminal, mas neste caso você vai começar a sentir uma certa demora na atualização da tela.

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.

O ping numa rede local, mesmo que seja uma rede de 10 megabits é muito baixo, em torno de 10 ms na pior das hipóteses. Ou seja, o tempo necessário para um click do mouse ir da estação até o servidor e este enviar de volta a resposta é mínimo, quase imperceptível. Mas, apesar disso, a estação precisa rodar uma versão compacta do Linux com um servidor X e tem o trabalho de montar as janelas baseado nas instruções recebidas do servidor.

Se o processador for muito lento a atualização da tela começará a ficar lenta. Um 486 DX-100 demora cerca de 0.5 segundo para redimensionar uma janela (usando o Xfree 4.2 padrão do LTSP), é relativamente rápido. Mas, um 386 demoraria 2 ou 3 segundos para fazer a mesma tarefa, o que já seria incômodo. O ideal é utilizar no mínimo micros 486 DX-100 com uma placa de vídeo PCI. Se você utilizar micros um pouco mais rápidos, a partir de um Pentium 100 a atualização de tela já passará a ser instantânea. Numa rede de 100 megabits você pode pendurar 10, 15 ou até mesmo 20 terminais no servidor antes que a velocidade da rede comece a tornar-se um gargalo.

Aqui estão as entranhas de um dos micros que estou usando nos testes. Ele é um 486 de 133 MHz da AMD com 12 MB de RAM. Ele tem um desempenho mais parecido com um DX-80 pois usa uma placa mãe sem cache L2. Como você pode ver, ele tem espetados apenas a placa de rede, uma Trident 9440 de 1 MB e um drive de disquetes:

Aqui ele já está rodando o KDE a partir do Celeron 700 com 256 MB que estou usando como servidor:

O boot é bem rápido, demora menos de 30 segundos (no 486) para cair na tela de login do servidor e, a partir daí o tempo de carregamento do KDE e dos programas depende apenas do desempenho deste. Se você usar um Athlon 2400+ com HDs em RAID e muita RAM por exemplo, todos os clientes terão a impressão de estarem usando uma super máquina que abre qualquer coisa quase instantâneamente, mesmo que na verdade estejam usando um monte de 486 velhos. Esta é a parte interessante… 🙂

Configurando

Antes de mais nada, clique no “Atualizar scripts de instalação” e o ícone mágico aparecerá no menu Instalar Novos programas > Servidores.

Antes de iniciar a instalação não se esqueça de dar um “apt-get update” ou clicar no “Atualizar lista de Pacotes“, pois parte da instalação é feita através do apt.

O primeiro passo é criar os disquetes de boot para as estações na página do rom-o-matic que será aberta em seguida. Você precisa apenas indicar o modelo da placa de rede e gravar a imagem seguindo as instruções da página. O endereço do site é:

http://www.rom-o-matic.org/

Estas imagens são incrivelmente pequenas, em torno de 50 KB e também podem ser opcionalmente gravadas num chip de boot na placa de rede.

Para criar a imagem do disquete basta apontar o módulo utilizado pela sua placa de rede. No meu caso estou usando uma Realtek 8139, que usa o módulo rtl8139. Estão disponíveis módulos para várias placas de rede, incluindo as 3com, Intel, sis900 (usada em muitas placas onboard) e via-rhine-6105, usado nas placas Encore novas. Em caso de dúvidas você pode consultar esta tabela: http://www.etherboot.org/db/.

Para criar o disquete, basta usar o comando:

(onde o eb-5.0.10-rtl8139.lzdsk é o nome do arquivo)

Se o disquete não estiver formatado, use o comando “fdformat /dev/fd0“

Depois de criar os disquetes, dê um boot usando o disquete apropriado em cada estação e anote o número do endereço MAC de cada placa de rede, que é mostrado no início do boot. Você precisará fornecer os endereços MAC de cada estação nos arquivos de configuração do LTSP que serão abertos em seguida.

O endereço MAC é um número de 12 dígitos, diferente em cada placa que você pode localizar facilmente entre as mensagens exibidas:

Enquanto o servidor não estiver configurado ele vai ficar indefinidamente no “Searching for DHCP Server…“, um sintoma de que o disquete conseguiu ativar corretamente a placa de rede. Agora só falta mesmo o servidor

A primeira parte da instalação é automática, o script se encarrega de instalar os pacotes necessários para o uso do LTSP, a lista inclui os pacotes:

• tftp
• tftpd
• bootp
• dhcp3-server

… instalados através do apt-get e os pacotes:

• ltsp-core-i386_3.0.7-3_all.deb
• ltsp-kernel-2.4.19-i386_3.0.5-0_all.deb
• ltsp-x-core-i386_3.0.4-0_all.deb
• ltsp-x-fonts-i386_3.0.0-0_all.deb
• ltsp-x-xserver-fbdev-3.3.6-i386_3.0.0-0_all.deb
• ltsp-x-xserver-svga-3.3.6-i386_3.0.0-0_all.deb

… baixados a partir da página do LTSP.

Caso você já tenha algum destes pacotes instalado o script simplesmente passa para o próximo:

Em seguida vem a parte mais complicada, que é a configuração propriamente dita, feita em quatro arquivos separados, que vão sendo abertos um a um em janelas do kedit. Você edita o arquivo, salva, fecha a janela e o script abre o seguinte até acabar todos. Os arquivos estão bem comentados o que facilita as coisas. Os arquivos vem com entradas para cinco clientes, mas você pode adicionar mais entradas caso necessário.

Lembre-se que em qualquer arquivo de configuração as linhas começadas por um “#” são comentários que não possuem efeito algum.

A primeira parada é o arquivo /etc/dhcp3/dhcpd.conf. Aqui vai a configuração do servidor DHCP, que diz aos clientes qual é o endereço IP de cada um, qual o IP e pasta do servidor que será usado para dar boot, etc.

Na primeira parte do arquivo você deve fornecer as configurações da rede, como a mascara de sub-rede, o endereço do default gateway, e o DNS do provedor.

O default dos arquivos de configuração é usar a faixa de IPs 192.168.0.x e um servidor de terminais configurado no endereço 192.168.0.10. Se você for usar estes endereços seu trabalho será bem menor 🙂

Logo abaixo vem a opção onde você deve fornecer o endereço IP usado pelo servidor Kurumin. Não altere o “/opt/ltsp/i386“, este é o diretório onde vai a mini-distribuição que será carregada pelos terminais:

Abaixo vem a configuração dos terminais, onde você deve fornecer o endereço MAC de cada um. O “fixed-address 192.168.0.11;” é o endereço IP que o servidor DHCP dará para cada terminal, ele sabe quem é quem por causa do endereço MAC que será sempre diferente em cada terminal:

O próximo arquivo é o /etc/exports, onde você deve fornecer a faixa de endereços usada na sua rede local. Você só precisa se preocupar em alterar o arquivo se estiver usando uma faixa diferente de 192.168.0.x

No /etc/hosts.allow você deverá novamente apenas alterar a faixa de endereços da sua rede, caso necessário:

A parte mais importante da configuração fica a cargo do arquivo /opt/ltsp/i386/etc/lts.conf. É aqui que você vai dizer qual a resolução de vídeo e que tipo de mouse será usado em cada estação e ainda tem a opção de ativar o swap via rede do LTSP, que permite que estações com pouca memória RAM consigam carregar tudo o que for necessário utilizando um pequeno arquivo de swap no HD do servidor.

Logo no início do arquivo você deve prestar atenção para substituir os dois “192.168.0.10” pelo IP correto do seu servidor, senão os clientes não conseguirão das boot nem por decreto 🙂

Veja que existem dois campos, para o “SERVER” (quem fica responsável por enviar os arquivos de boot) e o “XDM_SERVER” (quem realmente roda os aplicativos gráficos). Em geral uma única máquina cuida das duas funções, mas nada impede que você use dois servidores separados para as duas funções, basta especificar aqui.

Abaixo você verá a configuração default do LTSP. Não existe necessidade de alterar nada aqui pois você pode especificar configurações diferentes para cada estação mais abaixo.

O LTSP utiliza o Xfree 4.2.1 e já possui um sistema de detectação automática para o vídeo em cada estação (a opção “XSERVER = auto”). No final do boot ele tentará detectar a placa de vídeo e detectar as taxas de atualização suportadas pelo monitor via DCC. Este sistema funciona direto em uns dois terços dos micros, mas em um grande número de casos você precisará especificar algumas configurações manualmente para que tudo funcione adequadamente.

Veja também que o default do LTSP é utilizar um mouse PS/2 (sem roda) em todas as estações. Naturalmente você terá alguns micros com mouses seriais ou PS/2 com roda, o que também precisaremos arrumar. Esta configuração individual das estações é feita logo abaixo:

Veja que a configuração usada por default especifica pouca pouca para as estações:

O “Xserver = auto”, como já vimos, faz com que o LTSP detecte automaticamente a placa de vídeo em cada estação. O “USE_NFS_SWAP = Y” ativa o recurso de swap via rede para as estações. Ele é necessário para estações com menos de 32 MB de RAM, mas não atrapalha muito o tráfego da rede, pois a quantidade de dados manipulados pelas pelas estações é bem pequeno.

O “SWAPFILE_SIZE = 32m” especifica o tamanho deste arquivo de swap (os 32 MB são suficientes na maioria dos casos), enquanto o “RUNLEVEL = 5” faz com que as estações dêem boot direto em modo gráfico, que é o que queremos. Se por acaso você quiser ter alguma estação trabalhando em modo texto (para tentar descobrir o motivo de algum problema por exemplo), basta trocar o 5 por 3.

Mas, além destas existem várias outras opções que podem ser usadas. Se a detecção automática do vídeo não funcionar (a tela vai piscar algumas vezes e depois voltar ao modo texto) você pode indicar manualmente um driver, substituindo o “auto” por “vesa” (um driver genérico, meio lento mas que funciona na maioria das placas) ou “fbdev” por exemplo. Tem uma lista com os drivers incluídos no: http://www.xfree.org/4.2.1/manindex4.html

Outra coisa importante que você pode precisar mudar é o tipo de mouse usado nos terminais, afinal não é sempre que você utilizará mouses PS/2. Basta incluir algumas opções, veja os exemplos abaixo:

Exemplo para usar um mouse serial na estação:

Este exemplo força a estação a usar uma resolução e taxa de atualização específicas, para o caso do X estar abrindo mas o monitor estar ficando fora de sintonia, o que acontece em muitos monitores antigos (contribuição do ailtonjr):

A última parada é o arquivo /etc/hosts, onde ficam relacionados os endereços IP e os nomes de cada estação (ws001. ws002, etc.). Você só precisa alterar este arquivo se tiver alterado os IPs ou adicionado mais terminais no arquivo /etc/dhcp3/dhcpc.conf:

Depois de reiniciar o servidor, seus terminais já conseguirão carregar o sistema e pegar a tela de login do servidor. Agora é só correr pro abraço 🙂

Basta ir agora criando os logins das pessoas que forem usar os terminais. Cada usuário poderá usar seu próprio login, com todas as suas configurações e arquivos em qualquer um dos terminais, o que é uma das grandes vantagens. A conexão com a Web, impressora, disquete e gravador instalados no servidor também poderá ser automaticamente usados em qualquer um dos terminais, pois na verdade os programas nunca saem do servidor, os terminais funcionam apenas como se fossem vários monitores e teclados ligados a ele.

Tenha à mão também a configuração da sua rede, como o endereço deste servidor, máscara de sub-rede, servidores DNS do seu provedor, gateway padrão, etc.

O processo todo é relativamente simples. A instalação é feita de forma mais ou menos automática seu principal trabalho será fornecer os endereços MAC das placas de rede de cada estação e as configurações de rede nos arquivos de configuração do LTSP que serão abertos no final da instalação.

Como você pode ver, estamos na verdade fazendo uma instalação do LTSP, a vantagem é que algumas coisas já são pre-configuradas, o que facilita bastante as coisas. O assistente se encarrega de baixar e instalar os pacotes necessários e depois vai abrindo versões comentadas dos arquivos de configuração para que você pode fazer a configuração dos terminais.

Terminado, você deve ser capaz de obter a tela de login do servidor dando boot através do disquete em qualquer um dos terminais e, a partir daí, rodar todos os aplicativos de forma quase transparente. Tive bons resultados até com o Zsnes, um emulador de Super Nes. Mesmo via rede é possível jogar quase que normalmente :).

Mais configurações

Se você estiver usando placas de rede ISA nas estações, é preciso adicionar algumas linhas adicionais no arquivo /etc/dhcp3/dhcpd.conf, especificando o módulo usado pela placa (você já pesquisou sobre isso para gerar o disquete do rom-o-matic, lembra? 🙂

Antes de mais nada, descomente (ou inclua) estas duas linhas, que serão as duas primeiras linhas do arquivo:

Mais à baixo, dentro da seção referente à estação, você deverá adicionar mais duas linhas, mantendo as anteriores:

Substitua o “3c509” pelo módulo da placa de rede usada. Não altere o “e4:45:74:68:00:00” este não é um endereço MAC, mas sim uma string que ativa a linha com o módulo da placa.

Se você estiver usando uma daquelas placas antigas, onde ainda é preciso especificar o endereço de I/O usado pela placa, você deve incluí-lo na linha logo depois do módulo, como em:

(o driver “ne” dá suporte às placas NE 2000 compatible)

Usando clientes com boot via PXE

Muitas placas de rede atuais, incluindo muitas placas mãe com rede onboard oferecem um recurso de boot via rede utilizando o protocolo PXE, uma tecnologia criada pela Intel.

Este sistema é diferente do Etherboot, usado pelos disquetes que criamos no início do tutorial por isso é preciso fazer algumas adaptações para que o seu servidor LTSP funcione com clientes que usam o PXE. Por outro lado, você vai ter um ganho de praticidade muito grande, pois vai precisar apenas mudar uma opção no Setup ou pressionar uma tecla durante o boot ao invés de ter que manter um drive de disquete em cada micro ou sair atrás de alguém que venda ROMs para as placas de rede.

Em primeiro ligar, você precisa baixar o arquivo pxestuff-3.0.5-i386.tgz (ou a versão mais recente) que está disponível na página de download do LTSP. Este arquivo não tem versão .deb ou .rpm pois é apenas um arquivo compactado com arquivos que precisam ser copiados.

A instalação é bem rápida, tudo o que você precisa fazer é descompactar o arquivo (renomeie para .tar.gz se necessário), acesse a pasta que será criada e copie todos os arquivos para dentro da pasta /tftpboot/lts

Entre os arquivos estão uma versão especial do Kernel do LTSP e um módulo que ativa o suporte, carregado pelas estações no início do boot.

Para que funcione você precisará fazer mais duas coisas. Em primeiro lugar é preciso instalar o pacote “tftp-hpa”, substituindo o tftp “normal” que vem no Kurumin:

O segundo passo é editar o arquivo /etc/dhcpc/dhpcd.conf, alterando a entrada para cada estação que for utilizar o PXE, seguindo o modelo do arquivo “dhcpd.conf” que está dentro do arquivo:

O que muda é basicamente o “filename “/tftpboot/lts/pxelinux.0″;” que faz com que a estação carregue o módulo correto durante o boot. O “option vendor-encapsulated-options
09:0f:80:00:0c:4e:65:74:77:6f:72:6b:20:62:6f:6f:74:0a:07:00:50:72:6f: 6d:70:74:06:01:02:08:03:80:00:00:47:04:80:00:00:00:ff;” forma uma única linha, sem espaços. Ele é uma instrução não um endereço.

Depois disso basta reiniciar o servidor dhcp com o comando “/etc/init.d/dhcp3-server restart” e testar o boot nas estações.

Respondendo a algumas dúvidas freqüentes

Continuando o artigo, aqui vão as respostas para algumas dúvidas freqüentes quando se fala em terminais leves:

• Aplicativos como o KDE e o OpenOffice consomem muita memória. Abrir o KDE 3 junto com o OpenOffice e o Mozilla já consome quase 100 MB de memória. Quer dizer que se for ter 10 clientes rodando os três vou precisar de 1 GB de RAM no servidor?

O mais interessante é que não :-). O que acontece é que o Kernel não carrega cada aplicativos 10 vezes, mas reaproveita os dados do primeiro carregamento para todos os subseqüentes, carregando apenas dados que forem diferentes, como configurações dos usuários, papéis de parede, temas, etc.

O mais interessante é que os aplicativos em uso em outros clientes carregam muito mais rápido, pois na verdade já estão carregados no servidor. Se você manter o servidor ligado continuamente, vai notar que depois de algum tempo os aplicativos começarão a sempre abrir muito rápido.

O que deve ser levado em consideração na hora de avaliar quanta memória RAM será necessária no servidor é principalmente o número de aplicativos diferentes que serão utilizados e não o número de clientes. Você pode ir acompanhando o uso de memória no servidor através do comando “free” e assim avaliar quando é necessário comprar mais memória.

• Qual é a diferença entre usar clientes LTSP e usar o VNC? Não é quase a mesma coisa?

Usar terminais LTSP é bem diferente de usar o VNC. A grande diferença é que o VNC se limita a capturar a imagem da tela e enviar como um bitmap através da rede. Ele oferece várias opções de compactação é verdade, mas você sempre notará alguma demora na atualização.

No caso dos terminais temos uma instância do X rodando em cada um. O servidor não manda bitmaps, mas sim instruções para montar as imagens. Se você abrir um menu o VNC mandará a imagem do menu, enquanto o X envia apenas uma instrução com as dimensões do menu, o texto que vai dentro, etc.

Se você colocar uma imagem de 64×64 pixels como papel de parede, ladrilhada para que ocupe a tela toda, o VNC simplesmente capturará a tela toda e enviará como se fosse uma única imagem. O X por sua vez será mais esperto e enviará a imagem de 64×64 apenas uma vez, junto com uma instrução dizendo que ela deve ser replicada na tela toda. Ou seja, a comunicação é muito mais rápida e o uso da rede brutalmente menor, a ponto de você ter terminais funcionais mesmo numa rede de 10 megabits.

O VNC também utiliza muito processamento, tanto no servidor quanto no cliente. Para ter algo mais ou menos transparente é preciso ter um processador de 600 MHz em cada ponta e uma rede de 100 megabits entre os dois. No caso dos terminais LTSP o overhead é muito pequeno.

Enfim, o VNC é uma boa solução quando os PCs utilizam dois sistemas operacionais diferentes, mas caso ambos utilizem o Linux a idéia dos terminais é mais funcional.

• Mas e se os meus clientes utilizarem o Windows e não tiver como instalar o Linux em todos? Vou ter que usar o VNC de qualquer forma não é?

Você também pode utilizar máquinas Windows como terminais utilizando o Cygwin, que tem um servidor X embutido. Você pode baixar o programa no http://www.cygwin.com. Ao abrir você verá um terminal de texto, onde você pode dar o comando para obter a tela de login do servidor, X -query 192.168.0.1, X – broadcast, etc. A velocidade fica normal, a mesma que teria num cliente Linux.

Outra opção é simplesmente deixar um disquete do LTSP pronto, assim quando você quiser usar o micro como terminal basta reiniciar com o disquete no drive.

• Como faço para compartilhar a impressora com os clientes?

A impressora é “compartilhada” automaticamente, já que os dados na verdade não saem do servidor. Basta instalar a impressora localmente e ela já funcionará nos clientes. Imagine um servidor com um monte de monitores e teclados; a idéia dos terminais é mais um menos isso. Vários usuários no mesmo micro, compartilhando seus recursos e aproveitando os recursos multiusuário do Linux.

• E no caso dos jogos? Dá para jogar por exemplo Quake III nos clientes, mesmo que um pouco lento?

Depende, se você tiver uma placa Nvidia ou ATI com os drivers 3D corretamente instalados tanto no servidor quanto nos clientes até vai funcionar, caso contrário ao tentar abrir o Quake III nos clientes você receberá um erro, dizendo que não foi possível encontrar um sub-sistema OpenGL.

De qualquer forma, é possível rodar jogos 2D sem maiores problemas, dá para fazer um campeonato de FreeCiv por exemplo 🙂 Uma vez tentei jogar o Diablo II num terminal e também funcionou, apesar da atualização de tela ficar lenta por causa da rede. Limitação mesmo só com relação aos jogos 3D.

Enfim, é o tipo da coisa que você só realmente vê o quanto é interessante depois que começa a usar.

Alterando a tela de login e outras opções

Você pode personalizar vários opções relacionadas à tela de login das estações, como o texto de boas vindas, tipo e tamanho das fontes, logotipo, decoração dos botões, ocultar os nomes dos usuários, etc. no Centro de Controle do KDE > Administração do Sistema > Gerenciador de Login, mesmo lugar onde desabilitamos o desligamento remoto.

Você pode alterar a imagem de fundo substituindo o arquivo /usr/share/wallpaper/debian.jpg. Você pode colocar um logo da sua empresa ou escola por exemplo 🙂

Se você instalar outros gerenciadores de janela, como o Window Maker, Blanes, etc. através de pacotes .deb eles aparecerão automaticamente na lista de opções da tela de login.

O menu padrão do sistema, aquele que os usuários vêem ao clicar no botão K fica dentro da pasta /usr/share/applnk/. Os ícones nada mais são do que arquivos de texto comuns com algumas propriedades que ficam organizados na mesma estrutura de pastas vista no iniciar. Você pode mudar os ícones de lugar, adicionar atalhos para outros aplicativos, adicionar ícones de ajuda, etc.

As mudanças feitas no /usr/share/applnk/ afetam todos os usuários. Além dele existe uma pasta .kde/share/applnk/ dentro do diretório home de cada usuário, que armazena um menu “pessoal”, que permite que você disponibilize certos programas apenas para alguns usuários específicos. Se você jogar algum novo ícone alí, ele aparecerá apenas para o usuário em questão.

Fontes pequenas nas estações!

Um problema que você pode enfrentar ao usar o Kurumin Terminal Server são as fontes de tela ficarem menores nas estações do que no servidor. Isso talvez não seja um grande problema se você for usar um usuário diferente em cada estação (é só ajudstar o tamanho da fonte) mas vai ser trágico se você quiser usar os mesmos usuarios em todas as estações.

Existem duas soluções experimentais para esse problema:

• Solução 1 (foi testada e funcionou com os terminais usando resolução de 1024×768)

Edite o arquivo: /opt/ltsp/i386/etc/inittab (do servidor) e substitua a linha:

por:

Este arquivo é lído pelas estações durente o boot, é através dele que as estações sabem que devem pegar a tela de login do servidor. Isso obriga as estações a usarem o parametro “-dpi 100”, o que faz com que utilizem o mesmo conjunto de fontes do servidor, solucionando o problema. Obs: substitua o “192.168.0.10” pelo endereço IP do seu servidor.

• Solução 2 (sugerida pelo LZwill no forum)

Edite o arquivo /etc/X11/XF86Config-4 (no servidor).

Apague toda a seção de declaração de fontes:

E, coloque o trecho a seguir no lugar:

Este problema do tamanho das fontes acontece por que o Kurumin utiliza fontes de 100 dpi por default, enquanto o sistema do LTSP, carregado pelas estações utilizam fontes de 75 DPI por default. As fontes de 75 dpi são maiores que as fontes de 100 dpi, o que causa a diferença no tamanho das fontes caso o servidor esteja utilizando fontes de 75dpi e as estações fontes de 100 dpi. O importante nesse caso é que todos utilizem o mesmo tipo de fonte.

Só pra não perder a piada 😛

Juntando umas peças velhas que estavam jogadas por aqui, acabei montando mais um micro, um velho 486 SX 25 com 8 pentes de 1 MB e uma placa de vídeo VESA tão antiga quanto o resto. Como não tinha mais um gabinete, ele acabou virando esse amontoado aqui:

O mais interessante é que apesar de tudo, a sucataiada funcionou como terminal, foi só gravar o módulo da placa 3com509 e espetar um drive de disquetes:

Como ele utiliza uma placa de rede ISA, precisei adicionar aquelas duas linhas no arquivo /etc/dhcp3/dhcpd.conf, que ficou assim:

A configuração da placa de vídeo foi a parte mais complicada, pois ela não funciona com a detecção automática do vídeo (acontece com a maioria das placas ISA ou VLB). A melhor configuração que encontrei foi usar o driver “vesa” com 8 bits de cor (funciona tanto a 800×600 quanto a 1024×768). Existe também a opção de usar o driver “vga”, mas não é muito agradável de trabalhar a 640×480 com 16 cores…

Segundo a página de compatibilidade do X (http://www.xfree.org/4.2.1/Status.html) ela talvez funcionasse com o driver “trident” (aparece como não testado) que me daria um melhor desempenho, mas não funcionou.

A placa também funciona usando 16 bits de cor com o driver vesa, mas as cores ficam trocadas, talvez por defeito na placa. Também precisei configurar o mouse serial, ligado na COM1.

No final, a configuração no arquivo /opt/ltsp/i386/etc/lts.conf ficou assim:

Os últimos segredos estavam no próprio setup da placa. Tive que ativar o cache L1 e L2 (o padrão nesta placa é eles ficarem desativados!) e ativar o Video Bios Shadow. Esta opção não tem efeito se você estiver usando um driver adequado para a placa de vídeo, mas ao utilizar o driver vesa genérico a própria placa fica responsável por processar as instruções, fazendo com que a ativação do Video Bios Shadow chegue a representar um desempenho de mais de 100% para a velocidade do vídeo.

Sem o cache e sem o Video Bios Shadow o desempenho desse micro era ridículo, ele demorava mais de 5 segundos pra montar uma tela, mas depois das alterações ele ficou brutalmente mais rápido, o suficiente para fazer algo útil.

Em geral, vale bem mais à pena usar placas um pouco mais novas, que já tenham pelo menos slots PCI. Mas, colocar essas porcarias velhas pra funcionar não deixa de ser um passatempo :-p.

Se você não quiser ter dor de cabeça, outra opção seria usar micros novos. Uma placa mãe barata, com vídeo onboard, 64 MB de RAM e um processador o mais barato possível vai dar um excelente terminal. Como os terminais utilizam poucos recursos, mesmo placas instáveis como as 810 e 812 não devem causar problemas. Como você não vai precisar de HD nem CD-ROM (e nem disquete se você gravar as EPROM’s das placas de rede), cada terminal pode chegar a custar menos de 600 reais (sem monitor).

E, se você ainda está achando complicado, pode dar uma olhada neste vídeo, onde uma menininha de 14 anos do projeto K12LTSP monta um terminal em menos de 2 minutos!:

http://www.riverdale.k12.or.us/linux/flexpc.ram

Dando uma olhada na lista de preços do navenet.com encontrei algumas coisas baratas que poderiam ser usadas:

• 11685 PROC. C3-700 MHZ VIA SAMUEL (MB P3). 21,00
• 39662 MB S3.FC INTEL D810/9WMV S/V/F/L -NRE D8109WMV S/V/F/R. 21,00
• 42992 PROC. DURON 1.3 AMD OEM DURON 1.3 OEM. 34,00
• 44210 MB S4. 810DLMR SOM/VGA/FAX/LAN -XP 810D 841. 49,50
• 25433 MEM. DIMM 64 MB PC133 ORIG. BRAND SDRAM 64MB 133B. 13,00

Quase sempre aparecem alguns componentes relativamente antigos por um preço baixo, um C3 mais a placa mãe e 64 MB de RAM por exemplo custaria apenas 65 dólares!. Comprando uma placa com video e rede onboard só fica faltando mesmo o pente de memória, gabinete e, se for necessário, o drive e disquetes. No total este exemplo custaria uns 450 reais por terminal, incluindo os 25% que você pagaria para alguém trazer até aqui. Mesmo comprando um monitor de 17′, um teclado bom e um mouse óptico ainda sairia um pouco mais barato do que comprar um PC “completo” dos mais simples.

A principal economia neste caso não seria com o equipamento em sí, mas com a manutenção da rede. Usando componentes novos os terminais quase nunca vão dar problemas, a manutenção vai se restringir ao servidor. Usando hardware de qualidade ele também raramente vai dar problemas, fazendo com que o trabalho se concentre mais em ajudar e orientar os usuários ao invés de ficar arrumando paus nos micros.

Lembre-se que você pode rodar muitos aplicativos Windows através do Wine (gratuito) ou do Cross-over-office (US$ 59). A lista inclui uma grande partes dos softwares educacionais em CD-ROM e também muitos aplicativos profissionais. Você pode encontrar dicas de como rodar vários programas populares no: http://www.frankscorner.org/.

Os aplicativos Windows instalados no servidor também ficam automaticamente disponíveis para as estações.

Mais dúvidas e exemplos práticos

” Li seu artigo sobre o uso de terminais leves no Kurumin e fiquei muito interessado. Eu e um amigo desenvolvemos um software escrito em Turbo Pascal e com interface grafica e acesso a mySQL, que atualmente roda em estações DOS com boot remoto via uma rede Novell. Já fizemos a transposição do software para Free Pascal para Linux. Pretendemos sair da rede Novell por problemas com licenças de software. A intenção é migrar tudo para Linux. O programa roda a partir do console, não necessitando de servidor X, ele tem uma biblioteca grafica compilada no executável. Minha dúvida é como fazer com que os terminais façam login automáticamente no servidor ,sem a interface grafica KDE e disparem automaticamente o aplicativo em Free Pascal.A idéia é ter 50 terminais do tipo Pentium 200, 16MB RAM e todos vão rodar o mesmo aplicativo, acessando a mesma base de dados no mySQL. É um terminal dedicado a um só programa. Acho que um servidor Athlon 1700 com 1GB de memória RAM seria o suficiente, de acordo com o seu artigo no site. Sou um novato em Linux, estou migrando de um ambiente que conheço bem, que é Novell/Windows-SQL para algo novo e estou tateando no escuro.

Para fazer com que o terminal com o sistema seja aberto automáticamente basta colocar um atalho para ele dentro da pasta .kde/Autostart, dentro do diretório home do login usado (caso você esteja usando o KDE nas estações) ou adicionar o comando no arquivo .xsession, também dentro do diretório home (caso você esteja usando o IceWM ou outro gerenciador). O comando para fazer pipocar um terminal já com o aplicativo aberto seria “xterm -e programa” ou “konsole -e programa“.

Se você não quiser mesmo usar um desktop gráfico, mas apenas uma tela de texto puro e simples, existe a opção de mudar o runlevel das estações de 5 para 4 dentro do arquivo /opt/lts/i386/etc/lts.conf. A linha ficaria assim:

Isso faz com que as estações passem a apenas abrir uma seção telnet do servidor ao invés do modo gráfico. Para funcionar você deve instalar também o pacote “telnet-server” no servidor. Mas, eu ainda acho bem melhor usar o modo gráfico, pois permite abrir mais de um terminal se necessário e a resolução mais alta faz com que caiba mais texto dentro da janela do terminal. Você pode castrar o menu iniciar e eliminar outros programas, de modo que os usuários não tenham como ficar abrindo outros aplicativos.

Esta semana implantei uma rede de terminais leves com o Kurumin na PassagemExpressa, uma empresa de venda de passagens Rodoviárias e Aéreas (você pode comprar com eles quando for viajar, eles entregam em casa: http://www.passagemexpressa.com.br

O sistema é um site web que pode ser acessado a partir de qualquer navegador, também existiam alguns arquivos do Word e Excell que podem ser abertos sem muitos problemas no OpenOffice. Apesar das necessidades serem simples, eles teriam que gastar mais de 15 mil reais em software se fossem comprar Windows e Office para todas as estações. Um custo simplesmente inaceitável.

O primeiro passo foi colocar uma máquina com o Coyote compartilhando a conexão. Antes eles usavam um proxy instalado em um dos micros, que (da forma como estava configurado) além de não ser muito seguro só oferecia acesso via http. Por sinal, descobri um problema com a versão 2.2.0 do Wizard for Windows, o disquete criado por ele simplesmente não funciona. Você pode usar a versão 2.0.4 ou, melhor, usar o Wizard do Linux que oferece mais opções.

A rede possui um total de 8 micros, a migração foi feita “a quente” durante um dia normal de trabalho, sem interroper as atividades normais. Primeiro configurei o servidor, criando os logins de usuário, instalando o OpenOffice e fazendo algumas personalizações necessárias. Uma dica é que se você for criar vários usuários, pode fazer as alterações direto na pasta /etc/skel, ela é o modelo que é copiado para a pasta /home ao criar o usuário. Mudando direto na fonte, as alterações já vão para todos os usuários criados posteriormente.

Depois que o servidor estava pronto, foi só criar uma pilha de disquetes para as estações e ir configurando uma por uma, dando boot com o disquete, anotando o endereço MAC, adicionando o endereço no /etc/dhcp3/dhcpd.conf no servidor, junto com a configuração do mouse e vídeo no /opt/ltsp/i386/etc/lts.conf. A configuração de cada estação é rápida, um dos funcionarios ia fazer outra coisa, eu configurava a estação dele a na volta explicava o que havia mudado no sistema. A interface básica para eles é o programa via Web, que continua igual em qualquer sistema.

O dono preferiu trocar as placas rede por um monte Realtek’s 8139, todas iguais para facilitar a adiministração. Fora isso o unico gasta com hardware foram mais alguns drivers de disquete nas estações. No final houve *economia*, pois ficaram sobrando vários HDs.

A maioria das empresas trabalha desta forma, um único sistema que roda em todos os micros. Se for posível portar o sistema, roda-lo através do Wine, ou já estiver endo usado um sistema em php ou asp acessado através do navegador, então a solução dos terminais vai com certeza diminuir muito não so os custos com software, mas o custo de manutenção a longo prazo, que acaba sendo o principal benefício. Apenas um micro para configurar, apenas um micro pra fazer backup, etc.

Outro detalhe interessante é que a migração não precisa ser traumatica, com HDs sendo formatados, usuarios tendo que se adaptar na marra aos novos programas, etc. O terminais passam a trabalhar como terminais apenas quando são bootados com o disquete ou via PXE. Isto significa que não é preciso mudar nada nos HDs.

O LTSP é implantando como uma opção. Com o disquete no drive o micro dá boot através do servidor e sem ele o usuário tem acesso ao sistema antigo que está instalado no HD. Depois de tudo implementado você pode ir treinando e tirando as duvidas dos usuários e assim ir retirando gradualmente os HDs das estações e aparando as areastas que restarem.

O Flávio Moreira postou outro caso parecido no fórum:

Instalação LTSP :

1) Servidor : Pentium III / 650 MHz – 256 MB RAM. À direita, no-break, switch Encore 16 portas, Modem ADSL 3Com DualLink convertido para Router

2) Estação : Pentium 133MHz / 16 MB RAM. Conseguimos de graça – somente o monitor é novo

3) Pessoal trabalhando com o Kurumin (Não o tempo todo, quando querem usar o Kurumin é dado o boot por disquete.) Alias, como todas as placas são SiS900 onboard, temos apenas um disquete comunitário.

Você pode ler mais dicas e postar suas dúvidas neste topico do fórum:

http://www.guiadohardware.info/forum/viewtopic.php?t=674