Re: Zugriff auf DiskettenLWe von X-Terminals
Hallo,
José Luis Tinoco
Hi Dieter! [...]
Ich gehe davon aus, dass die Clients in einer changeroot Umgebung innerhalb /tftpboot booten und ihre Homeverzeichnisse unter /tftpboot/client/home liegen.
Ganz genau, wie es sich gehört.
Wozu dann Sicherheitsupdates ueber das Terminal auf Diskette, ich sehe da keinen Sinn.
Hmm, das meinte ich eigentlich nicht... ich meinte, ich möchte nicht, dass sich Benutzer überhaupt an den Diskless Clients lokal anmelden können (an der Konsole, die man mit z.B. Strg+Alt+F5 bekommt), und dann habe ich da ein paar Gründe angegeben, das ist aber nicht so relevant.
Da die Clients sich ja nur in ihrer changeroot Umgebung bewegen koennen und alle Prozesse von einem Server zu dem gemounteten Verzeichnis exportiert werden, besteht doch keine Moeglichkeit, das ein Client dem anderen in die Karten sehen kann.
Ok, also zu meiner Absicht: man kann sich an den X-Terminals (=diskless clients) lokal einloggen (also, ohne X-Sitzung, ohne dass der Server was davon weiss), dann kann man ganz normal das Diskettenlaufwerk benutzen, wie an der Textkonsole einer Linux-Workstation auch. So weit, so gut. Meine Benutzer aber loggen sich grafisch direkt in den Server ein mittels xdm, haben also nur indirekt was mit dem lokalen Rechner zu tun, und sind zu keinem Zeitpunkt lokal eingeloggt, sonder nur am Server. Nun arbeiten sie z.B. mit dem KDE-Desktop und haben da ein Floppy-Icon. Meine Absicht ist es, dass wenn sie auf diesem Floppy-Icon mit rechter Maustaste klicken und dann mit linker Maustaste "mount" wählen, dann nicht versucht wird, das Diskettenlaufwerk des Servers zu mounten (was mit einer Fehlermeldung abbricht, da meine Benutzer da nichts zu suchen haben, der Server ist in einem anderen Raum versteckt, sein Diskettenlaufwerk dürfen sie nicht mounten), sondern das Diskettenlaufwerk des X-Terminals zu mounten, an dem der Benutzer sitzt.
Jetzt verstehe ich langsam. Die clients haben aber doch die Dateien /tftpboot/client/etc/fstab /tftpboot/client/home/user In ./client/etc/fstab kannst du doch die client Adresse mit /dev/fd0 und Mountpoint relativ zum Wurzelverzeichnis, also z.B. /tftpboot/floppy setzen In ./client/home/user/.kde wird es doch sicher eine .rc Datei geben, in der der Pfad fuer das Floppy-Icon gesetzt werden kann.
So weit zu meiner Absicht. Es muss also ein Mechanismus geschaffen werden, mit dem ich als Benutzer, der am X-Terminal arbeite und dessen X-Sitzung am Server läuft, beim Anklicken des o.g. Icons meines KDE-Desktops, (a) das Mounten des Diskettenlaufwerkes des X-Terminals hervorrufe, an dem ich sitze.
Das habe ich versucht oben zu beschreiben. Anschliessend muss (b) das (am X-Terminal) gemountete Gerät
irgendwie auch am Server gemountet werden, da ich als Benutzer ja nur am Server eingeloggt bin und nur sein Dateisystem sehe. Mit dem Dateisystem des X-Terminals und mit allem, was in ihm passiert, habe ich nur indirekt was zu tun.
Das Floppy-Device wird ja dann ueber den Mointpoint auf dem Server gesehen. Aber wieso hat das X-Terminal denn ueberhaupt ein Dateisystem? Ich denke das sind Diskless Clients ? Der Client hat doch nur ein Mainboard mit BIOS, einen Prozessor, wenig RAM , eine Netzwerk Karte und vielleicht einen SVGA-Chip auf dem Mainboard.
Um (a) zu erreichen, lasse ich die Benutzer sich s.z.s. "als root" mittels SSH vom Server aus in die X-Terminals einloggen, und das jeweilige Diskettelaufwerk des X-Terminals mounten. Um (b) zu erreichen, exportiere (vom jeweiligen X-Terminal aus gesehen) ich mittels NFS das Diskettenlaufwerk zum Server, so dass ich dieses dann am Server unter einem Mounpoint wie "/floppy/terminal13" mounten kann. Die Inhalte dieses Mountpoints werden dann vom KDE-Desktop angezeigt.
OK, so wie ich das oben beschrieben habe, aber warum als root einloggen und wozu ssh ? Das klingt fuer mich wie "von hinten, durch die Brust ins linke Auge schiessen" :-)
Wie ich das im einzelnen gemacht habe, steht auf meiner letzten Nachricht zu diesem Thema.
Es tut mir leid, wenn ich o.g. Nachricht an die Liste zu wirr geschrieben habe, ich habe mir Mühe gemacht, anscheinend ohne viel Erfolg. Vielleicht kann man sie jetzt besser verstehen? [...]
Ja ich kann dich jetzt besser verstehen, aber siehst du auch die Moeglichkeit, es simpler und effizienter zu konfigurieren ? Gruss Dieter -- Dieter Kluenter mailto: dkluenter@gmx.de http: http://www.l4b.de --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hallo Dieter! Erstmal vielen Dank nochmal für Deine Mühe :-)) Also: Dieter Kluenter wrote:
Jetzt verstehe ich langsam. Die clients haben aber doch die Dateien /tftpboot/client/etc/fstab
Das ist richtig.
/tftpboot/client/home/user
Das aber nicht. Es gibt gar kein /tftpboot/client/home -Verzeichnis, es gibt nur /home bei uns. Nur da sind Benutzerdaten zu finden. Wenn ein Benutzer in den Rechnerraum kommt, und sich einloggt, läuft seine X-Sitzung nicht an der Maschine, an der er sich einloggt, sondern am Server. Das ganze Dateisystem, das der Benutzer während seiner Arbeit sieht, ist das des Servers. Er greift dann ganz normal auf seine Sachen in /home/benutzer zu.
In ./client/etc/fstab kannst du doch die client Adresse mit /dev/fd0 und Mountpoint relativ zum Wurzelverzeichnis, also z.B. /tftpboot/floppy setzen
Ja, das ist schon ungefähr so eingetragen. Wenn ich mich vor einen unserer Terminals hinsezte und z.B. Strg+Alt+F5 drücke, und mich dann so lokal am X-Terminal (also ohne, dass der Server etwas davon mitbekommt) einlogge, kann ich ganz normal mit "mount /floppy" das Diskettenlaufwerk des X-Terminals mounten. Ich hoffe, das meintest Du.
Das Floppy-Device wird ja dann ueber den Mointpoint auf dem Server gesehen.
Ganz genau.
Aber wieso hat das X-Terminal denn ueberhaupt ein Dateisystem? Ich denke das sind Diskless Clients ? Der Client hat doch nur ein Mainboard mit BIOS, einen Prozessor, wenig RAM , eine Netzwerk Karte und vielleicht einen SVGA-Chip auf dem Mainboard.
Ok, Žtschuldigung, ich hab da ein paar Begriffe durcheinander gebracht, glaube ich. Ja, die Terminals haben bei uns keine Platte, mit "Dateisystem des Terminals" meinte ich, das was unter /tftpboot/client zu finden ist, also das, was der Terminal "sieht".
OK, so wie ich das oben beschrieben habe, aber warum als root einloggen und wozu ssh ? Das klingt fuer mich wie "von hinten, durch die Brust ins linke Auge schiessen" :-)
Ja, das kommt mir auch _ziemlich_ unnötig kompliziert vor, nur fällt mir leider nichts Besseres ein. Als root einloggen... Eigentlich startet der Benutzer nur ein Skript mit su1, das mit root-Rechten dem X-Terminal sagt, er solle bitte sein Diskettenlaufwerk mounten (dafür loggt sich root für eine halbe Sekunde in den passenden Terminal ein und führt da "mount /floppy" aus). Wie kann man es besser machen? Der Benutzer sitzt an seinem Terminal, das Floppy-Icon, das er auf seinem KDE-Desktop sieht, ist in /home/benutzer/Desktop/Floppy.kdelnk konfiguriert. Da habe ich meine Änderungen eingetragen, aber das ist ja nur dem Server bekannt. Der Benutzer kann nur auf dem Server Befehle ausführen lassen (da er sich an den Terminals _lokal_ nicht einloggen kann, er kann sich nur grafisch über diesen X-Terminal am Server einloggen), also muss ich es irgendwie schaffen, dass er durch Ausführen eines Programms/Skriptes auf dem Server, seinem X-Terminal (ein anderer Rechner, der ihn als Benutzer gar nicht kennt) sagt "Kannst Du bitte Dein Diskettenlaufwerk unter Deinem /floppy -Mountpoint mounten? Danke!". Das wäre der erste Teil. Zum zweiten Teil des Prozesses (der Terminal exportiert sein Floppy an den Server), weisst Du schon was ich meine, so wie Du es in Deiner letzten Nachricht geschrieben hast.
Ja ich kann dich jetzt besser verstehen, aber siehst du auch die Moeglichkeit, es simpler und effizienter zu konfigurieren ?
Mir fällt da nicht nur nichts Besseres ein, mit fällt da einfach sonst gar nichts ein :-(( Kannst Du Dir vorstellen, dass es im Prinzip anders geht? Vielen Dank noch mal! :-))) JLT --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
participants (2)
-
dkluenter@gmx.de
-
tinoco@student.physik.uni-dortmund.de