22.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/server-basiert ist.
22.2.1 Client, Server, Protokoll
Der X-Server kümmert sich 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 das X-Protokoll, dessen Definition und Referenzimplementierung frei zugänglich sind.
Abbildung 22.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.
22.2.2 Toolkit und XLib
Mit dem X-Window-System wird eine Bibliothek, die Xlib, ausgeliefert, mit der X11- Programme entwickelt werden können. Sie kümmert sich dabei um die Kommunikation mit dem X-Server. Da die Programmierung mit der Xlib jedoch etwas 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 und Quellcode und hält den Code übersichtlicher. Außerdem bringen die Toolkits mittlerweile eine ganze Reihe von Features mit, die man in der reinen Xlib nicht findet und erst in aufwendigem Code implementieren 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. Es macht keinen Unterschied, ob man eine Anwendung lokal oder von einem entfernten Rechner startet. Zudem können X-Clients aufgrund ihrer Hardwareunabhängigkeit hervorragend auf andere Systeme portiert werden.
Einen Einblick in die Programmierung mit der Xlib und dem GTK+-Toolkit erhalten Sie in [Wolf06A].
22.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 dient die Shellvariable DISPLAY. In ihr werden die Adresse des X-Servers, die Display-Nummer und die Nummer des virtuellen Desktops angegeben. Damit kann genau festgelegt werden, wo das bzw. die Anwendungsfenster angezeigt werden soll(en). Der Aufbau der Variablen hat dabei die Form Adresse:Display.Desktop:
Listing 22.1 DISPLAY-Variable
$ echo $DISPLAY
192.168.0.3:0.0
Dabei ist Display Nummer 0 immer das erste Display, und »0« ist 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.
22.2.4 Zugriffskontrolle
Um wenigstens einen Hauch von Sicherheit in dieses Netzwerksystem zu bringen, wurde die Zugriffskontrolle auf dem X-Server implementiert. Damit verhindert man, dass fremde Rechner oder Benutzer den X-Server ansprechen können.
22.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.
Listing 22.2 Keine Rechte für X
Error: Can't open display: :0.0.
Xlib: connection to ":0.0" refused by server
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.
Listing 22.3 xhost
# xhost +localhost
22.2.6 Benutzer und xauth
NIS
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, das wir in Abschnitt NIS besprochen haben, ließe sich dieses Problem zwar beheben, aber auf diese Weise schösse man mit Kanonen auf Spatzen. Der Vollständigkeit halber sei gesagt, dass sich die Administration dann mit folgendem Befehl erledigt:
Listing 22.4 xhost und NIS
# xhost +nis:user@domain
xauth
Die Alternative zu xhost nennt sich xauth und erspart einem genau diesen Administrationsaufwand. 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 kryptografische Algorithmen wie etwa Triple DES erfolgen. Die Möglichkeiten, die Ihnen hierbei zur Verfügung stehen, finden Sie in der Manpage zu Xsecurity sowie in unserem Buch »Praxisbuch Netzwerksicherheit«. An dieser Stelle soll der Hinweis auf diese Möglichkeit genügen.
22.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 gehört zu den wichtigsten Anwenderprogrammen unter X11.
Standardmäßig wird Xterm mit X11 ausgeliefert. Es gibt aber auch viele weitere Implementierungen anderer Entwickler, die zusätzliche Features wie eine nahtlose Integration in das jeweilige Desktopsystem oder einfach nur grafische Verschönerungen wie einen transparenten Hintergrund implementieren. Entsprechend bringen auch die Desktopsysteme KDE und GNOME ihre eigenen Terminals mit.
Dieser Abschnitt behandelt den Xterm, da dies zum Standardumfang des X-Window-Systems gehört. Für Desktopsysteme und weitere Anwendersoftware sind jeweils eigene Kapitel vorgesehen.
Xterm
Xterm ist das Standardterminal unter X11. Seine Funktionalität fällt dabei minimalistisch aus. Trotzdem kann diese Software – mit Ausnahme von mehreren Terminals in einem Fenster – alle wirklich wichtigen Anforderungen des Anwenders befriedigen.
Typischerweise übergibt man Xterm nicht allzu 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. Gültige Werte finden Sie in der Manpage zu xterm. [Fn. Hier dennoch einige Beispiele zum Ausprobieren: green, blue, black, lightblue, lightgreen, darkgreen, cyan3, gray90.]
Abbildung 22.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 des Rollbalkens), oder
- die rechte Maustaste für die Optionen zu Schrift und Zeichensatz (kleine Schriften, große Schriften, UTF-8-Unterstützung usw.).
Abbildung 22.3 Xterm-Optionen
Weitere X11-Terminals
Neben dem Xterm gibt es noch weitere, bekannte Terminals wie die Konsole (KDE) oder Eterm. Beide unterstützen übrigens auch transparente Hintergründe.
Ihr Kommentar
Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.
