Figura 2-1. Instalador LTSP - Tela Principal
<
jam@LTSP.org>
Copyright © 2005 James A. McQuillan
| Histórico de Revisões | ||
|---|---|---|
| Revisão 4.1.3 | 2004-06-20 | Revisado por: jam |
| Revisão 4.1.3-0a-ptbr | 2005-11-12 | Revisado por: aac |
O LTSP fornece um meio simples de utilizar estações de baixo custo como terminais gráficos ou caracteres em um servidor GNU/Linux.
Em uma configuração tradicional de escritório há PC's relativamente potentes baseados em processadores Intel em cada mesa de trabalho. Cada um com muitos gigabytes de espaço em disco. Os usuários armazenam seus dados no disco local, e cópias de segurança são raramente (quando são) realizadas.
Será que realmente faz sentido ter um computador completo em cada mesa?
Dizemos que não.
Por sorte, há outro meio. Utilizando o LTSP, você pode ter PC's baratos, remover seu disco rígido, disquete, CD-ROM, e adicionar uma placa de rede com suporte a boot por rede. Muitas placas de rede possuem encaixes, apenas esperando por um chip de boot ser instalado.
Durante a fase de boot, a estação sem disco obtém suas informações IP e o kernel do servidor, e então monta o sistema de arquivos raíz via NFS.
A estação de trabalho pode ser configurada em um dos três modos:
Usando o X Windows, a estação de trabalho pode ser usada para acessar qualquer aplicação no servidor, ou em outros servidores na rede.
A estações de trabalho pode obter múltiplas sessões telnet no servidor. Cada sessão telnet estará em uma janela virtual separada. Pressionando Alt-F1 até Alt-F9 irá alternar entre as sessões.
A estação de trabalho pode ser configurada para cair diretamente em um shell bash no console. Isto é muito útil quando estiver depurando problemas com o X Windows ou NFS.
Uma coisa realmente interessante é que você pode ter várias estações de trabalho conectadas a um único servidor GNU/Linux. Quantas estações de trabalho? Bem, isto depende da capacidade do servidor e das aplicações que serão usadas.
Não é comum ter 50 estações de trabalho, todas utilizando o Mozilla e OpenOffice.org em uma Dual P4-2.4 com 4GB de ram. Nós sabemos que funciona. De fato, a carga média estará raramente acima de 1.0.
Nem o autor ou distribuidores, ou qualquer outro contribuidor deste documento é responsável de qualquer forma por danos físicos, financeiros, morais ou qualquer outro tipo ocorridos por seguir sugestões deste texto.
This document is copyright 2004 by James McQuillan, and is released under the terms of the GNU Free Documentation License, which is hereby incorporated by reference.
Iniciar uma estação sem disco envolve alguns passos. Entender o que está acontecendo ao longo do processo irá tornar muito mais fácil a solução de problemas se eles chegarem a acontecer.
Há quatro serviços básicos que são necessários para iniciar uma estação LTSP. São eles:
O LTSP é muito flexível. Cada um dos serviços relacionados acima podem ser oferecidos pelo mesmo servidor, ou de diferentes servidores. Por exemplo, iremos descrever uma configuração simples, na qual consiste de um único servidor, fornecendo todos os serviços acima.
Cada um dos métodos acima será explicado neste capítulo.
O arquivo de swap será então ativado, através do comando swapon.
serão todos criados.
Isto fará com que todas as entradas no arquivo /etc/inittab sejam executadas.
Mais entradas podem ser configuradas no inittab para mais sessões, se desejado.
Há um parâmetro chamado XSERVER no arquivo lts.conf, Se este parâmetro estiver faltando, ou configurado para "auto", então uma detecção automática da placa de vídeo será tentada. Se a placa for PCI ou AGP, então serão obtidos o PCI Vendor e o Device id, e feita uma busca no arquivo /etc/vidlist.
Se a placa for suportada pelo Xorg 6.7, a rotina pci_scan irá retornar o nome do módulo do driver. Se esta for suportada apenas pelo XFree86 3.3.6, o pci_scan irá retornar o nome do servidor X a ser usado. O script startx pode informar a diferença por que os nomes dos módulos do X Server 3.3.6 começam com 'XF86_', enquanto na nova versão do X Server Xorg, os nomes dos módulos são tipicamente em minúsculas, como ati ou trident.
O arquivo XF86Config será criado, baseado nas entradas do arquivo /etc/lts.conf.
Em um primeiro momento, isto confunde muitas pessoas. Elas estão à estação, mas elas estão executando uma sessão no servidor. Todos os comandos que elas executam, serão executados no servidor, mas a saída será mostrada na estação.
Pôr o kernel Linux dentro das memórias das estações pode ser feito de várias maneiras.
O Etherboot é um projeto de bootrom open-source muito popular. Ele contém drivers para muitas placas de rede comuns, e funciona muito bem com o LTSP.
O kernel Linux kernels precisa ser 'rotulado' com o mknbi-linux, o qual irá preparar o kernel para boot via rede, através da prefixação do kernel com alguns códigos adicionais e anexando uma initrd ao final do kernel.
O kernels que é fornecido com o LTSP já está 'rotulado' e pronto para uso com o Etherboot.
O Etherboot também pode ser gravado em disquete, funcionando perfeitamente para testes.
Parte da especificação 'Wired for Management' da década de 1990 incluiu a especificação de uma tecnologia de bootrom conhecida como Pre-boot Execution Environment comumente abreviada como PXE.
Uma bootrom PXE bootrom pode carregar até no máximo um arquivo de 32 Kilobytes. Um kernel Linux é um pouco maior que isto. Por isso, configuramos um carregador de boot de segundo estágio chamado pxelinux. O pxelinux é pequeno o bastante para ser carregado, e ele sabe como carregar arquivos grandes, como o kernel Linux.
O Managed Boot Agent (MBA) é uma bootrom de uma companhia chamada emBoot. A emBoot foi utilizada como a divisão Lanworks da 3Com. O MBA é na realidade, quatro bootroms em uma. Ele irá tratar PXE, TCP/IP, RPL e Netware.
A implementação PXE do MBA funciona muito bem. Você pode usá-la com o pxelinux para carregar o kernel Linux.
O método TCP/IP pode ser usado, mas antes, o kernel precisa ser preparado com um utilitário chamado imggen.
O Netboot, assim como Etherboot, é um projeto de software livre que fornece imagens ROM livres para boot. A diferença é que ele é um 'invólucro' para o driver NDIS ou drivers de pacotes distribuídos com as placas de rede.
Há dois modos de iniciar uma estação LTSP com disquete. Um modo é carregar o Etherboot no setor de boot do disquete. Então, ele funcionará como uma bootrom. O código de boot será executado, a placa de rede será iniciada, e o kernel será carregado do servidor de rede.
Você poderá também gravar o kernel e a initrd no disquete e iniciar daquela maneira. Entretanto, atualmente, é mais rápido carregar o kernel via rede.
O disco rígido pode ser usado com o LILO ou GRUB, para carregar o kernel Linux e a initrd ou você pode carregar uma imagem bootrom Etherboot do disco rígido, e esta atuará como uma bootrom.
Um CD-ROM 'bootavel' pode ser carregado com o kernel Linux ou uma imagem Etherboot.
Assim como o CD-ROM, disquete e disco rígido, você pode usar um dispositivo de armazenamento USB tanto para iniciar um módulo Etherboot, como um kernel Linux e uma imagem initrd.
É melhor pensar no LTSP como uma distribuição completa de Linux. É uma distribuição que funciona no topo de uma distribuição host. A distribuição host pode ser qualquer distribuição de Linux que você quiser. De fato, não há nenhuma exigência real que o host esteja rodando Linux. A única exigência é que o sistema host seja capaz de servidor NFS (Network File System). A maioria dos sistemas Unix pode fazê-lo. De fato, mesmo algumas versões de Microsoft Windows podem ser configuradas para trabalhar como um servidor LTSP.
Há três fases para construir um servidor LTSP.
A partir da versão 4.1, o LTSP possui um pacote de utilitários para a instalação e gerenciamento de pacotes dos clientes LTSP (O software que é executado nos clientes), e para configurar os serviços no servidor LTSP.
O utilitário de administração é chamado de ltspadmin e a ferramenta de configuração de ltspcfg. Ambas as ferramentas são partes do pacote ltsp-utils.
O pacote ltsp-utils está disponível nos formatos RPM e TGZ. Escolha o formato que preferir instalar, e siga as instruções apropriadas.
Faça o download da última versão do pacote RPM ltsp-utils, e instale-o utilizando o seguinte comando:
rpm -ivh ltsp-utils-0.1-0.noarch.rpm |
Faça o download da última versão do pacote RPM ltsp-utils, e instale-o utilizando o seguinte comando:
tar xzf ltsp-utils-0.1-0.noarch.tgz cd ltsp_utils ./install.sh cd .. |
Uma vez que a instalação do pacote ltsp-utils estiver completa, você pode executar o comando ltspadmin. Este utilitário é utilizado para gerenciar os pacotes dos clientes LTSP. Ele irá consultar o repositório de download do LTSP, e obter a lista dos pacotes atualmente disponíveis.
Execute o comando ltspadmin e você irá ver uma tela como o seguinte:
Nesta tela, você pode escolher "Install/Update", e se esta for a sua primeira vez executando o utilitário, ele irá exibir a tela de configuração do instalador.
Na tela de configuração, você pode definir diversos parâmetros que o instalador irá utilizar, para fazer o download e instalar os pacotes LTSP. Estes parâmetros são:
Esta é a URL, que aponta para o repositório de pacotes. Tipicamente, deverá ser http://www.ltsp.org/ltsp-4.1, mas se você desejar instalar os pacotes de um sistema de arquivos local, você pode usar file:. Por exemplo, se os pacotes estiverem em um CD-ROM, e você tiver montado o CD-ROM em /mnt/cdrom, então o valor para o repositório de pacotes será: file:///mnt/cdrom. (Note as três barras).
Este é o diretório no servidor, onde você deseja manter a árvore dos clientes LTSP. Tipicamente, será: /opt/ltsp. O diretório será criado, caso o mesmo ainda não exista.
Dentro deste diretório, o diretório raiz para cada uma das arquiteturas será criado. Atualmente, apenas as estações x86 são oficialmente suportadas pelo LTSP, mas há várias pessoas trabalhando em 'ports' para outras arquiteturas, como PPC e SPARC.
Se o servidor estiver por trás de um firewall, e o acesso a web deva ser feito através de um proxy, você pode configurar o instalador para usar o proxy aqui. Os valores devem conter a URL para o proxy, incluindo o protocolo e a porta. Um exemplo para esta configuração é: http://firewall.seudominio.com.br:3128.
Se você não precisa de um proxy, deverá configurar esta opção para "none".
Para pacotes localizados em um servidor FTP, se você precisar acessar através de um proxy FTP, você pode informar aqui. A sintaxe é similar para a opção proxy HTTP acima.
Se você não precisa de um proxy, deverá configurar esta opção para "none".
Uma vez que você tenha concluído a tela da configuração, o instalador consultará o repositório de pacotes e obterá a lista dos componentes atualmente disponíveis.
Figura 2-3. LTSP installer - Component list
Selecione cada um dos componentes que deseja instalar. Para selecionar um componente, mova a linha de destaque para o componente desejado e pressione 'I' para selecionar o componente individual. Você pode pressionar também 'A' para selecionar TODOS os componentes. Na maioria das vezes, será este o seu objetivo. Desta forma, você poderá dar suporte à maioria dos hardwares dos terminais.Há várias teclas que podem ser utilizadas para navegar nesta tela. Você pode obter ajuda para estas, pressionando a tecla ' H'.
Se você deseja ver a lista de pacotes que estão em um determinado componente, você pode pressionar 'S', e a lista de pacotes será exibida. Será mostrada a versão atualmente instalada, bem como a última versão disponível.
Uma vez que os componentes desejados estejam selecionados, você pode sair da tela de seleção de componentes. O instalador irá perguntar a você, para se certificar que você realmente deseja instalar/atualizar os pacotes selecionados. Se você responder 'Y', então ele irá fazer o download e a instalação dos pacotes selecionados.
Há quatro serviços básicos necessários para suportar o boot de uma estação LTSP. São eles:
O ltspcfg pode ser utilizado para configurar todos estes serviços, além de muitas outras coisas relacionadas ao LTSP.
Você pode acessar o ltspcfg do ltspadmin, ou pode executá-lo digitando ltspcfg em um shell.
Quando você executar o utilitário ltspcfg, ele irá verificar o servidor, para determinar o que está atualmente instalado e executando. Você verá uma tela como esta:
Para configurar todos os itens que precisam de configuração, escolha 'C', e o menu de configuração será exibido. Do menu de configuração, você precisará percorrer por cada item, para certificar-se que estes estão configurados corretamente para servir às estações LTSP.
Figura 2-7. ltspcfg - Initial screen
A variável Runlevel é usada pelo programa init. Com sistemas GNU/Linux e Unix, em um determinado momento, é dito estar em um "Runlevel" específico. Os Runlevels 2 ou 3 são tipicamente usados quando o servidor está em modo texto. O Runlevel 5 tipicamente indica que o sistema está em modo gráfico com suporte a rede.
Para um servidor LTSP, tradicionalmente o Runlevel 5 é usado. A maioria dos sistemas já está configurada para servir NFS e XDMCP quando no Runlevel 5. Para aqueles sistemas que ainda estão configurados para este fim, este utilitário tomará conta deles.
Para sistemas que possuem múltiplas interfaces de rede, você precisará especificar qual interface os Thin clients estão conectados.
Selecionando a interface, a ferramenta de configuração está apta para criar os outros arquivos de configuração apropriados, como os arquivos dhcpd.conf e /etc/exports.
O DHCP precisar ser configurado para fornecer as informações necessárias para as estações. Entre estas informações estão fixed-address, filename, subnet-mask, broadcast-address e root-path.
Selecionando este artigo de menu, você estará apto para criar o arquivo de configuração dhcpd.conf, e então ativar o dhcpd para executar no início do sistema.
O TFTP é usado pelo 'thin client' para fazer o download do kernel Linux. O serviço tftpd precisa ser ativado no servidor, para servir os kernels.
O Portmapper é usado pelos serviços RPC. Cada um dos serviços RPC, tal como o NFS.
O NFS é o serviço que permite que a árvore de diretórios local seja montada nas máquinas remotas. Este é necessário ao LTSP, porque as estações montam seus sistemas de arquivos raiz do servidor.
Este item de menu irá cuidar para que o serviço NFS seja configurado para iniciar com o sistema. O arquivo de configuração é /etc/exports e sua criação será descrita mais adiante nesta seção.
O XDMCP é o "X Display Manager Control Protocol". O servidor X envia uma requisição XDMCP para o gerenciador de 'Display' no servidor para obter uma tela de login.
Os gerenciadores de 'display' comumente em uso são o XDM, GDM e KDM. Este item de menu irá mostrar qual gerenciador de 'display' foi encontrado, e qual está configurado para executar.
Por medida de segurança, o gerenciador de 'Display' é configurado por padrão para não permitir as conexões de estações remotas. Esta é normalmente a razão para a Gray screen with large X cursor . O ltspcfg pode normalmente configurar o gerenciador de 'display" para permitir que estações remotas se conectem ao servidor.
Muitos serviços, como o NFS e o gerenciador de 'Display' precisam mapear o endereço IP da estação para um nome de host. Você pode configurar o Berkeley Intenet Naming Daemon (BIND) para fazer isto, mas você deve certificar-se de configurar o reverses corretamente. Finalmente, usar o BIND é provavelmente a melhor maneira fazê-lo, mas a configuração do BIND é além da finalidade deste documento e do utilitário ltspcfg.
Uma maneira mais simples para configurar o mapeamento de endereços IP e nomes de host é o arquivo /etc/hosts.
Alguns serviços usam uma camada de segurança conhecida como tcpwrappers. Este é configurado através do arquivo /etc/hosts.allow. Este item do menu irá configurar isto para você.
Este é o arquivo usado pelo NFS, para determinar quais diretórios permitem ser montados por máquinas remotas. Este item do menu criará este arquivo.
A configuração de cada estação é direcionada por entradas no arquivo lts.conf. Para estações razoavelmente modernas com um barramento PCI, não deve ser necessária nenhuma entrada adicional no lts.conf. Mas, o arquivo ainda precisa existir. Este item do menu criará o arquivo lts.conf padrão para você.
Agora, é o momento de informar o servidor LTSP sobre uma estação específica. Há três arquivos que contêm informações sobre as estações de trabalho.
A estação precisa de um endereço IP e outras informações. Ela irá obter as seguintes do servidor DHCP:
Para o nosso exemplo de ambiente LTSP, nós escolhemos o DHCP para gerenciar a atribuição de endereços IP das estações.
Durante a execução do script ltsp_initialize script, um arquivo dhcpd.conf é instalado. Ele estará localizado em /etc/dhcpd.conf.example, você pode copiá-lo para /etc/dhcpd.conf para utilizá-lo como base para a sua configuração do serviço DHCP. Você precisará modificar as partes deste arquivo que referenciam o ambiente de servidor(s) e estações.
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
Desde a versão 2.09pre2 do LTSP, você não precisa especificar um kernel particular a ser carregado. O pacote padrão do kernel suporta todos as placas da rede que o Linux suporta. Há dois arquivos de kernel incluídos no pacote do kernel LTSP. Um kernel tem o 'Linux Progress Patch' (LPP) aplicado, e o outro não. Os nomes para os kernels são:
vmlinuz-2.4.9-ltsp-5 vmlinuz-2.4.9-ltsp-lpp-5 |
Você pode ter observado que o kernel reside no diretório /tftpboot/lts, mas na entrada "filename" no arquivo /etc/dhcpd.conf está faltando o componente tftpboot do caminho. Isto é porque nas versões 7,1 e superiores do Redhat, o TFTP está sendo executado com a opção '-s'. Esta opção leva ao daemon do tftpd a funcionar na modalidade secure. Isto é, faz um chroot para o diretório /tftpboot quando inicia. Conseqüentemente, todos os arquivos que estão disponíveis ao daemon do tftpd são relativos ao diretório tftpboot.
Outras distribuições Linux podem não possuir a opção '-s' configurada para o tftpd, desta forma você precisará adicionar o prefixo /tftpboot ao caminho do kernel.
Mapeamento de endereços IP para nome de máquina
Os computadores comunicam-se perfeitamente com os endereços do IP. Então, nós seres humanos precisamos pôr nomes nos computadores, porque não podemos recordar os números. É onde o DNS ou o arquivo /etc/hosts entra no jogo. Este mapeamento de endereços IP para nomes de host geralmente não é necessário, exceto em um ambiente LTSP. Isto porque sem ele, o NFS lhe dará erros das permissões quando a estação de trabalho tenta montar o sistema de arquivos raiz.
Além dos problemas com o NFS, se a estação de trabalho não estiver listada no arquivo /etc/hosts, você poderá ter problemas também com gerenciadores de telas GDM ou KDM.
Há um número de entradas de configuração que podem ser especificadas no arquivo lts.conf.
O arquivo lts.conf possui uma sintaxe simples, que consiste em seções múltiplas. Há uma seção padrão chamada [default] e pode haver seções para estações individuais. As estações podem ser identificadas pelo nome de host, pelo endereço IP ou pelo endereço MAC.
Um arquivo lts.conf típico se parece com este:
#
# Config file for the Linux Terminal Server Project (www.ltsp.org)
#
[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
|
Exemplo 2-1. Arquivo lts.conf
Abaixo, uma lista das principais entradas:
Se sua placa de vídeo é PCI, e se esta é suportada pelo X.org 6.7.0, então você apenas precisa do pacote lts_x_core. Este contém todos os módulos de driver para o X4.
Há vários pacotes do XFree86 3.3.6 disponíveis para o LTSP. Isto é para o caso de sua placa de vídeo não ser suportada pelo X.org 6.7.0.
Você pode criar entradas no arquivo lts.conf para cada estação individual, ou você pode criar uma entrada padrão que pode ser compartilhada por todas as estações.
Nossa estação de trabalho possui uma placa de vídeo com chipset Intel i810, e esta pode ser detectada automaticamente, então nós não precisaremos de uma entrada XSERVER no arquivo lts.conf. A entrada XSERVER pode ser especificada, se você desejar, ou esta pode ser configurada para 'auto' para mostrar que a placa de vídeo será detectada automaticamente.
Queremos utilizar a estação de trabalho no modo gráfico, desta forma, precisamos que o runlevel esteja configurado para '5'. Isto é feito por outra entrada no arquivo lts.conf.
Com o comando ltspcfg, você pode obter o status atual da configuração de todos os serviços necessários ao LTSP. Através do menu principal do ltspcfg, pressione 'S', e você irá ver o status atual.
Uma vez que o servidor esteja configurado, é hora de concentrar-se na configuração da estação de trabalho.
Todo o que acontece depois que o kernel está na memória é sobre o projeto de LTSP. Há diversas maneiras de pôr o kernel na memória, incluíndo Etherboot, Netboot, PXE e o disquete.
Se sua placa de rede possui PXE embutido, então você pode usá-la para carregar o kernel do Linux. PXE é uma tecnologia de bootrom, similar a Etherboot ou a Netboot.
Talvez você precise ativar o bootrom PXE em sua placa de rede. Você também pode precisar mudar a ordem dos dispositivos de boot em sua BIOS, para fazer a "Boot from LAN" a primeira escolha, ao invés de "Floppy" ou "HDD".
O PXE tem uma limitação de somente poder carregar arquivos de 32kb ou menores. O kernel do Linux é um pouco maior que esta limitação, desta forma não é possível carregar o kernel Linux diretamente com o PXE. Você precisa carregar algo conhecido como 'Network Bootstrap Program' ou NBP.
Há um NBP disponível para carregar o kernel Linux chamado de pxelinux.0. Este é parte do pacote syslinux de H. Peter Anvin, um dos desenvolvedores do kernel.
O pacote LTSP do kernel inclui o NBP pxelinux.0 e o arquivo de configuração necessário para carregar o kernel Linux e a imagem do ramdisk.
A maneira de funcionamento é esta:
Aqui está um arquivo de configuração exemplo 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 Etherboot é um pacote de software para criar imagens ROM que possam realizar o download de código sobre uma rede Ethernet a ser executado em um computador x86. Muitas placas de rede têm um soquete onde um chip de ROM pode ser instalado. O Etherboot é o código que pode ser posto em tal ROM. | ||
| -- Ken Yap | ||
O Etherboot é também Open Source, protegido pela GNU General Public License, Version 2 (GPL2).
Para usar o Etherboot, se você já possui uma placa de rede com uma bootrom Etherboot, talvez precise modificar a configuração de sua BIOS para escolher a opção "Boot from LAN" para a carga do sistema operacional ao invés de "Floppy" ou "HDD".
Se você não possui uma bootrom Etherboot, você pode ou criar uma bootrom, ou você pode criar um disquete com uma imagem Etherboot em seu setor de boot.
O Etherboot suporta um vasto número de placas de rede. Mais de 200 modelos, com mais sendo adicionados todo o tempo. Se você escolher criar um disquete ou gravar o código em uma Eprom, precisará determinar qual o modelo de placa de rede possui.
Para placas de rede antigas baseadas no padrão ISA, não é tão importante que você determine o tipo exato. Primeiro, a maioria delas são placas ne2000 ou 3Com 3c509. Você precisa apenas obter o driver Etherboot correto, o que seleciona o tipo correto de mídia na placa 10 base-2 (Coax) e 10 base-T (Twisted pair).
Para as placas de rede PCI, é importante escolher o driver Etherboot que corresponda ao código PCI do fabricante e da placa de rede.
Às vezes, você terá sorte. Saberá exatamente que modelo de placa de rede tem, por que o modelo é impresso na própria placa de rede, e bate exatamente com a descrição dos modolos no Etherboot. Mas, em muitos casos, será necessário encontrar os números do PCI ID.
Se sua estação de trabalho tiver uma drive de disquete, você pode carregar um disquete tomsrtbt (Tom's Root Boot). Ou, se sua estação de trabalho tiver uma unidade de CD-ROM, você pode carregar um CD do Knoppix. Se você não puder carregar o linux em sua estação de trabalho, então sua única esperança pode ser mover a placa de rede para uma estação de trabalho que possa carregar o Linux.
Uma vez que tenha o Linux carregado, você pode 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)
|
[root@jamlap root]# lspci -n | grep "Class 0200"
0000:06:00.0 Class 0200: 8086:1229 (rev 09)
|
Você pode fazer o download do pacote Etherboot e configurá-lo para o tipo de bootrom que precisar. Então, você pode compilar o fonte para produzir uma imagem bootrom que possa ser gravada em uma EPPROM ou em um disquete.
Uma abordagem simples é ir ao site do Marty Connor's www.Rom-O-Matic.net.
O Marty fez um bom trabalho ao por um front-end web para configuração e compilação da geração de imagens bootrom Etherboot. Neste site, você seleciona o tipo de placa de rede que tem e que tipo de imagem deseja. Então, você tem a oportunidade de modificar muitas das opções de configuração do Etherboot. Então, você pode pressionar o botão 'Get ROM' e uma imagem bootrom personalizada será gerada enquando você espera.
Para o formato de saída da ROM, escolhar 'Floppy Bootable ROM Image'. Isto irá ocasionar a inclusão de um cabeçalho de 512 bytes que é um boot loader para carregar a imagem etherboot na memória ram onde esta possa ser executada.
Pressione o botão 'Get ROM'. A imagem bootrom será gerada enquanto você espera.. Isto leva apenas alguns segundos, e quando completar, seu navegador irá abrir a janela de "Salvar como" onde você pode definir onde a imagem bootrom será salva em seu computador.
Uma vez que tenha salvo a imagem em seu disco, você precisará gravá-la em um disquete. Insira um disquete na unidade e execute o seguinte comando para gravar o disquete:
dd if=Etherboot_Image of=/dev/fd0 |
É necessário um programador de EPROM para gravar a imagem do Etherboot em uma EPROM. Este tipo de equipamento varia de preço entre poucas centenas de dólares até milhares de dólares dependendo das características.
O processo de criação de uma bootrom é inteiramente dependente do programador de EPROM. Isto está fora do escopo deste documento.
Assumindo que o servidor e a estação estão configurados corretamente, é necessário apenas inserir um disquete de boot na estação de trabalho e ligá-la.
O código de Etherboot será lido do disquete para a memória, a placa de rede será encontrada e inicializada, uma requisição dhcp será emitida na rede e uma resposta será emitida pelo servidor e será feito o download doo kernel para a estação de trabalho. Uma vez que o kernel inicializou o hardware da estação de trabalho, o X Windows irá iniciar e uma tela de login deve aparecer na estação de trabalho, similar ao exemplo abaixo.
Figura 4-1. Login screen
Neste ponto, você pode logar. Uma coisa importante a ter em mente é que você está logando no servidor. Todos os comandos que você execuar, estarão sendo executados no servidor, e sua saída mostrada na estação de trabalho. Isto é o poder do X Windows.
Você pode executar qualquer programa que seja suportado pelo servidor.
Além da estação de trabalho ser uma GUI funcional ou um terminal, esta pode atuar como um servidor de impressão, permitindo a conexão de até 3 impressoras conectadas a portas paralelas ou seriais.
Tudo isso é transparente para os usuários das estações de trabalho. Eles nem mesmo notarão o pequeno tráfego que está saíndo das estações para as impressoras.
O LTSP usa o programa lp_server na estação de trabalho, para redirecionar os trabalhos de impressão do servidor para a impressora conectada a uma das portas da estação de trabalho.
Para habilitar a impressora na estação de trabalho, há um conjunto de entradas de configuração no arquivo lts.conf.
[ws001]
PRINTER_0_DEVICE = /dev/lp0
PRINTER_0_TYPE = P
|
Há muito mais opções disponíveis. Verifique posteriormente as seções do lts.conf neste documento para maiores informações sobre as entradas para a configuração de impressoras.
Configurar a impressora no servidor consiste em definir uma fila de impressão, usando a ferramenta de configuração de impressoras do servidor.
No Redhat 7.2, há ambas as ferramentas de configuração de impressoras baseadas em GUI e Texto. A ferramenta GUI é chamada de printconf-gui, e a baseada em Texto é chamada de printconf-tui. Em versões mais antigas o Redhat possui um programa chamado printtool. O printtool também existe no Redhat 7.2, mas este chamará o printconf-gui. Outras distribuições Linux possuem suas próprias ferramentas de configuração de impressoras.
Figura 5-1. Printconf-gui Adicionando uma nova impressora
Uma vez que você execute a ferramenta de configuração de impressoras, será necessário adicionar uma nova impressora. O programa lp_server permite à estação de trabalho emular um servidor de impressão HP JetDirect. Você apenas precisa criar uma impressora JetDirect.
Você precisa atribuir um nome à fila de impressão. O nome pode ser qualquer coisa, mas crie um nome inteligível, e o nome pode conter apenas os seguintes caracteres:
O nome escolhido no exemplo acima é ws001_lp. Este nome torna fácil ver que a impressora está associada com ws001.
Figura 5-2. Printconf-gui Informações detalhadas
Há dois campos obrigatórios para a comunicação com a impressora:
A primeira impressora que você conectar a uma estação de trabalho estará na porta TCP/IP 9100. A segunda impressora estará na porta 9101, e a terceira impressora estará na porta 9102.
Uma das funcionalidades que foram adicionadas à versão 4.0 do LTSP é algo chamado Screen Scripts. Há script para iniciar vários tipos de sessões.
Você pode especificar múltiplos scripts de tela para uma estação de trabalho. Fazendo isto, você terá múltiplas sessões. Elas podem ser de tipos diferentes, ou elas podem ser do mesmo tipo. Por exeplo, você pode especificar o seguinte:
SCREEN_01 = startx SCREEN_02 = shell |
Você pode especificar até 12 scripts de tela para uma estação de trabalho, mas a maioria das pessoas possuem apenas uma.
Tipos de scripts de tela disponíveis:
Este script iniciará o servidor X com a opção -query, para enviar uma requisição XDMCP ao gerenciador de janelas para obter a tela de login exibida na estação.
Este script iniciará um shell no terminal. Este tem por objetivo o uso na solução de problemas com a estação de trabalho. Porque ele lhe fornece uma sessão no thin client, ao invés de ser no servidor, não sendo muito útil para executar aplicações.
Este script executará uma sessão telnet que conectará ao servidor. Este lhe fornecerá uma sessão baseada em caracteres no servidor.
Por padrão, o telnet conectará ao servidor LTSP. Se você deseja especificar um servidor diferente, você pode passar este na mesma linha do script de tela. Por exemplo:
SCREEN_01 = telnet server2.mydomain.com
|
Este script iniciará o programa rdesktop, o qual conectará a um servidor Microsoft Windows. Você pode especificar na mesma linha qualquer opção do rdesktop que desejar, diretamente após o nome do script de tela. Por exemplo, se você deseja especificar o servidor ao qual a conexão deverá ser realizada, você pode fazê-lo desta forma:
SCREEN_01 = rdesktop -f w2k.mydomain.com
|
Os scripts de tela residem no diretório /opt/ltsp/i386/etc/screen.d. Você pode criar seus próprios scripts de tela e pô-los neste diretório. É melhor usar um dos scripts existentes como exemplo.
Se, após seguir os capítulos anteriores, sua estação de trabalho não carregar, então você deve começar o processo de pesquisar os problemas de instalação.
A primeira coisa a fazer é descobrir em que ponto do processo de carga a estação ficou.
Quando você iniciar por um disquete, você deverá ver algo similar a isto:
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 exemplo acima mostra o que você pode esperar ver na tela quando iniciando de um disquete. Se você não vir aquelas mensagens, indicando que o Etherboot iniciou, então você pode ter um disquete com defeito, ou você não gravou a imagem corretamente.
Se, você vir uma mensagem como a seguinte, então isto indica que provavelmente a imagem Etherboot que você gerou não é a imagem correta para 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> |
Se for até o ponto onde ele detecta a placa de rede e mostrar o endereço MAC correto, então o disquete provavelmente está normal.
Uma vez que a placa de rede esteja iniciada, ela irá enviar uma requisição DHCP para a rede local, procurando por um servidor DHCP.
Se a estação de trabalho receber uma resposta válida do servidor DHCP, então ela configurarará a placa de rede. Você saberá se funcionou corretamente caso as informações de endereço IP forem indicadas na tela. Aqui está 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 |
Se ao invés, você vir a seguinte mensagem na estação de trabalho, seguida de várias mensagens <sleep>, então algo está errado. Embora, seja comum ver uma ou duas mensagens <sleep>, depois da resposta do servidor dhcp.
Searching for server (DHCP)... |
Descobrir o que está errado pode ser algumas vezes difícil, mas aqui estão algunas coisas a observar.
A estação de trabalho está conectada à mesma rede que o servidor está conectado?
Com a estação de trabalho ligada, certifique-se de que as luzes de conexão estão acesas durante toda a conexão.
Se você estiver conectando diretamente a estação e o servidor (sem hub ou switch), certifique-se que você está usando um cabo cross-over. Se você estiver usando um hub ou switch, então certifique-se de estar utilizando um cabo normal straight-thru, entre ambos a estção e o hub, e o hub e o servidor.
Você precisa determinar se o dhcpd está sendo executado no servidor. Podemos encontrar a resposta de uma grande variedade de modos.
O dhcpd normalmente permanece em segundo plano, ouvindo na porta udp 67. Tente executar o comando netstat para ver se existe algo ouvindo nesta porta:
netstat -an | grep ":67 " |
udp 0 0 0.0.0.0:67 0.0.0.0:* |
Só porque o netstat mostra que alguma coisa está ouvindo na porta udp 67, não significa que é definitivamente o dhcpd que está escutando. Pode ser o bootpd, mas isto é incomum, porque o bootp não é mais incluído na maioria das distribuições Linux.
Para certificar-se que é o dhcpd que está sendo executado, tente executar o comando ps.
ps aux | grep dhcpd |
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
|
Se você não vir nenhuma linha mostrandoq ue o dhcpd está sendo executado, então você precisa checar se o servidor está configurado para o runlevel 5, e que o dhcpd está configurado para iniciar no runlevel 5. Em sistemas baseados em Red Hat, você pode executar o comando ntsysv e procurar o dhcpd para certificar-se que ele está configurado para inciar.
Você pode tentar iniciar o dhcpd com este comando:
service dhcpd start |
O arquivo /etc/dhcpd.conf possue uma entrada para a estação de trabalho?
Você deve verificar novamente a configuração 'fixed-address' no arquivo de configuração, para certificar-se que esta casa com a placa de rede na estação de trabalho.
Execute o seguinte comando para ver o que ele diz:
ipchains -L -v |
Chain input (policy ACCEPT: 229714 packets, 115477216 bytes): Chain forward (policy ACCEPT: 10 packets, 1794 bytes): Chain output (policy ACCEPT: 188978 packets, 66087385 bytes): |
Execute o seguinte comando para ver o que ele diz:
iptables -L -v |
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 |
Tente monitorar o arquivo /var/log/messages enquanto a estação de trabalho estiver iniciando. Você pode fazê-lo com o seguinte comando:
tail -f /var/log/messages |
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 |
O Etherboot usa o TFTP para copiar o kernel Linux do servidor. Este é um protocolo muito simples, mas algumas vezes há problemas ao tentar fazê-lo funcionar.
Se você vir uma mensagem similar a esta:
Loading 192.168.0.254:/lts/vmlinuz-2.4.24-ltsp-4.........
|
Se, ao invés, você não vir os pontos, então há um problema. Problemas possíves incluem:
Se o tftpd não estiver configurado para executar, então ele certamente não estará apto a responder às requisições da estação de trabalho. Você pode ver se ele está sendo executado, você pode usar o comando netstat, como este:
[root@bigdog]# netstat -anp | grep ":69 "
udp 0 0 0.0.0.0:69 0.0.0.0:* 453/inetd
|
Há dois métodos comuns de executar o tftpd, são eles o inetd e o novo xinetd
O inetd usa um arquivo de configuração chamado /etc/inetd.conf. Neste arquivo, certifique que a linha que começa com tftpd não está comentada. Isto é como a linha deve parecer:
tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd -s /tftpboot
|
O xinetd usa um diretório com arquivos de configuração individuais. Um para cada serviço. Se o seu servidor está usando o xinetd, então o arquivo de configuração para o tftpd é chamado de /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
}
|
O kernel precisa estar em um local onde o daemon tftpd possa acessá-lo. Se a opção '-s' do daemon tftpd for utilizada, então qualquer coisa que a estação procurar precisa estar relativo ao diretório /tftpboot. Então, se a entrada filename no arquivo /etc/dhcpd.conf está configurada para /lts/vmlinuz-2.4.24-ltsp-4, então o kernel precisa estar em /tftpboot/lts/vmlinuz-2.4.24-ltsp-4
Há diversas coisas que podem impedir que o sistema de arquivos raíz seja montado. incluíndo as seguintes:
Se você obter o seguinte erro:
Kernel panic: No init found. Try passing init= option to kernel. |
Se você obter o seguinte erro:
Root-NFS: Server returned error -13 while mounting /opt/ltsp/i386 |
Examine o arquivo /var/log/messages para ver se há algum indício. Uma entrada como esta:
Jul 20 00:28:39 bigdog rpc.mountd: refused mount request from ws004 for /opt/ltsp/i386 (/): no export entry |
O NFS pode ser um serviço complexo e difícil na solução de problemas, mas entendendo o que deve ser configurado e quais ferramentas estão disponíveis para diagnosticar os problemas irá certamente ajudar a tornar isto mais fácil.
Há três daemons que precisam estar em execução no servidor para o NFS funcionar corretamente. portmap, nfsd e mountd.
Se você obter 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 |
ps -e | grep portmap |
30455 ? 00:00:00 portmap |
netstat -an | grep ":111 " |
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:* |
/etc/rc.d/init.d/portmap start |
O NFS possui 2 daemons que precisam estar executando. O nfsd e o mountd. Ambos são iniciados pelo script /etc/rc.d/init.d/nfs.
Você pode executar o comando ps para certificar-se que eles estão em execução.
ps -e | grep nfs ps -e | grep mountd |
Você deve estar apto a executar o script de inicio com o argumento restart para causar o inicio de ambos, mas por alguma razão, o script /etc/rc.d/init.d/nfs não reinicia o nfsd desta maneira. Ele reinicia somente o mountd (erro?). Assim, você deve preferivelmente executar a seguinte seqüência dos comandos:
/etc/rc.d/init.d/nfs stop /etc/rc.d/init.d/nfs start |
Se os daemos estiverem executando, mas o NFS continuar não funcionando, você pode verificar se eles se registraram com o portmapper utilizando o comando rpcinfo.
rpcinfo -p localhost |
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 |
Ah garoto!, Provavelmente a única parte a mais difícil de configurar uma estação de trabalho LTSP é ter o servidor X configurarado corretamente. Se você estiver usando uma placa de video razoavelmente nova, e esta for suportada pelo Xorg Xservers, e você tiver um monitor razoavelmente novo que possa gerenciar uma grande escala de freqüências e definições, então é razoavelmente fácil seguir em diante. Geralmente, nesse caso, se não funcionar, o mais provável é que o servidor X não é o certo para esta placa de vídeo.
Quando um servidor X não funciona com sua placa, é geramente óbvio. Ou o servidor X não inicia, ou a tela estará incorreta.
Quando a estação de trabalho está pronta para iniciar o servidor X, ela chama o script startx, o qual inicia o servidor X localmente na estação de trabalho, com a opção -query apontando para um servidor, onde um gerenciador de sessão, como o XDM, GDM ou KDM está executando.
Porque o servidor X é iniciado pelo script startx, que é iniciado pelo programa init, quando ele falha, o init tentará executá-lo novamente. O init continuará este laço de tentar executar o servidor X 10 vezes, então desiste, porque pensa que está 'respawning' rapidamente. Depois que finalmente desiste, a mensagem de erro do servidor X deve ser deixada na tela.
Esperar o servidor X falhar 10 vezes pode ser irritante, assim uma maneira simples de evitar as falhas repetidas é iniciar a estação de trabalho no runlevel 3, de modo que o servidor X não seja iniciado automaticamente. Ao invés disto, quando você iniciar a estação de trabalho, começará com um shell bash. Do shell bash, você pode iniciar o servidor X manualmente com o seguinte comando:
sh /tmp/start_ws |
O gerenciador de telas é o daemon que executa no servidor, esperando que um servidor X o contate. Uma vez que o contato é feito, ele irá mostrar uma tela de login na tela, oferecendo ao usuário a chance de logar no servidor.
Os três gerenciadores de tela mais comus são:
Isto indica que o servidor X está em execução, mas ele não conseguiu fazer contato com o gerenciador de telas. Algumas das possíveis razões para isto são:
Nas versões recentes do Red Hat (7.0 e superiores), o gerenciador de relas é iniciado através do init. No arquivo /etc/inittab, há uma linha que se parece com esta:
x:5:respawn:/etc/X11/prefdm -nodaemon |
O gerenciador de telas padrão depende de quais pacotes foram instalados. Se o GNOME está instalado, então o GDM é o gerenciador de telas padrão. Se o GNOME não estiver instalado, então o script prefdm irá checar para ver se o KDE está instalado. Se ele estiver, então o KDM será o gerenciador de telas padrão. Se o KDE também não estiver instalado, então o XDM será o gerenciador de telas padrão.
Usando o comando netstat, você deverá conseguir ver se há um gerenciador de telas em execução. No servidor, execute o comando abaixo:
netstat -ap | grep xdmcp |
udp 0 0 *:xdmcp *:* 1493/gdm |
Se você vir uma linha como esta mostrada acima, indicando que definitivamente há um gerenciador de telas ouvindo, então você precisa certificar-se que a estação de trabalho está enviando a consulta XDMCP para o servidor correto.
No arquivo lts.conf, você pode ter uma entrada que especifica o endereço IP do servidor que está executando o gerenciador de telas. A entada é opcional, mas se presente, deve parecer-se com isto:
XDM_SERVER = 192.168.0.254 |
Se a entrada 'XDM_SERVER' não estiver presente, esta usuará então o valor da entrada 'SERVER', se presente. Se esta não estiver presente, então ela usará 192.168.0.254.
A qual mesmo que especificada, você apenas precisa certificar-se que o endereço IP é realmente o endereço correto do servidor executando o gerenciador de telas.
Se você tiver determinado que o gerenciador de telas está em execução, então é possível que ele fora configurado para ignorar requisições XDMCP de hosts remotos. Você precisará checar os arquivos de configuração do gerenciador de telas particular em execução para determinar se ele está configurado corretamente.
A configuração padrão para o Red Hat dé desativar a habilidade das estações de trabalho receberem acesso a uma sessão XDM. O script Ltsp_initialize tomará cuidado de permitir isto para você, mas se não estiver funcionando, você deve verificar o arquivo /etc/X11/xdm/xdm-config. Procure uma entrada que pareça com esta:
DisplayManager.requestPort: 0 |
Outro arquivo de configuração também é importante para que o XDM sirva a requisições remotas de login. É um arquivo chamado /etc/X11/xdm/Xaccess que DEVE conter uma linha que inicia com um asterisco '*'. A linha é normalmente incluída no arquivo, mas a Red Hat a mantém comentada. O script ltsp_initialize irá corrigir a linha para você, mas se o XDM não funcionar, você deve verificar este arquivo. Uma linha válida deve parecer-se com a abaixo:
* #any host can get a login window |
Novas versões do KDM possuem um arquivo chamado kdmrc. Diferentes distribuições Linux mantém este arquivo em locais diferentes. Para o Red Hat 7.2, é /etc/kde/kdm/kdmrc . Para as outras distribuições, você deve executar o comando locate para localizar onde o arquivo é mantido.
A entrada que controla se estações de trabalho remotas poderão receber a tela de login é a seção [Xdmcp]. Certifique-se que a entrada Enable está configurada para true.
Versões antigas do KDM usam o arquivo de configuração do XDM, localizado em /etc/X11/xdm.
O GDM usa um conjunto de diferentes arquivos de configuração. Eles estão localizados no diretório /etc/X11/gdm.
O principal a ser examinado é o arquivo gdm.conf. Procure pela seção [xdmcp]. Você deve ver uma entrada dentro desta seção chamada 'Enable'. Ela deve estar configurada como '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 ativar ou desativar XDMCP remoto. Novas versões usam 'false' e 'true'.
Existem algumas decisões que deve ser tomadas sobre o kernel que irá rodar na estação. Você precisa decidir se você quer usar um dos kernels padrões disponíveis para download, ou criar o seu próprio. E, você precisa decidir se você quer mostrar uma tela gráfica, com uma barra de progresso, isso é possível com o Linux Progress Patch (LPP).
O pacote do kernel que é disponível com o LTSP atualmente inclui dois kernels. Um tem o Patch para mostrar a barra de progresso já aplicado e configurado, e o outro não tem esse patch aplicado.
Ambos os kernels tem o patch para Swap por NFS aplicado.
Existe duas maneiras de configurar um kernel para o LTSP. O método padrão é usar algo chamado 'Initial Ram Disk' (Disco de Ram Inicial), ou initrd para simplificar. A imagem initrd é um pequeno sistema de arquivos que é adicionado ao kernel. A imagem do sistema de arquivos initrd é carregada na memória, e uma vez que o kernel é carregado isso irá montar o ramdisk com seu sistema de arquivos raiz. Existem duas vantagens de se usar uma imagem initrd. Primeiro, nós poderemos compilar os drivers de rede como módulos e carregar o módulo correto durante o boot. Isso permite a um simples kernel suportar virtualmente todas as placas de rede. A outra vantagem é que nós podemos rodar um cliente DHCP como programa de usuário melhor que no espaço do kernel. Rodar o cliente como um programa de usuário permite um melhor controle sobre as opções solicitadas e recebidas do servidor. Tambem, resulta um kernel ligeiramente menor. A outra maneira para configurar o kernel é sem o initrd. Construir o kernel sem o initrd requer que um específico driver para placa de rede seja linkada dentro do kernel, e isso tambem requer uma autoconfiguração do IP e "O sistema de arquivos Root em NFS" sejam setados ao se construir o kernel. A vantagem de não usar initrd é que o kernel é ligeiramente menor, e carregará mais rápido. uma vez que a estação de trabalho estará rodando, não há vitualmente nenhuma diferença em como a estação de trabalho funciona.
O kernel padrão do LTSP inclui um Ramdisk inicial (initrd) que tem o cuidado de detectar a placa de rede, e faz solicitação DHCP em área de usuário. O objetivo principal para a imagem era de faze-la o menor possível. Entçai, nós escolhemos a biblioteca de substituição uClinux libc, e o busybox para a que precisariamos durante o boot.
Se você quer criar seu próprio kernel, você deve fazer o download do pacote ltsp_initrd_kit. Isso contem a hierarquia do sistema de arquivos raiz e o script para criar a imagem.
Quando criamos um kernel customizado, é comum e uma boa idéia iniciar com os fontes do kernel atualizados direto do site ftp.kernel.org. A razão para isso é que as distribuições como RedHat, aplicam muitos patches aos seus fontes do kernel, deixando você com uma série de código fonte que realente não estão no kernel oficial.
Faça o download do pacote de fontes do kernel de sua escolha, e salve no diretório /usr/src. O kernel é localizado no diretório /pub/linux/kernel no servidor ftp.kernel.org. Você precisa pegar uma versão recente da série 2.4.x, porque você precisa incluir suporte a devfs .
Tambem, se você quer incluir suporte a swap via nfs ou o Patch para a barra de progresso no linux (Linux Progress Patch (LPP)), você precisa ter certeza de pegar os patches e os fontes do kernel que sejam compatíveis. No momento em que escrevo isso, o kernel 2.4.9 é o último que suporta essas características.
Para nosso exemplo, nós iremos usar o kernel 2.4.9. O caminho completo é ftp://ftp.kernel.org/pub/linux/kernel/v2.4/linux-2.4.9.tar.bz2
Descompacte os fontes do kernel no diretório /usr/src. Você precisa ter cuidado, porque quando você descompactar o pacote, será criado um diretório chamado linux . Você pode já ter um diretório chamado linux com um direfente código fonte, e você não deve sobrescreve-lo. Então verifique a existência desse diretório, e se ele existir, renomei-o para outro nome antes de descompactar seus fontes.
O pacote de fontes será baixando comprimido com o utilitário de compactação bzip2. Então nós precisamos descompacta-lo antes de usar o programa tar. Você pode usar o seguinte comando para descompacta-lo:
bunzip2 <linux-2.4.9.tar.bz2 | tar xf - |
mv linux linux-2.4.9 |
cd linux-2.4.9 |
Eu normalmente gosto de modificar o Makefile antes de começar a configuração do novo kernel. Perto do inicio do arquivo existe uma variável chamada EXTRAVERSION . Eu seto esta para 'ltsp-1', então o número da versão atual do kernel será '2.4.9-ltsp-1', que tornará fácil a identificação do kernel posteriormente. O topo do Makefile deverá ficar parecido com isso:
VERSION = 2 PATCHLEVEL = 4 SUBLEVEL = 9 EXTRAVERSION = -ltsp-1 KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION) |
Após descompactar o kernel, você pode ter vários patches que deseja aplicar. Por exemplo, o patch para Swap por NFS ou o Patch para barra de progresso do Linux. Esses patches DEVEM ser aplicados antes de configurar o kernel.
O patch para Swap por NFS irá possibilitar ao kernel da estação de trabalho usar um arquivo de swap localizado no servidor NFS. Enquanto é normalmente recomendado ter bastante memória na estação para não se fazer necessário swap, algumas vezes pode ser dificil se addicionar mais memória, especialmente em computadores antigos. Então, essa característica de fazer swap via NFS pode fazer um computador sem utilidade realmente usável.
Se o diretório corrente é /usr/src/linux-2.4.9, e o patch está em /usr/src, você pode fazer o seguinte para testar o patch:
patch -p1 --dry-run <../linux-2.4.9-nfs-swap.diff |
patch -p1 <../linux-2.4.9-nfs-swap.diff |
O patch de progresso do linux (LPP) irá permitir que você configure um logo gráfico para mostrar durante o processo de boot. As mensagens normais de kernel no boot serão redirecionadas para outra tela tty, e instruções especiais serão adicionadas nos scripts de boot que origina uma barra de progresso para refletir quanto do processo de boot já foi feito.
Como o patch para Swap NFS, você pode testar o patch LPP com o comando:
patch -p1 --dry-run <../lpp-2.4.9 |
patch -p1 <../lpp-2.4.9 |
Você pode agora executar o programa de configuração do kernel de sua escolha. Opções disponíveis são:
Isso irá chamar a versão X Windows do utilitário de configuração do kernel.
Isso irá chamar a versão baseada em curses do utilitário de configuração do kernel.
Isso irá chamar a versão baseada em perguntas do utilitário de configuração do kernel.
Configurando o kernel para uso com o initrd requer que as seguintes opções sejam setadas:
Sistema de arquivos /dev deve estar habilitado. Isso é selecionado na seção 'File systems'. Não especifique 'Automatically mount at boot'. A montagem deve ser efetuada pelo script /linuxrc
Estações LTSP requerem que o kernel suporte um disco RAM (RAM disk). Isso é setado na seção 'Block devices'
Isso também deve ser habilitado.
Você precisa ter certeza de que o kernel que você está construindo pode executar na CPU da estação. Isso é feito na seção 'Processor type and features'. Você deve também desligar o suporte a SMP a menos que você tenha realmente múltiplas CPUS.
A estação estará montando seu sistema de arquivos raiz via NFS, então o suporte a cliente NFS é necessário.
Configuração do kernel para uso sem initrd defere de um kernel com initrd em algumas maneiras:
Estações LTSP precisam que o kernel tenha suporte a Ram Disk.
Isso precisa ser desabilitado.
Isso precisa ser habilitado. Isso irá instruir o kernel para configurar automaticamente a interface de rede eth0, baseado nos valores passados na linha de comando do kernel.
Não é necessário especificar opçoes de DHCP, BOOTP ou RARP porque a imagem de boot Etherboot já tem feito uma requisição de DHCP ou BOOTP, e o fará com os parâmetros de IP disponíveis na linha de comando do kernel. Isso dispensa o kernel do problema de fazer sua própria requisição.
Quando não é usado o initrd, você deve escolher o driver da placa de rede específico que combine com sua placa de rede. Isso DEVE ser linkado de forma estática no kernel, porque a interface de rede é necessária antes de montar o sistema de arquivos raiz. Essa é a principal diferença para o kernel com initrd.
Com o LTSP versão 2.09pre2, o suporte a devfs é necessário. Isso é verdadeiro independente se initrd é usado ou não
Ao NÃO usar initrd, o sistema de arquivos /dev deve ser montado pelo kernel, durante o processo de boot. Então, diga 'Y' aqui.
A Estação irá montar o sistema de arquivos raiz via NFS, então o suporte a cliente NFS é necessário.
Para tornar as coisas mais faceis, uma cópia do arquivo .config é incluido no pacote ltsp_initrd_kit. Você pode copiar isso para o diretório /usr/src/linux-2.4.9
Uma vez que você terminou de selecionar ou de-selecionar as opções do kernel, você precisar gerar o kernel. Os seguintes comandos devem ser executados para gerar o kernel:
make dep make clean make bzImage make modules make modules_install |
make dep && make clean && make bzImage && make modules && make modules_install |
Quando a compilação do kernel finalizar, o novo kernel estará situado em /usr/src/linux-2.4.9/arch/i386/boot/bzImage.
Para Etherboot carregar o kernel linux, é necessário que seja preparado. Isso é chamado 'Marcar' o kernel. Este processo adicionará código extra ao kernel que é executado antes do controle ser passado para o kernel. A ferramenta para marcar o kernel é chamada ' mknbi-linux'.
O ltsp_initrd_kit inclui um script shell chamado buildk que inclui todos os comandos que você precisa para preparar a imagem do kernel para boot por rede.
Quando projetamos o LTSP, um dos problemas que sabíamos que teríamos que tratar era com a variedade de configurações de hardware das estações. Certamente, qualquer que seja a combinação de processador, placa de rede e vídeo disponíveis hoje, poderiam não estariam disponíveis em três meses, então queremos adicionar mais estações à rede.
Então, planejamos um modo de especificar as configurações de cada estação. O arquivo de configuração é chamado de lts.conf e encontra-se no diretório /opt/ltsp/i386/etc.
O formato do lts.conf permite configurações 'padrões' e configurações individuais por estação. Se todas as suas estações são idênticas, você poderia especificar todos os seus parâmetros de configuração na sessão '[Default]'.
Este é um exemplo do 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
|
Comentários iniciam com o sinal '#' e continuam até o final da linha.
Isso indica onde o sistema de arquivos raiz do LTSP está localizado. O valor padrão é /opt/ltsp
Isso é o servidor que é usado para XDM_SERVER, TELNET_HOST, XFS_SERVER e SYSLOG_HOST, se qualquer um deles não for especificado explicitamente. Se você tem uma máquina que está atuando como um servidor para tudo, então você pode apenas especificar o endereço aqui e omitir os outros parâmetros de servidor. Se este valor não for setado, 192.168.0.254 será usado.
Se você quer enviar as mensagens de log para uma máquina que não seja o servidor padrão, então você pode especificar essa máquina aqui. Se este parâmetro não for especificado, então ele irá usar o parâmetro 'SERVER' descrito acima.
Isso especifica o endereço IP do servidor NFS usado quando o sistema de arquivos /homeé montado. O padrão é o que quer que tenha sido setado no parâmetroSERVER
Configure isso para Y se você quer ligar o swap por NFS. O Padrão é N
Isso é como você pode controlar o tamanho o arquivo de swap. O padrão é 64m.
O arquivo de swap pode existir em qualquer servidor da rede que tenha capacidade de manipulá-lo. Você pode especificar o endereço IP desse servidor. O padrão é o que quer que tenha sido setado no parâmetro NFS_SERVER.
O diretório no servidor que é exportado por NFS. O padrão é /var/opt/ltsp/swapfiles. Tenha certeza que o diretório está sendo exportado no arquivo /etc/exports.
Se a estação está configurada para ter uma interface baseada em caracteres, então o valor desse parâmetro será usado como o host para o telnet. Se esse valor não for setado, então será usado o valor do parâmetro SERVER acima.
Usado para gerar o arquivo resolv.conf.
Usado para gerar o arquivo resolv.conf.
Até 12 scripts de tela pode ser configurado por estação. Isso irá permitir até 12 sessões na estação que serão acessíveis pressionando-se as teclas Ctrl-Alt-F1 até Ctrl-Alt-F12
SCREEN_01 = startx SCREEN_02 = shell |
Atualmente os valores possíveis incluem:
Até 10 módulos do kernel podem ser carregados usando essas entradas de configuração. A linha de comando que você usaria executando o 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 é o caminho absoluto, então insmod será usado para carregar esse módulo. Senão, modprobe será usado.
Quando a estação inicializa, isso criará um ramdisk e montará no diretório /tmp. Você pode controlar o tamanho do sistema de arquivos com esse parâmetro. Especifique isso em unidade de kbytes (1024 bytes). Para criar um ramdisk de 1 megabyte, especifique RAMDISK_SIZE = 1024
Se você modificar o tamanho do ramdisk aqui, você precisará mudar também o tamanho do ramdisk dentro do kernel. Isto pode ser compilado dentro, ou se você está usando Etherboot ou Netboot, você dirá para o kernel o tamanho do ramdisk quando você rotular o kernel com mknbi-linux.
O valor padrão para isso é 1024 ( 1 mb )
Scripts RC adicionais podem ser executados pelo script rc.local. Apenas coloque o script no diretório /etc/rc.d, e especifique o nome do script em uma dessas entradas.
Se o pacote de som LTSP está instalado, você precisa configurar essa entrada para Y e isso irá executar o script rc.sound para configurar a placa de som e o daemon. O padrão é N.
Se você quer apontar o XDM para uma máquina diferente do servidor padrão, então você deve especificar o servidor aqui. Se o parâmetro não for especificado, então será usado o parâmetro SERVER descrito acima.
Isso define qual servidor X a estação irá executar. Para placas de video PCI e AGP, este parâmetro não é necessário. O script rc.local poderá auto detectar a placa. Você pode também configurar esse valor para auto para indicar que ele irá tentar auto detectar a placa.
Para placas de vídeo ISA, ou para forçar um servidor X específico, você pode especificar o nome do driver ou Xserver nesse entrada.
Se o valor iniciar com XF86_, então o XFree86 3.3.6 será usado. Senão, X.org 6.7.0 será usado. O valor padrão para isso é auto.
Até 3 Modelins ou resoluções podem ser configuradas para a estação. Esta entrada pode ter dois diferentes tipos de valores. Podendo ser uma resolução ou um completo modeline.
X_MODE_0 = 800x600 or X_MODE_0 = 800x600 60.75 800 864 928 1088 600 616 621 657 -HSync -VSync |
Se nenhuma das entradas X_MODE_x forem especificadas, então serão usadas as geradas em modelines, e as resoluções de 1024x768, 800x600 and 640x480.
Se uma ou mais entradas X_MODE_x forem especificadas, elas cancelarão completamente qualquer uma gerada em modelines.
Qualquer valor que funcione no protocolo de ponteiros do X.org pode ser colocado aqui. Valores típicos incluem "Microsoft" e "PS/2". O valor padrão para isso é "PS/2".
Isto é o dispositivo onde o mouse está conectado. Se é um mouse serial, isto será uma porta serial, como /dev/ttyS0 ou /dev/ttyS1. Se é um mouse PS/2, o valor será /dev/psaux. O valor padrão para isso é /dev/psaux.
Este é o valor 'Resolution' no arquivo XF86Config . O valor típico para um mouse serial é 50 e o valor típico para um mouse PS/2 é 400. O valor padrão para isso é 400.
Isso informa ao sistema quantos botões o mouse possui. Normalmente é setado para 2 ou 3. O valor padrão para isso é 3.
Isso informa ao servidor X para copiar um mouse de 3 botões aceitando um clique de ambos, os botões da esquerda e da direita simultaneamente. O valor padrão é N.
Para um mouse serial, isso define a taxa de baud. O valor padrão para isso é 1200.
Isto é o número de bits usados para a profundidade de cores. Valores possíveis são 8, 15, 16, 24 e 32. 8 bits teremos 256 cores, 16 teremos 65536 cores, 24 teremos 16 milhões de cores e 32 bits teremos 4.2 bilhões de cores! Nem todos os servidores X suportam todos esses valores. O Valor padrão para isso é 16
Você tem a escolha de executar um servidor de fontes X (XFS) ou ler as fontes através de um sistema de arquivos NFS. O servidor de fontes deve oferecer uma maneira simples de manter todas as fontes em um lugar, mas existem alguns problemas quando o número de estações cresce aproximadamente para mais de 40. Os 2 valores para essa opção são: Y e N. Se você quer utilizar um servidor de fontes, então você deve usar a entrada XFS_SERVER para especificar qual host irá atuar como um servidor de fontes.
Se você esta usando um servidor de fontes X para fornecer fontes, então você pode usar essa entrada para especificar o endereço IP do host que está atuando como um servidor de fontes. Se isso não for especificado, será usado o servidor padrão, que está especificado na entrada SERVER descrita acima.
Isto configura o parâmetro de configuração HorizSync do X.org. O padrão é "31-62".
Isto configura o parâmetro de configuração VertRefresh do X.org. O padrão é "55-90".
Se você quer criar seu próprio arquivo XF86Config completo você pode fazer isso colocando-o no diretório /opt/ltsp/i386/etc. Então, o que quer que você decida chamar é necessário ser colocado como valor para essa variável de configuração. Por exemplo:
XF86CONFIG_FILE = XF86Config.ws004 |
Se você está conectando uma touch screen na estação, você pode habilitá-la configurando esta entrada para Y. Se habilitada, as entradas de configurações adicionais irão configurar os aspectos específicos da touch screen. O valor padrão é N.
Uma touch screen funciona como um mouse e normalmente é interfaceada com a estação através de uma porta serial. Você pode especificar qual porta serial com essa entrada. Por exemplo, você pode configurá-la igual a /dev/ttyS0. Não há valor padrão para essa entrada.
Entrada de calibração para um touch screen EloTouch. Padrão é 433.
Entrada de calibração para um touch screen EloTouch. Padrão é 3588.
Entrada de calibração para um touch screen EloTouch. Padrão é 569.
Entrada de calibração para um touch screen EloTouch. Padrão é 3526.
Entrada de calibração para um touch screen EloTouch. Padrão é 10.
Entrada de calibração para um touch screen EloTouch. Padrão é 10.
Se você quer a capacidade de executar aplicações localmente na estação, configure esta variável para Y. Diversos passos adicionais devem ser feitos no servidor para habilitar aplicações locais. Verifique a seção 'Local Apps' no manual do LTSP para mais informações. O valor padrão é N.
Se você configurou LOCAL_APPS, então você deve ter um servidor NIS na rede. A entrada NIS_DOMAIN é onde você especifica o nome do domínio NIS. É necessário combinar o nome do domínio com o que foi definido no servidor NIS. Isso não é o mesmo que um domínio Internet. O valor padrão é ltsp.
Configure isso com o endereço IP de seu servidor NIS se você não quiser enviar um broadcast que irá localizar o servidor NIS.
Todos os arquivos de suporte de teclado são copiados dentro da hierarquia /opt/ltsp/i386 , para configurar suporte a teclado internacional é simplesmente uma questão de configurar o X.org. Existem vários parâmetros de configuração para isso.
Os valores para os parâmetros abaixo são da documentação do X.org. O que é valido para o X.org é valido para estes parâmetros.
Gostaríamos de adicionar documentação para mostrar quais valores são necessários para cada tipo de teclado internacional. Se você trabalha com isso e quer configurar seu teclado internacional, dê um retorno para o grupo de desenvolvimento do LTSP que será muito valorizado.
O valor padrão para isso é a palavra 'default '.
O valor padrão para isso é a palavra 'default '.
O valor padrão para isso é 'us(pc101)'.
O valor padrão para isso é 'pc101'.
O valor padrão para isso é 'us'.
Até três impressoras podem ser conectadas a uma estação diskless. A combinação de impressoras seriais e paralelas pode ser configurada através das seguintes entradas no arquivo lts.conf :
O nome do primeiro dispositivo de impressão. Nomes como /dev/lp0, /dev/ttyS0 ou /dev/ttyS1 são permitidos.
O tipo de impressora. Opções válidas são 'P' para Paralela, e 'S' para Serial.
A número de porta TCP/IP a ser usado. Por padrão, será usado ' 9100'
Se a impressora é serial, essa é a configuração para selecionar a velocidade (baud rate). Por padrão, '9600' será usado.
Para impressoras seriais, o controle de fluxo pode ser especificado. Use 'S' para controle de fluxo por software (XON/XOFF) ou 'H' para controle de fluxo por Hardware (CTS/RTS). Se nenhum deles for especificado, ' S' será usado.
Para impressoras seriais, a Paridade pode ser especificada. As opções são: 'E'-Even, 'O '-Odd ou 'N'-None. Se não for específicada, ' N' será usado.
Para impressoras seriais, o número de data bits pode ser especificado. As opções são: '5', ' 6', '7' e '8'. Se não for especificado, '8' será usado.
Nome do segundo dispositivo de impressão
Tipo do segundo dispositivo de impressão
Porta TCP/IP do segundo dispositivo de impressão
Velocidade (baud rate) da segunda impressora (serial)
Controle de fluxo da segunda impressora (serial)
Paridade da segunda impressora (serial)
Bits de dados da segunda impressora (serial)
Nome da terceira impressora
Tipo da terceira impressora
Porta TCP/IP da terceira impressora
Velocidade (baud rate) da terceira impressora (serial)
Controle de fluxo da terceira impressora (serial)
Paridade da terceira impressora (serial)
Bits de dados da terceira impressora (serial)
Em um ambiente LTSP, você tem a opção de rodar as aplicações localmente na estação, ou remotamente no servidor.
De longe, a maneira mais fácil de configurar um ambiente LTSP é rodar as aplicações no servidor. Isto é, a aplicação cliente roda no servidor usando CPU e memória do servidor, enquanto é mostrado a saída de tela na estação e usando o teclado e mouse da estação.
Isso é uma capacidade fundamental do X Windows. A estação funciona como um terminal X Windows padrão.
Para que um usuário execute uma aplicação na estação, esta precisa de algumas informações sobre o usuário. Informções sobre o seguinte:
Há benefícios da execução de aplicações na estação.
Configurar a capacidade de executar aplicações localmente necessita de muito mais.
Algumas entradas devem ser configuradas no arquivo lts.conf:
Isto deve ser setado para Y. Fará com que os seguintes passos aconteçam durante a processo de boot da estação.
Com NIS, todos os pontos na rede que querem ser associados a um servidor NIS específico precisam pertencer ao mesmo domínio NIS (isso não é relacionado de forma alguma a domínio DNS). Você usa a entrada NIS_DOMAIN para especificar o nome do domínio NIS que a estação irá pertencer.
NIS irá tentar conectar com um servidor NIS específico, ou irá enviar um broadcast para a rede, procurando por um servidor. Se você quer escolher um servidor específico, então entre com o endereço IP do servidor na entrada NIS_SERVER.
NIS é um tipo de serviço Cliente/Servidor. No servidor, há um daemon rodando, que irá aceitar requisições de clientes (estações de trabalho). O daemon no servidor é chamado ypserv .
Na estação, existe um processo chamado ypbind . Quando a estação precisa localizar uma informação sobre um usuário, tais como a verificação de uma senha ou localização do dirtório home de um usuário, usará o ypbind para estabelecer uma conexão com o ypserv, no servidor.
Se você já está rodando NIS em seu ambiente de rede, então não será necessário configurar o servidor LTSP para rodar ypserv. Você pode apenas configurar as entradas NIS_DOMAINNAME e NIS_SERVER no lts.conf para combinar com seu esquema NIS atual.
Se você não esta rodando NIS em sua rede, então você deverá configurar o servidor para rodar o ypserv.
Para uma completa informação na configuração de um servidor NIS, consulte o documento HOWTO no site LDP chamado The Linux NIS(YP)/NYS/NIS+ HOWTO. Consulte a lista de outras fontes de informação no final deste documento.
Para configurar uma aplicação para executar na estação, você precisa colocar todos os componentes da aplicação em um lugar onde a estação possa vê-la.
Com as versões antigas do LTSP (2.08 e anteriores), vários diretórios eram exportados no servidor e montados na estação. Diretórios como /bin, /usr/bin, /lib e /usr foram expostos para a estação.
O problema com esse esquema é que isto só funciona se a estação e o servidor forem da mesma arquitetura. Na verdade, mesmo com as diferenças, como o servidor é um Pentiun II (i686) e a estação um Pentium Clássico (i586) isso pode ser um problema, porque o servidor irá ter as bibliotecas i686 e não as bibliotecas i386, i486 ou i586.
Então, a maneira mais clara de resolver isto é ter uma árvore completa com todos os binários e bibliotecas que a estação irá precisar, independente das bibliotecas e binários do servidor.
Configurando uma aplicação para execução local requer a colocação de todas as peças necessárias na árvore. Um desses pacotes disponíveis para download no site do LTSP é o pacote do netscape local, que instala muito dos arquivos no diretório /opt/ltsp/i386/usr/local/netscape. Coisas como classes java, arquivos de Help, arquivos binários executáveis e scripts são colocados ali.
Netscape não precisa de quaisquer bibliotecas de sistema adicionais, então não há nada a adicionar no diretório /opt/ltsp/i386/lib . Muitas aplicações requerem bibliotecas adicionais.
Então, como você pode determinar quais bibliotecas serão necessárias? Isto é o que o comando ldd torna acessível.
Vamos pressupor que você precisa configurar uma certa aplicação para rodar localmente. Escolheremos gaim como exemplo. gaim é um cliente de Mensagens Instantâneas da AOL, isso irá permitir que você se comunique com outras pessoas nos foruns da AOL.
A primeira coisa que você vai precisar fazer é localizar o arquivo binário executável do gaim. Em um sistema Redhat 7.2, ele está localizado no diretório /usr/bin .
Uma vez localizado o binário do gaim, você pode executar ldd nele:
[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 é dinamicamente linkado em posição contrária.
A maioria dos programas usam bibliotecas compartilhadas, confie no carregador dinâmico ld-linux para localizar e carregar cada uma das bibliotecas compartilhadas. Entretanto, alguns programas, no entanto, carregam as bibliotecas manualmente com chamadas a função dlopen(). Para essas aplicações, ldd não irá mostrar as bibliotecas. Neste caso, strace deve ser usado para rastrear a execução desse programa, e você deverá ver as chamadas ao dlopen(), com o nome da biblioteca listada em seus argumentos.
Uma vez que a lista de bibliotecas for coletada, as bibliotecas necessárias deverão ser copiadas para seus locais apropriados na árvore /opt/ltsp/i386.
No X Windows, os programas funcionam normalmente em relação ao lugar onde o gerenciador de janelas está sendo executado. Isto é, se o gerenciador de janelas está executando no servidor, mostrando sua saída na estação, então todos os programas que serão chamados, serão executados no servidor, enviando sua saída para a estação.
O truque é o servidor dizer para a estação executar o programa. Isso é feito tipicamente com o comando rsh .
Aqui está um exemplo de como executar o programa gaim na estação:
HOST=`echo $DISPLAY | awk -F: '{ print $1 }'`
rsh ${HOST} /usr/bin/gaim -display ${DISPLAY}
|
O exemplo acima pode ser digitado em uma janela xterm, ou pode ser colocado em um shell script, e ser executado por um ícone na área de trabalho.
De modo similar é feita a execução local do Netscape, mas uma variável de ambiente adicional deve ser setada antes de executar o programa.
HOST=`echo $DISPLAY | awk -F: '{ print $1 }'`
rsh ${HOST} MOZILLA_HOME=/usr/local/netscape \
/usr/local/netscape/netscape -display ${DISPLAY}
|
Quase todos os aspectos de uma estação podem ser configurados com entradas no arquivo lts.conf, que geralmente está localizado no diretório /opt/ltsp/i386/etc .
Aqui está um exemplo das entradas no arquivo lts.conf para um mouse serial padrão 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 |
Aqui está um exemplo das entradas no arquivo lts.conf para o uso de um Intellimouse:
X_MOUSE_PROTOCOL = "IMPS/2" X_MOUSE_DEVICE = "/dev/psaux" X_MOUSE_RESOLUTION = 400 X_MOUSE_BUTTONS = 5 X_ZAxisMapping = "4 5" |
A estação ThinkNIC possui uma porta USB, que pode ser usada para conectar uma impressora local. Aqui está um exemplo das entradas necessárias no arquivo lts.conf :
MODULE_01 = usb-ohci MODULE_02 = printer PRINTER_0_DEVICE = /dev/usb/lp0 PRINTER_0_TYPE = S |
Por padrão, X.org 6.7.0 será usado para a estação. Se você quer forçar a estação a usar o antigo Xserver XFree86 3.3.6, você deve primeiramente carregar o pacote Xserver 3.3.6 apropriado. Então, você precisa adicionar a entrada no arquivo lts.conf . Este é um exemplo da especificação do SVGA Xserver:
XSERVER = XF86_SVGA |
www.linuxdoc.org/HOWTO/Diskless-HOWTO.html
www.xfree86.org/current/mouse.html
www.linuxdoc.org/HOWTO/XFree86-Video-Timings-HOWTO.html
Managing NFS and NIS
Hal Stern
O'Reilly & Associates, Inc.
1991
ISBN 0-937175-75-7
TCP/IP Illustrated, Volume 1
W. Richard Stevens
Addison-Wesley
1994
ISBN 0-201-63346-9
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)
