Torsten Förtsch
IT System Development & Security
Kaum macht man's richtig, schon geht's, ;-)

>> Home >> Tipps & Tricks >> XTerminal

Bau eines XTerminals mit SuSE Linux 8.1

Vor kurzem hatte ich das Vergnügen, mir ein neues Notebook anzuschaffen. Das alte Toshiba Tecra 8000 mit 128MB RAM wollte ich nicht gleich verschrotten und eigentlich einen DSL Router daraus basteln. Doch dann beschwerte sich meine Liebste immer wieder, es sei in ihrem Zimmer im Winter immer so kalt und die Arbeit am Rechner mache überhaupt keinen Spaß. Also wurde es erst mal nichts aus dem Router, sondern ich baute ein XTerminal, damit meine Frau schön gemütlich im Wohnzimmer arbeiten kann. (Eine bessere Heizung hätte es auch getan, aber Computer liegen mir eben mehr.)

So, da es zuerst ein Router werden sollte, heißt das Ding jetzt also ganz lapidar router. Und da mein Netz sehr klein und ganz lokal ist, heißt er vollständig router.local.

Jetzt wird es ernst. Folgende Anforderungen wollte ich erfüllen:

Damit ergab sich ein Ding, was einem X Terminal sehr ähnlich ist. Da ich keine Lust hatte, hunderte von CDs zu verbrennen, nur um kleine Fehler zu beseitigen. Also musste eine VMware Box als Test Rechner her. Ich erstellte also ein CD Image mit mkisofs und isolinux installierte es in der VMware Box als virtuelles CD Laufwerk und konnte probieren soviel ich wollte.

Der schwierigste Teil des Ganzen war die Anpassung des Standardlinux an ein read-only Root Filesystem. Einen gewissen beschreibbaren Teil des Filesystems braucht Linux, z.B. zum Anlegen von UNIX Domain Sockets (gerade X11). Die brauchen zwar keinen Platz, aber die Directory muß schreibbar sein. Da keine Festplatte Verfügung stand, brauchte ich also einen RAM-Disk. Die beste Lösung schien mir shmfs. Hier muß nicht vorher festgelegt werden, wie groß der RAM-Disk sein soll. Dieses Filesystem paßt sich automagisch an. Normalerweise ist es unter /dev/shm gemountet.

XDMCP

Der Schlüssel zu einem X Terminal lautet XDMCP. Mit diesem Protokoll kann man mit einem X Display Manager über TCP/IP reden und ihn fragen, ob man auf seinem Rechner arbeiten darf. Der X Server selbst unterstützt XDMCP schon von selbst nämlich mit den Optionen -query, -broadcast oder -indirect. Im ersten Fall fragt er direkt beim Display Manager eines bestimmten Rechners an. Diese Variante fällt bei mir aus. Ich wollte ja eine Liste der möglichen Rechner sehen. -broadcast schickt zwar eine Anfrage an alle Rechner im lokalen Netz. Doch greift sich der X Server einfach den, der zuerst antwortet, und versucht mit diesem zu arbeiten. Wieder keine Liste, Mist. Die letzte Variante, -indirect, ist, was ich suchte. Hier beauftragt der X Server einen irgendwo (wo wird der Option als Parameter mitgegeben) laufenden Display Manager eine Liste der möglichen Rechner zu ermitteln und diese zu präsentieren. Irgendwo kann natrlich auch der lokale Rechner sein.

XDMCP Ablauf-Diagramm

Damit war der Weg klar:

  1. Der X Server beauftragt den lokalen Display Manager (Option -indirect router.local)
  2. Der Display Manager schickt eine Broadcast Anfrage an alle Rechner im lokalen Netz.
  3. Die Display Manager der entfernten Rechner antworten.
  4. Der lokale Display Manager präsentiert die Liste.
  5. Der Benutzer trifft seine Wahl. Er wählt ein Element der Liste aus.
  6. Der lokale Display Manager beauftragt den Display Manager des gewählten Rechners seinen Login Dialog zu zeigen.
  7. Der entfernte Display Manager zeigt seinen Login Dialog.

Als erstes galt es, die Display Manager auf den entfernten Rechnern dazu zu bringen, überhaupt einen nicht-lokalen Login zu akzeptieren. Vor einigen Jahren, als es noch kein KDE oder GNOME o.ä gab, wäre die Sache einfach gewesen. Der einzige damals existierende Display Manager war xdm und wurde mit /etc/X11/xdm/xdm-config konfiguriert Und tatsächlich, selbst bei einer SuSE Distribution findet sich dieses File an dieser Stelle. Darin gibt es eine Zeile, die den Port, auf dem xdm auf Anfragen aus dem Netz lauschen soll, angegeben:

DisplayManager.requestPort:    0

Damit wird xdm verboten Anfragen aus dem Netz entgegenzunehmen. Sie muß also auskommentiert, oder die 0 durch eine 177 ersetzt werden. (177 ist der Standardport für XDMCP.) Danach sollte ein

X -indirect localhost

oder

X -indirect router.local

von der Kommandozeile funktionieren. Ich bevorzugte damals localhost, da ich den Hostnamen nicht hart verdrahten wollte. Da ich bisher keinen anderen Display Manager für Zugriff aus dem Netz konfiguriert hatte, enthielt die Liste der Rechner genau einen.

Meine anderen beiden Rechner liefen mit KDE und sollten auch den KDM als Display Manager benutzen. Also fahndete ich unter /opt/kde3 nach einer Datei namens kdmrc und fand doch tatsächlich /opt/kde3/share/config/kdm/kdmrc. Ich bin kein KDE Spezialist, also war ich erst mal froh, eine Text Datei gefunden zu haben.

Auch enthielt diese Datei eine mit

[Xdmcp]

überschiebene Sektion mit vielen Kommentaren. Prima, dachte ich. Einige kleine Änderungen und schon sollte es funktionieren. Doch, was ich auch tat, es funktionierte nicht. Zum Schluß war ich soweit, daß ich einen meiner Rechner umkonfigurierte, damit er xdm statt kdm benutzt. Damit hatte ich ja schon einmal Erfolg. Gut, danach erschien der Rechner in der Liste. Doch, wenn ich ihn auswählte, passierte nichts und nach einer Weile sah ich wieder eine frische Liste statt eines Anmeldefensters. Darüber mußte ich erst mal eine Nacht schlafen. Irgendwann ging mir ein Licht auf. Bis dahin hatte ich auf router immer

X -indirect localhost

eingegeben, um den X Server zu starten. Wenn nun der lokale xdm localhost:0.0 als Display an den entfernten Display Manager übergibt, versucht dieser eine Verbindung mit diesem Display herzustellen. Das muß aber schief gehen, denn localhost ist auf jedem Rechner lokal. Also startete ich

X -indirect router.local

auf router und ... Kaum macht man's richtig, schon geht's.

Bei SuSE ist alles anders

Gut, nachdem xdm als Display Manager auf dem entfernten Rechner funktionierte, startete ich eine neue Runde, um vielleicht doch noch kdm zum Laufen zu bringen. Ich erinnerte mich, daß es sich ja um ein SuSE System handelt und da ist meist einiges anders. Also erforschte ich /etc/sysconfig, ob sich da nicht irdendeine Datei versteckt, die vielleicht etwas mit dem Display Manager zu tun hat. Und siehe, es gibt doch wirklich /etc/sysconfig/displaymanager. Und tatsächlich findet sich dort eine Option

#
# Allow remote access to your display manager (kdm only for now)
#
DISPLAYMANAGER_REMOTE_ACCESS="no"

Es schien, es reiche einfach hier "no" durch "yes" zu ersetzen. Ausprobiert, Fehlanzeige! Nach einer Weile kam mir die Idee vielleicht mal SuSEconfig zu starten. Der erzählte irgendwann

Executing /sbin/conf.d/SuSEconfig.kdm3...

Und in diesem File fand ich dann endlich

kdmdir="$r/etc/opt/kde3/share/config/kdm/"

Jetzt kamen nur noch Kleinigkeiten. Der Display Manager auf dem router sollte nicht mehr automagisch den X Server starten. Das wollte ich in einem extra Script machen, damit der Display Manager auch ohne X Server läuft. Also /etc/X11/xdm/Xservers leeren. Alternativ könnte ich dort auch die Zeile

:0 local /usr/X11R6/bin/X :0 vt07 -indirect router.local

eintragen. Dann startet jedesmal, wenn der Display Manager startet auch ein X Server. Doch halt, hatte ich nicht in /etc/sysconfig/displaymanager etwas gesehen,das auch damit zu tun haben könnte? Richtig:

#
# let the displaymanager start a local Xserver
# set to "no" for remote-access only
#
DISPLAYMANAGER_STARTS_XSERVER="yes"

Also flink auch noch das geändert, sonst macht mir SuSE sicher wieder alles kaputt beim nächsten SuSEconfig. Na ja, nachdem das Ganze auf CD gebrannt ist, kann auch ein SuSEconfig daran nichts mehr ändern.

Nun mußte alles noch schön werden. Dazu dient hauptsächlich /etc/X11/xdm/Xresources und dort im Besonderen die mit Chooser beginnenden Zeilen. Die Hintergrundfarbe wird allerdings in dem Script /etc/X11/xdm/RunChooser gesetzt (xsetroot -solid ...). Hier können auch zusätzliche Programme, wie z.B. eine Uhr oder eine sich langsam drehende Erde im Hintergrund oder sogar ein Window Manager gestartet werden. Doch Vorsicht, diese Programme laufen alle als Root.

Und voila, das ist mein router nach dem Booten.

Nach dem Booten

Noch einmal alle Dateien auf einen Blick (und einige bisher nicht erwähnte):

Nachtrag

Ursprünglich stammt der Text vom März 2003.

Aus heutiger Sicht ist hinzuzufügen, daß man auf keinen Fall mehr .local als Domainnamen nehmen sollte. Mit SuSE 9.[12] funktioniert diese Domain nicht mehr. Ich habe seitdem mehrere CD's neu gebrannt. Mal war sie kaputt, dann habe ich einen lokalen Nameservice installiert, ... Der T8000 tut aber immer noch seine Dienste als XTerminal, 7 Jahre nach seiner Anschaffung! Alle Versuche, meiner Frau ein neues Notebook zu kaufen, scheiterten: Er funktioniert doch und hat schon so lange gehalten. Da können wir ihn nicht einfach wegwerfen. Es ist ein ähnlich persönliches Verhältnis zum Notebook wie zu unserem Kater entstanden.

Anmerkung zum KDM in Suse ab 9.1

Mit Suse-Linux ab Version 9.1 als XDMCP-Server ist folgendes Verhalten zu beobachten. Das Chooser-Fenster zur Auswahl eines Rechners erscheint, man wählt einen Rechner mit Suse ab 9.1. Nach einigen Sekunden erscheint statt des Anmelde-Fensters wieder das Chooser-Fenster.

Suse versucht, die Distribution immer mehr auf die Benutzung von IPv6 umzustellen. Das verursacht gelegentlich Probleme. Nun hat es den Displaymanager getroffen. KDM lauscht nämlich nicht mehr auf dem IPv4-Port 0.0.0.0:177, sondern auf IPv6 :::177. Damit ist der Displaymanager also für IPv4-sprechende Xterminals nicht erreichbar.

Gelöst wird das Problem mit Hilfe der Datei /etc/X11/xdm/Xaccess auf dem Server. Nach Einfügen der Zeile:

LISTEN 0.0.0.0

funktionierte mein Xterminal wieder wie gewohnt.

Vielen Dank an Ulrich Hiller, der IPv6 als die Wurzel des Übels ausmachte.

Letzte Aktualisierung: 06.08.2008