Dank automatischer Hardware-Erkennung müssen Admins das X-Window-System kaum noch manuell konfigurieren. Doch wer die hervorragenden Netzwerkfähigkeiten und Tuningmöglichkeiten von X11 verwenden will, sollte Hintergrundwissen mitbringen. Dieser Artikel vermittelt grundlegende Kenntnisse.

Linux richtet es sich auf immer mehr Ex-Windows-Desktops gemütlich ein [1]. Wichtige Erfolgsfaktoren sind vor allem die gut benutzbaren Oberflächen [2] und konkurrenzfähige Anwendungen. Echte Admins fühlen sich dagagen den Tools unter der Haube verpflichtet, die für Maus, Tastatur, Grafikkarte und Monitor zuständig sind.

Die Grundlage fast jeder grafischen Darstellung unter Linux ist der X-Server. Ausnahmen sind vor allem die Konsole und die SVGA-Lib [3], eine gealterte Bibliothek zur direkten Wiedergabe von Grafiken. Im X-Server finden sich primitive Routinen zur Darstellung von Fensterhierarchien, einfache Hardwarebeschleunigung sowie Funktionen für den Umgang mit Tastatur und Maus.

Wer sich nicht gut mit Client-Server-Architekturen auskennt, den wird das X-Protokoll anfänglich vielleicht verwirren. Denn bei X11 arbeitet der Server oft lediglich auf einer kleinen Workstation unter dem Tisch, während die Clients vielleicht auf einer dicken Kiste im Rechenzentrum laufen.

Client und Server fast vertauscht

Bei X ist der Server das Programm, das direkt mit dem Benutzer interagiert. Er zeichnet Widgets (Grafikelemente) auf den Bildschirm und nimmt Eingaben entgegen. Die Clients benutzen diesen Server; sie zeichnen nicht selbst auf den Bildschirm (greifen also meist nicht direkt auf die Grafikhardware zu), sondern weisen den Server an, Grafikaktionen auszuführen. Typische X-Clients sind Textverarbeitungsprogramme, Webbrowser oder Terminal-Emulationen.

Falls Client und Server räumlich getrennt sind, steht der X-Server fast immer auf dem Schreibtisch des Anwenders. Das trifft auch für die typischen Thin Clients unter Linux zu, die unter anderem einen vollständigen X-Server enthalten. Wo sich der Client befindet, ist ziemlich nebensächlich. Sofern eine ausreichend schnelle Netzwerkverbindung bereitsteht, darf der Client im Rechenzentrum nebenan oder auf der anderen Seite der Welt laufen – meist befindet er sich allerdings auf der gleichen Maschine wie der Server.

Der Einsatz eines puren X-Servers mit einem einzelnen Client bietet sich unter Umständen auf so genannten Kiosk-Systemen an, bei denen nur eine einzige Anwendung startet, zum Beispiel in Internetcafés oder als Sichtgeräte für Röntgenfilme.

Ein simples Kiosk-System konfigurieren ist mit zwei Befehlen getan. Als Erstes startet der Admin den Server und anschließend den oder die gewünschten Clients. In dem folgenden Aufruf gibt die Option »:3« an, dass der Server auf dem vierten (die Zählung beginnt bei null) lokalen Display (nicht dem vierten Monitor) starten soll:

X :3 < /dev/null > /dev/null 2>&1 &
exec firefox --display :3 &

Das Programm »xinit« vereinfacht diesen Aufruf, indem es sich selbst um den Start des X-Servers kümmert. Die folgende Zeile startet den X-Server und in seinem Gefolge ein Xterm, falls nicht die Datei ».xinitrc« im Homeverzeichnis des Benutzers etwas anderes vorsieht:

xinit -fn 9x13 -- :3 > /dev/null 2>&1 &

Kernstück jeder X-Umgebung ist die Datei »/etc/X11/XF86Config-4«. Je nach X-Server-Variante und eingesetzter Distribution heißt sie auch »xorg.conf« oder ähnlich. Diese Datei enthält die Konfiguration für alle Geräte, mit denen der X-Server zusammenarbeitet.

Da Linux bei automatischer Hardware-Erkennung beachtliche Fortschritte gemacht hat, müssen Admins meist keine oder nur wenige Änderungen an der Serverkonfiguration vornehmen. Programme, die diese Datei automatisch erstellen, sind zum Beispiel »xf86cfg«, »xf86config« oder – bei Suse – Sax beziehungsweise Sax 2.

Die Konfigurationsdatei ist nicht nur für den Computer und seine Grafikkarte spezifisch, sondern auch für den Monitor. Vor einem Wechsel von Monitor respektive Grafikkarte sollten Administratoren also unbedingt darauf achten, sich einen alternativen Zugangsweg zum Computer offen zu lassen (Netzwerk oder Konsole), falls die Optionen falsch sind und der X-Server nicht startet.

Windowmanager

Der X-Server allein ist noch nicht sehr benutzerfreundlich, besonders wenn ihn mehrere Programme gleichzeitig bedienen. Für komfortables Arbeiten an einer Workstation fehlt noch eine strukturierende Komponente: Der Windowmanager versieht die einzelnen Fenster mit einer Titelleiste zur Identifikation und einem Rahmen zur Größenänderung. Abbildung 1 zeigt TWM, einen der ältesten Windowmanager.

TWM erlaubt das Verschieben von überlappenden Fenstern und ordnet sie sogar automatisch an. Außerdem implementiert er ein einfaches Menü, mit dem Anwender Programme starten, Fenster minimieren oder deren Größe ändern. Klassische Windowmanager wie TWM oder FVWM sind klein, effizient und dabei trotzdem komfortabel. Sie finden heute noch auf Thin Clients oder älteren Systemen Anwendung, wenn es auf Platz und Geschwindigkeit ankommt.

Um eine X-Session mit TWM und Firefox zu starten, genügen drei Zeilen:

X :3 < /dev/null > /dev/null 2>&1 &
twm -display :3 &
exec firefox --display :3 &

Die meisten Anwender bevorzugen jedoch ein komplettes Desktop Environment wie KDE oder Gnome. Diese kompletten Frameworks enthalten neben einem Windowmanager viele weitere Tools und Utilities sowie umfangreiche Bibliotheken. Letztere sollen die GUI-Programmierung erleichtern, ein einheitliches Erscheinungsbild fördern und die Kommunikation zwischen verschiedenen Anwendungen optimieren.

Bei den modernen Desktop Environments gehört neben dem Windowmanager auch ein Sessionmanager zum Umfang. Er stellt die vorherige Sitzung wieder her, startet also die zuletzt benutzten Programme und platziert ihre Fenster an der richtigen Stelle. Sowohl Gnome als auch KDE enthalten leistungsfähige Sessionmanager.

Grafisch einloggen

Der X-Server kümmert sich um die Ein- und Ausgabe auf dem Bildschirm, der Windowmanager sorgt für bequemes Arbeiten mit mehreren Fenstern. Da wünschen sich Nutzer nur noch die Möglichkeit, sich mit einem grafischen Fenster ins System einzuloggen. Kaum ein Anwender möchte die grafische Sitzung mit Konsolen-Kommandos beginnen.

Komfortabler ist ein Displaymanager. Er ruft einen X-Server auf und öffnet ein Dialogfenster ähnlich dem in Abbildung 2 gezeigten. Hat sich ein Benutzer erfolgreich authentifiziert, startet der Displaymanager die eingestellte Umgebung. Die Netzwerkfähigkeiten des X11-Systems erlauben es bei Bedarf sogar, den Displaymanager auf einem anderen Computer als auf dem des X-Servers laufen zu lassen. Er startet dann als einfacher Client. Über das Protokoll XDMCP erhält der X-Server Verbindung zum Displaymanager auf einem anderen Rechner.

Abbildung 1: Ein X-Server mit dem simplen Windowmanager TWM. Windowmanager nutzen den X-Server, um Fenstern einen Rahmen und die Titelleiste zu verpassen. Obwohl TWM nur sehr wenige Funktionen beherrscht, lässt sich mit ihm bereits angenehm arbeiten.

Entweder gibt der Admin dabei einen Computer als Host für den Displaymanager vor oder der X-Server schickt Broadcast-Pakete an das gesamte LAN und findet so automatisch einen passenden Displaymanager. Der Aufruf sieht folgendermaßen aus: »X -broadcast«. Um den Displaymanager von einem dedizierten Rechner anzufordern, startet man den X-Server mit »X -query Host«.

Alle modernen Linux-Distributionen installieren gemeinsam mit X11 auch einen Displaymanager samt passender Konfiguration. Wo diese genau steht, verrät am einfachsten »locate« [4] gefolgt vom Namen des gewünschten Managers. Verbreitet sind neben dem traditionellen XDM auch die Alternativen von KDE (KDM) und Gnome (GDM).

Displays ansteuern

Ein Rechner ist nicht darauf beschränkt, nur einen X-Server zu starten. Mit seinen virtuellen Terminals ist Linux in der Lage, mehrere Server gleichzeitig zu bedienen. Spezielle X-Software arbeitet sogar ohne Monitor und Tastatur, was für Terminalserver wichtig ist. Da Client und Server unabhängig voneinander agieren und nicht mal auf demselben Computer laufen müssen, ist es erforderlich, den Clients mitzuteilen, auf welchem Display sie ihre Ausgabe darstellen sollen. Dazu dient die Environment-Variable »DISPLAY«.

Abbildung 2: Mit einem grafischen Login-Screen – das Bild zeigt den von KDM – loggen sich Benutzer komfortabel ein. Zudem bietet er in der Regel ein Menü zur Auswahl des Desktops oder zum Herunterfahren des Systems.

Sie enthält einen optionalen Hostnamen, eine Display-Nummer sowie eine ebenfalls optionale Screen-Nummer: »(Host):Display(.Screen)«. Die Screen-Nummer ist in der Regel nur für Xinerama-Umgebungen interessant, bei denen ein X-Server mehrere Monitore bedient. Ist der Hostname in »DISPLAY« nicht angegeben, kontaktieren die Clients den lokalen Rechner. Dabei findet die Kommunikation nicht über TCP-Ports (wie bei X11-Netzwerkverbindungen), sondern über Unix-Sockets statt.

Nach dem Login über einen Displaymanager sind alle Umgebungsvariablen passend gesetzt. Wer X-Programme manuell startet, muss möglicherweise die entsprechende Variable setzen. Der folgende Aufruf startet den Browser Firefox auf dem lokalen Rechner; die Oberfläche von Firefox zeigt dabei der X-Server auf dem Rechner »sun14« an:

export DISPLAY=sun14:0
firefox &

Beim X11-Einsatz übers Netzwerk sind zwei Probleme zu bedenken: Erstens erlaubt nicht jeder Server Verbindungen von jedem beliebigen Client – das wäre ein Sicherheitsrisiko. Zweitens sind die Datenströme in der Voreinstellung unverschlüsselt. Angreifer können problemlos in den Protokollen herumschnüffeln sowie Session Hijacking ausführen, also sich in fremde Sitzungen einklinken und diese übernehmen.

Wie selbstverständlich setzt heute fast jeder X-Server schon per Voreinstellung eine Zugriffskontrolle ein. Auf Linux-Systemen stehen zwei Alternativen zur Verfügung: Xhost erlaubt dedizierten Computern den Zugriff und ist damit nicht übermäßig sicher. Xauth benutzt kryptographische Cookies und bietet damit eine sehr feine Steuerung.

Diese Schutzmechanismen sind wichtig, weil X-Clients über diverse Protokolle sehr weit reichenden Einfluss auf den Server und auf andere Clients ausüben. So ist beispielsweise das Mitlesen von Tastatureingaben kein großes Problem. Zugriff auf den eigenen X-Server sollten daher nur vertrauenswürdige Programme haben.

Zugriffskontrolle per Cookie

Das Tool Xauth speichert alle Cookies in der Datei ».Xauthority« im Heimatverzeichnis des Nutzers. Jeder gestartete Client sieht in diese Datei hinein und benutzt das passende Cookie, um sich bei dem X-Server zu authentifizieren. Wer seine Session auf einem fremden Rechner oder mit einem anderen Account auf dem gleichen Rechner benutzen will, muss das Cookie in seine ».Xauthority« importieren (siehe Listing 1). Der Aufruf »xauth nextract« speichert es dabei zunächst in einer Datei ab. Das Kommando »xauth nmerge« importiert die Datei in ».Xauthority«.

Die Variante mit Xhost bietet sich auf einem möglichst nicht vernetzten Rechner an, um die Zugriffskontrolle vorübergehend komplett auszuschalten. Der Befehl »xhost +« erlaubt jedem Client von jedem Rechner aus den Zugriff auf das Display. »xhost -« schaltet die Zugriffskontrolle wieder ein.

Xauth kontrolliert allerdings lediglich, wer auf einen X-Server zugreifen darf. Die übertragenen Daten sind damit noch in keiner Weise geschützt. Wer den Mechanismus aus Listing 1 für den Start von Clients auf einem fremden Rechner einsetzt, muss also immer noch mit fremden Lauschern rechnen.

Das weit verbreitete SSH [5] hilft dabei, das X-Protokoll durch eine verschlüsselte Verbindung zu tunneln. Das Programm sorgt für Verschlüsselung, setzt die Environment-Variablen richtig und legt für den Zugriff per Xauth eine ».Xauthority«-Datei auf dem entfernten Rechner an.

X mit SSH tunneln

Voraussetzung für einen solchen Tunnel ist, dass in »/etc/ssh/sshd_config« (und eventuell »/etc/ssh/ssh_config«) die Variable »X11Forwarding« auf »yes« gesetzt ist. Danach startet der Benutzer über die Kommandozeilenoption »-X« einen Tunnel für X11 (Listing 2). SSH stellt auf dem entfernten Rechner einen virtuellen X-Server bereit (meist »:10«), dessen Clients es auf dem lokalen X-Server anzeigt. (mwe/fjl)

01 mas:~$ xauth nextract myxkey :0
02 mas:~$ chmod 640 myxkey
03 mas:~$ su unsafe
04 Password:
05 unsafe:/home/mas$ firefox
06 Xlib: connection to ":0.0" refused by server
07 Xlib: No protocol specified
08 
09 (firefox-bin:3086): Gtk-WARNING **: cannot open display: :0
10 unsafe:/home/mas$ xauth nmerge myxkey
11 unsafe:/home/mas$ firefox

01 mas@ishi:~$ ssh -X kanat.pair.com
02 [...]
03 mas@kanat:$ echo $DISPLAY
04 localhost:10.0
05 mas@kanat:$ firefox &