X-Window-System

Soll es grafisch zugehen, spielen viele Komponenten mit, um die schnöde Linux-Textkonsole zu verdrängen. Die wichtigste Aufgabe übernimmt der X-Server, das Herzstück des X-Window-Systems, kurz X11 oder X: Er steuert Grafikkarte (und damit den Monitor), Maus und Tastatur an. Ohne Zusatz-Tools bringt der X-Server pixelbasierte Ausgaben von Fenstern und darin einfache geometrische Formen und Texte auf den Schirm. Auch Mausbewegungen, Klicks und Tastendrücke erkennt er und macht daraus so genannte X-Events.

Das allein wäre nicht genug für eine grafische Oberfläche. Zusätzlich braucht es einen Window-Manager, der die schlichten Fenster des X-Servers mit einem Rahmen und Buttons zum Schließen, Minimieren und Verschieben versieht und die zahlreichen Maus-basierten Manipulationen, etwa Größenänderungen eines Fensters, umsetzt. Erst mit dem Window-Manager bekommt die Oberfläche ihre Optik, sodass ein KDE-Desktop anders aussieht als eine Gnome-Oberfläche.

Komfort beim Anmelden bringt der Display-Manager. Er präsentiert einen grafischen Login und startet nach erfolgreicher Authentifizierung den Window-Manager und weitere Programme. Abbildung 1 zeigt die Ebenen vom X-Server bis zum Desktop und die Kommunikationswege.

Rollenverteilung

Wichtig zu wissen ist, dass X ein Client-Server-Modell verwendet. Die Rollenverteilung verwirrt gelegentlich: Der X-Server läuft lokal auf der Maschine, an der Monitor und Tastatur angeschlossen sind. Er stellt seine Dienste (grafische Elemente anzeigen und Tastatur- und Maus-Events erzeugen) den X-Clients zur Verfügung. Letztere sind normale Anwendungsprogramme, die wahlweise lokal (auf der gleichen Maschine wie der X-Server) oder auf einem entfernten, via Netz erreichbaren Rechner laufen.

LPI-relevante Themen sind neben dem X-Server von X.org auch Display- und Window-Manager (siehe Kasten "LPI-Aufgabengruppen"); sie konzentrieren sich auf Installation und Konfiguration. Das LPI behandelt diese Themen im Topic 110, das zu Prüfung 101 gehört.

Die meisten Distributionen bringen X bereits mit, in der Regel landet es bei der Standardinstallation auch vorkonfiguriert auf der Festplatte. Sollte dies nicht der Fall sein, holt ein Aufruf des Paketmanagers den Schritt nach.

Übersetzungsarbeit

Eine Alternative ist die Übersetzung aus den Quellen, sie ist jedoch recht aufwändig: Zunächst sind die Sourcen [3] zu besorgen, was über Git, CVS (zur Zeit noch) oder den Download von Tar-Archiven möglich ist. Sind die Quellen installiert, bieten sich mehrere Build-Skripte an, um sie zu übersetzen. Zwar ist auch das Kompilieren von Hand möglich, das kostet aber viel Zeit.

Wenn diese Schritte erfolgreich abgearbeitet sind, geht es mit der Konfiguration weiter. Auch hier führen mehrere Wege zum Ziel. Das Kommando »Xorg -configure« startet die automatisierte Konfiguration des X-Servers, »xorgcfg« ist ein grafisches Konfigurationstool, »xorgconfig« ist die Alternative für Freunde der Textkonsole. Um den X-Server korrekt zu konfigurieren, sind Informationen über die Grafikhardware erforderlich. Wer nicht ins Handbuch des Rechners blicken will, behilft sich mit den üblichen Linux-Tools wie »lspci«.

Xorgconfig führt schrittweise durch die Einrichtung (Abbildung 2) und schreibt die Ergebnisse in die zentrale Konfigurationsdatei »/etc/X11/xorg.conf«. Nach erfolgter Konfiguration aktiviert »startx« den X-Server: Dieser Test prüft, ob alle Einstellungen korrekt sind.

Zum Konfigurationsprogramm Xorgconfig gibt es zahlreiche distributionseigene Alternativen. Ein Klassiker ist Sax 2 von Suse/Novell; Fedora Core liefert das Tool »system-config-display« mit. Beide übernehmen einen Großteil der Arbeit und bewähren sich vor allem beim Erkennen und korrekten Einbinden der Grafikhardware. Für die LPI-Prüfung sind aber die generischen Tools relevant.

Gelegentlich zeigt der Monitor das Bild nicht vollständig, leicht verschoben oder verzerrt an. Dann hilft ein Aufruf von »xvidtune« (Abbildung 3) weiter; das Programm justiert die X-Oberfläche. Ist die gewünschte Einstellung erreicht, gibt Xvidtune eine so genannte Modeline aus, die der Anwender in die X-Konfigurationsdatei übernimmt. Modelines sehen immer wie folgt aus:

Modeline   "1280x1024" 165.29 1280 1392 1528 1744 1024 1025 1028 1077

Dabei haben die einzelnen Angaben hinter dem Modeline-Schlüsselwort folgende Bedeutungen: »1280x1024« vergibt einen Namen, über den die Modeline aktivierbar ist. Der nächste Wert ist die Pixel Clock, ein Umrechnungsfaktor zwischen Pixeln und Sekunden. Es folgen je vier Werte für das horizontale und das vertikale Timing der Grafikkarte - davon gibt der jeweils erste die Auflösung an (im Beispiel also 1280 und 1024).

Zahlreiche Webseiten beschäftigen sich mit der Berechnung von Modelines. Wer nicht selbst zum Taschenrechner greifen will, findet im Modeline-Generator [8] ein praktisches Tool. Heute sind Modelines nur noch nötig, wenn die Darstellung nicht optimal ist (siehe Beschreibung von Xvidtune) oder eine ungewöhnliche Auflösung gewünscht ist. Neuere X-Server kennen die richtigen Parameter für die meisten Auflösungen auch ohne explizite Modelines.

Zentrale Konfiguration

Die X.org-Konfigurationsdatei »/etc/X11/xorg.conf« ist in Abschnitte (Sections) unterteilt (Abbildung 4). Jeder Abschnitt beginnt mit dem Schüsselwort »Section« und endet mit »EndSection«, dazwischen stehen die Konfigurationsparameter. X.org kennt die in Tabelle 1 aufgeführten Abschnitte. Aus Kompatibilitätsgründen darf es auch noch »Keyboard«- und »Pointer«-Sections geben, die in der aktuellen Version durch »InputDevice«-Abschnitte ersetzt sind. Die ebenfalls veralteten »XInput«-Abschnitte unterstützt X.org nicht mehr.

Auf den Schirm

»Screen«-Abschnitte fassen je eine Grafikkarte, einen Monitor und eventuell weitere Informationen (etwa Modes-Blöcke mit speziellen Modelines) zusammen und regeln damit die Ansteuerung eines Monitors. Für den Dual-Head-Betrieb mit zwei Bildschirmen sind mehrere solche Abschnitte erforderlich. Deren Anordnung legt dann die »ServerLayout«-Section fest. E

Der X-Fontserver (Xfs) stellt eine Schriftensammlung bereit, die X-Server verwenden können - sind sie entsprechend konfiguriert, ist es nicht mehr nötig, Schriften lokal zu installieren, da sich der X-Server diese vom X-Fontserver holt. Auch beim Einsatz dieses Servers steht am Anfang die Konfiguration. Die passenden Dateien liegen in der Regel unter »/etc/X11/fs/config« (Abbildung 5). Sie sind übersichtlich und weitgehend selbsterklärend.

Sobald der X-Fontserver eingerichtet ist, folgt die Umstellung der X-Server im Netzwerk: Diese sollen nun auch den X-Fontserver nutzen. Dazu passt man in der Konfigurationsdatei des X-Servers den Abschnitt »Files« an. Der Eintrag

FontPath "tcp/192.168.100.1:7000"

bewirkt, dass der X-Server sich die Fonts vom X-Fontserver mit der IP-Adresse 192.168.100.1 holt. 7000 ist der Standardport, auf dem X-Fontserver Anfragen entgegennehmen; wer diesen Port ändert, muss ihn auch in der X-Server-Konfiguration anpassen.

Xdm, Gdm und Kdm

Display-Manager präsentieren einen grafischen Anmeldedialog und starten nach erfolgreichem Login einen Window-Manager, zum Beispiel KWin (KDE), Metacity (Gnome) oder Ice-WM. Es gibt mehrere solche Tools, die bekanntesten sind Xdm, Kdm (KDE) und Gdm (Gnome). Xdm liegt in der Regel unter »/usr/X11R6/bin«, seine Konfigurationsdateien verbergen sich in »/usr/X11R6/lib/X11/xdm« oder »/etc/X11/xdm«.

Der Manager akzeptiert auch Remote-Verbindungen über das X Display Manager Connection Protocol (XDMCP), wenn er entsprechend konfiguriert ist. Entfernte Zugriffe richtet man über die Datei »Xaccess« ein. Das funktioniert aber nur, wenn in der zentralen Konfigurationsdatei »xdm-config« Anmeldungen von entfernten Rechnern aus erlaubt sind. Dazu ist folgende Zeile auszukommentieren (ein Ausrufezeichen voranstellen):

DisplayManager.requestPort:     0

Nach seinem Neustart akzeptiert Xdm Anmeldungen aus der Ferne. Hat sich ein Benutzer erfolgreich authentifiziert, führt Xdm das Skript »/etc/X11/xdm/Xsession« aus. Wenn es im Homeverzeichnis noch eine ähnlich benannte Datei (».Xsession« oder ».xsession«) gibt, startet das globale Xsession-Skript diese Datei zusätzlich.

Manager-Wahl

Eine Alternative zu Xdm ist der Gnome Display Manager (Gdm). Auch er unterstützt das Display Manager Connection Protocol. Seine Konfigurationsdateien liegen unter »/etc/X11/gdm«. Änderungen nimmt man entweder direkt in den Konfigurationsdateien (»defaults.conf« und »custom.conf«) vor oder benutzt das Einrichtungsprogramm »gdmsetup«. Üblicherweise liegt es im Verzeichnis »/opt/gnome/sbin«, je nach Distribution aber auch an anderer Stelle.

Um die Konfiguration von Hand zu ändern, bearbeitet man die Datei »custom.conf«. Die hier vorgenommenen Einstellungen überschreiben die Standardwerte aus »defaults.conf«. Nach Änderungen ist ein Neustart von Gdm nötig, um diese zu aktivieren.

Der Dritte im Bunde nennt sich Kdm (KDE Display Manager). Er spricht ebenfalls das XDMCP. Die Kdm-Konfigurationsdatei heißt »kdmrc« und liegt meist im Verzeichnis »KDE-DIR/share/config/kdm«. Hierbei ist KDE-DIR das Wurzelverzeichnis der KDE-Installation, das sich wieder von Distribution zu Distribution unterscheidet. Wer die Datei nicht von Hand bearbeiten mag, findet im KDE-Kontrollzentrum ein Modul für die Kdm-Einrichtung.

Runlevel anpassen

Damit die Display-Manager beim Systemstart verfügbar sind, muss man sie in geeigneten Runlevels aktivieren. Das Programm »/sbin/init« schaltet zwischen Runlevels hin und her, für deren Konfiguration die Datei »/etc/inittab« zuständig ist. In welchem Runlevel X standardmäßig startet, variiert von Distribution zu Distribution, meist ist es Runlevel 5. Der Parameter »initdefault« legt den Standard-Runlevel fest, also jenen, in dem Linux beim Booten startet:

id:3:initdefault:

Dieser Eintrag bedeutet, dass das Programm »init« beim Systemstart Runlevel 3 aktiviert. Um beispielsweise Kdm als Display-Manager zu aktivieren, sollte der Initdefault auf 5 lauten und in Runlevel 5 folgender Eintrag den Kdm starten:

x:5:respawn:/usr/bin/kdm

Das »respawn« sorgt dafür, dass Init den Kdm nach einem Absturz sofort wieder aufruft - andernfalls könnte sich kein Benutzer mehr anmelden.

Alternativ eignet sich auch ein Start-und-Stop-Skript im Verzeichnis »/etc/init.d/«, das in »/etc/init.d/rc5.d/« oder »/etc/rc5.d« richtig verlinkt sein muss. Debian-Systeme verwenden übrigens den Standard-Runlevel 2. Den braucht der Admin nicht zu verändern, er sollte nur darauf achten, dass er den Display-Manager in Runlevel 2 einträgt.

Fensterverwaltung

Ein weiteres Lernziel für die LPI-Prüfung ist Objective 1.110.4: Installation und Anpassung eines Window-Managers. Weit verbreitete Window-Manager sind KWin (KDE) und Metacity (Gnome). Für welchen man sich entscheidet, ist im Wesentlichen eine Geschmacksfrage, denn der Window-Manager ist für einen Großteil der Optik und des Verhaltens verantwortlich. Eine Auswahl von Window-Managern gibt es unter [6].

Nach der Installation via Paketmanager oder mit dem klassischen Kompilierdreischritt stehen noch Anpassungen an: Das Look&Feel vieler Window-Manager und auch der X-Toolkits (Qt, GTK, Motif & Co.) lässt sich über die Datei ».Xdefaults« im Homeverzeichnis beeinflussen. Die Syntax für Einträge in dieser Datei ist immer gleich:

Programm.Klasse.Ressource: Wert

Der erste Parameter legt fest, auf welches Programm sich die Einstellung bezieht. Klassen gruppieren Ressourcen, zum Beispiel ist es möglich, über die Klasse »Geometry« allgemeine Angaben zur Fenstergröße und -position zu definieren. Die Ressource definiert den zu ändernden Wert, zum Beispiel »Foreground« für die Vordergrundfarbe.

Um beispielsweise Xterm-Fenster immer mit schwarzem Hintergrund zu öffnen, sieht die Konfigurationszeile folgendermaßen aus, das Sternchen dient als Wildcard-Zeichen:

xterm*Background: black

Einen ausführlichen Artikel über X-Ressourcen gibt es unter [9].

Remote X

Ein wichtiges Feature von X ist, dass die Clients nicht auf demselben Rechner laufen müssen wie der Server. Um die Ausgabe einer X-Anwendung auf ein anderes Display (also zu einem anderen X-Server) umzuleiten, sind vorab ein paar Schritte notwendig.

Zunächst ist der X-Server so einzurichten, dass er Verbindungsversuche von einem anderen Rechner zulässt. Das geht mit dem Kommando »xhost«, dessen Aufrufvarianten Tabelle 2 listet. Der Befehl »xhost +pingu« erlaubt dem Host »pingu« den Zugriff. Um die Ausgabe umzuleiten, gibt man der X-Anwendung den Parameter »-display« mit oder setzt die Umgebungsvariable »DISPLAY«. Der Wert der Display-Variablen hat stets den Aufbau »Host:Xserver.Display«.

Wer beispielsweise die Ein- und Ausgabe von X-Anwendungen, die auf dem Rechner »pingu« laufen, auf die Maschine »XSRV« umleiten will, führt folgende Schritte durch: Auf »XSRV« den Host »pingu« mit »xhost +pingu« in die Liste der zulässigen X-Hosts eintragen. Auf »pingu« das Display umstellen. Der Host heißt »XSRV«, der X-Server trägt die Nummer 0 (der erste X-Server) und das Display ist ebenfalls 0, also lautet der Aufruf: »export DISPLAY="XSRV:0.0"«. Jede auf Pingu gestartete X-Anwendung öffnet dann ihr Fenster auf XSRV.

Es sind also nur wenige Schritte nötig, um eine solche Umleitung einzurichten. In der Praxis funken allerdings oft Firewalls dazwischen. Zudem öffnet Xhost je nach Aufrufart eine große oder sehr große Sicherheitslücke: Nach »xhost +pingu« hat jeder Benutzer des Rechners Pingu uneingeschränkten Zugriff auf den X-Server von XSRV, bei der allgemeinen Freigabe mit »xhost +« sogar jeder Benutzer eines beliebigen PC, der Pingu via Netzwerk erreicht. Zu den Programmen, die jedermann dann starten kann, gehört beispielsweise »import«, das einen Screenshot vom Desktop macht. Auch die Tastatureingaben kann er verfolgen.

Unterstützung in Sicherheitsfragen bietet der Einsatz von Xauth, das über so genannte Magic Cookies [10] nur berechtigte Zugriffe erlaubt. Einfacher und sicherer wird die X-Umleitung beim Remote-Login via SSH mit dem Parameter »-X«, der das X11-Forwarding aktiviert. Das spart sogar das manuelle Setzen der Display-Variablen und schützt die Übertragung kryptographisch.

Prüfungsvorbereitung

X ist ein sehr komplexes Thema. Auch wenn die Prüfungsfragen nicht alle Unterthemen streifen, ist es hilfreich, sich der Komplexität zu stellen und sich vertieft in die X-Konfiguration einzuarbeiten sowie mit verschiedenen Display- und Window-Managern zu experimentieren. Verbindungen über XDMCP herstellen, die Begrüßungstexte im Display-Manager ändern und Fenster auf andere Server umleiten macht Spaß und führt schnell zu guten Erfolgsquoten. (fjl)