[GUFSC] GNU/Linux no LabGrad

[Leonardo Trentini Lang]

> Recomendo então que estude um pouco mais sobre terminais remotos.
> Vc verá que a tela que aparece para o usuario é a do servidor
> (xdmcp) e o floppy esta no cliente o que pode ser feito é montar
> remotamente (via samba) o floppy (que esta no cliente) no servidor.

O que eu quis dizer é que usar Samba é desnecessário. Dá pra resolver
o problema inteiro usando <editor-de-texto-favorito>, mount e chroot,
com ajuda de um patch e de recursos do kernel 2.6.15+. O que deve ter
causado confusão é que, realmente, não desenvolvi todo o raciocínio no
e-mail anterior, talvez por ter dado mais importância à parte dinâmica
do problema.

Continuando: depois de montar o disp. removível com supermount-ng
*localmente*, compartilha-se ele com o servidor *via NFS* ou algo
similar (sim, dá pra compartilhar mounts via NFS). Só não sei se
compartilhar uma unidade montada com supermount vai preservar
a semântica desejada, mas é algo que pode ser testado. Outra solução
seria compartilhar, por exemplo, o próprio dispositivo de disquete
ou cdrom - caso a opção do NFS não funcione - e montar no *servidor*
com supermount. Mas aí é interessante googlar por alguma solução deste
nível [nbd não serve, BTW - mas pode ser um bom ponto de partida].

A partir daí, cria-se um "espelho" da raiz (/) para cada máquina,
usando binded mounts ('mount --bind'), removendo o acesso dos
espelhos a eles mesmos (kernel 2.6.15+, 'mount --make-unshared') e
colocando cada {disquete,cdrom,usb-storage} compartilhado dentro
da árvore de cada máquina ('mount --bind' denovo, ou montando o
próprio compartilhamento NFS ali). Por exemplo:

/maquinas -- onde localizam-se as árvores virtuais.
bancadap103 -- máquina hipotética.

# mkdir -p /maquinas/bancadap103/
# mount --make-unshared /maquinas/
# mount --rbind / /maquinas/bancadap103/
# mount -t nfs bancadap103:/media/floppy \
      /maquinas/bancadap103/media/floppy

Pra entender como funciona esse mecanismo do mount
(bind, rbind, make-unshared, etc), é só dar uma olhada no patch
das shared subtrees [1], que entrou recentemente no kernel.

Por fim, quando abre-se uma conexão XDMCP com o servidor, e o
usuário loga, faz-se um chroot (que, se não me engano, pode
ser feito até no Xsession) para dentro dessa árvore virtual,
privativa da máquina, *no servidor*. E pronto: todos os outros
arquivos do servidor, assim como as unidades removíveis,
estão acessíveis, e não há nenhum acesso às unidades das outras
máquinas. Problema de segurança resolvido.

> Fazer isso dinamicamente é um pé no saco....

É sim, mas não precisa ser dinamicamente. Esse era o problema
que o supermount iria resolver.

> tenho coisas mais importantes para resolver.....

Eu não duvido. Disse que era 'simples', não que não era trabalhoso. ;)

Não me leve a mal, não quis botar competência nenhuma em
questionamento - muito pelo contrário. O meu ponto é, basicamente,
o que comentei antes sobre o maior problema do LabUFSC: a falta de
pessoal. Mesmo as coisas que poderiam ser resolvidas, ficam pendentes
porque sempre há algo mais urgente aparecendo, e pouca gente pra
ajudar. Isso atrapalha bastante, infelizmente.

E é isso.

[1] http://lwn.net/Articles/159077/
--
Leonardo Lang AKA tlang em inf
-- 
Ciências da Computação (cco021)
Universidade Federal de Santa Catarina
-- 
BNU-FNS, SC, Brasil
-- 
Usuário GNU/(Linux #217916)