LTSP-4

Feb 3, 2004 - James McQuillan

LTSP Versão 4.0

Tradução: Marlon Dutra - 7 de março de 2004

Ok, foi um longo tempo. Muito tempo. Mas o LTSP 4 está finalmente disponível. O documento abaixo descreve alguns dos novos recursos, como instalar ele, como configurar e como pegar o código fonte.

Isso é uma daquelas coisas que nós poderíamos levar mais uns 2 anos, e continuar sentindo que não está do jeito que a gente gostaria. Mas, em algum ponto, nós percebemos que precisamos lançar a versão e ter o máximo de pessoas possível usando ela.

Muito obrigado,
Jim McQuillan - jam@Ltsp.org

Novos recursos
Instalação
Configuração
Aplicações locais
Código fonte
LTSP Build Environment (LBE)

Verifique a errata para as últimas informações.

Novos Recursos

Instalação

O procedimento de instalação do LTSP foi incrivelmente simplificado. Se você alguma vez já instalou o Ximian Desktop 2, você vai se sentir em casa com o novo instalador do LTSP-4.

Passo 1:

Primeiro de tudo você precisa o super-usuário na máquina. Então, um simples comando wget vai buscar o instalador do LTSP e iniciar o processo de instalação.

su -
wget -q -O - http://www.ltsp.org/ltsp_installer | sh

Passo 2:

Uma vez que o instalador terminou, você vai precisar configurar vários serviços no seu servidor. Nós criamos um novo utilitário chamado ltspcfg, descrito abaixo, para ajudá-lo com o processo de configuração.

No futuro nos planejamos oferecer pacotes DEB e RPM.

Passo 3:

Não há ainda um kernel específico para o LTSP-4. Os kernels para LTSP-3 vão trabalhar muito bem com LTSP-4. Você pode usar a versão RPM do pacote do kernel, mas você vai precisar forçar a instalação, porque ela depende do pacote ltsp_core do LTSP-3. Uma maneira mais simples é provavelmente instalar o pacote TGZ ltsp_kernel.

ltsp_kernel-3.0.15-i386.tgz

Configuração

Com LTSP-4 nós separamos a instalação da configuração. Nós agora provemos uma ferramenta de configuração chamada ltspcfg.

Você pode baixar ou um pacote RPM ou um pacote tarball contendo a ferramenta ltspcfg.

ltspcfg vai ajudar você a configurar os serviços necessários para rodar as estações LTSP.

Notas de instalação para o ltspcfg:

Aplicações locais

Em alguns casos é um desperdício ter uma CPU poderosa e bastante memória numa estação de trabalho e estar usando ela apenas para o rodar o kernel do Linux e o servidor X. Então, com LTSP, você tem a opção de rodar algumas aplicações localmente.

Nós levantamos a aplicação usando SSH.

Para tornar o ssh muito seguro, nós teríamos que gravar as chaves privadas da estações num dispositivo de armazenamento local, como um disquete, flash disk ou HD. Nós ainda não fomos tão longe assim com isso. A chave privada é gravada no servidor e acessada via NFS. NÓS SABEMOS que isso é um problema de segurança. Nosso primeiro objetivo com ssh era tornar possível levantar aplicações na estação. Nós estamos trabalhamos em tornar isso o mais possível.

Um par de chaves pública / privada é compartilhado entre todas as estações, e elas precisam ser criadas com o comando ssh-keygen e gravadas no diretório /opt/ltsp/i386/etc/ssh. A chave pública também precisa estar copiada no arquivo /etc/ssh/ssh_known_hosts. Na verdade, a mesma chave precisa existir nesse arquivo várias vezes, uma vez para cada estação, com o nome da estação precedendo cada registro. Uma vez que isso foi ajustado, se você quiser evitar que o usuário tenha que entrar com a senha cada vez que ele precisar abrir uma aplicação local, você vai precisar colocar as chaves públicas dos usuários nos seus próprios arquivos authorized_keys.

Para gerar o par de chaves para as estações, rode os seguintes comandos: 

ssh-keygen  -q  -t rsa1  -f /opt/ltsp/i386/etc/ssh/ssh_host_key      -C ''  -N ''
ssh-keygen  -q  -t rsa   -f /opt/ltsp/i386/etc/ssh/ssh_host_rsa_key  -C ''  -N ''
ssh-keygen  -q  -t dsa   -f /opt/ltsp/i386/etc/ssh/ssh_host_dsa_key  -C ''  -N ''

Você vai precisar tirar os conteúdos do arquivo /opt/ltsp/i386/etc/ssh/ssh_host_rsa_key.pub e adicionar uma linha no arquivo /etc/ssh/ssh_known_hosts para cada estação. Assegure-se que você colocou o nome da estação na frente de cada registro.

Abaixo está um exemplo de como o arquivo /etc/ssh/ssh_known_hosts deve se parecer: 

ws001  ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAxFCM2eZU7P3HvEOMYhAFUiwE...
ws002  ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAxFCM2eZU7P3HvEOMYhAFUiwE...
ws003  ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAxFCM2eZU7P3HvEOMYhAFUiwE...
ws004  ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAxFCM2eZU7P3HvEOMYhAFUiwE...
ws005  ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAxFCM2eZU7P3HvEOMYhAFUiwE...

Uma vez que o ssh está certo e o NIS está configurado no servidor, as seguintes configurações precisam ser adicionadas no arquivo lts.conf: 

LOCAL_APPS       = Y
NIS_DOMAIN       = ltsp

Tendo essas configurações adicionadas e a estação reiniciada, o usuário pode levantar programas na estação. Claro, a aplicação e todas as suas bibliotecas (libs) precisam estar acessíveis para a estação via NFS.

Aqui está um exemplo de como rodar um programa no cliente: 

ssh  ws001  uptime

Eu tive sucesso ao levantar o Mozilla Firebird 0.7 como uma aplicação local. Eu não criei o pacote oficial. Isso foi mais um teste, simplesmente para ver se eu podia fazer. E funciona!!! Ele requer a cópia de um monte de bibliotecas no diretório /opt/ltsp/i386/usr/lib, e a cópia do diretório do Mozilla Firebird para /opt/ltsp/i386/usr/local/MozillaFirebird-0.7. Uma vez isso feito, levantar o Firebird na estação é feito mais ou menos assim: 

ssh ws001 env DISPLAY=:0.0 /usr/local/MozillaFirebird-0.7/MozillaFirebird

Uma das principais razões para criar o LTSP-4 como o "Build envinronment" é que nós podemos construir aplicações locais. Nós planejamos oferecer um pacote oficial incluindo o Mozilla inteiro e todas as bibliotecas necessárias.

Código Fonte

O LTSP-4 é construído inteiramente do código fonte. Isso não significa que você DEVE compilar ele. Nós temos pacotes binários disponíveis também. É só que você PODE compilar ele, e customizar tudo o que você quiser.

Para ter contato com o código fonte, dê uma olhada na informação abaixo de como acessar o código via CVS.

LBE (LTSP Build Environment)

Provavelmente o maior recurso do LTSP-4 é o fato de ele ser inteiramente construído a partir do código fonte. Nas versões anteriores nós pegávamos binários de outras distribuições (principalmente RedHat 7).

Quando estávamos no processo de organizar o código fonte para todas os pedaços do LTSP, nós achamos que era quase impossível de fechar todas as versões de ferramentas de desenvolvimento em todas as plataformas onde as pessoas gostariam construir o LTSP. Por exemplo, para compilar a glibc 2.2, você precisa do gcc 3.2 ou mais novo pra fazer isso, e muitas distribuições de Linux existentes ainda não incluem ele. Então, nós viemos com algo que nós chamamos de LBE.

O LBE contém todos os compiladores, linkers e quaisquer outros utilitários que são usados para compilar o LTSP. Na realidade são exatamente as mesmas ferramentas e versões que nós usamos para construir os releases oficiais do LTSP.

Houve uma incrível quantidade de trabalho feito no LBE desde o LTSP-3. O processo inteiro de construção foi refeito e o método de obter os tarballs do fonte mudou.

Novo com o LTSP-4 é o esquema de cross-compilador. Nós achamos que nós precisávamos construir um cross-compilador, para forçar as ferramentas no LBE a usar as bibliotecas e os arquivos de include corretos. Nós ficamos muito irritados tentando entender por que o LBE compilava em algumas distros e em outras não. Então nós entendemos que cada distribuição tinha diferentes versões dos arquivos cabeçalho, e isso causava alguns problemas. Então nós temos um cross-compilador agora. Mesmo estando em um sistema x86 e gerando código x86, uma coisa brilhante é que isso nos deixa mais perto dum ambiente de construção onde nós podemos gerar código para clientes não x86. Mas, isso é uma coisa futura. Nós ainda não estamos prontos para manusear isso. Tendo um cross-compilador, isso também deve eliminar a necessidade de ter versões específicas de gcc e binutils no seu sistema.

Há uma árvore central bem pequena que é usada para iniciar o processo de construção. Os tarballs do fonte para os componentes individuais do LBE e LTSP não estão mais gravados dentro do pacote core. Eles são baixados automaticamente, usando o wget, no início do processo de construção.

Ainda mais, os componentes que são comuns entre o LBE e o LTSP compartilham o mesmo tarball, ao invés de incluir uma cópia do código duas vezes. Um exemplo seria o bash, o shell usado para ambos LBE e LTSP-4.

Uma ferramenta de construção muito poderosa foi escrita para o LBE e o LTSP. Essa ferramenta lê uma lista de pacotes para serem construídos, e então para cada pacote ela lê o arquivo package.def para instruções sobre como fazer a compilação.

Construindo o LTSP-4 do código fonte

  1. Baixando do CVS

    Escolha um diretório e vá para ele. Eu uso o diretório /usr/local/projects, mas você pode usar qualquer diretório que você prefira.

    Pegue o pacote LBE via cvs usando o seguinte comando: 

    cvs -d :pserver:anonymous@cvs.ltsp.org:/usr/local/cvsroot checkout lbe

    Isso vai criar um subdiretório chamado lbe que contém o seguinte: 

    lbe
build_all
crosscomp-src
initrd-src
kernel-src
lbe-src
ltsp-src
README
TODO
  2. Construindo

    ./build_all

    Esse processo vai construir os cross-compiladores, o LBE, o LTSP, o initrd e o kernel do LTSP.

    Esteja preparado para aguardar um tempo. Num Pentium 4 2,5 GHz, isso leva mais ou menos umas 3 horas.

© Linux Terminal Server Project