!!! 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 __Chooser__s.
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|http://permalink.gmane.org/gmane.comp.freedesktop.lightdm/71] und wir hoffen, das die Neuerungen irgendwann auch mal in die Standard-Pakete rüberwachsen.

----
!!! Tips und Links

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 [http://www.nomachine.com 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 [http://www.pl-berichte.de/berichte/lt2004-nxartikel.html
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|http://www.jcraft.com/weirdx/] ist ein Xserver in Java, auch als Java-Applet

!!Links

*[Mini-HowTo|http://www.pro-linux.de/t_netzwerk/xdmcp.html] auf Pro-Linux

[{Tag X11 ThinClient}]