Cara, vivi uma situa��o id�ntica, consegui resolver e uso at� hoje.
Se voc� n�o gosta do automount, lamento, ter� que us�-lo.
Na minha opini�o voc� tem duas possibilidades:
01 - Usar boot remoto (www.ltsp.org). Voc� n�o precisar� mais dos HDs das esta��es e todo o boot e configura��o ser� feito sem interfer�ncia de um sistema na esta��o. Com boot remoto � criado um diret�rio no servidor com uma raiz "virtual" para esta��o. Ap�s o boot pela rede a esta��o monta essa raiz virtual e passa a "pensar" que seu sistema � aquele diret�rio exportado via NFS pelo servidor e montado por um script nessa raiz "virtual. O LTSP disponibiliza um pacote para acesso ao disquete. Ele � um servidor (floppyd) que fica rodando na esta��o. O absurdamente irritante disso � que o acesso ao disquete se faz como em um FTP, ou seja, n�o � poss�vel, por exemplo, abrir diretamente um arquivo de um disquete. � necess�rio copi�-lo antes. E a interface para acessar o disquete � no m�nimo estranha - MToolsFM (apesar de gr�fica). Por�m, digo isso da vers�o 3.x da LTSP. A vers�o, 4.x, dizem, resolveu muitas dessas coisas horr�veis. N�o experimentei.
02 - Usar a instala��o da esta��o para sincronizar via NFS o acesso ao floppy. Acho que � o seu caso pois est� usando Linux instalado em um HD normalmente e apenas o uso do X � que acontece remotamente.
O servidor e a esta��o ter�o o automount rodando.
Quando um usu�rio do terminal X acessar, por exemplo, o diret�rio meu_disquete, o automount do servidor tentar� montar o /mnt/floppy, exportado via NFS pela esta��o.
O automount da esta��o, ao perceber que est�o tentando acessar o /mnt/floppy vai montar o /dev/fd0 no /mnt/floppy.
Quando o usu�rio no X sair do meu_disquete, o automount do servidor vai desmontar o acesso via NFS do diret�rio /mnt/floppy da esta��o.
E o automount da esta��o, ao perceber que "largaram" o /mnt/floppy, vai desmontar o /dev/fd0.
Uso isso em uma rede com dez computadores. S�o usu�rios leigos viciados em windows.
Nunca tive problemas.
O que pode ficar bizarro � o fato de que voc� dever� ter um diret�rio onde todos os diret�rios de disquetes da rede estariam dispon�veis.
O legal disso � poder acessar de qualquer esta��o o floppy de qualquer outra esta��o.
Algo como, ao entrar no diret�rio /home/dispositivos, o usu�rio encontrar:
disquete_estacao1 disquete_estacao2 disquete_estacao3 ...
Ele ter� que saber qual � a sua para abrir o disquete correto.
E nem pense em colocar esses diret�rios que o automount vai usar diretamente em um diret�rio que � lido de cara ao entrar em seu n�vel mais alto.
Isso significa que, se os diret�rios citados acima (disquete_estacao_...) forem os diret�rios que o automount usar� diretamente, quando um usu�rio entrar no /home/dispositivos o servidor tentar� montar os disquetes de todas as esta��es. N�o vai chegar a travar servidor e esta��es, mas vai dar dor de cabe�a.
A solu��o que usei foi criar um /home/DISQUE_e_CDROM_estacao_1 e por a� vai (n�o necessariamente esse nome horr�vel).
Quando o usu�rio entrar no /home/DISQUE_e_CDROM_estacao_1 por exemplo, encontrar�, dentro, o diret�rio que de fato o automount usar�, ou seja, algo como simplesmente DISQUETE.
Ou seja, o diret�rio usado pelo automount ficar� isolado dentro de um diret�rio anterior onde o usu�rio vai escolher de qual esta��o � o disquete.
Complicado? Se souber vender o fato de que um usu�rio pode acessar todos os disquetes de qualquer esta��o, pode ser um mote para vender "avan�o" e n�o complica��o.
Por exemplo, se um drive der problema ou queimar, o usu�rio pode colocar o disquete em outra esta��o sem precisar interromper o trabalho do outro usu�rio.
Bom... de qualquer maneira vai complicar mesmo.
N�o encontrei nenhuma solu��o melhor.
Ou melhor, atualmente tenho algumas esta��es usando boot remoto (no esquema FTP horr�el - 5 esta��es), algumas usando X remoto (o seu caso - 6 esta��es) e o restante (uma penca) delas como esta��es plenas (com HD e instala��o direitinho).
O automount n�o deu nenhum problema a n�o ser pelo maldito Konqueror que por configura��o para "otimizar" o sistema mantinha o acesso ao diret�rio do automount mesmo depois de o Konqueror ser fechado.
Mas � s� desabilitar esse configura��o no pr�prio Konqueror (se for usar o maldito KDE).
Espero ter ajudado de alguma maneira.
Ralei muito com esse neg�cio de X remoto e boot remoto LTSP.
Curti muito a id�ia, ao contr�rio de todos os usu�rios que n�o entendiam que se n�o fosse por isso os computadores que usavam iriam para sucata e ficariam sem qualquer coisa.
Fora isso, a irrita��o fica por conta do automount que � horr�vel. Ele funciona, mas funciona feio.
Ouvi falar de um tal de MagicDev. N�o procurei saber sobre o assunto. Talvez voc� encontre algo mais interessante do que o automount.
[]'s Alexander
On Thu, 17 Feb 2005, Joelcio Kuroski wrote:
Tenho algumas m�quinas velhas com um pequeno HD e uma mini-distro instalada. Elas funcionam como terminais X rodoando aplica��es remotamente num servidor. Obviamente o gerenciador de janelas instalado (KDE 3.2.3) mostra os dispositivos (entre os quais o floppy) do servidor, e n�o da m�quina que funciona como terminal. Para um usu�rio desse terminal usar o dispositivo local o Valter (Giganerds) me sugeriu que o terminal exportasse via NFS o /mnt/floppy para o servidor e entao ele ficaria dispon�vel para uso para o proprio terminal (via servidor). O problema � que eu queria deixar isso transparente para os usu�rios, que sao leigos e acostumados com o Windows. Cada vez que for necess�rio trocar esse disquete � preciso: 1) desmontar o diretorio exportado por NFS no servidor 2) desmontar o dispositivo floppy no terminal "Trocar disquete" 3) remonntar o dispositivo floppy no terminal 4) remontar o diretorio exportado por NFS no servidor Algu�m passou por um problema assim? Algu�m tem uma sugest�o para que o passo 1 execute automaticamente o passo 2 assim como o 3 dispare o 4? Tem como fazer isso com os �cones de dispositivos do KDE?
Abra�os!
Joelcio Kuroski -- GUS-BR - Grupo de Usuarios Slackware - BR http://www.slackwarebrasil.org/ http://www.linuxmag.com.br/mailman/listinfo/slack-users
-- GUS-BR - Grupo de Usuarios Slackware - BR http://www.slackwarebrasil.org/ http://www.linuxmag.com.br/mailman/listinfo/slack-users
