GAVRI-IM :: Grupo de Administradores Voluntários dos Recursos de Informática

Todos os passos aqui relatados foram realizados em uma máquina rodando Debian GNU/Linux 3.1 (codinome 'sarge'). A versão do LTSP escolhida foi a 4.1, pelas novas características de acesso a dispositivo local dos clientes, que permite manipulação de disquetes, cdroms e dispositivos usb. Para efetivar esta instalação nos guiamos pelo link oficial no sítio do LTSP, bem como alguns outros links para suprir dúvidas sobre os novos serviços que esta nova versão incorpora.

%ICO_SETA_DIR_AZUL% Instalação e configuração dos pacotes

Servidor DHCP:

Um servidor DHCP precisa ser instalado e configurado para identificar os clientes, garantir que estes inicializem um kernel do linux e apartir daí comecem a executar as operações necessárias a se integrar ao conjunto LTSP.

O servidor DHCP utilizado estava na versão 3.0.1, que precisa que a versão do kernel seja maior ou igual 2.2.x:

apt-get install dhcp3-server

Após a instalação é necessário rever as configurações deste serviço no arquivo /etc/dhcp3/dhcpd.conf(exemplo). Neste arquivo adicionamos duas linhas na seção global (antes da definição das subredes) para permitir o acesso a instruções de placas de rede ISA:

   option option-128 code 128 = string;
   option option-129 code 129 = text;

Para configurar as máquinas clientes dentro de uma sub-rede específica você pode usar as opções no arquivo de configuração para tal, bem como para grupo de máquinas clientes. No exemplo abaixo você pode perceber que a sub-rede que usamos é a 192.168.0.0/24 com máscara 255.255.0.0, com o roteador no ip 192.168.0.1 com DNS com o valor IP-DNS-SUA-REDE e domínio grupo.seu.dominio.de.rede. Ainda nesse exemplo o servidor de NFS está no ip 192.168.154.1. Altere estas configurações de acordo com sua rede de trabalho e coloque-as no arquivo dhcpd.conf:

subnet 192.168.0.0 netmask 255.255.0.0 {
        default-lease-time 86400;
        max-lease-time 90000;
        option subnet-mask 255.255.0.0;
        option broadcast-address 192.168.255.255;
        option routers 192.168.0.1;
        option domain-name-servers IP-DNS-SUA-REDE;
        option domain-name "grupo.seu.dominio.de.rede";   

        group { 
           option   root-path   "192.168.154.1:/opt/ltsp/i386";
           use-host-decl-names   on;

        # AQUI COLOQUE AS CONFIGURACOES DOS HOSTS, DESCRITOS ABAIXO 
        #  NESSE TUTORIAL.

        } #fim do group
} #fim do subnet

As configurações das máquinas clientes (hosts) habilitam funcionalidades importantes como a configuração de opções na placa de rede. No momento em que o cliente buscar o IP no DHCP este o informa qual o caminho do kernel que precisará ser carregado para a memória pela opção 'filename', veja um exemplo de configuração de uma máquina cliente existente do dhcpd.conf:

#Exemplo de configuracao para adicionar uma nova maquina no LTSP:
# - com instruções extras;
# - para usar um deste basta apagar os '#' mais à esquerda, assim você
# estará descomentando as linhas e ativando as configurações;
#
#   host NOME_DO_PC {
#      # O número NUMERO-MACADDRESS é o endereço físico da
#      #  placa de rede que independe da rede em que a máquina
#      #  esteja. Troque o nome NUMERO-MACADDRESS pelo número do
#      #  MAC da placa de rede.
#       hardware ethernet   NUMERO-MACADDRESS;
#      # O número do fixed-address é o IP que a máquina
#      #  vai possuir, troque o 'XXX' por um número entre
#      #  1 e 255, mas para manter a ordem adicione '1' (um)
#      #  no número IP da última máquina neste arquivo de
#      #  configuração.
#      fixed-address      192.168.154.XXX
#      # Este caminho de arquivo é o do kernel que será
#      #  carregado para a máquina cliente no LTSP, sem essa linha
#      #  a máquina não irá iniciar no LTSP! Afinal não exitirá
#      #  sistema para carregar! :-)
#      filename      "/tftpboot/lts/vmlinuz-486.ltsp"
#      #
#      # Estas opções abaixo são para placas de rede ISA
#      #  descomente-as se a placa de rede desta máquina for ISA
#      #  caso seja PCI não é necessário, pode deixar comentado!
#      #
#      # Esta opção possui um número parecido com o MACADDRESS
#      #  mas não tem nada haver com ele, é uma instrução
#      #  a nível de hardware que a placa de rede ISA entende.
#      #  Não mude esse número senão pode não funcionar! :-)     
#      #option option-128   e4:45:74:68:00:00
#      #
#      # Esta opção possui outras instruções a nível de
#      #  hardware para que a placa de rede entenda quais
#      #  os endereços de entrada e saída do sistema para 
#      #  usar, e qual o tipo de Chipset está sendo usado!
#      #  Em nosso caso, o chipset era da família NE2000, 
#      #  se o seu chipset for outro, o google.com pode ajudar!
#      #option option-129   "NIC=ne IO=0x300"
#   }   
#
# Resumindo :-), para um cliente com placa de rede ISA NE2000 ficamos com:
host s154pc03 {
   hardware ethernet       03:10:30:57:08:ad;
   fixed-address           192.168.154.103;
   filename                "/tftpboot/lts/vmlinuz-486.ltsp";
   
   # Opções disponíveis após a pré-definição na seção global
   #
   # executa uma instrução, esse número em hexadecimal é uma instrução
   # para a placa de rede e não um endereço MAC
   option option-128       e4:45:74:68:00:00;
   #
   # identifica o chipset da placa de rede e o endereço de entrada/saída
   option option-129       "NIC=ne IO=0x340";
}

Perceba que em nosso caso utilizamos uma placa de rede ISA do modelo NE2000, que possui o endereço de entrada/saída em 0x340, um valor comum para placas deste tipo.

Para maiores informações sobre configurar o DHCP veja a seção Script de Configuração do LTSP 4.1 (!!!!!!).

/etc/init.d/dhcp3-server restart

Caso ocorra uma falha ao reiniciar o serviço do DHCP certifique-se que a placa de rede em que o DHCP está rodando está corretamente configurada, e depois verifique o arquivo dhcpd.conf para garantir que as configurações estão corretas. Algumas vezes ocorre de esquecermos de fechar as chaves nas definições de grupo e sub-rede, então fique atento, antes de se revoltar! smile

Servidor TFTP:

O TFTP é um serviço de FTP (File Transfer Protocol) simples desprovido de autenticação usado pelo EtherBoot nos clientes para que este possa baixar o kernel específico para seu uso (não necessariamente o kernel do servidor, não recomendamos). Assim basta configurar o tftpd que é um servidor de TFTP. Para isso precisamos instalar:

apt-get install tftp tftpd

Depois de instalar, deve-se configurar o tftpd para rodar no inetd, editando o arquivo /etc/inetd.conf e adicionando a linha do tftpd. Por razões de segurança é aconselhável comentar as linhas de todos os outros serviços.

Como argumento pode-se passar ao in.tftpd o diretório onde este permitirá o acesso, evitando que outros arquivos de outros diretórios possam ser acessados por TFTP, o que não é seguro. Em nosso caso, adicionamos a seguinte linha ao /etc/inetd.conf:

# execute este serviço apenas nas máquinas que agem como "servidores de boot"
tftp    dgram   udp   wait   nobody   /usr/sbin/tcpd   /usr/sbin/in.tftpd /tftpboot/lts

/etc/init.d/inetd restart

Servidor NFS:

Após o cliente do LTSP conseguir o kernel e colocar o mesmo em execução, este cliente tentará montar o diretório onde o LTSP está instalado no servidor (normalmente /opt/ltsp/i386) como sua raiz do sistema de arquivos na sua memória RAM, através do protocolo NFS. Veja como acessar a memória RAM da máquina cliente mais adiante em (!!!!!!).

apt-get install nfs-kernel-server

Para configurar o NFS veja a seção Script de Configuração do LTSP 4.1 (!!!!!!).

Em nosso caso, foi preciso reconfigurar o arquivo /etc/exports, após a execução do ltspadmin, alterando a linha:

/opt/ltsp/            192.168.0.0/255.255.0.0(ro,no_root_squash,sync)

por

/opt/ltsp/i386        192.168.0.0/255.255.0.0(ro,no_root_squash,sync)

Sempre após qualquer alteração no arquivo /etc/exports, reinicialize o serviço:

/etc/init.d/nfs-kernel-server restart

Servidor XFS (X Font Server):

Para a execução de um cliente do servidor X, que utilize os recursos de fontes na interface gráfica do servidor LTSP, é necessário configurar o arquivo do cliente do X para usar as fontes do servidor X na máquina servidora do LTSP, conforme exemplo na sessão Files:

Section "Files"
   FontPath   "tcp/192.168.154.1:7100" #Servidor de Fontes do X
   # if the local font server has problems, we can fall back on these
   FontPath   "/usr/lib/X11/fonts/misc"
   FontPath   "/usr/lib/X11/fonts/cyrillic"
   FontPath   "/usr/lib/X11/fonts/75dpi/:unscaled"
   FontPath   "/usr/lib/X11/fonts/100dpi/:unscaled"
   FontPath   "/usr/lib/X11/fonts/Type1"
   FontPath   "/usr/lib/X11/fonts/Speedo"
   FontPath   "/usr/lib/X11/fonts/100dpi"
   FontPath   "/usr/lib/X11/fonts/75dpi"
EndSection

Para que isto ocorra também é preciso instalar o pacote xfs no servidor LTSP (em nosso exemplo considerado de IP 192.168.154.1), perceba que este pacote não tem nada haver com os programas relativos ao tipo de partição XFS.

Entretanto, a instalação do xfs por padrão deixa desabilitado a opção do transporte por TCP/IP das fontes do servidor X, basta editar o arquivo /etc/X11/fs/config na máquina servidora do LTSP, e comentar a linha da variável no-listen=tcp, para que o cliente possa acessar as fontes do X através da rede, veja:

# turn off TCP port listening (Unix domain connections are still permitted)
#no-listen = tcp

/etc/init.d/xfs restart

Servidor SYSLOG:

O programa syslogd é naturalmente o servidor de logs do sistema, que se comunica com os outros programas pelos sockets UNIX. O cliente do LTSP não guarda os logs na sua memória, mas sim na máquina servidora LTSP, afinal a memória RAM é volátil e qualquer momento o cliente pode travar. Entretanto ainda é preciso ler os logs para saber qual problema ocorreu, a forma encontrada pelo time do LTSP foi utilizar o servidor de logs do sistema da máquina servidora.

Para isso é preciso alterar a configuração no arquivo /etc/init.d/sysklogd na variável SYSLOGD para o valor "-r", veja como fica:

# Options for start/restart the daemons
#   For remote UDP logging use SYSLOGD="-r"
#
SYSLOGD="-r"

/etc/init.d/sysklogd restart

Gerenciador de Tela/Sessões

Para utilizar a instância gráfica é sempre útil configurar um gerenciador de entrada como o WDM, KDM ou GDM. Aqui vamos explicar como configurar o GDM (Gnome Display Manager) para funcionar através do XDMCP (X Display Manager Control Protocol), para saber como configurar no WDM ou KDM veja as instruções na Configuração da versão 3 do LTSP (as versões do kdm e wdm usadas eram mais antigas, mas deve funcionar! Notifique-nos em caso contrário!).

Agora é necessário configurar o arquivo /etc/gdm/gdm.conf adequadamente para o funcionamento do LTSP. Esta configuração abrange detalhes como quantidade de conexões que o processo do gdm deve aceitar e a quantidade de telas por máquina, ou seja, é preciso você adequar à sua realidade as informações deste arquivo.

Ao invés de editar o arquivo manualmente e reiniciar o serviço, você pode executar:

# Sessão SECURITY do gdm.conf
[security]
(...)
# --corta--
# Configuração para o GDM aceitar conexões remotas
# Se 'true' isso irá utilizar a opção '-nolisten tcp' a cada linha de
# comando do X, é bom manter por padrão para utilização indevida do GDM 
# como servidor de XDMCP, afinal pode ser um risco de segurança permitir
# acesso ao X remotamente.
# No caso do LTSP isto é necessário para permitir as tais conexões remotas
# ao GDM e assim servir a interface gráfica! Logo atribua o valor 'false'
DisallowTCP=false
# --corta--
(...)
# --corta--
# Sessão XDMCP do gdm.conf
[xdmcp]
# Ativando o XDMCP, apesar de não ser muito seguro ativá-lo em uma rede.
# É imporante configurar o /etc/hosts.allow e /etc/hosts.deny para apenas
# as máquinas conhecidas terem acesso ao XDMCP. De toda forma é mais seguro
# controlar o acesso à porta 177 (porta padrão do XDMCP) através de um 
# firewall, para evitar problemas com maus usuários.
# Leia o manual do GDM para maiores informações de segurança do XDMCP.
Enable=true

# Desativando o redirecionamento para outro servidor XDMCP.
HonorIndirect=false

# Configurando a quantidade de pedidos a serem recebidos sem descartá-los.
MaxPending=10
MaxPendingIndirect=10

# Configurando a quantidade máxima de sessões XDMCP por vez. Isto pode ser 
# entendido como a quantidade máxima de máquina que serão clientes do XDMCP.
MaxSessions=30

# Configurando o tempo de espera por uma conexão.
MaxWait=15
MaxWaitIndirect=15

# Configurando a quantidade de vezes que um usuário qualquer pode logar na
# mesma máquina cliente (host). Normalmente este valor é baixo para evitar
# ataques por DoS pela tentativa de muitos logins por máquina. Mas a depender
# dos problemas que você venha a ter com as máquinas clientes pode aumentar 
# um pouco, por exemplo, se o host reinicia abruptamente muitas vezes, então 
# os processos do gdm para este host provavelmente demorarão a serem mortos 
# pelo kernel (entram em espera por resposta do host para receber o sinal de
# término).
DisplaysPerHost=2

# Configurando o tempo (em segundos) para confirmar que uma sessão não está mais
# respondendo. Melhor manter este valor baixo!
PingIntervalSeconds=30

# Configurando a porta onde o XDMCP vai funcionar, isto é importante nos casos 
# em que a porta 177 está sendo filtrada por algum firewall. O padrão é 177.
Port=177
# --corta--
(...)
# Sessão GUI do gdm.conf
[gui]
(...)
# --corta--
# Configurando o menu de ações (conhecido como Menu de Sistema) é mostrado no 
# GDM, este menu contém as opções REINICIAR, DESLIGAR, SUSPENDER e CONFIGURAR.
# Entretanto todas estas opções são relacionadas à máquina onde o GDM está 
# instalado e não na máquina cliente, logo é recomendado manter o valor como 
# 'false', evitando que a máquina servidora seja desligada ou reiniciada.
SystemMenu=false

# Dentro do menu de sistema (ações), você pode configurar que as opções desse
# menu só seja acessada pelo usuário 'root', ou seja, ao clicar será solicitada
# a senha de 'root'. Isto é extremamente recomendado!
SecureSystemMenu=true
# --corta--
(...)
# Sessão SERVERS do gdm.conf
[servers]
(...)
# --corta--
# Configurando quais os servidores padrões. Um servidor padrão é ativado na 
# máquina em que o gdm está instalado. Caso você não queira que exista uma 
# sessão GDM no servidor, basta comentar as linhas do gênero abaixo:
0=Standard
#1=Terminal
#2=Chooser
# Note que 'Standard', 'Terminal' e 'Chooser' se relacionam às respectivas sessões 
# 'server-Standard', 'server-Terminal' e 'server-Chooser' dentro do mesmo arquivo
# gdm.conf.
# --corta-- 
(...)

/etc/init.d/gdm restart

Instalação do LTSP v4.1:

wget -c http://www.ltsp.org/ltsp-utils-0.10.tgz;

tar xvzf ltsp-utils-0.10.tgz
cd ltsp-utils-0.10.tgz
ls
COPYING  install.sh  ltspadmin  ltspcfg  ltspinfo
./install

Esta operação instalou alguns programas usados pelo instalador do LTSP v4.1 como: ltspadmin, ltspcfg e ltspinfo.

A execução desta ferramenta apresentou um erro devido a inexistência de uma biblioteca, a libwww-perl. Resolvemos o problema com:

apt-get install libwww-perl

Se você possui uma versão anterior do LTSP já instalada, os desenvolvedores recomendam que a instalação do pacotes do ltsp-4.1 seja feita em um diretório diferente, o que pode ser feito também através da ferramenta ltspadmin. Em nosso caso, salvamos a instalação antiga do ltsp-4.0.

Instalamos TODOS os pacotes. Depois escolhemos o item do menu Configure LTSP, que executa a ferramenta ltspcfg para configurar os serviços necessários no servidor LTSP.

%ICO_SETA_DIR_AZUL% Configuração dos disquetes de boot para os clientes

Baixamos do sítio http://www.etherboot.org/ (em 07/10/2004) os pacotes de duas versões do etherboot:

tar xvjf etherboot-5.0.7.tar.bz2;
cd etherboot-5.0.7/src;

Para confeccionar o disquete para uma placa de rede baseada no módulo 'eepro100' e colocar diretamente no disquete que está no /dev/fd0:

make bin32/eepro100.fd0

Para confeccionar o disquete para uma placa de rede baseada no módulo 'ne' e colocar diretamente no disquete que está no /dev/fd0:

O mesmo procedimento é usado para a versão 5.3.9, exceto pela pasta 'bin32' que não existe nesta versão, mas existe a pasta 'bin' que serve para o mesmo fim. Tivemos problema com o disquete gerado por esta versão para as placas NE2000 ISA, que não completaram a inicialização e busca de IP.

Caso você use o serviço DHCP em outras portas que não as padrões (67 para o servidor e 68 para o cliente), é necessário fazer uma pequena modificação em um arquivo de cabeçalho.

Na versão 5.0.7 altere o arquivo src/etherboot.h dentro da pasta onde você descompactou o pacote do etherboot-5.0.7:

#define BOOTP_SERVER    67 //altere aqui o valor da porta em que o servidor DHCP 
                           //  está rodando
#define BOOTP_CLIENT    68 //altere aqui o valor da porta em que o cliente vai 
                           //  buscar o servidor DHCP, normalmente BOOTP_SERVER+1

Na versão 5.3.9 altere o arquivo src/include/bootp.h dentro da pasta onde você descompactou o pacote do etherboot-5.3.9, de acordo com as mesmas instruções descritas acima.

%ICO_SETA_DIR_AZUL% Recompilando um kernel para os clientes LTSP

Para especializar o kernel dos clientes não é difícil. Nós usamos o kernel 2.4.24 em nossos clientes. Após baixar os fontes do kernel em http://www.kernel.org, é preciso aplicar algumas modificações para as necessidades do LTSP.

Esta modificação habilita no cliente a configuração de um arquivo de 'swap' no servidor que é usado para facilitar as trocas de memória. Disponibilizamos uma versão desse patch que é usado com o kernel 2.4.24:

Esta modificação habilita no cliente o acesso aos dispositivos locais por 'supermount', que é a idéia de montar os dispositivos no momento em que o acesso é requisitado, e permite por software a definição de um tempo limite para desmontar caso o acesso não esteja sendo feito. Disponibilizamos uma versão desse patch que é usado com o kernel 2.4.24:

cd /usr/src/kernel-source-X.X.X
make menuconfig
make dep && make clean && make bzImage && make modules && make modules_install

Após a compilação o arquivo bzImage estará em /usr/src/kernel-source-X.X.X/arch/i386/boot/bzImage.

Usando o etherboot o kernel do linux precisa ser marcado através do mknbi-linux, que irá preparar o kernel para a inicialização pela rede, prefixando alguns códigos adicionais e anexando o initrd ao final do kernel.

apt-get install mknbi-linux

Ao descompactar esse pacote será criada uma pasta ltsp_initrd_kit e dentro têm um script buildk o qual usará o mknbi-linux para construir um initrd adequado para a inicialização dos clientes. Também recomendamos a edição do arquivo root/linuxrc dentro da mesma pasta que é o script que será executado no momento da inicialização do cliente do LTSP depois do kernel ser carregado na memória. Esse script contêm as informações sobre a configuração de rede, montagem do diretório /opt/ltsp/i386 do servidor LTSP na memória do cliente através do NFS, dentre outras atividades importantes como o carregamento de módulos no cliente.

tar xvzf ltsp_initrd_kit-3.0.15-i386.tgz
cd ltsp_initrd_kit
ls -l
-rwxr-xr-x   1 root root   14345 2004-02-02 01:58 buildk
-rw-r--r--   1 root root  876394 2004-04-06 14:21 bzImage-2.4.24-ltsp-4
-rw-r--r--   1 root root   23692 2004-04-06 14:21 config-2.4.24-ltsp-4
-rw-r--r--   1 root root     152 2004-04-06 14:21 config.in
-rw-r--r--   1 root root  975103 2004-04-06 14:21 initrd-2.4.24-ltsp-4.gz
-rw-r--r--   1 root root 2560000 2004-04-06 14:21 initrd.ltsp
drwxr-xr-x   2 root root     116 2004-02-04 03:05 patches
drwxr-xr-x  13 root root     136 2004-01-27 16:36 root
drwxr-xr-x  13 root root     136 2003-11-15 13:22 root_pcmcia
-rw-r--r--   1 root root 1861120 2004-04-06 14:21 vmlinuz-2.4.24-ltsp-4

Uma das funcionalidades que pode ser necessária alterar no root/linuxrc é a porta do servidor DHCP, por exemplo. Caso o servidor DHCP rode este serviço em uma porta que não é a padrão (67), informação configurada na variável DPORT.

NOVO: Caso você queira passar parâmetros ao kernel do cliente LTSP durante a sua inicialização então altere o arquivo buildk e no final altere a linha:

DE:

--append="init=/linuxrc rw"

PARA:

--append="init=/linuxrc rw SEUSPARAMETROS"

SENDO: SEUSPARAMETROS por exemplo vga=791

Lembre-se que estes parâmetros dependem do seu kernel, ou seja, não adianta colocar vga=791 sem que o suporte a VESA esteja configurado no kernel. Para colocar este suporte recompile seu kernel.

Agora caso você tenha recompilado o kernel do cliente LTSP, basta executar o script abaixo e seguir as telas de configuração:

bzImage-X.X.X-version
vmlinuz-X.X.X-version
initrd-X.X.X-version.gz

Sendo que a expressão X.X.X-version depende da sua compilação do kernel, por exemplo, 2.4.24-ltsp-client. Organizando os arquivos faça:

mkdir /tftpboot/lts/X.X.X-version
cp bzImage-X.X.X-version /tftpboot/lts/X.X.X-version
cp initrd-X.X.X-version.gz /tftpboot/lts/X.X.X-version
cp initrd.ltsp /tftpboot/lts/X.X.X-version
cp vmlinuz-X.X.X-version /tftpboot/lts

Por fim basta notar que a compilação do kernel do cliente LTSP cria uma pasta do tipo X.X.X-version no /lib/modules do servidor. Para no momento da inicialização o cliente poder carregar seus módulos corretamente ele precisa que esta pasta esteja em /opt/ltsp/i386/lib/modules, porque esta é a pasta montada por NFS. Desta forma faça:

mv /lib/modules/X.X.X-version /opt/ltsp/i386/lib/modules

Atenção, certifique-se que você está fazendo esta operação com a pasta de módulos referente ao kernel do cliente LTSP que acabou de ser compilado, para evitar que por distração você mova a pasta do kernel do seu servidor LTSP e o sistema pare de funcionar, em último caso.

%ICO_SETA_DIR_AZUL% Configurações extras no LTSP 4.1

Como um software livre, o LTSP também nos permite aplicar certas modificações que se adequem à realidade local. Sendo assim podemos fazer a festa!!

Modificação no Acesso a Dispositivos Locais

No IM/UFBA, atualmente, existe a necessidade do acesso a disquetes nos clientes, que é provido pelo pacote ltsp-localdev contido na distribuição do LTSP 4.1. Entretanto o método de acesso disponível pelo ltsp-localdev (descrito em http://www.ltsp.org/localdev.txt e LTSP:Ltsp/LocalDrives ) é baseado no programa autofs para obter o acesso ao compartilhamento Samba que cada cliente exporta (estes compartilhamentos são os pontos de montagem dos dipositivos locais - disquete,cdrom,hd - usando os recursos do supermount habilitado no kernel do cliente).

Em nosso caso, esta solução traz alguns problemas como a falta de controle na permissão dos usuário que acessam este compartilhamento, uma vez que não temos como limitar através da configuração do autofs qual usuário pode usar o compartilhamento de qual cliente. Isto causaria, por exemplo, que qualquer usuário logado em um cliente do LTSP pudesse acessar o compartilhamento de qualquer outro usuário logado em outro cliente do LTSP. Normalmente esta situação é indesejável.

Solucionamos este problema de duas formas atualmente, uma mais grosseira e outra mais elegante smile

umount -f $HOME/disquete_ltsp

su -c 'smbmount //$REMOTE_HOST/floppy $HOME/disquete_ltsp -o guest,username=nobody' $USER

smbumount $HOME/disquete_ltsp

Perceba que estes comandos serão inseridos dentro dos scripts referidos anteriormente, e dependem das variáveis internas que o gdm utiliza, por exemplo, pode acontecer que você esteja usando o KDM e que a variável $REMOTE_HOST não esteja disponível ou o seu conteúdo (IP da máquina cliente que faz a requisição remota ao Xserver) seja referenciado por outra variável.

Abaixo estão alguns patches para os scripts do GDM que utilizamos aqui no IM/UFBA:

Para aplicar estas modificações indicamos antes que você faça uma cópia de backup dos seus scripts originais e então execute os seguintes comandos como administrador:

cd /etc/gdm/PreSession
patch -p0 < /caminho/onde/está/patch_script_PreSession_gdm_LTSP-localdev_access
cd /etc/gdm/PostSession
patch -p0 < /caminho/onde/está/patch_script_PostSession_gdm_LTSP-localdev_access

Outra Modificação no Acesso a Dispositivos Locais

Para possibilitar o uso de disco rígido através do compartilhamento Samba.

(em breve..)

Modificação na Tabela de Inicialização

Para facilitar a manipulação dos terminais de forma similar a uma máquina normal CTRL+ALT+F7 = X, CTRL+ALT+(F1 até F6) = terminais.