Grafische Linux-Anwendungen via Netzwerk

 Zielgruppe: Fortgeschrittene 

Wenn man eine Linux-Anwendung auf einem anderen Rechner starten will, aber die grafische Oberfläche an seinem Arbeitsplatz angezeigt haben möchte, ist das kein Problem. Das X11 Window System von Linux unterstützt die Anzeige von Fenstern auf fremden Rechnern. Dabei bietet der X-Server einen grafischen Anzeige-Dienst an, der von einem X-Client, also einer beliebigen grafischen Anwendung unter Linux genutzt werden kann. Auf diese Weise kann man zum Beispiel rechenintensive Programme auf Applikationsservern starten und so seinen Arbeitsplatzrechner entlasten (und das Netzwerk belasten).

Wir gehen einfach mal von der folgenden Situation aus: Auf dem Rechner A ist genug Rechenpower, die man nutzen möchte, um zum Beispiel mit Grip OggVorbis Dateien zu erstellen. Auf dem Rechner B muss man wichtigere Dinge tun (z.B. arbeiten) und kann deshalb nicht die Rechenpower verschwenden. Doch bevor man den Rechner A in der Ecke vergammeln lässt, nutzt man ihn lieber sinnvoll. Hier werden zwei Varianten vorgestellt, mit denen man letztlich das gleiche Ziel erreicht. Einmal ohne und einmal mit Verschlüsselung. Letzteres ist zu empfehlen, mag aber vielleicht wegen der ssh Konfiguration den ein oder anderen abschrecken. Zur Konfiguration der ssh gibt es aber auch brauchbare Artikel im Internet. Beide Lösungen haben ihre Vor- und Nachteile. Ich empfehle, erstmal alles zu lesen! Hier gehe ich aber davon aus, dass ein entferntes Anmelden auf Rechner A bereits möglich ist.

Konfiguration auf dem X-Server (unverschlüsselt)

Auf dem Rechner B läuft ein X-Server. Man arbeitet dort mit KDE oder irgend einer anderen Oberfläche. Der gestartete X-Server muss auch am Netzwerk lauschen. Man kann dies als root mit nmap prüfen:

nmap localhost

sollte die folgende Zeile ausspucken:

6000/tcp open X11

Falls nicht, muss man unter Debian sarge die Datei /etc/X11/xinit/xserverrc so ändern, dass der X-Server am Netzwerk lauscht. Normalerweise wird dies nämlich aus Sicherheitsgründen durch die Option "-nolisten tcp" unterbunden. Nimmt man diese weg, so dass nur noch

#!/bin/sh
exec /usr/bin/X11/X -dpi 100

in der Datei steht, dann sollte es gehen. Man muss nur noch den X-Server neu starten. Wie das geht, hängt von dem verwendeten Display-Manager ab:

/etc/init.d/xdm restart

oder

/etc/init.d/kdm restart

oder

/etc/init.d/gdm restart

oder ... als root sollte reichen. Bitte vorher auslogen und alle Daten speichern. Danach sollte aber der offene Port mit nmap sichtbar sein. Damit die grafischen Daten von Rechner A überhaupt verarbeitet werden, muss man dies ausdrücklich erlauben, idem man die IP-Adresse von A (hier 192.168.3.1) einer "Erlaubt"-Liste für hinzufügt:

xhost +192.168.3.1

Dies geht nur als root und muss wiederholt werden, wenn man den Rechner neu gestartet hat. Eine Möglichkeit, dies dauerhaft zu konfigurieren, gibt es bestimmt auch, habe ich aber nie gebraucht (Wer sie mir nennen mag, wird in diesem Artikel verewigt :-) ).

Konfiguration auf dem X-Client (unverschlüsselt)

Man logt sich aus der Ferne von B aus auf A ein. Dies kann per ssh oder sonstewie geschehen. Wichtig ist auf diesem Rechner, dass keine grafische Oberfläche vorhanden sein muss, sondern nur die zu nutzenden grafischen Programme benötigt werden. Die Konfiguration von der grafischen Oberfläche kann man sich also sparen. Statt dessen teilt man dem System durch den Befehl

export DISPLAY=192.168.3.2:0.0

mit, dass der Rechner B als Anzeige genommen werden soll. Danach kann man das entsprechende grafische Programm starten, wie zum Beispiel

grip

Dass grip nun auf dem Rechner A läuft merkt man spätestens dann, wenn man auf den eject-Button drückt. Es öffnet sich das CD-Rom Laufwerk am Rechner A und nicht am Rechner B.

Mit ssh geht alles verschlüsselt

Wenn man seinen Mitbenutzern des Netzwerkes nicht 100%-ig vertraut, empfiehlt sich für den regelmäßigen Gebrauch eine sicherere Konfiguration. Denn jede einzelne Tastatureingabe und somit auch alle Passwörter können ohne Verschlüsselung problemlos von Dritten mitgelesen werden. Anstatt den X-Server direkt am Netz lauschen zu lassen, kann man darauf verzichten und den Datenverkehr durch einen ssh Tunnel tunneln - also versschlüsseln.

Um dies zu tun, benötigt man auf dem Rechner A das Programm xauth, welches bei Debian im Paket xbase-clients ist. Dieses Paket muss also installiert sein:

apt-get install xbase-clients

Der ssh Server auf dem Rechner A muss das X-Forwarding unterstützen. Deshalb muss man in der Datei /etc/ssh/sshd_config die Option X11Forwarding auf yes setzen

X11Forwarding yes
X11DisplayOffset 10

Die Option X11DisplayOffset gibt an, welche Displaynummern lokal sind und welche nicht. Das werden wir gleich sehen. Jedenfalls muss man nach dieser Änderung an der Konfiguration den ssh Dienst neu starten (z.B. mit /etc/init.d/ssh restart).

Logt man sich nun von Rechner B per ssh auf dem Rechner A ein, dann verwendet man die Option -X, um das X11 Forwarding zu nutzen:

ssh -X 192.168.3.1

Bei Problemen und zum Testen lohnt sich noch die zusätzliche Option -v, mit der man mehr über die Aktionen der ssh Shell erfährt. Ist man auf Rechner A eingelogt, setzt man die DISPLAY Variable auf

export DISPLAY=localhost:10.0

und zeigt damit an, dass keine lokale (kleiner 10), sondern eine entfernte Ausgabe wünscht. Bei mir ist diese Variable aber immer schon gesetzt, wenn ich mich mit diesem ssh Kommando so anmelde. Der export Befehl kann also ggf. entfallen. Nun kann man

grip

starten, und hat seinen Spaß mit einer verschlüsselten Verbindung. Wer dies auch noch überprüfen möchte, kann gern nebenbei als root in einem xterm Programme wie tethereal oder iptraf zur Kontrolle laufen lassen. Sehr schön an dieser Lösung ist, dass man sich die Konfiguration mit xhost sparen kann und der geplagte Admin kein neues Loch in irgendeine Firewall bohren muss.