[GUFSC] GNU/Linux no LabGrad

[r2 em inf.ufsc.br]

Pow cara , devo lhe pedir desculpas ,
no mail anterior quis ironizar e acabei passando por rude.
Não levei a mal seu comentario nao...no stress...

Tipo... como havia dito no primeiro mail,
esse negocio de ficar montando via NFS não da certo.
Muito bonito , facil , blz....
Mas apartir do momentos que vc coloca mais de 40 maquinas na rede
com NFS, ele pira!
Sim...exatamente , pira!!!
Não acham mais servidor , ficam esperando pacote e travam.

Comentei sobre a solução do SMB , pq é muito mais facil quando o cara se loga
, colocar no script pra fazer um link para "smb://$IP/floppy" e
"smb://$IP/cdrom".
Entendes!?

Montar todos no servidor não  rola....
vai ter neguinho gravando coisa no diskete do outro....
=/
Sempre tem um com espirito de porco pra avacalhar...infelizmente.

Outra solução que o Zeh axou , era de fazer um FTP direto pra maquina.
Ele ta estudando isso agora...não sei direito como funciona.

Arthur

>> 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)
>
> _______________________________________________
> GUFSC mailing list
> GUFSC em softwarelivre.ufsc.br
> https://www.softwarelivre.ufsc.br/mailman/listinfo/gufsc
>