freeX: Grafische Ausgaben umleiten

Grafische Ausgaben umleiten

Da der Trend ganz klar zum Drittrechner und zu leistungsstarken Servern geht, wird es immer wichtiger, daß die grafischen Ausgaben umgeleitet werden können. Dabei müssen es nicht immer VNC und vollständige Desktops sein, die übertragen werden. Das System X11 besticht durch seine Netzwerkunterstützung. In diesem Artikel zeigen wir, wie man die Ausgabe eines Programms auf einen anderen Bildschirm umleitet.

1. Ausgabe umlenken 2. Umleitung mit »xhost« 3. Umleitung mit »auth« 4. Umleitung mit »ssh«

Die grafischen Ausgaben eines Programms lassen sich mit Hilfe von X11 komplett auf einen anderen Rechner übertragen. Von Text-Anwendungen ist dieses vielleicht schon bekannt: Über »telnet«, »rlogin« oder »ssh« logt man sich auf einem anderen Rechner ein, startet dort »vi« oder »mutt« und sieht die Ausgaben auf der lokalen Workstation.

Dieses Verhalten läßt sich auch für grafisch-orientierte Programme wie z.B. GIMP oder »gv« übernehmen. Um die Ausgabe von grafischen Anwendungen umzuleiten, die gegen die normale Xlib gelinkt sind, stehen drei Möglichkeiten zur Verfügung mit folgenden Merkmalen:

• »xhost«
• »xauth«
• »ssh« und »xauth«

Generell gilt, daß von den Applikationen die Umgebungsvariable »DISPLAY« abgefragt wird. In dieser müssen die Informationen enthalten sein, wo die grafische Ausgabe erfolgen soll. Sie wird in allen drei Fällen mit folgendem Inhalt gesetzt:

   Rechnername:Display-Nummer.Screen-Nummer

Rechnername

Mit »Rechnername« wird der Name des Rechners im Netzwerk bezeichnet, an dem der Monitor physikalisch angeschlossen ist, auf dem die Ausgabe daher erfolgen soll. Hier darf sowohl ein vollständiger Name samt Domain (auch FQDN genannt), ein einfacher Rechnername, wenn die Domain klar ist bzw. in »/etc/resolv.conf« angegeben wurde, als auch eine IP-Nummer angegeben werden.

Display-Nummer

Als »Display« wird normalerweise eine Menge von Monitoren bezeichnet, die über eine gemeinsame Tastatur und Maus angesprochen werden. Die meisten Workstation haben jedoch nur einen einzigen Monitor angeschlossen, so daß hier meistens ausschließlich der Wert »0« verwendet wird. Es wäre jedoch von der Architektur von X11 her problemlos möglich, an einem Rechner mehrere unterschiedliche Monitore, Tastaturen und Mäuse anzusteuern, auch wenn auf einem herkömmlichen PC die Hardware dieses meistens nicht hergibt.

Screen-Nummer

Einige Displays teilen sich eine einzige Tastatur und Maus bei mehreren physikalischen Monitoren. Jeder dieser »Screens« erhält eine eindeutige Nummer, auch hier wird bei 0 angefangen zu zählen. Normalerweise wird hier also auch der Wert »0« verwendet. Bei XFree86 4.x mit Xinerama, mehreren Grafikkarten und Monitoren, könnte auf diese Weise mit »1« der zweite, mit »2« der dritte physikalische Monitor adressiert werden.

Ausgabe umlenken

Um die Ausgabe auf ein normales X11-System umzuleiten, an dem nur eine Tastatur, nur eine Grafikkarte und nur ein Monitor angeschlossen ist, wird die Variable nach der obigen Vorschrift wie folgt gesetzt:

   DISPLAY=rechnername:0.0
   export DISPLAY

Alternativ zu dieser Umgebungsvariablen wird von vielen X-Programmen der Parameter »-display dpy« (oder teilweise »--display dpy«, z.B. bei GIMP) unterstützt, der als Argument die den gleichen Wert erhält, hier also »-display rechnername:0.0«.

Dieses muß auf dem Rechner durchgeführt werden, auf dem das Programm gestartet wird, nicht auf dem es ausgegeben werden soll. Zusätzlich dazu muß das System, auf dem die Ausgabe erscheinen soll, so eingestellt werden, daß einem externes Programm seine Ausgaben dorthin schicken darf.

Diese Möglichkeit, die grafische Ausgabe von Programmen umzuleiten, ist recht alt. Früher wurde sie vor allem dafür benutzt, rechenintensive Programme auf dem leistungsfähigsten Server zu starten und die Ausgabe auf die eigene Workstation umzuleiten. Eine Sun-IPX ist nicht unbedingt für die Lösung umfangreicher Differentialgleichungen geeignet. Stehen jedoch Maple oder Mathematica auf einem schnellen Parallelrechner zur Verfügung, wird das Programm dort gestartet, die Ausgabe jedoch auf den eigenen Arbeitsplatz umgeleitet.

Umleitung mit »xhost«

Diese Möglichkeit ist die einfachste und älteste. Sie bringt allerdings den Nachteil mit sich, daß bei unvorsichtiger Verwendung jeder Benutzer auf das laufende X11 zugreifen kann, wenn er auf dem entfernten Rechner eingeloggt ist. Damit kann er nicht nur selbst Programme starten, die auf dem X11-Bildschirm erscheinen, sondern z.B auch die Tastatur verstellen. Daher sollte mit dieser Methode extrem vorsichtig umgegangen werden. Sie wird nur deshalb angegeben, weil dieses auf alten Unix-Rechnern die einzige Möglichkeit ist, die Ausgabe umzuleiten

Mit Hilfe des Programms »xhost« wird auf dem Rechner, auf dem die grafische Oberfläche läuft, das Display für andere Rechner freigegeben. Die Syntax ist recht einfach:

Mit Host wird in diesem Fall der Rechner (oder dessen IP-Nummer) bezeichnet, auf dem das Programm gestartet wird, dessen Ausgabe umgeleitet werden soll. Als besondere Form darf der Name des Rechners entfallen. In dem Fall darf jeder andere Rechner im Netzwerk auf das Display zugreifen, dort Fenster öffnen, die Konfiguration abfragen oder ändern.

Wenn die Erlaubnis, auf das Display zuzugreifen, mit »xhost« erteilt wird, sollte sie direkt nach dem Start der Anwendung wieder entzogen werden, damit kein anderer Benutzer des entfernten Rechners auf das Display zugreifen kann. Die bereits gestartete Anwendung wird dadurch nicht beeinflußt, da dessen Verbindungskanal bereits geöffnet ist und der Zugang bereits gewährt wurde.

Umleitung mit »auth«

Bei dieser Möglichkeit wird mit MIT-MAGIC-COOKIES gearbeitet. Diese Cookies werden zwischen dem Server und dem Client ausgetauscht und vom X-Server wie eine Eintrittskarte in die wunderbare Welt der Workstation behandelt. Auf den X-Server dürfen dann nur die Applikationen zugreifen, die das passende Magic-Cookie verwenden.

Um dieses zu erreichen, wird eine Datei mit Zugriffsrechten und Cookies verwaltet, die sowohl auf dem Client (dem entfernten Rechner) als auch dem Server gepflegt werden muß. Dieses geschieht durch das Programm »xauth«, dessen Bedienung im folgenden kurz erläutert wird. Dieses Programm extrahiert Informationen aus der Autorisierungsdatei und fügt welche hinzu.

Normalerweise wird die Datei ».Xauthority« verwendet. In einer Umgebung mit einem gemeinsam genutzten Home-Verzeichnis und mehreren X-Servern kann dieses zu Problemen führen, da die Cookies für jeden lokalen X-Server neu erzeugt werden. Das würde bedeuten, daß mit dem Start eines neuen X-Servers die Authentifizierung für den ersten gelöscht würde. Damit könnten auf den ersten X-Server keine Ausgaben mehr erfolgen. Dieses Problem wird durch die Umgebungsvariable »XAUTHORITY« umgangen, die den zu verwendenden Dateinamen enthält. So könnte man z.B. immer die Datei ».Xauthority.rechnername« verwenden, indem an entsprechender Stelle diese Variable gesetzt wird. Den Rechnernamen erhält man durch Verwendung von »`hostname`«, also z.B. durch folgendes Fragment:

   XAUTHORITY=~/.Xauthority.`hostname`
   export XAUTHORITY

Um mit diesem Mechanismus zu arbeiten, muß beim Start von X11 dem X-Server mitgeteilt werden, daß die Authentifizierung über »xauth« geschehen soll. Je nach verwendeter Distribution passiert dieses bereits automatisch beim Aufruf von »startx« sowie beim grafischen Login über »xdm«, »gdm« oder »kdm«.

Wenn die Distribution dieses nicht übernimmt, läßt sich das leicht erreichen. Ob Sie dieses benötigen, lesen Sie an der Authentifizierungsdatei ab. Wenn sie existiert und einen aktuellen Zeitstempel trägt, dann ist Ihr System entsprechend vorbereitet und verwendet bereits diese Art der Authentifizierung.

Ist das jedoch nicht der Fall, dann wird wie folgt vorgegangen: Der X-Server wird nicht mit »startx« gestartet, sondern direkt mit dem Programm »xinit«. Allerdings wird vorher die Authentifizierungsdatei angepaßt bzw. angelegt und als Parameter übergeben. Die folgenden Befehle sind dazu nötig:

   [0] XAUTHORITY=~/.Xauthority; export XAUTHORITY
   [1] rm -f $XAUTHORITY
   [2] xauth add :0 . `mcookie`
   [3] xauth add `hostname`:0 . `mcookie`
   [4] xinit -- -auth $XAUTHORITY

0. Zeile - Die Variable »XAUTHORITY« wird sinnvoll gesetzt, damit später auf dessen Inhalt zugegriffen werden kann.

1. Zeile - Falls bereits eine Autorisierungsdatei existiert, wird diese gelöscht.

2. Zeile - Die Datei wird erstellt und ein Cookie für den Unix-Domain-Socket wird hinzugefügt. Mit »:0« wird die normale Verbindung für grafische Applikationen beschrieben. Dieses geht nicht über eine normale Netzwerkverbindung sondern über eine Rechner-interne Verbindung.

3. Zeile - Ein weiteres Cookie wird hinzugefügt und zwar für »rechnername:0«.

4. Zeile - Jetzt wird der X-Server gestartet. Die auf »--« folgenden Argumente werden direkt an X übergeben. Damit wird dem X-Server mitgeteilt, wie die Authentifizierung zu erfolgen hat.

Damit sind die Grundlagen gelegt, um auch von einem entfernten Rechner auf den X-Server zuzugreifen. Gestattet ist es jedoch noch längst nicht. Um dieses zu ermöglichen, muß das passende Cookie auf den zweiten Rechner übertragen werden. Dazu wird zuerst das entsprechende Cookie aus der Datei extrahiert, auf den entfernten Rechner übertragen, dort eingebaut, das Display gesetzt und das Programm gestartet. Zusammen ergibt das folgende Schritte:

   [1] xauth extract - `hostname`:0> cookie
   [2] rcp cookie remote: (ssh cookie remote:)
   [3] rlogin remote (ssh remote)
   [4] xauth merge - < cookie
   [5] DISPLAY=rechner:0.0; export DISPLAY
   [6] xterm

1. Zeile - Cookie extrahieren und in der Datei »cookie« speichern.

2. Zeile - Die Datei mit dem Cookie wird auf den entfernten Rechner übertragen, hier könnten genauso auch »ftp« oder andere Übertragungsdienste verwendet werden.

3. Zeile - Auf dem entfernten Rechner einloggen

4. Zeile - Dort wird nun das Cookie in die lokale Authentifizierungsdatei übernommen.

5. Zeile - Das Display passend setzen

6. Zeile - Die Anwendung starten. Wenn alles geklappt hat, erscheint die Ausgabe jetzt auf der lokalen Workstation.

Als Kurzform der Zeilen 1 bis 5 wird der folgende Einzeiler verwendet:

   xauth extract - `hostname`:0 | rsh remote xauth merge -
   xauth extract - `hostname`:0 | ssh remote xauth merge -

Von dem Rechner, auf dem man normalerweise arbietet auf das Display eines entfernten Rechners zu schreiben, ist relativ selten, kommt jedoch ebenfalls vor. In einem solchen Fall wird ebenfalls das X11-Cookie ausgetauscht, allerdings in umgekehrter Richtung. Dazu logt man sich zuerst auf dem entfernten Rechner ein, extrahiert das Cookie und fügt es lokal in die Liste der Cookies ein. Die Kurzform sieht dann wie folgt aus:

   ssh remote xauth extract - \`hostname -f\`:0|xauth merge -

Wichtig ist dabei, daß die Ausführung des Programms »hostname« auf dem entfernten Rechner erfolgt, weshalb die Backticks mit einem Backslash geschützt werden müssen. Ansonsten würde xauth nur vermelden, daß es keine Cookies für die andgegebene Adresse gefunden hat.

In beiden Fällen ist es erforderlich, daß der X-Server nicht mit »-nolisten tcp« gestartet wurde, denn sonst akzeptiert dieser überhaupt keine Verbindungen aus dem Netzwerk, theoretisch authorisiert oder nicht. Die Kommandozeile für den X-Server befindet sich in den Dateien »/etc/X11/xdm/Xservers« und »/etc/X11/xinit/xserverrc«. Welche verwendet wird, hängt davon ab, ob der X-Server via »xdm« oder »startx« (bzw. »xinit«) gestartet wird.

Umleitung mit »ssh«

Viel einfacher gestaltet sich die Umleitung von grafischen Programmen, wenn »ssh« und »xauth« installiert sind. In diesem Fall kann nämlich das gesamte Vorgehen von der Secure Shell übernommen werden. Dazu wird die Option »-X« angegeben. Die Secure Shell tunnelt dann eine X11-Verbindung über den verschlüsselten Kanal, der zum entfernten Rechner aufgebaut wurde. Auf der anderen Seite, auf dem entfernten Rechner, wird das Display entsprechend gesetzt. Die »ssh« fängt dort die Ausgaben ab, tunnelt sie durch die SSH-Verbindung zu dem Rechner, auf dem die grafische Oberfläche läuft und der lokale X-Server stellt die Fenster dar.

Abbildung 1: Die X11-Verbindung wird in der SSH-Verbindung getunnelt.

Zusätzlich muß eine Weiterleitung von X-Anwendungen erlaubt sein. Je nach verwendeter Distribution muß dazu in »/etc/ssh/sshd_config« folgendes ebenfalls eingetragen sein:

   X11Forwarding yes

Dieses Vorgehen bietet mehrere Vorteile. Die Verbindung und gesamte Übertragung erfolgt im Normalfall verschlüsselt. Ein Mithören der Verbindung ist dadurch äußerst schwierig. Was bei einer herkömmlichen X11-Übertragung problemlos möglich ist, die IP-Pakete abzuhören und die Ausgabe auf einem zweiten Monitor parallel darzustellen, wird dadurch erheblich erschwert.

Ein weiterer Vorteil liegt darin, daß keine zusätzlichen Ports auf dem Server erforderlich sind. Somit kann man das X11-Forward auch durch eine Firewall betreiben, die restriktiv nur wenige Ports eingehend durchläßt. Wenn eine ausgehende SSH-Verbindung gestattet ist, ist das ausreichend, da die X11-Verbindung dadurch getunnelt wird.

Wenn der Rechner in ».ssh/config« konfiguriert wird, kann dort auch direkt die Einrichtung des X-Tunnels mit der folgenden Einstellung standardmäßig erreicht werden.

   »ForwardX11 yes

Wird »ssh« mit dem Parameter »-x« aufgerufen, wird der Tunnel nicht eingerichtet.

Quelle: freeX 5/01