View Attach Info

XDMCP Terminal-Server#

Manchmal ist es sinnvoll, einen anderen Rechner fernsteuern zu können. Am komfortabelsten geht dies, wenn man die gesamte Oberfläche (z.B. KDE) auf einen anderen Rechner umgeleitet werden könnte. Dies geht unter Linux am besten mit dem XDMCP-Protokoll.

Wer ist hier der Server?#

Zur Terminologie: Der X-Server ist der Rechner, auf dem die Oberfläche dargestellt wird, also der Rechner, vor dem der Benutzer sitzt. Die Programme, die auf einem entfernten Rechner (den der normale Benutzer als Server bezeichnen würde), können über diesen X-Server aus Ihrer Sicht dem "entfernten" Benutzer Bildschirmausgaben senden.

Wie funktioniert's?#

In einem normalen KDE-System wird der X-Server vom KDE-Programm "KDM" verwaltet und gestartet. KDM ist der eigentliche Login-Manager. In einem normalen Linux-System geht dieser Login-Manager hin und startet einen X-Server (also eine Bildschirmoberfläche). Nachdem er auf diese Weise ein Terminal "gefunden" hat, sendet er dort ein Fenster hin, damit man sich einloggen kann.

So weit so gut. Nun kann man dies jedoch auch anders einrichten. KDM kann auch gar keinen oder mehrere X-Server (Alt-Shift-F7 und Alt-Shift-F8) öffnen. Darüberhinaus können aber auch andere X-Server über das Netzwerk sich beim KDM melden und bekommen dann ebenfalls ein Login-Fenster.

Um das so einzurichten, muss man zuerst mal den KDM (der auf dem eigentlichen Server läuft) so einrichten, daß er Verbindungen übers Netzwerk annimmt. Danach muss man einen X-Server starten, der übers Netzwerk eine Verbindung sucht.

Konfiguration#

KDM (auf dem Terminal-Server)#

Die Verbindung per XDMCP grundsätzlich erlauben geht in der Datei /etc/kde3/kdm/kdmrc. Hier wird folgendes eingetragen: 

  [Xdmcp]
  Enable=true

Dann muss angegeben werden, welche Rechner speziell sich einloggen dürfen. Im Beispiel gebe ich einfach mal alles frei. Dies geht in der Datei /etc/kde3/kdm/Xaccess durch eine Zeile, die einfach ein Sternchen enthält.

Um die Änderungen nun zu aktivieren, sollte man nun den KDM neu starten: 

  /etc/init.d/kdm restart

X (auf dem Arbeitsplatz)#

Man startet den X-Server per Konsole mit folgendem Befehl: 

  X -query terminalservername

Ggf. sollte man vorher mit /etc/init.d/kdm stop seine eigene graphische Oberfläche beenden. Wer bereits einen X-Server offen hat und einen zweiten auf Shift-Alt-F8 öffnen will, kann z.B. auch folgendes machen: 

  X :1 -query terminalservername

Statt dem Namen kann man natürlich auch die IP-Adresse angeben. Damit kann man insbesondere ausschliessen, das Probleme nur mit der Namensauflösung zusammenhängen (ein immer wieder gern gemachter Fehler bei allen möglichen Netzwerkdiensten).

graphisch auswählen, das man auf einen fremden Rechner will

Man kann auch das lokale kdm (auf dem Arbeitsplatz) ao konfigurieren, daß man beim Starten des Rechners aussuchen kann, ob man auf dem eigenen oder dem entfernten Rechner arbeiten will. Näheres zu den kdm-Optionen gibts übrigens auf http://docs.kde.org/stable/en/kdebase/kdm/kdm-files.html. Man schreibt folgende Zeilen in die Datei /etc/kde3/kdm/kdmrc in die Sektion [X-*-Greeter]: 

  LoginMode=DefaultLocal
  ChooserHosts=terminalserver.localdomain

(Man kann letztere Zeile wohl auch weglassen, wenn der Terminalserver per Broadcast zu erreichen ist.)

Chooser konfigurieren#

Falls man mehrere Terminal-Server im Netz hat, kann man nun noch weiter gehen. Es gibt sog. indirekte Querys, bei denen der XDMCP-Server gar nicht selber das Login bereitstellt, sondern die Anfrage nur "durchreicht" an den eigentlichen KDM-Server. Interessant wird dies vor allem unter Einsatz des Choosers. Dann öffnet sich als allererstes ein Chooser-Fenster, in dem man alle bekannten XDMCP-Server aufgelistet bekommt. Man kann sich dann einen aussuchen, indem man ihn anklickt. Daraufhin erscheint dann als nächstes das Login-Fenster des entsprechenden Rechners. Hierzu sind zwei kleine Änderungen nötig:

Auf dem Server, der die erste Anfrage bekommt, muss der chooser aktiviert werden. Dazu schreibt man in die Xaccess-Datei eine Zeile wie diese: 

  * CHOOSER BROADCAST

Wenn man (nur) spezielle Terminalserver ansprechen will oder diese durch einen Broadcast nicht erreichbar sind, kann man auch Ihre Namen angeben: 

  * CHOOSER susi heidi franzi

Dann ersetzt man beim Start des X-Servers "-query" durch "-indirect". Schon kanns losgehen. -- ThomasBayen

Chooser per Display Manager#

In einer Umgebung, wo es mehrere Rechner gibt, auf denen man arbeiten kann, wäre es eigentlich schön, wenn mein normaler Rechner, an dem ich sonst immer arbeite und mich einlogge, mir beim Anmelden die Wahl gibt, dieses auch auf einem anderen Rechner des Netzwerks zu tun. Um das zu erreichen, braucht man eine Möglichkeit, im Rahmen der normalen Anmeldung einen Chooser aufzurufen. Obwohl mir persönlich dieses Ansinnen sehr offensichtlich erscheint, ist das gar nicht so einfach.

Grundsätzlich gibt es zwei Möglichkeiten, das zu erreichen: Möglichkeit eins bedeutet, das man einen Display Manager (das ist das Programm, welches das Login ermöglicht) benutzt, der einem die Wahl lässt, einen Chooser aufzurufen. Wäre ja eigentlich einfach... Leider kann das nur der gdm (aber nicht gdm3), der in der aktuellen Debian-Distribution bekanntlich nicht mehr enthalten ist und der kdm. Im kdm kann man unten im Menü "Remote Login" (Alt-R) aufrufen und erhält einen wunderschönen Chooser, in dem sofort alle Rechner aufgeführt sind, die einen XDMCP-Broadcast unterstützen. :-)

Die Möglichkeit 2 ist, das man den lokalen X-Server so startet (mit "-indicrect localhost"), das er auf den lokalen Displaymanager per XDMCP zugreift. Dieser muss dann so eingestellt sein, das er für indirekte Anrufe einen Chooser anzeigt. Das habe ich jetzt nicht probiert, laut Doku sollten das aber so gut wie alle Display Manager beherrschen.

Der Nachteil an Methode 1 ist, das man sich - wenn man wie ich KDE4 hasst und deshalb einen anderen Desktop bevorzugt (Xfce4 in meinem Fall), ca. 250MB KDE-Bibliotheken ins Haus holt. Der Nachteil an Methode 2 ist, das man dafür seine Startskripte anpassen muss und ich vermute, das man nicht mehr auf das Session-Management des DM zugreifen kann (siehe z.B. KdeSessions). Sprich: Man kann nicht so einfach einen weiteren Server auf einem anderen virtuellen Terminal starten. Diese Funktion ist auch bekannt als "Als anderer Benutzer anmelden".

Dummerweise ist gerade diese zuletzt angesprochene Möglichkeit, auf mehreren virtuellen Terminals mehrere verschiedene X-Server laufen zu haben in einer Umgebung, in der ich mich an unterschiedlichen Rechnern anmelden kann und will extrem hilfreich und wichtig.

Also bleibt als Erkenntnis, das man entweder den kdm nimmt (und dabei hofft, das andere DM irgendwann wieder das können, was schon vor Jahren jeder konnte), oder das man entsprechende Startskripte entwickelt, die das Session Management auch ohne kdm erlauben. Wäre vielleicht mal ein interessantes Projekt für die LUG?!?

Und außerdem bleibt als Erkenntnis, das die ganze Schei** mit KDE4 und Gnome3 die Entwicklung von Linux um mindestens 5 Jahre komplett zurückgeworfen hat und ich gerne wissen möchte, wie Microsoft das geschafft hat. :-(

Nachtrag: Irgendwie scheint der lightdm (der Name verspricht ja schonmal einiges...), der neuerdings auch von Ubuntu benutzt wird, das seit Ubuntu 12.10 zu unterstützen. Bei mir geht's nicht. :-( Ich habe mein Problem mal beschrieben und wir hoffen, das die Neuerungen irgendwann auch mal in die Standard-Pakete rüberwachsen.

Man kann wie unter KdeSessions beschrieben auch einen zweiten X-Server auf demselben Rechner starten, der dann vom gleichen KDM mit einem Login-Fenster versorgt wird.

Wenn einem eine solche einfache X-Verbindung nicht ausreicht, kann man mit dem NX-Server und FreeNX einerseits X-Verbindungen auch über enge Leitungen mit hoher Latenz rasant beschleunigen und andererseits auch wahlweise VNC- und Windows-Terminalserver-Verbindungen einbinden. Näheres dazu in einem Pro-Linux-Artikel. Debian-Pakete werden z.Zt. unter http://www.kalyxo.org/twiki/bin/view/Main/NoMachineNX zusammengestellt.

Unter http://www.bodenstab.org/xdm.html gibt es ein schönes HOWTO, das z.B. auch weitere Eingriffsmöglichkeiten durch Skripte beim Login-Prozess u.a. genau erklärt.

Probleme#

Lieber Thomas, das kann's nicht alleine sein. Ich habe all dies ( unter KDE3.1 ) zu Hause gemacht. Ich erhalte mit "X -query terminalserveradresse" vom anderen Rechner aus zwar ein X-Windows aber keine Möglichkeit mich anzumelden. Nur das Kreuz lacht mich an. -- KaiEhlers

Seltsam. Das bedeutet, es funktioniert gar nichts. :-( Du "erhältst" ja keinen X-Server, sondern startest ihn selber (mit "X ...". Dieser sollte dann nach einem sogenannten "query" ein Login-Fenster "erhalten". Wenn das nicht kommt, hakts irgendwo. Mit der KDE-Version hat das übrigens nix zu tun, da diese Funktionalität vom X-Server her kommt. Statt KDM (Login im KDE-Look) kannst Du also auch genausogut XDM (X-Windows / Motif-Look) oder GDM (Gnome-Look) nehmen. Die Konfiguration sollte bis auf Pfad und Namen der Konfigurationsdateien identisch sein.
Was ich nicht erwähnt hatte ist, daß man nach dem Ändern der Konfiguration auf dem "Server" (also da, wo KDM läuft und später die Programme laufen sollen) KDM neu starten sollte (bzw. überhaupt erstmal starten sollte, wenn man wie Kai normalerweise kein graphisches Login hat). Wenn das alles nicht hilft, würde ich mal in die Logdatei des X-Servers auf dem Client und in die KDM-Logdatei (wenns die gibt) auf dem Server schauen, ob sich irgendwo was tut. -- ThomasBayen

Seit dem ich mit ssh und XServer ( siehe SshMitXserver ) herumgefummelt habe, funktionierts. Das einzige, was ich aber für ssh verändert habe : Ich habe in der Datei /etc/ssh/sshd_config den Eintrag " forwardX " auf " yes " gesetzt. Daran kann's nicht liegen. -- KaiEhlers

Und wie geht's bei Suse 9.1?#

Im Prinzip genauso! Aber bei Suse ist ja immer irgendwas anders. /etc/kde3/kdm gibt es nicht. Hier wird mit xdm gearbeitet und es ist alles schon vorbereitet. XDMCP ist aktiviert - wo, dass weiss ich nicht. In der 

/etc/x11/xdm/Xaccess
sind mit * schon aller Rechner erlaubt. Hier kann man ggf. Einschränkungen machen. Suse hat aber den Port deaktiviert. Dieser muss in /etc/services aktiviert werden. 
 Zeilen vom Port 177 :
 xdmcp          177/tcp
 xdmcp          177/udp

Bei Suse wird nun 

 /etc/init.d/xdm restart
ausgeführt. Weiter wie oben beschrieben. Bei Suse am besten mit ALT+STRG+F2 ein TTY-Konsole öffnen und 
 X :1 -query terminalservername
aufrufen.

So nun noch für blinde Anfänger wie mich: das X wird groß geschrieben!

Der letzte Stolperstein liegt im Namen des Terminalservers. Wer hier Suse 9.1 Standard-Installation hat, bei dem heißen alle Rechner "linux". Der Rechnername bei der Samba-Installation hat hier keine Bedeutung! Also entweder die IP-Adresse angeben oder die Rechnernamen eindeutig machen. Siehe auch oben. -- Rolf Hagenguth

Xserver für Windows#

siehe unsere Seiten CygWin und XMing.

Xserver in Java#

weirdX ist ein Xserver in Java, auch als Java-Applet

Tags:  X11, ThinClient

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-10) was last changed on 05-Jan-2013 14:32 by Thomas Bayen