17.2 Und so funktioniert's 
Nun werden wir uns etwas genauer mit der Funktionsweise des X-Window-Systems auseinandersetzen. Dazu sei zunächst gesagt, dass X11 client/cerver-basiert ist.
17.2.1 Client, Server, Protokoll 
Das X-Window-System ist client/server-basiert. Der X-Server kümmert sich dabei um die Steuerung der Geräte, etwa um die Maus- und Tastatureingabe und die Bildschirmausgabe des Rechners, an dem der Anwender arbeitet.
Einen X-Client hingegen findet man in Form eines X11-Programms, etwa eines grafischen Terminals oder eines Textverarbeitungsprogramms. Diese Programme können auf Remote-Systemen oder lokal gestartet werden und kommunizieren dann mit dem jeweils gewünschten X-Server. Der X-Client sendet also beispielsweise seine Ausgabewünsche für den Bildschirm an den X-Server, der diese anschließend ausgibt. Der X-Server hingegen sendet beispielsweise die Tastatureingabe zur Verarbeitung an den X-Client.
X-Server und X-Client kommunizieren dabei über ein entsprechendes X-Protokoll, dessen Quellen frei zugänglich sind.
Abbildung 17.1 X-Window-System
Der X-Server läuft also auf der lokalen Workstation des Anwenders, und ein X-Client kann sowohl auf dem lokalen als auch auf einem beliebigen anderen System laufen.
Daher ist es nur logisch, dass die hardwareabhängigen Komponenten von den hardwareunabhängigen Komponenten des Systems getrennt sind.
17.2.2 Toolkit und XLib
Mit dem X-Window-System wird eine Library, die XLib, ausgeliefert, mit der X11-Programme entwickelt werden können. Die XLib kümmert sich dabei um die Kommunikation mit dem X-Server.
Da die Programmierung mit der XLib jedoch äußerst komplex ist, gibt es für eben diese Library verschiedene Toolkits wie Qt, Gtk oder Tk, auf denen auch große Oberflächen wie KDE oder GNOME aufsetzen.
Man entwickelt daher Programme nicht direkt mit XLib, sondern mit der Abstraktionsebene der Toolkits. Dies spart Zeit, Quellcode und hält den Code übersichtlicher. Außerdem bringen die Toolkits mittlerweile eine ganze Reihe von Features mit sich, die man so in der blanken XLib nicht findet und erst durch aufwendigen Code erzeugen müsste.
Der Vorteil von XLib und Toolkits besteht aber auch darin, dass sich weder Entwickler noch Anwender um die Kommunikation zwischen X-Client und X-Server kümmern müssen; die gesamte Kommunikation läuft transparent ab. Man spricht hierbei auch von Netzwerktransparenz. Es macht folglich keinen Unterschied, ob man eine Anwendung lokal startet oder dies auf einem entfernten Rechner tut. Zudem können X-Clients aufgrund ihrer Hardwareunabhängigkeit hervorragend auf andere Systeme portiert werden.
Einen Einblick in die Programmierung mit der XLib und in die Programmierung mit dem Gtk-Toolkit erhalten Sie in [Wolf06A].
17.2.3 Wohin soll die Reise gehen?
Wenn nun ein X-Client auf einem Rechner gestartet wird, muss dieser wissen, mit welchem X-Server er kommunizieren soll. Dazu verwendet man die Shell-Variable DISPLAY. In dieser werden die Adresse des X-Servers, die Display-Nummer und die Nummer des virtuellen Desktops angegeben. Damit kann genau festgelegt werden, wo das Anwendungsfenster (bzw. die Anwendungsfenster) angezeigt werden soll(en). Der Aufbau der Variable wird dabei in der Form Adresse:Display.Desktop gehalten:
echo $DISPLAY 192.168.0.3:0.0
Listing 17.1 DISPLAY-Variable
Dabei ist Display Nummer 0 immer das erste Display und 0 auch immer der erste virtuelle Desktop. Möchte man sich nur mit dem lokalen X-Server verbinden, genügt es übrigens, die DISPLAY-Variable auf den Wert »:0« zu setzen, also Adresse und virtuellen Desktop wegzulassen.
17.2.4 Zugriffskontrolle
Um wenigstens den Hauch von Sicherheit in dieses Netzwerksystem zu bringen, implementierte man die Zugriffskontrolle auf den X-Server. Damit verhindert man, dass fremde Rechner oder Benutzer den X-Server ansprechen können.
17.2.5 xhost
Die Zugriffskontrolle für X11 steuert man mit dem Programm xhost, das Bestandteil der Oberfläche ist. Ist man nämlich nicht unter den auserwählten autorisierten Hosts, bekommt man beim Versuch, einen X-Client zu starten, eine entsprechende Fehlermeldung von der XLib.
Error: Can't open display: :0.0. Xlib: connection to ":0.0" refused by server Xlib: Client is not authorized to connect to Server
Listing 17.2 Keine Rechte für X
Um einem Host den Zugriff auf den X-Server zu erlauben bzw. zu untersagen, genügt ein xhost-Aufruf mit dem + (erlauben) bzw. – (verbieten) vor dem Hostnamen, um die Autorisierung des X-Servers abzuändern.
# xhost +localhost
Listing 17.3 xhost
17.2.6 Benutzer und xauth
NIS
Aber wer aufgepasst hat, wird vielleicht bemerkt haben, dass hier nur ganze Hosts den Zugriff auf das System bekommen – oder eben nicht bekommen. Einzelne Benutzer können auf diese Weise nicht mit einer Autorisierung bedacht werden. Mittels Remote Procedure Calls (RPC) und NIS lässt sich dieses Problem zwar beheben, aber auf diese Weise schießt man mit Kanonen auf Spatzen. Aber der Vollständigkeit halber sei gesagt, dass sich die Administration dann mit folgendem Befehl erledigt:
# xhost +nis:user@domain
Listing 17.4 xhost und NIS
xauth
Die Alternative zu xhost nennt sich xauth und kann einem genau diesen Administrationsaufwand ersparen. Bei diesem System verfügt der Benutzer über einen oder mehrere Schlüssel, die in der Datei /.Xauthority im Heimatverzeichnis eingetragen werden. Mit diesen Schlüsseln kann dann die Anmeldung am X-Server über verschiedene kryptographische Protokolle, etwa Tripple-DES, erfolgen. Die Möglichkeiten, die Ihnen hierbei zur Verfügung stehen, finden Sie in der jeweiligen Manpage zu Xsecurity sowie in unserem Buch »Praxisbuch Netzwerksicherheit«. Sie nun zu erläutern, würde an dieser Stelle zu weit führen.
17.2.7 Terminals
Damit man auch unter X11 nicht auf die Shell verzichten muss, gibt es Software, die eine Shell in einem Anwendungsfenster ausführt. Die Eingaben werden dabei an die Shell weitergeleitet, und die Ausgaben der Shell werden im Anwendungsfenster ausgegeben.
Solche Terminalsoftware ist die wohl wichtigste Anwendersoftware unter X11. Standardmäßig wird der Xterm mit X11 ausgeliefert. Es gibt aber auch viele weitere Implementierungen anderer Entwickler, die zusätzliche Features wie einen transparenten Hintergrund implementieren. Außerdem bringen viele Desktop-Systeme, etwa KDE und GNOME, ihre eigenen Terminals mit. Doch dazu mehr an späterer Stelle.
In diesem Abschnitt soll es nur um den Xterm gehen, da dieser zum Standardumfang des X-Window-Systems gehört. Für Desktop-Systeme und weitere Anwendersoftware sind jeweils eigene Kapitel vorgesehen.
Xterm
Der Xterm ist wie gesagt das Standardterminal unter X11. Die Funktionalitäten von XTerm fallen dabei minimalistisch aus. Trotzdem kann diese Software – mit Ausnahme von multiplen Terminals in einem Fenster – alle wirklich wichtigen Anforderungen des Anwenders befriedigen.
Typischerweise übergibt man XTerm nicht sonderlich viele Parameter. Nützlich ist jedoch vor allem der Parameter -e. Er bewirkt, dass im Terminal ein bestimmtes Programm ausgeführt wird. Dies eignet sich unter anderem hervorragend zur Prozessüberwachung mit top: xterm -e top.
Ebenfalls beliebt sind die Parameter zur Farbkonfiguration, die mit -bgcolor <Farbe> für den Hintergrund und -fgcolor <Farbe> für den Vordergrund bestimmt werden können.
Abbildung 17.2 Xterm und Farben
Die Konfiguration von XTerm kann aber auch ganz einfach via Mausklick erfolgen. Dazu drückt man die Taste Strg und dazu entweder
- die linke Maustaste, um die Hauptoptionen zu verändern (hierzu gehört auch das Senden von Signalen)
- die mittlere Maustaste für Optionen, die das virtuelle Terminal selbst betreffen (etwa das Ein- und Ausschalten der Scrollbar)
- die rechte Maustaste für die Optionen der Schrift und des Zeichensatzes (kleine Schriften, große Schriften, UTF-8-Unterstützung usw.)
Abbildung 17.3 Xterm-Optionen
Weitere X11-Terminals
Neben dem Xterm gibt es noch weitere, sehr bekannte Terminals wie die KDE-konsole oder den Eterm. Beide unterstützen übrigens auch transparente Hintergründe.
