LtspTraducaoTati
:: Documentação do LTSP v4.1
por James McQuillan -> jam@LTSP.org
Tradução de Gravim (PSL-BA) e Tatiana Wells (MetaReciclagem.org)
Copyright © 2004 by James A. McQuillan
GNU/Linux é uma excelente plataforma para acionar terminais leves sem disco rígido. O propósito deste documento é mostrar como fazer isto, usando a tecnologia LTSP. Além disso, este documento trata de muitos outros tópicos a respeito de estações sem disco rígido.
Última revisão:
Revisão 4.1.3-en
2004-06-20
Revisado por: jam
Sumário
Introdução
1.. Disclaimer
1.. Copyright e Licença
Capítulo 1. A Teoria da Operação
#.1. Os passos que as estações de trabalho (clientes) seguirão
1.2. Rodando o kernel de dentro da memória
1.2.1 Boot ROM
1.2.2 Mídia local
Capítulo 2. Instalando o LTSP no servidor
2.1. Instalando os utilitários do LTSP
2.1.1. Instalando o pacote RPM
2.2 Instalando os pacotes TGZ
2.2 Instalando os pacotes do cliente LTSP
2.3 Configurando os serviços necessários para o LTSP
2.4. Configuração específica da estação de trabalho
2.5. Visualizando as configurações atuais
Capítulo 3. Configurando a estação de trabalho (o cliente)
3.1. Dando o boot com PXE
3.2. Dando o boot com Etherboot
Capítulo 4. Rodando as estações de trabalho
Capítulo 5. Imprimindo
5.1. Configuração de cliente
5.2. Configuração de servidor
Capítulo 6. Scripts de tela
Capítulo 7. Desproblematizando
7.1. Desproblematizando a imagem de disquete Etherboot
7.2. Desproblematizando DHCP
7.3. Desproblematizando TFTP
7.4. Desproblematizando o sistema de arquivos raiz NFS
7.5. Desproblematizando o servidor X
7.6. Desproblematizando o gerenciador de interface gráfica
Capítulo 8. Kernels
8.1. Padrões de kernels LTSP disponíveis
8.2. Cosntrua o seu próprio kernel
Capítulo 9. Entradas lts.conf
9.1. Exemplo de arquivo lts.conf
9.2. Parâmetros lts.conf disponíveis
Capítulo 10. Applicativos locais
10.1. Vantagens de se rodar aplicativos localmente
10.2. Considerações ao configurar suporte à aplicativos locais
10.3. Configuração de servidor para aplicativos locais
10.4. Configuração de aplicativos
10.5. Ativando aplicativos locais
Capítulo 11. Exemplos de configuração
11.1. Mouse serial
11.2. Mouse PS/2
11.3. Impressora USB em um ThinkNic
11.4. Forçando uma estação de trabalho a rodar o servidor X XFree86 3.3.6
Capítulo 12. Outras fontes de informação
12.1. Referências online
12.2. Publicações Impressas
Introdução
O que é LTSP?
LTSP (Linux Terminal Server Project) é um conjunto de soluções que oferece serviços para clientes sem disco rígido em suas máquinas. Ele dispõe de um meio simples para utilizar estações de trabalho tanto no modo gráfico quanto no modo texto.
Os criadores do LTSP acham sem sentido ter computadores desktops completos. Por isso desenvolveram uma solução (composta por um conjunto de outras) que assiste a clientes variados - assim como não exige que estes sejam máquinas com alto poder de processamento. A utilização de computadores-sucatas (DX4, pentium, pentium MMX, celeron, k-5, k-6, etc. numa frequência entre 66 e 300 MHz) nos clientes é viável. Utiliza-se a placa de rede para o boot, o que dispensa disco rígidos, disquetes, CD-ROM´s, etc. - apesar de suas exclusões não serem necessárias.
Durante o boot, os clientes obtêm seus endereços de IP e kernel do servidor e depois o sistema de arquivo é montado via NFS, também através do servidor.
Há três possibilidades de configuração do LTSP:
Interface Gráfica com o X Window System Pode-se acessar qualquer aplicação no servidor, ou em outros servidores que estejam na rede, através do X Window.
Modo caracter baseado em sessões Telnet
O cliente pode solicitar múltiplas sessões Telnet ao servidor. Estas sessões são alternadas através das teclas Alt+F1 até Alt+F9.
Shell prompt
A estação de trabalho pode ser configurada para ir direto pro console.
O interessante do LTSP é que você pode ter vários clientes em apenas um servidor Linux. A quantidade de clientes vai depender do número de servidores e das aplicações que serão usadas.
1. Disclaimer
Nem o autor nem os distribuidores, ou algum contribuinte tem nunhuma tipo de responsabilidade por danos físicos, financeiros, ou morais ou qualquer outro tipo dos danos ocorridos seguindo as sugestões neste texto.
2. Copyright e Licença
Este documento possui o copyright 2004 por James McQuillan, e é liberado sob os termos da licença GNU Free Documentation License, que é portanto incorporado como referência.
Capítulo 1. A Teoria da Operação
Há vários passos que envolvem a inicialização dos clientes. Entendendo o que acontece fica mais fácil resolver os problemas.
São quatro serviços básicos que o LTSP usa:
DHCP
TFTP
NFS
XDMCP
Como o LTSP é muito flexível você pode rodar estes serviços de diferentes servidores ou até mesmo todos num só. Imaginemos apenas um servidor. São estas as etapas percorridas pelos clientes:
1.1. Os passos que as estações de trabalho (clientes) seguirão
1. Carregar o kernel do Linux na memória do cliente. Pode ser feito de várias formas, inclusive:
Bootrom (Etherboot, PXE, MBA, Netboot)
Disquete
Disco rígido
CD-ROM
Cartão de memória via USB
Cada um desses métodos será explicado posteriormente nesse capítulo.
2. Após carregar o kernel ele começará sua execução.
3. O kernel inicializará o sistema inteiro e todos os periféricos que ele reconhecer.
4. Durante o processo de carregamento do kernel, será rodado um disco virtual (ramdisk) também na memória. Este disco virtual será montado como o diretório raiz "/" através da linha de comamdo root=/dev/ram0 do kernel.
5. Quando o kernel de inicialização terminar, será rodado o programa init. No LTSP, o kernel foi instruído para ler um pequeno script do shell. Para isso foi passado init=/linuxrc na linha de comando do kernel.
6. O script /linuxrc começa a fazer uma verredura do PCI bus procurando pela placa de rede. Para cada dispositivo PCI que ele encontrar, ele verifica no arquivo /etc/niclist para checar a sua ocorrência neste. Quando encontrado, o nome do módulo de driver NIC é retornado e o módulo do kernel é lido. Já nas placas ISA, o módulo do driver PRECISA ser especificado na linha de comando do kernel assim com os parâmetros de endereço ou IRQ que poderão ser necessários.
7. Um pequeno cliente de DHCP chamado dhclient será rodado e fará outra requisição do servidor DHCP. Esta requisição foi feita separadamente porque eram necessárias mais informações do que as recebidas do bootrom, com a primeira requisição do servidor DHCP.
8. Quando o dhclient tiver uma resposta do servidor, será rodado o arquivo /etc/dhclient-script que pegará as informações recebidas pelo dhclient e confgurará a interface eth0.
9. Até aqui, o sistema de arquivo raiz tem um disco virtual. Agora o script /linuxrc montará um novo sistema de arquivo raiz através do NFS. O diretório que é exportado do servidor é o /opt/ltsp/i386. Não pode-se simplesmente montar como "/". Primeiro tem que ser montado como /mnt. Depois ele fará um pivot_root que trocará o atual sistema de arquivo raiz por um novo sistema de arquivo. Quando ele terminar, o sistema de arquivo NFS será montado na raiz "/" e o antigo sistema de arquivo raiz será montado em /oldroot.
10. Quando a montagem e a pivotagem do novo sistema de arquivos estiverem concluídas, o trabalho do /linuxrc estará feito e precisaremos solicitar o programa /sbin/init.
11. O init lerá o arquivo /etc/inittab e comçará a configurar o ambiente da estação de trablho (cliente).
12. Uma das primeiras coisas que o arquivo inittab faz é ler o comando rc.sysinit que rodará enquanto o cliente estiver no estado "sysinit".
13. O script rc.sysinit criará 1MB de disco virtual para conter tudo que precisará ser escrito (ou modificado).
14. O disco virtual será montado como o diretório /tmp. Quaisquer arquivos que precisar serem escritos irão realmente existir no diretório /tmp e terão links simbólicos (symbolic links) apontando para eles.
15. O sistema de arquivo /proc é montado.
16. O arquivo lts.conf será analisado (parsed) e todos os parâmetros nesse arquivo que pertençam à essa estação de trabalho serão configurados com variáveis do ambiente para o script rc.sysinit usar.
17. Se a estação de trabalho for configurada para fazer swap (swap over) no NFS, o diretório /var/opt/ltsp/swapfiles será montado como /tmp/swapfiles. Mas se não tiver um arquivo de troca (swapfile) para essa estação de trabalho ainda, será criado automaticamente. O tamanho dos swapfiles é configurado no arquivo lts.conf.
O swapfile será ativado usando o comando swapon.
18. A interface de rede loopback é configurada. Essa é a interface de rede que tem o endereço de IP 127.0.0.1.
19. Se aplicações locais estão ativadas, o diretório /home será montado para que as aplicações tenham acesso ao /home dos usuários.
20. Muitos diretórios são criados no arquivo de sistema /tmp para segurar alguns arquivos de trânsito que são necessários enquanto o sistema está rodadno. Os diretórios abaixo serão criados.
a. /tmp/compiled
b. /tmp/var
c. /tmp/var/run
d. /tmp/var/log
e. /tmp/var/lock
f. /tmp/var/lock/subsys
21. O arquivo /tmp/syslog.conf será criado. Esse arquivo conterá informações sobre o deamon syslogd que se hospedará na rede para enviar a informação de login. O host syslog está especificado no arquivo lts.conf. Há um link chamado /etc/syslog.conf qua aponta para o arquivo /tmp/syslog.conf.
Original do item 21: " The /tmp/syslog.conf file will be created. This file will contain information telling the syslogd daemon which host on the network to send the logging information to. The syslog host is specified in the lts.conf file. There is a symbolic link called /etc/syslog.conf that points to the /tmp/syslog.conf file."
22. O deamon syslogd é iniciado usando o arquivo de configuração criado no item 21.
23. Uma vez que o script rc.sysinit é rodado, é retornado ao programa /sbin/init que mudará o runlevel do sysinit para 5.
24. Por default, há no inittab chamadas para rodar o script /etc/screen_session em tty1, tty2 e tty3. Isso significa que pode-se rodar três sessões ao mesmo tempo e que o tipo das sessões é controlado pelas chamadas de SCREEN_01, SCREEN_02 and SCREEN_03 no lts.conf.
Original do item 24: A palavra "entries" foi traduzida como "chamadas".
25. Se o SCREEN_01 está configurado como startx, o script /etc/screen.d/startx será executado. Ele rodará o X Window Sysytem oferecendo-lhe uma interface gráfica.
No arquivo lts.conf, tem um parâmetro chamado XSERVER. Se estiver faltando este parâmetro ou começarão esiver "auto" em seu lugar, ocorrerá uma tentativa de detecção automática da placa de vídeo.Se a placa for PCI ou AGP, ele pegará o fabricante e o seu identificador dela (Vendor and Device id) e procurará no arquivo /etc/vidlist.
Se Xorg 6.7 assistir a placa, a rotina pci_scan retornará o módulo do seu driver. Se ela for assitida apenas pelo XFree86 3.3.6, pci_scan retornará o nome do servidor X a ser usado. O script startx
Original do item 25: A palavra "suported" foi traduzida como asistir e "driver module" como "módulo de driver".
26. Se o Xorg for usado, o script /etc/build_x4_cfg será chamado para criar um arquivo XF86Config. Se o XFree86 3.3.6 for usado, então o script será chamado para criar o arquivo XF86Config. Estes arquivos são colocados no diretório /tmp que, se você se lembrar, é um disco virtual visto apenas pela estação de trabalho.
O arquivo XF86Config será criado baseado nas chamadas do arquivo /etc/lts.conf.
27. Uma vez criado o arquivo XF86Config então o script startx rodará o servidor do X como este novo arquivo de confuguração.
28. O servidor do X enviará uma requisição XDMCP ao servidor LTSP, que oferecerá uma tela de login (login dialog).
29. Agora, o usuário poderá logar. Eles pegarão uma sessão do servidor.
Isso confunde muitas pessoas no começo. Eles estão numa estação de trabalho, mas rodando uma sessão no servidor. Todos os comandos que eles rodarem serão rodados no servidor, mas a saída será mostrada na sua estação de trabalho.
1.2. Rodando o kernel de dentro da memória
Para rodar o kernel do Linux nas memórias das estações de trabalho existem vários meios.
Boot ROM
Mídia local
1.2.1 Boot ROM
Etherboot
Etherboot é um projeto bootrom muito popular de código aberto. Ele contém drivers de muitas placas de rede e trabalha muito bem com o LTSP.
O kernel do Linux tem que ser marcado (tagged) com o mknbi-linux, que irá preparar o kernel para o boot em rede colocando no kernel alguns códigos adicionais e adicionando o initrd para o fim do kernel.
Os kernels que já foram fornecidos pelo LTSP são marcados e estão prontos para dar o boot pelo Etherboot.
Etherboot também pode ser escrito num disquete, que é ideal para testes.
PXE
Parte da especificação do "Wired for Management", que vem tardiamente das anos 90, incluiu uma espeficicação para a tecnologia de bootrom conhecida como o Pre-boot Execution Environment abreviada como PXE.
Um bootrom PXE pode rodar, em sua maioria, um arquivo de 32 Kbytes. Um kernel do Linux é maior, então nós configuramos o PXE para ler um 2o. estágio do boot-loader (a 2nd stage boot-loader) chamado pxelinux. Ele é pequeno suficiente para ser carregado e ele sabe como rodar muitos arquivos grandes, como o kernel do Linux.
MBA
MBA (Managed Boot Agent) é um bootrom de uma empresa chamada emBoot. Ela foi uma divisão da 3Com. MBA é realmente 4 boots em 1. Ele abrigará PXE, TCP/IP, RPL e Netware.
A implementação de PXE trabalha bem. Você pode usá-la com pxelinux para dar boot em um kernel Linux.
O método TCP/IP pode ser usado, mas o kernel primeiro precisa estar preparado com um utilitário chamado imggen.
Netboot
O Netboot, assim como o Etherboot, é um sotware livre que oferece gratuitamente imagens de boot ROM. A diferença é que ele é um evoltório em torno do driver NDIS ou pacotes de drivers que enviam com as placas de rede.
Orignal do Parágrafo acima: " Netboot, like Etherboot, is a free software project that provides free boot ROM images. The difference is that it is a wrapper around the NDIS driver or packet drivers that ship with the network cards."
1.2.2 Mídia local
Disquete
Há duas maneiras de boot para uma estação de trabalho LTSP. Uma é carregar o Etherboot no setor do disquete. Então, ele agirá simplesmente como um bootrom. O código do boot será excutado, aplaca de rede será inicializada e o kernel será carregado do servidor.
Você também pode gravar o kernel e o initrd em um disquete e dar o boot. Entetanto, é realmente mais rápido carregar o kernel pela rede.
Disco Rígido (HD)
O disco rígido pode ser usado com o LILO ou GRUB para carregar o kernel do Linux e o initrd. Ou, você pode ler uma imagem Etherboot bootrom do HD e ele agirá como um bootrom.
CD-ROM
Um CD-ROM bootável pode ser carregado com um Linux kernel ou uma imagem Etherboot.
Dispositivo de Memória USB (Memory Keys)
Assim como um CD-ROM, disquete e HD, você pode usar um dispositivo de memória USB para dar o boot tanto um módulo Eherboot ou um completo kernel do Linux e a imagem initrd.
Capítulo 2. Instalando o LTSP no servidor
É melhor pensar no LTSP como uma completa distribuição Linux. É uma distribuição que está em cima de uma distribuição do servidor. Esta pode ser qualquer distribuição Linux que você desejar. Na verdade, não precisa ter necessariamente o Linux no servidor. O único pré-requisito é que o sistema operacional do servidor suporte o NFS (Network File System). A maioria dos sistemas UNIX suportam o NFS.
Há três etapas para criar um servido LTSP:
Instalação dos utilitários do LTSP
Instalação dos pacotes dos clientes
Configuração dos serviços necessários para o LTSP
2.1. Instalando os utilitários do LTSP
A versão 4.1 do LTSP tem um pacote de utilitários para a instalação e gerenciamento dos pacotes dos clientes (as coisas que serão executadas nos clientes), e para a configuração dos serviços no servidor LTSP.
O utilitário de administração é o ltspadmin e o das ferramentas de configuração é ltspcfg. Ambos os utilitários fazem parte do pacote ltsp-utils.
O pacote ltsp-utils está disponível nos formatos RPM e TGZ. Escolha qual formato vcoê prefere e siga as intruções adequadas.
2.1.1. Instalando o pacote RPM
Baixe o pacote mais recente do ltsp-utils em RPM e instale-o usando o comando abaixo:
rpm -ivh ltsp-utils-0.1-0.noarch.rpm
O comando acima instalará os utilitários no servidor.
2.2 Instalando os pacotes TGZ
Baixe o pacote mais recente do ltsp-utils em TGZ e instale-o usando o comando abaixo:
tar xzf ltsp-utils-0.1-0.noarch.tgz
cd ltsp_utils
./install.sh
cd ..
O comando acima instalará os utilitários no servidor. Ele é usado para sistemas que não se baseiam no pacote RPM.
2.2 Instalando os pacotes do cliente LTSP
Após instalar a o ltsp-utils, você já pode rodar o comando ltspadmin. Este utilitário é usado para o gerenciamento dos pacotes dos clientes LTSP. Ele requisitará um download e pegará uma lista dos pacotes atuais.
Origninal: " Once the installation of the ltsp-utils package is complete, you can run the ltspadmin command. This utility is used to manage the LTSP Client packages. It will query the LTSP download repository, and get the list of currently available packages."
Execute o comando ltspadmin e você verá uma tela como esta:
Figura 2-1. Instalador LTSP – Tela principal
Você poderá escolher a opção "Install/Update", e se for a primeira vez que você estiver rodando o programa, ele mostrará uma tela de configuração do instalador.
Figura 2-2. Instalador LTSP installer – Tela de configuração
Nesta tela você pode configurar muitas coisas que o instalador usará para baixar e instalar os pacotes do LTSP. Aqui estão:
Where to retrieve packages from (De onde você quer obter os pacotes)
Isto é uma URL apontando para onde o pacote está. Por default, ele será http://www.ltsp.org/ltsp-4.1, mas você pode instalá-lo a partir de um sistema de arquivo local - você usa o arquivo invés da URL. Pro exemplo, se os pacotes estiverem num CD-ROM e ele estiver montado em /mnt/cdrom, então o valor será: file:///mnt/cdrom. (Atenção com os 3 parênteses).
In which directory would you like to place the LTSP client tree (Em qual diretório você gostaria de colocar a árvore cliente LTSP)
Ele é o diretório no servidor onde você gostaria de colocar a árvore do cliente. Ele será /opt/ltsp. O diretório será criado caso ele não exista.
Dentro desse diretório, os diretórios root para cada arquitetura serão criados. Atualmente, apenas as estações x86 são suportadas pelo LTSP, mas há muitas pessoas trabalhando para suportar outras arquiteturas como PPC e Sparc.
HTTP Proxy (Proxy de HTTP)
Se o servidor estiver atrás de um firewall, e todos os acessos à web precisarem passar pelo proxy, você pode configurar o instalador para usar o proxy aqui. O valor deverá conter a URL para o proxy, incluindo o protocolo e a porta. Um exemplo para essa configuração é: http://firewall.yourdomain.com:3128.
Se você não precisa de um proxy, coloque "none".
FTP Proxy (Proxy de FTP)
Para os pacotes localizados num servidor FTP, se você precisar passar através de um FTP proxy, você coloca-o aqui. A sintaxe é parecida à opção acima do HTTP Proxy.
Se você não precisa de um proxy, coloque "none".
Após passar pela tela de configuração, o instalador requisitará os pacotes e obtém a lista de componentes deisponíveis atualmente.
Figura 2-3. Instalador LTSP – Lista de componentes
Selecione cada componente que você quer instalar. Para selecioná-los, mova a linha branca para aquele componente e clique 'I ' para selecioná-lo. Você também pode clicar em ' A' para selecionar TODOS os componentes. A maior parte do tempo, isso vai ser o que você quer. Dessa forma, você suportará uma grande linha de hardrware de clientes leves.
Existem várias teclas de navegação nesta tela. Você pode obter ajuda sobre estas pressionando a tecla 'H'.
Figura 2-4. Instalador LTSP – Janela de ajuda
Se você quiser olhar a lista dos pacotes que estão num componente particular, pressione 'S' e a lista dos pacotes será exibida. Ele mostrará a versão atual instalada e também a última versão disponível.
Figura 2-5. Instalador LTSP – Lista de pacotes
Uma vez que os componentes forem selecinados, você pode sair da tela de seleção dos componentes. O instalador lhe perguntará se você realmente quer instalar/atualizar os pacotes selecinados. Se você responder 'Y', ele baixará e instalará os pacotes selecionados.
2.3 Configurando os serviços necessários para o LTSP
São quatro os serviços básicos necessários para assistir o boot de uma estação LTSP. Eles são:
DHCP
TFTP
NFS
XDMCP
O ltspcfg pode ser usado para configurar todos esses serviços e mais muitas outras coisas relacionadas ao LTSP.
Você pode acessar o ltspcfg atravé do ltspadmin ou rodar o ltspcfg diretamente digitando-o na linha de comando. Você verá uma tela como essa:
Figura 2-6. ltspcfg – Tela inicial
Ela mostra todas as coisas que o utilitário procura.
Para configurar todas as coisas que precisam ser configuradas, escolha 'C' e o menu de configuração será exibido. No menu de configuração, você precisará navegar em cada item, para ter certeza que ele está configurdo corretamente para servir as estçãos de trabalho do LTSP.
Figure 2-7. ltspcfg – Tela inicial
1 - Runlevel
O Runlevel é a variável usada pelo programa init. Em sistemas Linux e UNIX, sem nenhum tempo dado, é dito ao sistema para ele ficar num "Runlevel" específico. O Runlevel 2 ou 3 é tipicamente usado quando o servidor está em modo texto. O Runlevel 5 tipicamente indica que o sistema está no modo gráfico numa rede.
Para um servidor LTSP, o Runlevel 5 é tradicionalmente usado. A maioria dos sistemas já são configurados para servir NFS e XDMCP no Runlevel 5. Para aqueles sistemas que não estão configurados para isto, o utilitário tomará conta deles.
2 - Interface selection
Para sistemas que têm várias interfaces de rede, você precisará selecionar em qual interface de rede os cliente estão conectados.
Selecionando a interface, a ferramenta de configuração estará apta a criar os arquivos de configuração corretamente, assim como os arquivos dhcpd.conf e /etc/hosts.
3 - DHCP configuration
O DHCP precisa ser configurado para fornecer os campos requisitados peos clientes. Entre estes campos, estão fixed-address (Mac Address) , filename, subnet-mask, broadcast-address e root-path.
Selecionadno este item do menu, você estará apto a criar o arquivo de configuração dhcpd.conf e habilitar o dhcpd para rodar automaticamente quando sua máquina for iniciada.
4 - TFTP configuration
O TFTP é usado pelos clientes para baixarem o kernel do Linux. O tftpd precisa estar rodando no servidor para servir o kernel.
5 - Portmapper configuration
O Portmapper é usado pelos serviços RPC. Cada serviço RPC, assim como o NFS.
6 - NFS configuration
NFS é o serviço que permite as árvores do diretório local serem montadas por máquinas remotas. Ele é necessário para o LTSP porque os clientes montam seus sistemas raízes (root) através do servidor.
Este item cuidará para que o NFS rode após o boot. O arquivo de configuração é o /etc/exports e a sua criação é descrita depois nesta seção.
7 - XDMCP configuration
XDMCP é o "X Display Manager Control Protocol". O servidor X envia uma requisição ao gerenciador de interfaces gráficas no servidor para conseguirem um tela de login.
Os gerenciadores de interfaces gráficas mais populares são XDM, GDM e KDM. Este item mostrará quais gerenciadores de interfaces gráficas foram encontrados e qual foi configurado para rodar.
Por questões de segurança, o gerenciador de interfaces gráficas é configurado por defualt para não permirtir acesso remoto. Esta é geralmente a razão para a tela cinza com cursor X grande. ltspcfg pode geeralmente configurar o gerenciador de interfaces gráficas para permitir acesso remoto para os clientes conseguirem conexão.
8 - Create /etc/hosts entries
Muitos serviços, como NFS e o gerenciador de interfaces gráficas precisam estar aptos a vincular o endereço IP de um cliente ao seu nome. Você pode configurar o Berkeley Internet Naming Daemon (BIND) para fazer isto, mas você deve ter certeza que configurou reversamente correto. Finalmente, usando bind é provalvelmente a melhor forma para fazer isto, mas a configuração do bind foge do escopo deste documento e do utilitário ltspcfg.
Do original do parágrafo acima: " Many services, like NFS and the Display manager need to be able to map the IP address of the workstation to a hostname. You could setup the Berkeley Intenet Naming Daemon (BIND) to do that, but you'd have to make sure you get the reverses setup properly. Ultimately, using bind is probably the best way to do it, but configuration of bind is beyond the scope of this document and the ltspcfg utility."
9 - Create /etc/hosts.allow entries
Alguns serviços usam uma camada de segurança conhecida como tcpwrappers. Isto é configurado através do arquivo /etc/hosts.allow. Este item configurará esse arquivo para você.
10 - Create the /etc/exports file
Este é o arquivo que o NFS usa para determinar quais diretórios são permitidos serem montados por máquinas remotas. Este item configurará esse arquivo para você.
11 - Create the lts.conf file
A configuração de cada cliente é direcionada pelas entradas no arquivo lts.conf. Para significativos clientes com PCI bus, não será necessária entradas adicionais no lts.conf. Mas mesmo assim o arquivo precisa existir. Este item criará o arquivo lts.conf default para você.
2.4. Configuração específica da estação de trabalho
Agora, está na hora de falar sobre os clientes ao servidor LTSP. Existem três arquivos que contêem as informações sobre os clientes.
1./etc/dhcpd.conf
2./etc/hosts
3./opt/ltsp/i386/etc/lts.conf
2.4.1 /etc/dhcpd.conf
Os clientes precisam de um endereço de IP e de outras informações. Eles pegarão o seguinte do servidor DHCP:
endereço de IP
nome do host
endereço de IP do servidor
gateway default
Pathname do kernel para rodar
path do servidor e diretório para ser montado como o sistema de arquivos raíz
Para nosso exemplo de ambiente LTSP, nós escolhemos configurar manualmente os endereços de IP das estações de trabalho.
Durante o script ltsp_initialize, um arquivo exemplo dhcpd.conf é instalado. O seu nome é /etc/dhcpd.conf.example e você pode copiá-lo para /etc/dhcpd.conf para fazê-lo de base para sua configuração do dhcp. Você precisará modificar as partes deste arquivo onde se referem as espeficicações dos seus clientes e do servidor.
O arquivo /etc/dhcpd.conf.example:
default-lease-time 21600;
max-lease-time 21600;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.0.255;
option routers 192.168.0.254;
option domain-name-servers 192.168.0.254;
option domain-name "ltsp.org";
option root-path "192.168.0.254:/opt/ltsp/i386";
shared-network WORKSTATIONS {
subnet 192.168.0.0 netmask 255.255.255.0 {
}
}
group {
use-host-decl-names on;
option log-servers 192.168.0.254;
host ws001 {
hardware ethernet 00:E0:18:E0:04:82;
fixed-address 192.168.0.1;
filename "/lts/vmlinuz.ltsp";
}
}
Figura 2-8. /etc/dhcpd.conf
Como o LTSP versão 2.09pre2, você não precisa mais especificar um kernel para carregar. O pacote do kernel básico possui todas as placas de redes que o Linux suporta. Existem dois arquivos de kernel incluído no pacote LTSP kernel. Um kernel tem o Linux Progress Patch (LPP) embutido e o outro não. Os nomes dos kernels são:
vmlinuz-2.4.9-ltsp-5
vmlinuz-2.4.9-ltsp-lpp-5
Você deve ter percebido que o kernel está no diretório /tftpboot/lts, mas a entrada para "filename" no arquivo /etc/dhcpd.conf está faltando no começo do caminho o diretório /tftpboot. Isso é porque nas versões 7.1 e posteriores do Redhat, o TFTP roda com a opção '-s'. Isso faz com que o daemon tftpd rode no modo secure. Ou seja, ele dá um chroot para o diretório /tftpboot quando é iniciado. Consequentemente, todos os arquivos que estão disponíveis ao daemon tftpd fiquem reçacionados ao diretório /tftpboot.
Outras distribuições Linuxpoderão não ter a opção '-s' configurada para o tftpd, então você precisará adicionar o diretório /tftpboot no começo da parâmetro do "filename".
2.4.2. /etc/hosts
Mapeia o endereço IP do host ao seu nome.
Os computadores geralmente se comunicam bem com o endereço de IP. Então, nós humanos damos nomes aos computadores porque não consigos memorizar tantos números. É aí que o DNS ou o /etc/hosts entram no jogo. Esta tarefa de mapear geralmente não é necessária, exceto num ambiente LTSP. Porque sem isso, o NFS dará erros de permissão quando os clientes requisitarem a montagem do sistema de arquivo.
Além dos problemas do NFS, se os clientes não estiverem listados no arquivo /etc/hosts você poderá também ter problemas com os gerenciadores de janelas GDM ou KDM.
2.4.3. /opt/ltsp/i386/etc/lts.conf
Há entradas de configurações que podem ser especificadas no arquivo lts.conf.
O arquivo lts.conf tem uma sintaxe simples que conssite em seções múltiplas. Tem uma seção default chamada [default] e lá pode ser seções para cada cliente separadamente. Os clientes podem ser identificados pelo seu nome, endereço de IP ou MAC address.
Um arquivo lts.conf típico se parece com este:
1.
1. Config file for the Linux Terminal Server Project (www.ltsp.org)
1.
[Default]
SERVER = 192.168.0.254
XSERVER = auto
X_MOUSE_PROTOCOL = "PS/2"
X_MOUSE_DEVICE = "/dev/psaux"
X_MOUSE_RESOLUTION = 400
X_MOUSE_BUTTONS = 3
USE_XFS = N
LOCAL_APPS = N
RUNLEVEL = 5
[ws001]
USE_NFS_SWAP = Y
SWAPFILE_SIZE = 48m
RUNLEVEL = 5
[ws002]
XSERVER = XF86_SVGA
LOCAL_APPS = N
USE_NFS_SWAP = Y
SWAPFILE_SIZE = 64m
RUNLEVEL = 3
Examplo 2-1. Arquivo lts.conf
A seguir está uma lista destas entradas:
XSERVER
Se a sua placa de vídeo é PCI e se ela for suportada pelo XFree86 4.1, então você apenas precisará do pacote lts_x_core package. Ele contém todos os módulos de driver para X4.
Existem muitos pacotes XFree86 3.3.6 disponíveis para o LTSP. Este é o caso de sua placa de vídeo não ser suportada pelo XFree86 4.1.
Você criar entradas no arquivo lts.conf para cada cliente separadamente ou você pode fazer entradas default que são compartilhadas por todos os clientes.
Nosso cliente tem um chipset de vídeo Intel i810 e pode ser detectada automaticamente, então nós não precisamos de nehuma entrada no arquivo lts.conf. A entrada XSERVER pode ser especificada se você quiser ou pode ser configurada para 'auto' para mostrar que ela irá ser detectada automaticamente.
RUNLEVEL
Nós queremos rodar o cliente no modo gráfico, então nós precisamos configurar o RUNLEVEL para '5'. Isto é feito com outra entrada no arquivo lts.conf.
2.5. Visualizando as configurações atuais
Com o ltspcfg você pode dar uma olhada no status atual de todos os serviços necessários para o LTSP. ATravés do menu do ltspcfg, pressione 'S' e você verá o status atual.
Figura 2-9. ltspcfg – Status atual
Capítulo 3. Configurando a estação de trabalho (o cliente)
Depois que o servidor estiver configurado, está na hora de focar a configuração no cliente.
O projeto LTSP é todo em cima do que acontece depis que o kernel estiver na memória. Há várias de colocar o kernel namemória dos clientes inclusive o Etherboot, Netboot, PXE e disquete.
3.1. Inicializando com PXE
Se a sua placa de rede ou seu PC tiver PXE embutido, então você poderá usá-lo para carregar o kernel na memória. PXE é uma tecnologia bootrom, parecida com a Etherboot ou Netboot.
Voce poderá precisar ativar o bootrom PXE na sua NIC. Voce poderá precisar mudar o dispositivo de boot na BIOS da sua paca mãe, escolhendo a opção "Boot from LAN" o primeiro dispositivo a ser o boot, invés do HD ou disquete.
PXE tem uma limitação de apenas ser capaz de carregar arquivos de no máximo 32kb. Como o kernel do Linux é um pouco maior, você não pode carregar o kernel diretamente através do PXE. Você precisará careegar algo conhecido como um 'Network Bootstrap Program' ou NBP.
Existe um NBP dsiponível para carregar o kernel do Linux pxelinux.0. Ele é uma parte do pacote syslinux que vem do colaborador do kernel H. Peter Anvin.
O pacote do kernel do LTSP inclui o pxelinux.0 NBP e o arquivo de configuração necessário para carregar o kernel do Linux e uma imagem inicial do disco virtual (ramdisk).
Ele trabalha assim:
O bootrom PXE inicializa a placa de rede e envia uma requisição DHCP.
O servidor DHCP responde com um endereço de IP e o nome do NBP para carregar.
O bootrom PXE baixa o NBP, colocá-o na memória e começa a executá-lo.
O NBP usa tftp para baixar o arquivo de configuração vindo do servidor.
O arquivo de configuração contém o nome do kernel, o nome do arquivo inicial virtual e opções para passar ao kernel, uma vez que ele é carregado.
Abaixo é exemplo de um arquvo de configuração do pxelinux.
prompt=0
label linux
kernel bzImage-2.4.24-ltsp-4
append init=/linuxrc rw root=/dev/ram0 initrd=initrd-2.4.24-ltsp-4.gz
O NBP, então, usa o o tftp para baixar o kernel do Linux e inicializar o disco virtual (initrd).
O controle é passado para o kernel do Linux, ele dá boot, monta o initrd e continua com a inicilização do cliente.
3.2. Dando o boot com Etherboot
Etherboot é um pacote de programas para a criação de imagens ROM que podem baixar código através de uma rede Ethernet para ser executado em um computador x86. Muitos adaptadoes de rede possuem um compartimento onde um chip ROM pode ser instalado. Etherboot é código que pode ser colocado nesta ROM.
-- Ken Yap
Etherboot também é um software livre, protegido através da licença GNU General Public License, Versão 2 (GPL2).
Para usar Etherboot, caso você tenha uma placa de rede com um bootrom Etherboot, você talvez tenha que mudar a configuração de sua BIOS para fazê-la "Bootar da LAN" antes de inicializar de um disquete ou disco rígido.
Se você ainda não tem um bootrom Etherboot, você pode fazer um bootrom, ou fazer um disquete com uma imagem Etherboot image em sua seção de boot.
Etherboot suporta inúmeras placas de rede. Mais de 200 modelos, com ainda mais modelo0s sendo adiionados a cada dia. Caso você deseje fazer um disquete ou gravar o código em uma Eprom, você terá que determinar que modelo de placa de rede você possui.
3.2.1. Escolhendo um driver Etherboot de uma placa de rede ISA
Para placas de rede ISA antigas, não importa muito a determinação de seu modelo exato. Antes de tudo, a maior parte delas são placas ne2000 ou 3Com 3c509. Você precisa apenas escolher o driver Etherboot correto, aquele que seleciona o tipo de mídia nas placas ambas 10 base-2 (Coaxial) and 10 base-T (Par Trançado).
3.2.2. Escolhendo um driver Etherboot de uma placa de rede PCI
Para placas PCI, é importante que você escolha o driver Etherboot driver correspondente ao fabricante e o seu identificador da placa de rede (Vendor and Device id)
As vezes você terá sorte. Saberá exatamente qual modelo de placa você tem, porque o número do modelo está impresso na placa, e corresponde exatamente à descrição de um dos módulos Etherboot. Porém, em muitos casos, você terá que achar os números identidficadores da PCI.
Caso suas estações de trabalho tenham um driver de disquete, você pode iniciar um disquete tomsrtbt (Tom's Root Boot). Ou, se suas estações de trabalho têm um driver de CD-ROM, vovê pode inicializar de um CD Knoppix. Se você não puder instalar linux em suas estações de trabalho, então sua única esperança talvez seja mover a placa de rede para uma máquina que possa inicializar linux.
Quando você tiver inicializado em Linux, poderá usar o comando lspci com a opção '-n'.
[root@jamlap root]# lspci -n
0000:00:00.0 Class 0600: 8086:7190 (rev 03)
0000:00:01.0 Class 0604: 8086:7191 (rev 03)
0000:00:03.0 Class 0607: 104c:ac1c (rev 01)
0000:00:03.1 Class 0607: 104c:ac1c (rev 01)
0000:00:07.0 Class 0680: 8086:7110 (rev 02)
0000:00:07.1 Class 0101: 8086:7111 (rev 01)
0000:00:07.2 Class 0c03: 8086:7112 (rev 01)
0000:00:07.3 Class 0680: 8086:7113 (rev 03)
0000:00:08.0 Class 0401: 125d:1978 (rev 10)
0000:01:00.0 Class 0300: 1002:4c4d (rev 64)
0000:06:00.0 Class 0200: 8086:1229 (rev 09)
No examplo acima, você pode ver uma entrada para cada placa PCI no sistema. Você apenas precisa notar os módulos Class 0200. Então, se digitar novamente o comando, especificando somente as interfaces Ethernet, a lista torna-se muito mais administrável.
[root@jamlap root]# lspci -n | grep "Class 0200"
0000:06:00.0 Class 0200: 8086:1229 (rev 09)
Os números de ID do PCI são: 8086:1229. O primeiro campo, 8086 é a ID do fabricante PCI. Neste example, o fabricante é a Corporação Intel. O segundo campo, 1229 é a ID do módulo PCI. Este número nos informa que modelo é a placa de rede. Neste caso, uma placa EtherExpress 100.
3.2.3. Criando um disquete de boot
Você pode baixar um pacote Etherboot e configurá-lo para o tipo de bootrom que você precisa. Então, você pode compilar o código para produzir uma imagem de bootrom que pode ser escrita em uma EPROM, ou em um disquete.
Um modo bem mais simples pode ser encontrado no site de Marty Connor www.Rom-O-Matic.net.
Marty fez um excelente trabalho em criar uma interface web para o processo de configuração e compilação de imagens bootrom com Etherboot. Neste site, você pode selecionar que tipo de placa de rede você tem, e que tipo de imagem você quer. Então, você tem a oportunidade de modificar diferentes opções de configuração Etherboot. Depois disso você clica no botão 'Get ROM' (Pegue a ROM) e uma imagem bootrom customizada será gerada enquanto você espera.
Para o formato de saída da ROM (output format), escolha 'Floppy Bootable ROM Image' (Imagem ROM de Disquete Inicializável). Esta opção incluirá um cabeçalho de 512 bites que é um boot-loader para carregar a imagem etherboot na ram onde pode ser executada.
Clique no botão 'Get ROM'. A imagem de bootrom image será gerada em poucos segundos. Quando completa, seu navegador abrirá uma janela pop-up com a opção "Save As" (Salvar Como), onde você pode designar onde você quer salvar a imagem no seu computador.
Após salvar a imagem no seu disco rígido, você precisa também gravá-la em um disquete. Insira este disquete em seu driver e digite o seguinte comando:
dd if=Etherboot_Image of=/dev/fd0
3.2.4. Criando um bootrom
Escrever uma imagem Etherboot para uma EPROM requer um programador EPROM. Este é um equipamento que varia de preço de centenas a milhares de dólares, dependendo de suas características.
O processo de criar uma bootrom é inteiramente dependente do programador EPROM. E está além do escopo deste documento.
Capítulo 4. Rodando as estações de trabalho
Supondo que o servidor e as estações de trabalho estão configuradas corretamente, você precisará somente inserir o disquete de boot no driver de disquete, e ligar a estação de trabalho.
O código Etherboot será lido do disquete para a memória, a placa de rede será achada e inicializada, o pedido de dhcp será enviado para a rede, uma resposta será enviada do servidor, e o kernel será baixado para as estações. Quando o kernel inicializar o hardware das estações de trabalho, janelas X (X Windows) começarão e um box de login aparecerá na estação de trabalho, parecido com o exemplo abaixo.
Figura 4-1. Tela de Login
Neste ponto, você pode se logar. Um coisa importante de ter em mente é que você está logando no servidor. Todos os comandos que você rodar estarão de fato rodando neste servidor, tendo como interface de saída as estações de trabalho. Este é o poder das janelas X (X windows).
Você pode rodar qualquer programa que seja suportado pelo servidor.
Capítulo 5. Imprimindo
Sem considerar o fato de que as estações de trabalho são GUI totalmente operacionais ou character mode terminal, também podem funcionar como servidores de impressão, permitindo com que até três impressoras sejam conectados às portas paralelas e seriais.
Isto é tudo transparente para o usuário das estações de trabalho. Eles nem notarão o pequeno volume de tráfego que está passando das estações de trabalho até as impressoras.
5.1. Setup cliente
LTSP usa o programa lp_server em suas estações de trabalho, para redirecionar trabalhos de impressão do servidor à impressora conectada à uma das portas de estação. daemon
Para permitir a impressora nas estações, existe uma série de entradas de configuração no arquivo lts.conf.
[ws001]
PRINTER_0_DEVICE = /dev/lp0
PRINTER_0_TYPE = P
A entrada acima fará com que o programa lp_server rode como um daemon, escutando na porta 9100 TCP/IP um fluxo de impressão (stream) do servidor. O dado de impressão será então redirecionado à impressora conectada à porta paralela /dev/lp0.
Existem muitas outras opções disponíveis. Cheque a seção do arquivo lts.conf a seguir neste documento para mais informações sobre as entradas de configuração da impressora.
5.2. Setup Servidor
Configurandi a impressora no servidor é feita somente definindo a fila de impressão, usando a ferramenta de configuração da impressora no servidor.
No Redhat 7.2, existe uma ferramenta de configuração da impressora tanto em GUI quanto em modo texto. A ferramenta GUI é chamada de printconf-gui, e a ferramenta modo texto printconf-tui. Versões mais antigas do Redhat têm um programa chamado printtool. Printtool também existe no Redhat 7.2, mas se chamará printconf-gui. Outras distribuições Linux têm suas próprias ferramentas de configuração de impressão.
Figura 5-1. Printconf-gui Adicionando uma nova impressora
Quando você inicia a sua ferramenta de configuração da impressora, você precisa adicionar uma nova impressora. O programa lp_server permite com que as estações de trabalho emulem um servidor de impressão HP JetDirect. Você só precisa criar uma impressora JetDirect.
Você precisa dar à impressora um nome de fila (Queue name). O nome pode ser qualquer coisa, mas que tenha um significado, e conter apenas os seguintes caracteres:
"a-z" caixa baixa
"A-Z" caixa alta
"0-9" números
"-" hífen
"_" underscore
O nome escolhido no example abaixo é ws001_lp . O nome torna fácil ver qual impressora está associada com ws001.
Figura 5-2. Printconf-gui Detalhe de informação
Existem dois campos requisitados para se comunicar com a impressora:
1.Endereço IP ou hostname da estação de trabalho com que a impressora está associada.
2.A porta TCP em que o daemon lp_server está escutando.
A primeira impressora que você conectar à estação de trabalho será na porta 9100 TCP/IP. A segunda impressora será na porta 9101, e a terceira impressora na porta 9102 .
Capítulo 6. Scripts de Tela
Uma novidade do LTSP que foi adicionado na versão 4.0 é algo chamado de Screen Scripts. Estes são scripts para começar vários tipos de sessões.
Você pode especificar múltiplos scripts de tela para uma estação de trabalho. Fazendo isto, você permitirá múltiplas sessões. Estes podem ser diferentes tipos de sessão, ou sessões do mesmo tipo. Por examplo, você pode especificar o seguinte:
SCREEN_01 = startx
SCREEN_02 = shell
Isso iniciará o servidor X na primeira tela, e um shell prompt na segunda tela. Você pode trocar entre telas pressionando Ctrl-Alt-F1 para ir para primeira tela, e Ctrl-Alt-F2 para a segunda tela.
Você pode especificar até 12 scripts de tela para cada estação de trabalho, poréma maior parte das pessoas tem somente uma.
Tipos de scripts de tela:
startx
Este script iniciará o servidor X com uma opção -query, para mandar um pedido de XDMCP para um gerenciador de display, obtendo assim um box de login na tela.
shell
Este script iniciará um shell no terminal. Isso é realmente usado com a intenção de descobrir problemas (troubleshooting) nas estações de trabalho. Porque fornece a você uma seção no cliente leve, no lugar do servidor, não é muito útil para rodar aplicativos.
telnet
Este script iniciará uma seção telnet que conectará ao servidor. Isso lhe dará uma sessão baseada em caracteres no servidor.
Por padrão, telnet conectará ao servidor LTSP. caso você deseje especificar um servidor diferente, você pode fazê-lo na mesma linha do script de tela. Por examplo:
SCREEN_01 = telnet server2.mydomain.com
Você também pode especificar quantas opções o Telnet conheça, porém, caso você especifique outras opções, você deve também especificar o servidor a ser conectado.
rdesktop
Este script acionará o programa rdesktop, que irá por sua vez conectar a um servidor which Microsoft Window. Você pode especificar quantas opções rdesktop vpcê quer na mesma linha, diretamente depois do nome do script de tela. Por examplo, se você quer especificar o servidor a ser conectado, você pode fazer assim:
SCREEN_01 = rdesktop -f w2k.mydomain.com
O examplo acima iniciará o rdesktop em modo tela cheia. O usuário verá uma janela de login, e terá que logar somente uma vez. Isso é muito útil quando você apenas quer uma kanela de login, sem ter um login Linux ou um gerenciador de janelas. O usuário nem saberá que está rodando Linux.
O script de tela está localizado no diretório the /opt/ltsp/i386/etc/screen.d. Você pode criar seu próprio script de tela e colocá-lo neste diretório. É recomendável seguir um dos scripts existentes como exemplo.
Capítulo 7. Desproblematizando
Caso, mesmo tendo seguido todos os capítulos anteriores, suas estações de trabalho não funcionem, então você deve iniciar o processo de desproblematizar a instalação.
A primeira coisa a fazer é descobrir até que ponto as estações de trabalho foram em seu boot.
7.1. Desproblematizando a imagem de disquete Etherboot
Quando você inicializa pelo disquete, você deve ver algo parecido com isso:
loaded ROM segment 0x0800 length 0x4000 reloc 0x9400
Etherboot 5.0.1 (GPL) Tagged ELF for [LANCE/PCI]
Found AMD Lance/PCI at 0x1000, ROM address 0x0000
Probing...[LANCE/PCI] PCnet/PCI-II 79C970A base 0x1000, addr 00:50:56:81:00:01
Searching for server (DHCP)...
<sleep>
O examplo acima mostra o que você deve esperar ver na tela quando inicializando pelo disquete. Caso você não veja estas mensagens, indicando que o Etherboot começou, talvez vocvê tenha um disquete ruim, ou a imagem não foi gravada propriamente.
Caso a seguinte mensagem apareça, então indica que você provavelmente gerou uma imagem que não corresponde à sua placa de rede.
ROM segment 0x0800 length 0x8000 reloc 0x9400
Etherboot 5.0.2 (GPL) Tagged ELF for [Tulip]
Probing...[Tulip]No adapter found
<sleep>
<abort>
Caso chegue ao ponto em que detecta a placa de rede e mostra o endereço MAC correto, então o disquete provavelmente está bom.
7.2. Desproblematizando DHCP
Uma vez que a placa de rede foi incializada, esta enviará uma transmissão DHCP para a rede local, procurando por um servidor DHCP.
Caso a estação de trabalho consiga uma resposta válida do servidor DHCP server, configurará então a placa de rede. Você pode dizer se funcionou direito caso a informação do endereço IP apareça na tela. Segue um exemplo de como deve aparecer:
ROM segment 0x0800 length 0x4000 reloc 0x9400
Etherboot 5.0.1 (GPL) Tagged ELF for [LANCE/PCI]
Found AMD Lance/PCI at 0x1000, ROM address 0x0000
Probing...[LANCE/PCI] PCnet/PCI-II 79C970A base 0x1000, addr 00:50:56:81:00:01
Searching for server (DHCP)...
<sleep>
Me: 192.168.0.1, Server: 192.168.0.254, Gateway 192.168.0.254
caso você veja uma linha que começa com 'Me:', seguido de um endereço IP, então você sabe que o DHCP está funcionando corretamente. Você pode seguir então para checar se o TFTP está funcionando.
Se caso contrário, você veja a mensagem seguinte em sua estação de trabalho, seguido de uma série de mensagens <sleep>, então algo está errado. No enatnto, é comum ver uma ou duas mensagens de <sleep>, depois da qual o servidor dhcp responde.
Searching for server (DHCP)...
Descobrir o que está errado pode ser muitas vezes difícil, mas aqui seguem algumas dicas.
7.2.1. Checar as conexões
A estação de trabalho está conectada fisicamente à mesma rede que o servidor está conectado?
Com as estações de trabalho ligadas, certifique-se de que as luzes de link estão acesas à todas as conexões.
Se você está conectando diretamente as estações de trabalho e o servidor (sem um hub ou switch), certifique-se que vc está usando um cabo cruzado. Se você está usando um hub ou switch, então você está usando um cabo normal (straight-thru), ambos entre as estações de trabalho e o hub, e também entre o hub e o servidor.
7.2.2. O dhcpd está funcionando?
Voc precisa determinar se o dhcpd está funcionando no servidor. Nós podemos achar esta resposta de duas formas.
dhcpd normalmente fica no plano de fundo, escutando na udp porta 67. Tente dar o comando netstat para ver se alguém está escutando naquela porta:
netstat -an | grep ":67 "
Você deve obter uma resposta parecida com esta:
udp 0 0 0.0.0.0:67 0.0.0.0:*
A quarta coluna mostra o endereço de IP e a porta, separadada por um sinal de dois pontos (':'). Um endereço somente zeros ('0.0.0.0') indica que ele está escutando em todas as interfaces. Isso significa que, voc deve ter uma interface eth0 e eth1, e que o dhcpd esta escutando em ambas as interfaces.
Mas não é porque o netstat mostra que tem algo escutando udp na porta 67, que significa que é definitivamente o dhcpd que está escutando. Pode ser o bootpd, mas é muito improvável, porque bootp não está mais incluido na maior parte das distribuições Linux.
Para ter certeza que é o dhcpd que está trabalhando, tente dar o comando ps.
ps aux | grep dhcpd
Você deve obter uma resposta parecida com esta:
root 23814 0.0 0.3 1676 820 ? S 15:13 0:00 /usr/sbin/dhcpd
root 23834 0.0 0.2 1552 600 pts/0 S 15:52 0:00 grep dhcp
A primeira linha mostra que o dhcpd está rodando. A segunda é apenas o seu comando grep.
Se você não vê as linhas que mostram o dhcpd rodando, então você precisa chcar se o servidor está configurado para runlevel 5, e que dhcpd está configurado para começar em runlevel 5. Nos sistemas baseados em Redhat, você pode tentar o ntsysv e descer até se certificar que o dhcpd está configurado para começar.
Você pode tentar começar o dhcpd com este comando:
service dhcpd start
Preste atenção na resposta, poderá mostrar erros.
7.2.3. Checar de novo a configuração dhcpd
O arquivo/etc/dhcpd.conf tem uma entrada para a sua estação de trabalho?
Você deve checar novamente a configuração de 'fixed-address' no seu arquivo config, para ter certeza que bate exatamente com a placa na estação de trabalho.
7.2.4. ipchains ou iptables está bloqueando o seu pedido?
7.2.4.1. Checando ipchains
Digite o seguinte comando para ver o que responde:
ipchains -L -v
Caso você obtenha uma resposta assim:
Chain input (policy ACCEPT: 229714 packets, 115477216 bytes):
Chain forward (policy ACCEPT: 10 packets, 1794 bytes):
Chain output (policy ACCEPT: 188978 packets, 66087385 bytes):
Então não é o ipchains que está bloqueando o caminho.
7.2.4.2. Checando iptables
Digite o seguinte comando para ver o que responde:
iptables -L -v
Caso você obtenha uma resposta assim:
Chain INPUT (policy ACCEPT 18148 packets, 2623K bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 17721 packets, 2732K bytes)
pkts bytes target prot opt in out source destination
Então não é o iptables que está bloqueando o caminho.
7.2.5. A estação de trabalho está mandando o pedido?
Olhe o arquivo /var/log/messages enquanto a estação de trabalho está inicializando. Você pode fazer isto com o seguinte comando:
tail -f /var/log/messages
Isso irá 'seguir' o arquivo de log enquanto novas adições são feitas a ele.
server dhcpd: DHCPDISCOVER from 00:50:56:81:00:01 via eth0
server dhcpd: no free leases on subnet WORKSTATIONS
server dhcpd: DHCPDISCOVER from 00:50:56:81:00:01 via eth0
server dhcpd: no free leases on subnet WORKSTATIONS
Caso você veja mensagens como estas acima dizendo 'no free leases', isso indica que o dhcpd está rodando, mas não sabe nada sobre as estações de trabalho que estão pedindo um endereço de IP.
7.3. Desproblematizando TFTP
Etherboot usa TFTP para obter um kernel Linux do servidor. Isso é im protocolo razoavelmente simples, mas pode as vezes dar problemas para começar a funcionar.
Caso você veja uma mensagem como esta:
Loading 192.168.0.254:/lts/vmlinuz-2.4.24-ltsp-4.........
com pontos enchendo a tela rapidamente, isso normalmente indica que o TFTP está funcionando normalmente, e o kernel está sendo baixado.
Se, caso contrário, você não ver os pontos, então existe um problema. Possíveis problemas incluem:
7.3.1. tftpd não erstá rodando
Se o tftpd não está configurado para rodar, então certamente não será possível que a estação de trabalho obtenha uma resposta para o seu pedido. Você pode ver se ele está rodando com o comando netstat, assim:
[root@bigdog]# netstat -anp | grep ":69 "
udp 0 0 0.0.0.0:69 0.0.0.0:* 453/inetd
Caso você não obtenha nenhuma resposta para este comando, então provavelmente tftpd não está rodando.
Existem dois métodos comuns para chamar o tftpd, eles são o inetd e o mais novo xinetd
inetd usa o arquivo de configuração chamado /etc/inetd.conf. Neste arquivo, certifique-se que a linha para começar o tftpd NÃO está comentada. A linha deve se parecer com esta:
tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd -s /tftpboot
xinetd usa um diretório de arquivos de configuração individuais. Um arquivo para cada serviço. Se o seu servidor está usando xinetd, então o arquivo de configuração para o tftpd se chama /etc/xinetd.d/tftp. Abaixo está um exemplo:
service tftp
{
disable = no
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
server_args = -s /tftpboot
}
Certifique-se que a linha disable não diz yes.
7.3.2. O kernel não está onde o tftpd espera encontrá-lo
O kernel precisa estar em um lugar que o daemon tftpd pode acessá-lo. Caso a opção '-s' esteja especificada para a seção daemon tftpd, então tudo que a estação de trabalho está pedindo deve estar relativo ao /tftpboot. Então se a entrada filename no arquivo /etc/dhcpd.conf está marcada como /lts/vmlinuz-2.4.24-ltsp-4, então o kernel precisa ser /tftpboot/lts/vmlinuz-2.4.24-ltsp-4
7.4. Desproblematizando o sistema de arquivos root NFS
Existem várias coisas que podem prevenir um sistema de arquivos root de ser montado. Incluindo os seguintes:
7.4.1. init não achado
Caso você obtenha o seguinte erro:
Kernel panic: No init found. Try passing init= option to kernel.
Então provavelmente você está montando o diretório errado como o sistema de arquivos root, ou o diretório /opt/ltsp/i386 está vazio.
7.4.2. Servidor retornou erro -13
Caso você obtenha o seguinte erro:
Root-NFS: Server returned error -13 while mounting /opt/ltsp/i386
Isso indica que o diretório /opt/ltsp/i386 não está listado no arquivo /etc/exports.
Olhe o arquivo /var/log/messages para ver se fornece alguma pista. Uma entrada como esta:
Jul 20 00:28:39 bigdog rpc.mountd: refused mount request from ws004
for /opt/ltsp/i386 (/): no export entry
Que então confirma a nossa suspeita que a entrada em /etc/exports não está correta.
7.4.3. Problemas de Daemon NFS (portmap, nfsd & mountd)
NFS pode ser um serviço complexo e difícil para desproblematizar, mas entendendo o que deveria ser a configuração inicial e que ferramentas existem disponíveis para diagnosticar os problemas, certamente irá ajudá-lo a fazer isto mais fácil.
Existem três daemons que precisam estar rodando no servidor para que o NFS funcione corretamente: o portmap, nfsd e o mountd.
7.4.3.1. O Portmapper (portmap)
Caso você obtenha a seguinte mensagem:
Looking up port of RPC 100003/2 on 192.168.0.254
portmap: server 192.168.0.254 not responding, timed out
Root-NFS: Unable to get nfsd port number from server, using default
Looking up port of RPC 100005/2 on 192.168.0.254
portmap: server 192.168.0.254 not responding, timed out
Root-NFS: Unable to get mountd port number from server, using default
mount: server 192.168.0.254 not responding, timed out
Root-NFS: Server returned error -5 while mounting /opt/ltsp/i386
VFS: unable to mount root fs via NFS, trying floppy.
VFS: Cannot open root device "nfs" or 02:00
Please append a correct "root=" boot option
Kernel panic: VFS: Unable to mount root fs on 02:00
Isso é provavelmente causado pelo não-funcionamento do daemon portmap. Você pode confirmar se o portmapper está rodando através do comando ps:
ps -e | grep portmap
Caso o portmapper esteja rodando, você deve obter uma resposta assim:
30455 ? 00:00:00 portmap
Outro teste é usar o netstat. O portmapper usa TCP e UDP na porta 111. Tente isso:
netstat -an | grep ":111 "
Você deve obter uma resposta assim:
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN
udp 0 0 0.0.0.0:111 0.0.0.0:*
Caso sua resposta não seja parecida com esta, então o portmapper não está funcionando. Você deve iniciar o portmapper assim:
/etc/rc.d/init.d/portmap start
Então, você deve certificar-se que o portmapper está configurado para começar quando o servidor inicializar. Rode ntsysv para ter certeza que está indicado para rodar.
7.4.3.2. Os daemons NFS e MOUNT (nfsd & mountd)
NFS tem 2 daemons que precisam estar rodando. nfsd e mountd. Ambos são iniciados pelo script /etc/rc.d/init.d/nfs.
Você pode dar o comando ps para se certificar que eles estão rodando.
ps -e | grep nfs
ps -e | grep mountd
Caso mostre que um ou dois destes daemons não estão rodando, então você precisa iniciá-los.
Normalmente, você pode rodar um script de inicialização com o argumento restart para fazer com que ambos inicializem, mas, se por alguma razão, o script /etc/rc.d/init.d/nfs não re-inicia o nfsd dessa forma, só re-iniciando mountd (bug?). Então, você deve dar a seguinte sequência de comandos:
/etc/rc.d/init.d/nfs stop
/etc/rc.d/init.d/nfs start
Você pode obter erros no comando stop, mas isso é Ok. O comando start deve mostrar o status OK.
Caso os daemons estejam rodando, mas o NFS ainda não fiunciona, você pode verificar que eles se registraram com o portmapper através do comando rpcinfo.
rpcinfo -p localhost
Você deve obter respostas como as seguintes:
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100021 1 udp 32771 nlockmgr
100021 3 udp 32771 nlockmgr
100021 4 udp 32771 nlockmgr
100005 1 udp 648 mountd
100005 1 tcp 651 mountd
100005 2 udp 648 mountd
100005 2 tcp 651 mountd
100005 3 udp 648 mountd
100005 3 tcp 651 mountd
100024 1 udp 750 status
100024 1 tcp 753 status
Isso indica que o nfs (nfsd) e o mountd estão ambos rodando e se registraram com o portmapper.
7.5. Desproblematizando o Xserver
Ai, ai... provavelmente a parte mais difícil de configurar uma estação de trabalho LTSP, é fazer com que o servidor X esteja configurado direito. Se você está usando uma placa de vídeo nova, que é suportada pelo Xorg Xservers, e você tem um novo monitor que suporta uma larga margem de frequências e resoluções, então isso é muito direto. Usualmente, neste caso, quando não funciona, é muito provável que seja o servidor X incorreto para aquela placa.
Quando um servidor X não funciona com a sua placa, é normalmente bem óbvio. Ou o servidor X nem começa, ou a imagem estará incorreta.
Quando a estação de trabalho está pronta para começar o servidor X, ela chama o script startx, que inicia o servidor X nas estações de trabalho locais, com a opção -query apontando para o servidor, onde um gerenciador de interface gráfica como o XDM , GDM ou KDM está rodando.
Porque o servidor X começa por um script startx, que por sua vez é inicializado pelo programa init program, quando falha, init tentará rodá-lo novamente. init vai continuar em loop tentando rodar o servidor X 10 vezes, e despois desistindo, porque pensa que está respawning muito rapidamente. Depois que finalmente desiste, a mensagem de erro do servidor X deve aparecer à esquerda na tela.
Esperar com que o servidor X falhe 10 vezes pode ser bem irritante, então, um modo simples de evitar as flhas repetitivas é começar as estações de trabalho em runlevel 3, para que o servidor X server NÃO comece automaticamente. ao invés disso, quan do você inicializar as estações de trabalho, você vai obter um pedido (prompt) de bash. A partir deste, você pode começar o servidor X manualmente com o seguinte comando:
sh /tmp/start_ws
O servidor X server tentará inicializar, e depois falhará, então retornando ao pedido de bash, para que você possa ver a causa da falha.
7.6. Desproblematizando o gerenciador de interface gráfica
O gerenciador de interface gráfica é o daemon que roda no servidor, esperando com que um servidor X faça contato com ele. Uma vez que o contato foi feito, ele mostrará na tela uma entrada de login, dando @ usuári@ uma chance de se logar no servidor.
Os três gerenciadores de interface gráfica mais comuns são:
XDM – Está por aí desde sempre. Vem junto com o sistema de janelas X padrão.
GDM – É o 'Gnome Display Manager'. Integrante do pacote Gnome.
KDM – É o 'KDE Display Manager'. Integrante do sistema K Desktop.
Mais recentemente, distribuições GNU/Linux incluem todas as três interfaces gráficas.
7.6.1. Tela cinza com um grande sinal X
Isto indica que o servidor X está funcionando, mas que não conseguiu conectar com o gerenciador de interface gráfica. Algumas possíveis razões são:
1.O gerenciador de interface gráfica talvez não esteja funcionando
Em versões recentes do Redhat (7.0 e acima), o gerenciador de interface gráfica é inicializado do init. No arquivo /etc/inittab, existe uma linha que se parece com essa:
x:5:respawn:/etc/X11/prefdm -nodaemon
O script prefdm determinará qual gerenciador de interface gráfica a rodar.
O gerenciador de interface gráfica padrão depende dos pacotes que foram instalados. Se o Gnome está instalado, então o GDM é o gerenciador de interface gráfica padrão. Caso o Gnome não esteja instalado, então o script prefdmvai ver se o KDE está instalado. Caso esteja, então o KDM será o gerenciador de interface gráfica padrão. Caso KDE também não esteja inatalado, então o XDM será o gerenciador de interface gráfica padrão.
Usando o comando netstat, você pode ver se existe um gerenciador de interface gráfica rodando. No servidor, dê o seguinte comando:
netstat -ap | grep xdmcp
Você deve ver os resultados mostrando que existe um processo escutando na porta xdmcp (177).
udp 0 0 *:xdmcp *:* 1493/gdm
Isso mostra claramente que o gdm está rodando com um PID de 1493, e está escutando na porta xdmcp.
Caso mostre uma linha como a abaixo, indicando que existe definitivamente um gerenciador de interface gráfica escutando, então você precisa certificar-se de que as estações de trabalho estão mandando a pergunta XDMCP para o servidor correto.
No arquivo lts.conf, você pode ter uma entrada que especifica o endereço IP do servidor que está rodando o gerenciador de interface gráfica. A entrada é opcional, mas caso presente, deve se parecer com isso:
XDM_SERVER = 192.168.0.254
é claro que o endereço IP de sua rede pode ser diferente do exemplo acima.
Caso a entrada 'XDM_SERVER' não esteja presente, usará o valor da entrada 'SERVER', caso presente. Caso não esteja presente, então usará 192.168.0.254.
Não importando de quê forma está especificada, você só precisa certificar-se que o endereço IP é o endereço correto do servidor rodando o gerenciador de interface gráfica.
2.O gerenciador de interface gráfica talvez esteja configurado para ignorar pedidos de hosts remotos.
Caso você esteja certo que o gerenciador de interface gráfica está funcionando, então é possível que ele tenha sido configurado para ignorar pedidos de XDMCP de hosts remotos. Você precisará checar os arquivos de configuração do gerenciador do seu interface gráfica em específico para determinar se ele está configurado direito.
XDM
A configuração padrão para o Redhat é desabilitar a capacidade das estações de trabalho de terem acesso de login do XDM. O script ltsp_initialize fará com que isso seja revertido, mas se não estiver funcionando, você deve checar o arquivo/etc/X11/xdm/xdm-config. Procure por uma entrada que se pareça com isso:
DisplayManager.requestPort: 0
Esta entrada DEVE estar comentada para que o XDM possa escutar na porta 177 por pedidos remotos.
Existe outro arquivo de configuração importante para que o XDM sirva pedidos de login remotos. O arquivo /etc/X11/xdm/Xaccess DEVE conter uma linha que começa com um asterisco '*'. Esta linha é normalmente incluida no arquivo, mas o Redhat deixa a linha comentada. O script ltsp_initialize consertará essa linha para você, mas se o XDM ainda não parece estar funcionando, você deve checar este arquivo. Uma linha válida se parece com isso:
* #any host can get a login window
KDM
Novas versões do KDM têm um arquivo chamdo kdmrc . Diferentes distribuições Linux o arquivam em diferentes lugares. No Redhat 7.2, é /etc/kde/kdm/kdmrc. Em outras distros, você deve dar o comando locate para achar aonde ele está.
TA entrada que controla se as estações de trabaçho remotas podem obter um login é a seção [Xdmcp]. Tenha certeza que a entrada Enable está como true.
Versões antigas do KDM usam os arquivos de configuração XDM, localizados em /etc/X11/xdm.
GDM
GDM usa um sistema diferente de arquivos de configuração. Eles estão localizados no diretório /etc/X11/gdm.
O arquivo principal para se olhar é o gdm.conf. Olhe a seção [xdmcp]. Você pode ver uma entrada naquela seção chamada 'Enable'. Deve estar mostrando '1' ou 'true', dependendo da versão do GDM. Aqui está um exemplo:
[xdmcp]
Enable=true
HonorIndirect=0
MaxPending=4
MaxPendingIndirect=4
MaxSessions=16
MaxWait=30
MaxWaitIndirect=30
Port=177
Note a linha 'Enable=true'. Versões antigas do GDM usam '0' e '1' para dizer se estão Disable ou Enable o remoto XDMCP. Novas versões usam 'false' e 'true'.
3.Estando o gerenciador de interface gráfica definitivamente funcionando, e escutando os pedidos de estações de trabaçho remotas, talvez seja um problema simples que ele não consegue mapear o endereço de IP até o hostname. As resytações de trabalho precisam então estar listadas no arquivo /etc/hosts file, ou precisam ser configuradas corretamente nas tabelas de DNS.
Capítulo 8. Kernels
Existem algumas decisões a serem tomadas quanto ao kernel que roda nas estações de trabalho. Você precisa escolher se quer rodar um dos kernels padrões disponíveis para dowload, ou construir o seu próprio. E, você precisa decidir se você quer mostrar a tela gráfica, completa com barra de progresso, que é possível pelo Linux Progress Patch (LPP).
8.1. Padrões de kernels LTSP disponíveis
O pacote de kernel que vem junto ao LTSP na verdade inclui dois kernels. Um que tem o Linux Progress Patch já configurado e rodando, e outro sem o patch.
Ambos os kernels têm o patch NFS Swap.
8.2. Monte seu próprio kernel
Existem duas formas de configurar um kernel para LTSP. O método padrão é usar algo chamado 'Initial Ram Disk', ou encurtando, o initrd. A imagem initrd é um pequeno sistema de arquivos que é pendurado no kernel. A imagem do sistema de arquivos initrd é aberta na memória, e uma vez que o ketnel é inicializado, irá montar o disco virtual como o seu sistema de arquivos raíz. Existem algumas vantagens em usar uma imagem initrd. Primeiro, nós podemos compilar os discos como módulos e rodar o módulo correto durante o bootup. Isso permite com que um simples kernel suporte virtualmente todos os tipos de placas de rede. A outra vantagem é que podemos rodar o cliente DHCP como um programa "user-land" ao contrário de em kernel-space. Rodando o cliente em user-land permite um melhor controle das opções requeridas e recebidas do servidor. E também faz com que o kernel fique ligeiramente menor. A outra forma de configurar o kernel é sem o initrd. Construindo um kernel sem um initrd requer que uma placa de rede específica esteja estaticamente ligada ao kernel, e também requer que IP-Autoconfig e "Root filesystem on NFS" estejam configurados quando construindo o kernel. A vantagem de não usar um initrd é que o kernel é ligeiramente menor, é irá inicializar um pouco mais rápido. Uma vez que as estações de trabalho estão funcionando, não existe muita diferença em como elas trabalham.
O kernel padrãp para LTSP inclui uma Initial disco virtual (initrd) que cuida de detectar a placa de rede, e fazendo um chamado de espaço para o DHCP. O objetivo maior dessa imagem é fazê-lo o menor possível. Então, por isso escolhemos a biblioteca de trocas uClinux libc, e busybox para os utilitários que precisaremos para a inicialização.
Se você quer construir seus próprios kernels, você deve baixar o pacote ltsp_initrd_kit. Ele contém a hierarquia do sistema de arquivos raiz, e um script para construir a imagem.
8.2.1. Obtendo o código-fonte para o kernel
Ao construir um kernel customizado, é geralmente uma boa idéia começar com fontes de kernel frescas, diretamente do site ftp.kernel.org. A razão para isso é que distribuições como o Redhat, aplicam muitos patches aos códigos-fonte de seus kernels, deixando você com um código-fonte que na verdade não combina com aquele do kernel oficial.
Baixe o pacote-fonte do seu kernel escolhido, e o salve no diretório /usr/src. Os kernels estão localizados no diretório /pub/linux/kernel no servidor ftp.kernel.org. Você deve pegar a recente série de kernels 2.4.x, porque você precisa incluir suporte ao devfs.
E também, se você quer incluir suporte para trocar o NFS ou o Linux Progress Patch (LPP), você deve certificar-se que os os patches e os códigos-fontes do kernel são os mesmos. Neste momento em que escrevo, o kernel mais recente que dá apoio à esses processos é o 2.4.9.
Para o nosso examplo, usaremos o kernel 2.4.9. O caminho completo para ele é: ftp://ftp.kernel.org/pub/linux/kernel/v2.4/linux-2.4.9.tar.bz2
Desempacote o código-fonte do kernel no diretório /usr/src. Você precisa tomar cuidado ao fazer isso já que ele estará em um diretório chamado linux, e você talvez já tenha um diretório com o mesmo nome com códigos-fontes diferentes, e você não quer bagunçá-lo. Então procure por um diretório linux existente, e se este houver, nomeie-o diferentemente antes de desempacotar.
O pacote-fonte que baixamos foi comprimido com a ferramenta de compressão bzip2. Então devemos desempacotá-lo antes de o jogarmos no programa tar. Você pode usar o seguinte comando para desempacotá-lo:
bunzip2 <linux-2.4.9.tar.bz2 | tar xf -
Quando o desempacotamento finalizar, você terá um diretório chamado linux contendo toda a árvore-fonte. Neste ponto, usualmente renomeia-se o diretório para algo mais informativo.
mv linux linux-2.4.9
Once the directory has been renamed, then change into the new directory:
cd linux-2.4.9
Eu normalmente gosto de modificar o Makefile antes de começar a configurar o novo kernel. No começo dele, está uma variável chamada EXTRAVERSION. Coloco-a como 'ltsp-1', para que o atual número da versão seja '2.4.9-ltsp-1', o que faz com que o kernel fique facilmente identificável mais tarde. A parte de cima do Makefile deve se parecer com isso quando você tiver acabado:
VERSION = 2
PATCHLEVEL = 4
SUBLEVEL = 9
EXTRAVERSION = -ltsp-1
KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)
8.2.2. Patches de Kernel
Depois de desempacotar o kernel, você deve ter vários patches que quer aplicar. Por examplo, o NFS Swap patch ou o Linux Progress Patch. Estes patches TÊM que ser aplicados antes de configurar o kernel.
8.2.2.1. NFS Swap patch
O NFS Swap patch permitirá com que o kernel das estações de trabalho usem um swapfile localizado no servidor NFS. Enquanto é normalmente recomendado ter memória suficiente na estação de trabalho para não requerer área de troca, as vezes pode ser difícil adicionar mais memória, especialmente em computadores velhos. Então, a habilidade de troca de NFS pode fazer com que um computador que antes era sucata, de fato tornar-se perfeitamente usável.
Se o diretório corrente é o /usr/src/linux-2.4.9, e o patch está em /usr/src, você pode fazer o seguinte teste com ele:
patch -p1 --dry-run <../linux-2.4.9-nfs-swap.diff
Isso irá testar o patch, para certificar-se que ele pode ser aplicado de forma limpa. SE terminar sem erros, então você pode aplicá-lo sem a opção --dry-run.
patch -p1 <../linux-2.4.9-nfs-swap.diff
8.2.2.2. Linux Progress Patch (LPP)
O Linux Progress Patch (LPP) permitirá com que você configure um logo gráfico que aparecerá durante o processo de inicialização. As mensagens normais de inicialização do kernel são re-direcionadas para uma outra tela tty, e instruções especiais são adicionadas aos scripts de inicialização, fazendo com que a barra de progresso reflita o quão longe o processo de inicialização foi.
Assim como o patch NFS Swap, você pode testar o patch LPP por este comando:
patch -p1 --dry-run <../lpp-2.4.9
Quando o teste completar positivamente, então você pode aplicar o patch com:
patch -p1 <../lpp-2.4.9
8.2.3. Configurando as opções de kernel
Você pode agora rodar o programa de configuração de kernel de sua preferência. Algumas opções são:
make xconfig
Este irá chamar a versão X Windows da ferramenta de configuração de kernel.
make menuconfig
Este irá chamar as versões (the curses based version) da ferramenta de configuração de kernel.
make config
Este irá chamar a versão simples uma-linha-de-cada-vez da ferramenta de configuração de kernel.
8.2.3.1. Configurações de kernel para usar com initrd
Configurar um kernel para usar com initrd requer que as seguintes opções estejam presentes:
Sistema de arquivos -> suporte ao sistema de arquivos /dev
O suporte ao sistema de arquivos /dev deverão estar permitidas. Isso é feito na seção 'File systems'. NÃO especifique 'Automatically mount at boot'. A montagem será feita pelo script /linuxrc.
Dispositivos de bloqueio -> suporte à placa RAM
Estações de trabalho LTSP requerem que o kernel suporte uma placa RAM. Isso é feito na seção 'Block devices' (Dispositivos de bloqueio).
Dispositivos de bloqueio -> suporte inicial à placa RAM (initrd)
Isso também deve estar permitido.
Tipo e características do processador -> família do processador
Você deve certificar-se que o kernel que você construiu pode de fato rodar na CPU da estação de trabalho. Isso é feito pela seção 'Processor type and features'. Você também deve desvalidar (turn off) o apoio a SMP a não ser que você de fato tenha múltiplas CPUs.
Sistema de arquivos -> sistema de arquivos de rede -> suporte a Clientes NFS
As estações de trabalho terão seus arquivos de sistema raíz montados via NFS, então suporte a clientes NFS são requiridos.
Isto deve dar conta das opções requeridas. Você também pode desvalidar muitas opções de kernel, para reduzir seu tamanho.
8.2.3.2. Configurações de kernel para uso sem o initrd
Configurando o kernel para uso sem o initrd é diferente de um kernel com initrd, de algumas formas:
Dispositivos de bloqueio -> suporte à placa RAM
Estações de trabalho LTSP requerem que o kernel suporte a placa RAM.
Dispositivos de bloqueio -> suporte inicial à placa RAM (initrd)
Este precisa estar desligado.
Opções de rede -> Nível de autoconfiguração IP:kernel
Este precisa estar ligado. Isso irá instruir o kernel a automaticamente configurar a interface ethernet eth0, baseado em valores passados na.
Não é necessário especificar as opções DHCP, BOOTP ou RARP porque o Etherboot bootrom já faz um pedido DHCP ou BOOTP, e fará com que os parâmetros de IP fiquem disponíveis na linha de comando do kernel. Isso faz com que o kernel evite o trabalho de chamar a si mesmo.
Suporte a dispositivo de rede -> Ethernet (10 ou 100Mbit)
Não usando o initrd, você deve escolher um dispositivo de placa de rede específico que corresponda à sua placa de rede. Isso DEVE estar estaticamente conetado ao kernel, porque a interface ethernet é necessária antes de montar o sistema de arquivos raiz. Essa é a maior diferença de um kernel com initrd.
Sistemas de arquivo -> suporte a sistemas de arquivo /dev
A partir do LTSP versão 2.09pre2, suporte a devfs é necessário. Isso é verdade, não importando se o initrd é usado ou não.
Sistemas de arquivo -> montar automaticamente na inicialização
NÃO usando o initrd, o sistema de arquivos /dev deve ser montado pelo kernel, durante o processo de inicialização. Então diga 'Y' (yes/sim) aqui.
Sistemas de arquivo -> sistemas de arquivo de rede -> suporte a cliente NFS
As estações de trabalho terão seus sistema de arquivos raiz montados via NFS, então suporte a clientes NFS é necessário.
8.2.4. Construindo o kernel
Para facilitar as coisas, uma cópia do arquivo.config está incluso no pacote ltsp_initrd_kit. Você pode copiá-lo para o diretório /usr/src/linux-2.4.9.
Uma vez que você selecionou ou des-selecionou as opções de kernel, você precisa construí-lo. Os comandos a seguir precisam ser executados para construir o kernel:
make dep
make clean
make bzImage
make modules
make modules_install
Você pode escrevê-los em sequência, assim:
make dep && make clean && make bzImage && make modules && make modules_install
O sinal duplo (&) significa que se o primeiro comando completar com sucesso, então o segundo comando será executado. Se o segundo comando for executado com sucesso, então o terceiro comando será executado, e por aí vai.
Quando a compilação de kernel terminar, o novo kernel estará em /usr/src/linux-2.4.9/arch/i386/boot/bzImage.
8.2.5. Marcando o kernel para Etherboot
Para o Etherboot lidar com um kernel Linux, ele precisa estar preparado. Isso é chamdo de 'Tagging' (Marcar) o kernel. Este processo irá adicionar mais código ao kernel, que por sua vez é executado antes que o controle passe para ele. A ferramenta para marcar o kernel é chamada ' mknbi-linux'.
O ltsp_initrd_kit inclui um script shell chamado buildk que inclui todos so comandos que você precisa para preparar a imagem do kernel para inicilização em rede.
Capítulo 9. Entradas lts.conf
Quando fizemos o LTSP, um dos assuntos que sabíamos que teríamos que lidar com, era a variedade de configurações de hardware das estações de trabalho. Certamente, qualquer combinação de processador, placa de rede, e placa de vídeo disponível hoje, não mais ocorreria daqui a três meses, quando quiséssemos adicionar mais estações de trabalho à rede.
Então, criamos uma maneira de especificar a configuração de cada estação de trabalho. Este arquivo de configuração é o lts.conf e fica no diretório /opt/ltsp/i386/etc.
O formato do lts.conf permite configurações 'padrões' assim como uma configuração específica para cada estação de trabalho. Se todas as suas estações de trabalho são idênticas, você pode especificar todas as suas configurações na seção padrão '[Default]'.
9.1. Exemplo de arquivo lts.conf
Um exemplo de arquivo lts.conf:
[Default]
SERVER = 192.168.0.254
X_MOUSE_PROTOCOL = "PS/2"
X_MOUSE_DEVICE = "/dev/psaux"
X_MOUSE_RESOLUTION = 400
X_MOUSE_BUTTONS = 3
USE_XFS = N
SCREEN_01 = startx
[ws001]
XSERVER = auto
X_MOUSE_PROTOCOL = "Microsoft"
X_MOUSE_DEVICE = "/dev/ttyS1"
X_MOUSE_RESOLUTION = 50
X_MOUSE_BUTTONS = 3
X_MOUSE_BAUD = 1200
[ws002]
XSERVER = XF86_Mach64
[ws003]
SCREEN_01 = shell
9.2. Parâmetros lts.conf disponíveis
9.2.1. Parâmetros gerais
Comentários
Comentários começam com o sinal '#' e continuam até o fim da linha.
LTSP_BASEDIR
Isso indica onde o sistema de arquivos raíz LTSP está localizado. O padrão é /opt/ltsp
SERVER
Este é o servidor que é usado para XDM_SERVER, TELNET_HOST, XFS_SERVER e SYSLOG_HOST, caso nenhum destes esteja especificado explicitamente. Se você tem uma máquina que está como servidor para tudo, então você deve especificar aqui somente o endereço, e omitir os outros parâmetros de servidor. Se este valor não está estabelecido, 192.168.0.254 será usado.
SYSLOG_HOST
Se você quer mandar mensagens de log para uma máquina que não seja o servidor padrão, então você pode especificar a máquina aqui. Caso este parâmetro não seja epecificado, então será usado o parâmetro 'SERVER' descrito acima.
NFS_SERVER
Este especifica o endereço IP do servidor NFS usado quando o sistema de arquivos /home é montado. O padrão é qualquer um que o SERVER esteja configurado para.
USE_NFS_SWAP
Coloque Y (yes/sim) caso você queira ativar a troca NFS. O padrão é N (no/não).
SWAPFILE_SIZE
Este é como você controla o tamanho do arquivo de troca (swapfile). O padrão é 64m.
SWAP_SERVER
O arquivo de troca pode existir em qualquer servidor na rede que é capaz de lidar com ele. Aqui você pode especificar o endereço de IP deste servidor. O padrão é qualquer um que o NFS_SERVER esteja indicando.
NFS_SWAPDIR
O diretório no servidor que está sendo exportado via NFS. O padrão é /var/opt/ltsp/swapfiles. Certifique-se que o diretório está sendo exportado no arquivo /etc/exports.
TELNET_HOST
Se a estação de trabalho está configurada para ter uma interface de texto, (character based) então o valor deste parâmetro será usado como hospedeiro para x (hosto to telnet into). Caso este valor NÃO esteja especificado, então o valor do SERVER acima será usado.
DNS_SERVER
Usado para construir o arquivo resolv.conf.
SEARCH_DOMAIN
Usado para construir o arquivo resolv.conf.
SCREEN_01 thru SCREEN_12
Até 12 scripts de tela podem ser especificados para cada estação de trabalho. Isto te permitirá 12 sessões na estação, cada uma acessível pelo clique Ctrl-Alt-F1 através das chaves Ctrl-Alt-F12.
SCREEN_01 = startx
SCREEN_02 = shell
No momento, valores possíveis incluem:
startx
telnet
rdesktop
shell
Olhe o diretório /opt/ltsp/i386/etc/screen.d para mais scripts de tela, ou escreva os seus, e coloque-os aqui.
MODULE_01 até MODULE_10
Até 10 módulos de kernel podem ser carregados usando estas configurações de entrada. A linha de comando inteira que você usará quando rodar insmod pode ser especificada aqui. Por exemplo:
MODULE_01 = uart401.o
MODULE_02 = "sb.o io=0x220 irq=5 dma=1"
MODULE_03 = opl3.o
Se o valor desse parâmetro é um pathname absoluto, então insmod será usado para carregar o módulo. Ou então, modprobe será usado.
RAMDISK_SIZE
Quando as estações de trabalho inicializam, elas criam um disco virtual e montam no diretório /tmp. Você pode controlar o tamanho do sistema de aqruivo com este parâmetro. Especifique em unidades de kbytes (1024 bytes). Para criar um disco virtual de 1 megabyte, especifique RAMDISK_SIZE = 1024
Se voc trocar o tamanho do disco virtual aqui, você também terá que trocar o tamanho do disco virtual dentro do kernel. Isso pode ser compilado, ou se você está usando Etherboot ou Netboot, você diz ao kernel o tamanho do disco virtual quando você marca o kernel com o mknbi-linux.
O valor padrão para ela é 1024 ( 1 mb )
RCFILE_01 thru RCFILE_10
Outros scripts RC podem ser executados pelo script rc.local. Apenas coloque-o no diretório /etc/rc.d e especifique seu nome em uma dessas entradas.
SOUND
Se o pacote LTSP Sound está instalado, você precisa colocar nesta entrada Y (yes/sim), e ela executará o scrpit rc.sound para configurar a placa de som e o daemon. O padrão é N (no/não).
9.2.2. Parâmetros X-Windows
XDM_SERVER
Caso você queira apontar XDM para uma outra máquina ao invés do servidor padrão, você pode especificar este outro servidor aqui. Se este parâmetro não estiver especificado, então será usado o parâmetro estabelecido acima em 'SERVER'.
XSERVER
Este define qual servidor X as estações de trabalho irão rodar. Para placas de vídeo PCI e AGP, este parâmetro não precisa ser estabelecido. O script rc.local deverá ser capaz de auto-detectar a placa. Você também pode colocar este valor para auto indicando que deve tentar auto-detectar a placa.
Para placas de vídeo ISA, ou para forçar um servidor X específico, você deve especificar o nome do dispositivo ou servidor X nesta entrada.
Se esse valor começa com XF86_, então XFree86 3.3.6 será usado. Ou então, X.org 6.7.0 será usado. O valor padrão é auto.
X_MODE_0 até X_MODE_2
Até 3 Modelines ou resoluções podem ser configuradas para a estação de trabalho. Esta entrada pode ter dois tipos de valor. Pode ser tanto uma resolução, quanto um modeline completo.
X_MODE_0 = 800x600
or
X_MODE_0 = 800x600 60.75 800 864 928 1088 600 616 621 657 -HSync -VSync
Caso nenhuma das entradas X_MODE_x forem especificadas, então usará os modelines emb modelines utidos, e as resoluções 1024x768, 800x600 e 640x480.
Caso uma ou mais entradas X_MODE_x forem especificadas, elas irão sobrepor-se completamente aos modelines embutidos.
X_MOUSE_PROTOCOL
Qualquer valor que funcione para a palavra-chave X.org Pointer Protocol pode ser colocada aqui. Valores típicos incluem "Microsoft" e "PS/2". O valor padrão é "PS/2".
X_MOUSE_DEVICE
Este é o dispositivo com o qual o mouse está conectado. Se é um mouse serial, esta deve ser uma porta serial, como /dev/ttyS0 ou /dev/ttyS1. Se é um mouse de teclado PS/2, este valor será /dev/psaux. O valor padrão é /dev/psaux.
X_MOUSE_RESOLUTION
Este é o valor de 'resolução' do arquivo XF86Config. Um valor típico para um mouse serial é 50 e para um mouse PS/2 400 . O valor padrão é 400.
X_BUTTONS
Este indica ao sistema quantos botões o mouse têm. Normalmente esta configurado para 2 ou 3. O valor padrão é 3.
X_MOUSE_EMULATE3BTN
Este indica para o servidor X emular um mouse de 3 botões, aceitando um clique do botão direito e esquerdo ao mesmo tempo. O valor padrão é N (no/não).
X_MOUSE_BAUD
Para um serial mice, isto define o tempo de x (baud rate). O valor padrão é 1200.
X_COLOR_DEPTH
Este é o número de bits a serem usados para a resolução de cor (color depth). Valores possíveis são 8, 15, 16, 24 e 32. 8 bits indicará 256 cores, 16 serão 65536 cores, 24 serão 16 milhões de cores e 32 bits serão 4.2 bilhões de cores! Nem todos os servidores X suportam todos esses valores. O valor padrão é 16
USE_XFS
Você pode escolher entre rodar o X Font Server (XFS) ou ler as fontes através do sistema de arquivos NFS. O servidor de fontes deve ter uma forma simples de manter todas as fontes em um só lugar, mas têm havido alguns problemas quando o número de estações excede 40. Os 2 valores para esta opção são Y (yes/sim) and N (no/não). O valor padrão é N (no/não). Caso você queira usar um servidor de fontes, você pode usar a entrada XFS_SERVER para especificar qual hospedeiro será o seu servidor de fonte.
XFS_SERVER
Caso você esteja usando o X Font Server para servir fontes, então você pode usar esta entrada para especificar o endereço IP do hospedeiro que está sendo usado como servidor de fontes. Caso ele não esteja especificado, irá usar o servidor padrão, que está especificado na entrada SERVER acima.
X_HORZSYNC
Este configura o parâmetro X.org HorizSync . O valor padrão é "31-62".
X_VERTREFRESH
Este configura o parâmetro X.org VertRefresh. O valor padrão é "55-90".
XF86CONFIG_FILE
Caso você queira criar todo o seu arquivo XF86Config você pode fazer isto, e colocá-lo no diretório /opt/ltsp/i386/etc. Então, qualquer um que você decida chamar deve entrar como um valor para esta variável de configuração. Por exemplo:
XF86CONFIG_FILE = XF86Config.ws004
9.2.3. Parâmetros de Touch screen
USE_TOUCH
Se você está conectando uma touch screen à estação de trabalho, você pode ativá-la configurando esta entrada para Y (yes/sim). Caso ativada, entradas de configuração adicionais configurarão aspecvtos específicos da touch screen. O valor padrão é N .
X_TOUCH_DEVICE
Uma touch screen funciona como um mouse e usualmente está conectada à uma estação de trabalho através de uma porta serial. Você pode especificar qual porta serial com esta entrada. Por exemplo, você pode deixá-la igual a /dev/ttyS0. Não há valor padrão para esta entrada.
X_TOUCH_MINX
Entrada de calibração para uma touch screen EloTouch. O padrão é 433.
X_TOUCH_MAXX
Entrada de calibração para uma touch screen EloTouch. O padrão é 3588.
X_TOUCH_MINY
Entrada de calibração para uma touch screen EloTouch. O padrão é 569.
X_TOUCH_MAXY
Entrada de calibração para uma touch screen EloTouch. O padrão é 3526.
X_TOUCH_UNDELAY
Entrada de calibração para uma touch screen EloTouch. O padrão é 10.
X_TOUCH_RPTDELAY
Entrada de calibração para uma touch screen EloTouch. O padrão é 10.
9.2.4. Parâmetros Local apps
LOCAL_APPS
Caso você deseje ahabilidade de rodar aplicativos localmente em uma estação de trabalho, deixe esta variável como Y (yes/sim). Muitos passos adicionais devem ser tomados no servidor para permitir local apps. Veja a seção 'Local Apps' no manual LTSP para mais informações. O valor padrão é N.
NIS_DOMAIN
Caso você configure LOCAL_APPS, então você deve ter um servidor NIS na rede. A entrada NIS_DOMAIN é onde você especifica o nome de domínio NIS. É necesário que combine com um nome de domínio definido no servidor NIS. Isso NÃO é a mesma coisa que um nome de domínio de internet. O valor padrão é ltsp.
NIS_SERVER
Configure este para o endereço de IP do seu servidor NIS caso você não queira que ele transmita um pedido de servidor NIS.
9.2.5. Parâmetros de teclado
Todos os arquivos de suporte de teclado estão copiados na hierarquia /opt/ltsp/i386, então configurar suporte de teclado internacional é feito simplesmente configurando o X.org. Existem uma série de parâmetros de configuração para isso.
Os valores para os parâmetros acima são da documentação X.org. O que estiver válido para o X.org é válido para estes parâmetros.
Gostaríamos de adicionar documentação mostrando quais valores são necessários para cada tipo de teclado internacional. Se você trabalha com isso e pode configurar seus teclados internacionais, nos contate com esta informação. Ficaremos muito agradecidos.
XkbTypes
O valor padrão é a palavra 'default '.
XkbCompat
O valor padrão é a palavra 'default '.
XkbSymbols
O valor padrão é 'us(pc101)'.
XkbModel
O valor padrão é 'pc101'.
XkbLayout
O valor padrão é 'us'.
9.2.6. Parâmatros de configuração da impressora
Até três impressoras podem ser conectadas a uma estação de trabalho sem disco rígido. Uma combinação de impressoras seriais e paralelas podem ser configuradas pelas entradas do arquivo lts.conf a seguir:
PRINTER_0_DEVICE
O nome do dispositivo da primeira impressora. Nomes como /dev/lp0, /dev/ttyS0 ou /dev/ttyS1 são permitidos.
PRINTER_0_TYPE
O tipo de impressora. Escolhas válidas são 'P ' para Paralela, e 'S' para Serial.
PRINTER_0_PORT
baud rate O número da porta TCP/IP a ser usada. Por padrão, usará a ' 9100'
PRINTER_0_SPEED
Caso a impressora seja serial, esta é a configuração que selecionará a baud rate. O padrão '9600' será usado.
PRINTER_0_FLOWCTRL
Para impressoras seriais, o controle de fluxo pode ser especificado. ' S' para controle de fluxo Software (XON/XOFF), ou 'H ' para controle de fluxo Hardware (CTS/RTS). Caso nenhum destes esteja especificado, ' S' será usado.
PRINTER_0_PARITY
Para impressoras seriais, a Paridade pode ser especificada. As escolhas são: 'E'-Even, 'O'-Odd ou 'N'-None. Caso não seja especificado, 'N' será usado.
PRINTER_0_DATABITS
Para impressoras seriais, o número de data bits pode ser especificado. As escolhas são: '5', '6', '7' e '8'. Caso não seja especificado, '8' será usado.
PRINTER_1_DEVICE
Nome do dispositivo da segunda impressora
PRINTER_1_TYPE
Tipo de dispositivo da segunda impressora
PRINTER_1_PORT
Dispositivo de porta TCP/IP da segunda impressora
PRINTER_1_SPEED
Baud rate (serial) da segunda impressora
PRINTER_1_FLOWCTRL
Controld de fluxo da segunda impressora (serial)
PRINTER_1_PARITY
Paridade da segunda impressora (serial)terceira impressora
PRINTER_1_DATABITS
Data bits da segunda impressora (serial)
PRINTER_2_DEVICE
Nome do dispositivo da terceira impressora
PRINTER_2_TYPE
Tipo de dispositivo da terceira impressora
PRINTER_2_PORT
Porta do dispositivo TCP/IP da terceira impressora
PRINTER_2_SPEED
Baud rate da terceira impressora (serial)
PRINTER_2_FLOWCTRL
Controle de fluxo da terceira impressora (serial)
PRINTER_2_PARITY
Paridade da terceira impressora (serial)
PRINTER_2_DATABITS
Data bits ad terceira impressora (serial)
Capítulo 10. Aplicativos Locais
Em um ambiente LTSP, você pode escolher entre rodar os aplicativos localmente na estação de trabalho, ou remotamente no servidor.
De longe, a forma mais fácil de configurar um ambiente LTSP é rodar os aplicativos no servidor. Isso é, a aplicação cliente roda no servidor, usando a CPU e memória do servidor, enquanto mostra o seu output nas estações de trabalho e usa mouse e teclado da estação de trabalho.
Esta é a capacidade fundamental das Janelas X. As estações de trabalgo trabalham exatamente como um terminal X Windows padrão.
Para rodar um aplicativo na estação de trabalho, estas precisam saber algumas informações sobre o usuário. Informações como estas:
Identidade do usuário
Grupo primário que o usuário pertence
O diretório home dos usuários
LTSP conta com o Network Information Service - NIS, (formalmente chamado Yellow Pages/Páginas Amarelas) para montar a informação de usuários e grupos disponíveis nas estações de trabalho.
10.1. Benefícios de rodar aplicativos localmente
Existem benefícios de se rodar apliucativos nas estações de trabalho.
Reduz o trabalho no servidor. Em redes grandes com aplicativos de memória intensa, como o Netscape, rodar os aplicativos nas estações de trabalho pode obter uma melhor performance, contanto que as estações de trabalho sejam fortes o suficiente para segurar a onda.
Aplicativos fugitivos (runaway) não afetarão outros usuários.
Suporte a som é bem mais fácil de configurar quando o aplicativo que toca o som está rodando nas estações de trabalho.
10.2. Considerações ao configurar suporte a aplicativos locais
Configurar a habilidade de rodar aplicativos localmente requer muito mais.
Maior demanda nas estações de trabalho. Ela precisará de mais RAM e uma CPU poderosa. 64mb de ram nas estações de trabalho é um bom começo.
NIS – Para rodar os aplicativos nas estações de trabalho, você deve primeiramente se identificar nas estações de trabalho. Isso quer dizer que elas precisam saber quem você é. Isso requer alguma forma de autenticação por senha. NIS foi escolhido como o método de autenticação de usuários pela rede.
Diretórios adicionais precisam ser exportados das estações de trabalho para serem montados via NFS.
Inicialização mais lenta dos aplicativos, porque eles precisam ser lidos via NFS, causando aumento de atividade de rede. E também porque cada cópia do programa está rodando em sua própria CPU, você não terá a vantagem da habilidade do Linux/Unix de compartilhar segmentos de código entre múltiplas instâncias do mesmo programa, que reduziria o tempo do segundo e demais chamados do programa.
10.3. Configurações do servidor para aplicativos locais
10.3.1. Entradas lts.conf
Algumas poucas entradas têm que ser configuradas no arquivo lts.conf:
LOCAL_APPS
Precisam estar como Y (yes/sim). Isso irá provocar o seguinte processo nas estações do trabalho durante o processo de inicialização:
1.O diretório /home no servidor será montado via NFS.
2. /var/yp/nicknames será criado nas estações de trabalho.
3.O portmapper será iniciado nas estações de trabalho.
4.xinetd será iniciado nas estações de trabalho.
5.O arquivo /etc/yp.conf será criado nas estações de trabalho.
6.O comando domainname rodará com o valor da entrada do lts.conf NIS_DOMAIN.
7.O ypbind rodará nas estações de trabalho.
NIS_DOMAIN
Com NIS, todos os nodos da rede que querem se associar com um servidor NIS específico precisam pertencer ao mesmo domínio NIS (isso não se relaciona de nehuma forma com o domínio DNS). Você usa a entrada NIS_DOMAIN para especificar o nome do domínio NIS do qual a estações de trabalho farão parte.
NIS_SERVER
NIS tentará usar um servidor NIS específico, ou mandará um chamado para a rede, procurando por um servidor. Se você quer escolher um servidor específico, então coloque o endereço de IP deste servidor na entrada NIS_SERVER.
10.3.2. Nestações de trabalhoetwork Information Service - NIS
NIS é um tipo de serviço Client/Server. No servidor, existe um daemon rodando, que aceitará chamados de clientes (estações de trabalho). Este daemon no servidor é chamado ypserv.
Nas estações de trabalho, existe um processo chamado ypbind. Quando as estações de trabalho precisam checar informação sobre um usuário, como verificar uma senha ou achar seu diretório home, usará ypbind para estabelecer uma conexão com ypserv, no servidor.
Se você já está rodando NIS no seu ambiente de rede, então não é necessário configurar o servidor LTSP para também rodar ypserv. Você só precisa configurar o NIS_DOMAINNAME e as entradas NIS_SERVER em lts.conf para combinar com o seu esquema NIS.
Se você NÃO está rodando NIS em sua rede, então você terá que configurar o servidor para rodar ypserv.
Para informações completas sobre a configuração de um servidor NIS, cheque o documento HOWTO do site LDP chamado The Linux NIS(YP)/NYS/NIS+ HOWTO. Olhe a lista de outras fontes de informação ao final deste documento.
10.4. Configurações de aplicativos
Ao configurar um aplicativo para rodar nas estações de trabalho, você deve colocar todos os componentes deste aplicativo em um lugar que a estação de trabalho possa ver.
Com versões antigas de LTSP (2.08 e anteriores), muitos diretórios eram exportados para o servidor e montados pela estação de trabalho. Diretórios como /bin, /usr/bin , /lib e /usr eram expostos para a estação de trabalho.
O problema com este esquema é que ele funciona apenas se a estação de trabalho e o servidor são a mesma arquitetura. De fato, até diferenças como o servidor ser um Pentium II (i686) e as estações de trabalho serem um Pentium (i586) clássico podem ser um problema, porque o servidor provavelmente terá bibliotecas i686 e não bibliotecas i386, i486 ou i586.
Então, a forma mais limpa de se lidar com isso é ter uma árvore completa com todos os binários e bibliotecas que a estação de trabalho precisará, independente dos binários e bibliotecas do servidor.
Configurando um aplicativo para uma execução local requer colocar todas as peças requeridas nesta árvore. Um dos pacotes disponíveis para baixar do site LTSP é o pacote Local netscape, que instala vários arquivos no diretório /opt/ltsp/i386/usr/local/netscape. Coisas como aulas de java (java classes), arquivos de ajuda, arquivos binários executáveis e scripts são colocados aqui.
Netscape não precisa de nenhum sistema de biblioteca adicional, então não há nada a adicionar ao diretório /opt/ltsp/i386/lib. Muitos aplicativos requerem bibliotecas adicionais.
Então, como você pode determinar quais bibliotecas precisa? Eis que a resposta sureg no comando ldd.
Vamos pressupor que você quer configurar um certo aplicativo para rodar localmente. Vamos dizer o gaim, por exemplo. gaim é um cliente de mensageiro instantâneo da AOL, que permite com que você se comunique com outras pessoas nos fóruns AOL. ???!!
A primeira coisa que você precisa fazer é achar o arquivo binário executável gaim. No sistema Redhat 7.2, ele está localizado no diretório /usr/bin.
Uma vez que você localizou o binário gaim, você pode rodar ldd para ver suas dependências:
[jam@server /]$ ldd /usr/bin/gaim
libaudiofile.so.0 => /usr/lib/libaudiofile.so.0 (0x40033000)
libm.so.6 => /lib/i686/libm.so.6 (0x40051000)
libnsl.so.1 => /lib/libnsl.so.1 (0x40074000)
libgnomeui.so.32 => /usr/lib/libgnomeui.so.32 (0x4008a000)
libart_lgpl.so.2 => /usr/lib/libart_lgpl.so.2 (0x4015d000)
libgdk_imlib.so.1 => /usr/lib/libgdk_imlib.so.1 (0x4016c000)
libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40191000)
libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x4019a000)
libgtk-1.2.so.0 => /usr/lib/libgtk-1.2.so.0 (0x401b1000)
libdl.so.2 => /lib/libdl.so.2 (0x402df000)
libgdk-1.2.so.0 => /usr/lib/libgdk-1.2.so.0 (0x402e3000)
libgmodule-1.2.so.0 => /usr/lib/libgmodule-1.2.so.0 (0x40319000)
libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x4031d000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40325000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40333000)
libgnome.so.32 => /usr/lib/libgnome.so.32 (0x40411000)
libgnomesupport.so.0 => /usr/lib/libgnomesupport.so.0 (0x40429000)
libesd.so.0 => /usr/lib/libesd.so.0 (0x4042e000)
libdb.so.2 => /usr/lib/libdb.so.2 (0x40436000)
libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x40444000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x40468000)
libc.so.6 => /lib/i686/libc.so.6 (0x40495000)
libz.so.1 => /usr/lib/libz.so.1 (0x405d1000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
A listagem acima mostra todas as bibliotecas que o programa gaim está dinamicamente dependente.
A maior parte dos programas que usam bibliotecas compartilhadas, confiam no dinâmico buscador (loader) ld-linux para localizar e baixar cada uma das bibliotecas compartilhadas. Alguns programas, no entanto, baixam as bibliotecas manualmente com a função de chamado dlopen(). Para estes aplicativos, ldd não mostrará as bibliotecas. Neste caso, strace pode ser usado para traçar a execução de um programa, e você verá os chamados de dlopen(), com o nome da biblioteca listada nos argumentos.
Uma vez que a lista de bibliotecas foi coletada, as bibliotecas requeridas precisarão ser copiadas para seus lugares apropriados na árvore /opt/ltsp/i386.
10.5. Ativando aplicativos locais
Nas janelas X, programas rodam tipicamente relativos ao lugar em que o gerenciador de janelas roda. Isso significa que se o gerenciador de janelas está rodando no servidor, mostrando o seu resultado (output) nas estações de trabalho, então quaisquer programas que forem ativados, também rodarão no servidor, mandando o seu output para a estação de trabalho.
O truque é ter o servidor informando as estações de trabalho para ativar o programa. Isso é tipicamente feito com o comando rsh.
Aqui está um exemplo de com o rodar o programa gaim em uma estação de trabalho:
HOST=`echo $DISPLAY | awk -F: '{ print $1 }'`
rsh ${HOST} /usr/bin/gaim -display ${DISPLAY}
O examplo acima pode ser inserido em uma janela xterm, ou pode ser colocado em um script shell,e ser ativado por um ícone na área de trabalho.
Ativando o local Netscape é feito de forma parecida, mas uma variável ambiente adicional precisa ser estabelecida, antes de rodar o programa.
HOST=`echo $DISPLAY | awk -F: '{ print $1 }'`
rsh ${HOST} MOZILLA_HOME=/usr/local/netscape \
/usr/local/netscape/netscape -display ${DISPLAY}
Capítulo 11. Exemplos de configuração
Praticamente qualquer aspecto de uma estação de trabalho pode ser configurada com entradas no lts.conf, que é normalmente localizado no diretório /opt/ltsp/i386/etc.
11.1. Mouse Serial
Este é um exemplo de uma entrada lts.conf para um mouse padrão serial de 2 botões:
X_MOUSE_PROTOCOL = "Microsoft"
X_MOUSE_DEVICE = "/dev/ttyS0"
X_MOUSE_RESOLUTION = 400
X_MOUSE_BUTTONS = 2
X_MOUSE_EMULATE3BTN = Y
11.2. Mouse PS/2 (Wheel mouse)
Este é um exemplo de uma entrada lts.conf para um Intellimouse:
X_MOUSE_PROTOCOL = "IMPS/2"
X_MOUSE_DEVICE = "/dev/psaux"
X_MOUSE_RESOLUTION = 400
X_MOUSE_BUTTONS = 5
X_ZAxisMapping = "4 5"
11.3. Impressora USB em uma ThinkNic
A estação de trabalho ThinkNIC tem uma porta USB, que pode ser usada para conectar uma impressora local. Este é um exemplo de entrada requerida no arquivo lts.conf:
MODULE_01 = usb-ohci
MODULE_02 = printer
PRINTER_0_DEVICE = /dev/usb/lp0
PRINTER_0_TYPE = S
11.4. Forçando uma estação de trabalho a rodar um servidor X Free86 3.3.6 X
Por padrão, X.org 6.7.0 será usado na estação de trabalho. Se você quer forçar a estação de trabalho a usar uma versão mais antiga como o servidor X XFree86 3.3.6, você terá que primeiro ativar o pacote 3.3.6 Xserver. Então, você deverá adicionar a entrada no arquivo lts.conf. Este é um exemplo para especificar um servidor X SVGA:
XSERVER = XF86_SVGA
Capítulo 12. Outras fontes de informação
12.1. Referências Online
1.O site oficial LTSP
www.LTSP.org
2.O documento para Linux Diskless-Nodes HOW-TO
www.linuxdoc.org/HOWTO/Diskless-HOWTO.html
3.Página do Etherboot
etherboot.sourceforge.net
4.Site Rom-O-Matic
www.Rom-O-Matic.net
5.Suporte para Mouse X.org
www.xfree86.org/current/mouse.html
6.XFree86-Video-Timings-HOWTO
www.linuxdoc.org/HOWTO/XFree86-Video-Timings-HOWTO.html
7.Linux NIS(YP)/NYS/NIS+ HOWTO
www.linuxdoc.org/HOWTO/NIS-HOWTO.html
12.2. Publicações Impressas
1.Managing NFS and NIS
Hal Stern
O'Reilly & Associates, Inc.
1991
ISBN 0-937175-75-7
2.TCP/IP Illustrated, Volume 1
W. Richard Stevens
Addison-Wesley
1994
ISBN 0-201-63346-9
3.X Window System Administrator's Guide
Linda Mui and Eric Pearce
O'Reilly & Associates, Inc.
1993
ISBN 0-937175-83-8
(Volume 8 of the The Definitive Guides to the X Window System)
- 3529 leituras
Comentários recentes
1 ano 31 semanas atrás
2 anos 6 dias atrás
2 anos 2 semanas atrás
2 anos 16 semanas atrás
2 anos 16 semanas atrás
2 anos 18 semanas atrás
2 anos 19 semanas atrás
2 anos 19 semanas atrás
2 anos 19 semanas atrás
2 anos 19 semanas atrás