Se você leu este capítulo com atenção desde o início, já teve acesso a mais informações sobre o uso de aplicativos remotamente do que muitos administradores de sistema. Vamos aproveitar então o final deste capítulo para ver uma abordagem prática sobre a configuração de uma rede de terminais leves e tirar as dúvidas que você possa ainda ter.
Hoje em dia é possível comprar placas de rede 10/100 por menos de 30 reais e, com o barateamento dos novos padrões, estes preços não voltarão a subir. Com as redes tão baratas, aplicações que estavam fora de moda, como os terminais diskless, terminais gráficos, etc. voltaram a ser atrativas.
Os PCs continuam relativamente caros, mas a banda de rede está muito barata. Com isto, começa a fazer sentido aproveitar PCs antigos, transformando-os em terminais de PCs mais rápidos. Com uma rede bem planejada, um único Pentium 4 ou Athlon pode servir 5, 10, 20 ou até mesmo 40 terminais 486/Pentium (como já tive notícias) e com um desempenho muito bom, já que os aplicativos rodam no servidor, não nos terminais.
A grande vantagem é a economia de custos. Para montar um laboratório com 10 PCs novos, ligados em rede, você gastaria pelo menos 16.000 reais, fora a mão de obra. Usando um servidor e 10 terminais 486 você poderia gastar menos de 4500 reais (fora mão de obra), presumindo que comprasse cada 486 por R$ 200. O desempenho nos terminais porém não será o de um 486, mas sim o de um Pentium 4 ou Athlon. Esta solução é muito útil também em “ambientes hostis”, como terminais de acesso público, já que um 486 custa muito menos para ser substituído do que um PC novo. Você também pode incluir mais terminais caso necessário a um preço muito baixo, aproveitando o mesmo servidor.
O custo de administração da rede também é atrativo, pois as configurações e arquivos ficam concentradas no servidor, facilitando a manutenção e os backups. Você pode criar uma instalação padronizada para os clientes e simplesmente copiá-la para todas as máquinas usando o dd ou o g4u (como veremos adiante). Se algum dos clientes der problemas, o usuário simplesmente usa outro.
Todas as soluções que apresentarei a seguir são baseadas no Linux. A Microsoft oferece uma solução para terminais, chamada Windows Terminal Server. A eficiência também é boa, mas é inviável por causa do custo do software, já que além da licença do servidor, é preciso pagar por mais uma licença para cada terminal. No final, os custos do sistema da Microsoft são parecidos com os de simplesmente trocar todos os micros. Não é à toa que esta solução é tão pouco usada… Não abordarei esta solução aqui pois não considero uma opção vantajosa.
Como vimos, existem quatro formas de rodar aplicativos remotamente:
1- Via VNC, numa estação com o Windows ou Linux instalado.
2- Rodando aplicativos via SSH ou Telnet, numa estação com Linux ou Windows.
3- Rodando toda a interface gráfica apartir do servidor, numa estação com Linux.
4- Usando o Etherboot para criar estações diskless, que baixam todo o software apartir do servidor.
O VNC é interessante para máquinas que rodam Windows, pois permite misturar programas das duas plataformas. Mas, em compensação, ele também é mais pesado, tanto para o cliente quanto para o servidor, e consome mais banda da rede. Com uma rede de 10 megabits e um 233 MMX você já poderá usa-lo confortavelmente, mas para ter realmente a mesma velocidade de atualização de tela que teria sentado na frente do servidor, você precisaria de uma rede de 100 megabits. Já expliquei com detalhes a configuração e uso do VNC, você pode consultar as páginas anteriores.
Outra solução é usar o SSH ou Telnet para rodar aplicativos remotamente. Se o cliente rodar Windows é possível apenas rodar aplicativos de modo texto ou utilizar o MixServer ou WinXe para rodar também aplicativos gráficos, mas se o cliente também rodar Linux é possível rodar diretamente qualquer aplicativo gráfico instalado no servidor, sem precisar de software adicionais. A vantagem neste caso é que você pode misturar aplicativos locais e remotos. Esta é a solução ideal caso você tenha estações Linux com uma configuração razoavelmente atual.
Via SSH também é possível carregar toda a interface gráfica apartir do servidor e rodar todos os programas a partir dele (como também expliquei anteriormente). Este seria o próximo nível, que poderia ser usado se você tiver um monte de terminais 486 com 12 ou 16 MB de RAM, mas com pelo menos 200 ou 300 MB de espaço em disco para uma instalação mínima do Linux. Neste caso é possível configurar as estações para abrir diretamente na tela de Login do servidor, dispensando o uso do SSH.
Finalmente, se as estações não tiverem sequer HD, você pode configurá-las para dar boot através da rede, usando um disquete ou a ROM da placa de rede. Neste caso elas baixarão todo o software apartir do servidor. Esta é a solução mais trabalhosa e a menos flexível, mas a que exige menos hardware nas estações.
Falando assim, até parece que o assunto é complicado, mas tenha em mente que não é. Se você tentar colocar estas idéias na prática, vai ver como é algo bastante simples. Vamos então aos detalhes:
Configuração do servidor: Além da penca de placas de rede, o servidor precisa ter uma configuração razoável, já que vai rodar vários aplicativos diferentes e ao mesmo tempo.
O mínimo recomendável para um bom desempenho seria um Pentium III, Celeron ou Duron de 600 MHz, 128 MB de RAM e mais 32 MB para cada cliente, além de um HD razoavelmente rápido e uma placa mãe com 6 slots PCI, de preferência com uma placa de vídeo AGP (ou onboard) para não ocupar nenhum dos slots PCI. Claro que um processador mais rápido seria muito bem vindo. Para 10 clientes o ideal seria usar um Athlon ou Pentium 4 com 512 MB. Não deixe também de monitorar o uso de memória RAM no servidor e fazer um upgrade sempre que necessário.
A placa de vídeo pode ser qualquer uma suportada pelo Linux embora, segundo o Wooky, usar uma GeForce 2 ou GeForce 3 com os drivers oficiais da Nvidia permite que você execute aplicativos 3D (inclusive jogos) nas estações com aceleração 3D, feita pelo servidor. Os jogos 3D não seriam muito interessantes, já que via rede a velocidade de atualização da tela não é suficiente para mais do que dois ou três FPS em tela cheia, mas é uma mão na roda se você pretender rodar algum aplicativo gráfico com suporte a OpenGL.
O HD também deve ter espaço suficiente para guardar todos os arquivos pessoais dos usuários. O servidor também não vai precisar de um monitor, pois depois de configurado você poderá acessar as configurações a partir de qualquer terminal. Nada impede entretanto que você use o próprio servidor como mais um terminal, já que com o usuário logado no sistema como um usuário normal (jamais deixe que utilizem a conta root neste caso) terá pouca chance de fazer barbeiragens no sistema.
Depois de planejar a rede e montar o servidor, falta montar a rede e instalar o Linux no servidor. Você pode tirar as suas dúvidas sobre o cabeamento da rede aqui:
Você pode utilizar qualquer distribuição Linux mas, se você é iniciante, ou não está muito a fim de ficar perdendo tempo eu recomendo o Mandrake, que é atualmente o mais simples de configurar.
Com o sistema instalado, você ainda precisará configurar as placas de rede. A forma menos problemática de fazer isso é instalar o sistema com apenas uma placa e adicionar mais uma placa a cada reinicializarão. O Kudzu detectará as novas placas a cada boot, terminado você ainda precisará configurar os endereços IP de cada uma.
No Mandrake você pode fazer isso através do Mandrake Control Center > Rede & Internet > Conexão. Você verá uma lista com todas as placas de rede instaladas no sistema. Clique em “Configurar” para abrir o Wizzard que permitirá que especifique o endereço IP a ser usado por cada uma.
Lembre-se que se uma placas placas de rede estiver sendo usada para conectar à Internet (ADSL, cabo…) ela deverá ser configurada com o endereço fornecido pelo provedor, ou com a opção “bootop/DHCP”, não com o endereço de rede local.
Na etapa final você deverá especificar o nome do host, o servidor DNS e o Gateway para acesso à Web e qual das placas de rede está conectada ao Gateway. No nosso exemplo seria a eth0.
Se você tiver uma conexão via ADSL ou cabo, os dois campos deverão ser preenchidos com os dados fornecidos pelo provedor e o dispositivo de gateway será a placa de rede conectada ao ADSL/Cable Modem. Se o servidor está acessando através de uma conexão compartilhada por outra máquina, os dois campos devem ser preenchidos com o endereço IP do servidor de conexão (192.168.0.1 se for uma máquina Windows compartilhando a conexão através do ICS).
Logo abaixo você verá o utilitário para compartilhar a conexão com a Internet, mas no nosso caso ele não é necessário, pois o único que acessará a Web será o servidor. Os terminais apenas mostram a janela do Browser, montada por ele.
Estas instruções se aplicam ao Mandrake e ao Techlinux. Se você estiver usando o Conectiva ou o Red Hat você deverá fazer a configuração através do Linuxconf. No Slackware use o “netconfig”.
Como o servidor será acessado por vários usuários, outro detalhe importante é estabelecer que apenas o root poderá reiniciar o sistema. Para isso, abra o Kcontrol com permissões de root (kdesu kcontrol num terminal) e acesse a seção Sistema > Gerenciador de login > Sessões
Esta é a configuração básica do servidor. Daqui pra frente, as configurações necessárias variam de acordo com o meio de acesso escolhido. Basta colocar em prática as instruções das páginas anteriores, ativando o servidor SSH ou configurando o servidor para fornecer a tela de login.
Outro detalhe importante é que você deve orientar os usuários a desligarem os clientes localmente, pressionando Ctrl + Alt + F6 para mudar para o terminal de modo texto local e em seguida Ctrl + Alt + Del para finalmente desligarem o terminal. Como o KDE (ou o que estiver usando) roda no servidor, não haverá nenhum ícone que permita desligar o cliente. Justamente por isso até desativamos a possibilidade dos usuários desligarem o servidor remotamente, caso contrário sempre um ou outro iria se confundir e desligar o servidor ao invés de desligar seu terminal 😉
Uma outra abordagem razoavelmente segura que você pode adotar ao usar terminais leves, é usar o sistema de arquivos ReiserFS nos clientes, já que ele oferece uma boa tolerância contra desligamentos incorretos e simplesmente orientar os usuários a desligarem os terminais no botão. Como os clientes não estarão rodando nenhum aplicativo importante, apenas a seção remota do X, a possibilidade de ter problemas usando um sistema robusto como o ReiserFS é pequena, na maioria dos casos um risco aceitável já que mesmo que houvesse qualquer problema bastaria reinstalar o sistema. Fica a seu critério qual das duas opções adotar.
Um exemplo: Tenho um notebook IBM Thinkpad 560, um Pentium 133 com 16 MB de RAM e um HD de 1 GB. Não é difícil fazer uma instalação enxuta do Slackware que rode nesta máquina, mas com 16 MB de RAM o desempenho é sofrível.
Como tenho na minha rede três máquinas mais rápidas configuradas como servidores XDM e quase sempre pelo menos uma das três está ligada, resolvi transformar o notebook num terminal burro, que ao inicializar exibe a lista dos servidores disponíveis e me permite logar e utilizar qualquer um deles.
Para configura-lo, comecei fazendo uma instalação compacta do Slackware 8.1. Aproveitei para deixar o servidor de FTP ativado, assim eu posso utilizar o restante do espaço vago no HD para fazer backup e transportar dados.
Depois de configurar o X e a rede, foi preciso apenas alterar os arquivos de inicialização para que o Slackware inicializasse direto em modo gráfico (editando o /etc/inittab) e obtendo a tela de login do servidor (editando o /etc/rc.d/rc.4)
Veja que no meu caso tenho três máquinas que podem ser usadas como servidores, sempre pelo menos uma está ligada, mas nem sempre a mesma. Sendo assim, eu não posso usar o comando “X -query IP”. Eu também quero ser capaz de escolher qual máquina usar caso mais de uma esteja ligada, o que descarta o uso do comando “X -broadcast”, onde ele simplesmente obteria a tela de login da primeira máquina que respondesse, sem me dar a chance de escolher.
A solução no meu caso foi incluir a linha:
/usr/X11/bin/X -indirect 192.168.0.0
Assim ele envia o pacote de broadcast pedindo a lista dos servidores disponíveis para todas as máquinas da rede. Assim, não importa quais dos três servidores estejam ligados, o notebook consegue obter a listagem e me permite escolher qual utilizar:
Eu poderia utilizá-lo inclusive em outras redes que utilizassem a faixa 192.168.0. onde existissem servidores XDM ativos.
Veja também
Sobre o Autor
Deixe seu comentário