Der X11-Desktop auf Solaris will nicht mehr

Ich habe daheim eine Sun Ultra 5 mit Solaris. Die benutze ich als Mailserver oder graphische Firewall. Wer E-Mail lesen will, muss sich per Xming auf die Kiste verbinden und dort arbeiten. Die Kommunikation macht die Sun per UUCP mit jengate.thur.de. Klappt eigentlich ganz gut. Bis zu einem Umbau an meinem häuslichen DSL-Anschluss. Danach ging nichts mehr.

Überraschung

256px-SUN-Ultra5

Was kann eine lokale Verbindung zwischen zwei Geräten nur so kaputt machen? Gewechselt wurde nur die Konfiguration des DSL-Routers, der nun auf einer anderen Leitung mit anderen Zugangsdaten laufen sollte.

Danach bliebt das Xming in einem beruhigend grauem Fenster stehen. Der Anmeldebildschrim kam und kam nicht hoch.

xming-fail

Also Wireshark angeworfen und mit geschnüffelt.

xdmcp-fail

Wie? localhost kann kein Display öffnen? Und die Nachricht kommt von der Sun?

Die ersten Tage habe ich damit zugebracht, die Konfiguration der Sun auseinander zu nehmen. Erfolglos.

Entscheidender Hinweis

Irgendwann bin ich über den rettenden Beitrag gestolpert. Wie immer kann man sich nachträglich nicht erklären, welche Suchbegriffe man immer anders hatte, um das passende Ergebnis derartig lange zu verfehlen.

Dieser Beitrag redet ausschließlich vom reverse DNS. Und was sagt die Sun dazu?

;; QUESTION SECTION:
;111.44.168.192.in-addr.arpa.   IN      PTR

;; ANSWER SECTION:
111.44.168.192.in-addr.arpa. 429 IN     PTR     localhost.

;; Query time: 5 msec
;; SERVER: 192.168.44.254#53(192.168.44.254)

Was zur Hölle? Diese DSL-Box hatte vor der Umstellung doch korrekte Antworten geliefert!

Nach längerer vergeblicher Konfiguration an der Box, versuchte ich endlich die blöde Drecksplastik zu umgehen.

Ich grab' mir also einfach den DNS Server aus den DSL-Daten und frage direkt an:

Primärer DNS:  195.50.140.248
Sekundärer DNS:  195.50.140.246

Auf geht's!

;; QUESTION SECTION:
;111.44.168.192.in-addr.arpa.   IN      PTR

;; AUTHORITY SECTION:
168.192.in-addr.arpa.   300     IN      SOA     prisoner.iana.org. hostmaster.root-servers.org. 2002040800 1800 900 604800 604800

;; Query time: 38 msec
;; SERVER: 195.50.140.248#53(195.50.140.248)

Alles bestens! Endlich ist die Fehlerquelle ausgemacht und umgangen.

Trotzdem funktioniert es weiterhin nicht.

xming-fail

Beim genaueren Hinschauen hatte ich doch beide DNS Server in die /etc/resolv.conf eingetragen. Sollte der andere?

;; QUESTION SECTION:
;111.44.168.192.in-addr.arpa.   IN      PTR

;; ANSWER SECTION:
111.44.168.192.in-addr.arpa. 600 IN     PTR     localhost.

;; Query time: 23 msec
;; SERVER: 195.50.140.246#53(195.50.140.246)

WTF? Und diese Kiste antwortet auch noch schneller?

Dann ist es ja kein Wunder, dass die Sun sich für die schnellere Antwort entschied und so daneben lag.

Einfache Lösung

Die triviale Lösung besteht darin, einfach den korrekten Namen ins /etc/hosts zu schreiben

192.168.44.111     pc.goldberg.jena.thur.de

Trotzdem bleibt Xming beim grauen Fenster.

xming-fail

Aber der Sniffer zeigt, dass ich auf dem richtigen Weg bin:

xdmcp-pc

Das DNS hat tatsächlich Einfluss auf die Meldung!

Jetzt ist auch klar, was bisher genau passiert ist:

  • Der XDMCP-Dienst auf der Sun hat einen reverse DNS gemacht
  • und diesen Namen als Ziel für die X11-Anwendungen übergeben.
  • Die Anwendung macht eine Vorwärtsauflösung dieses Namens
  • und landet auf der falschen Maschine (dort, wo kein X-Server läuft).

Aber warum steht da nicht der volle Name?

Ganz einfach: Weil die ultra die gleiche Domain benutzt und sie aus Effizienzgründen heraus kürzt.

Korrekte Lösung

Ich könnte den Hack weiter führen und noch den Kurznamen in die /etc/hosts Datei eintragen. Das ist aber nervig und fehleranfällig.

Es soll auch einfach so gehen. Also muss ich das DNS korrekt flicken. Und das geht am einfachsten, indem man einen lokalen DNS Dienst betreibt.

Erstmal etwas vor konfigurieren und dann gleich starten:

# svcadm enable svc:/network/dns/server

Jetzt wird es spannend. Wird der Xming eine Antwort bekommen?

Zumindest der lokale DNS-Client ist zufrieden, wenn auch initial etwas langsam:

;; QUESTION SECTION:
;111.44.163.192.in-addr.arpa.   IN      PTR

;; AUTHORITY SECTION:
192.in-addr.arpa.       10800   IN      SOA     z.arin.net. dns-ops.arin.net. 2016013077 1800 900 691200 10800

;; Query time: 2045 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)

Aber nun endlich die Nagelprobe!

xdmcp-ok

Hurra! Die Kommunikation tut wieder!

xming-ok
Avatar
Lutz Donnerhacke 09.06.2016 22:10
Das Gleiche passiert natürlich auch, wenn die Windows Firewall an ist und dem X-Client auf der Sun den Zugriff auf den X-Server (Xming) verbietet. Diese Firewall ist am einfachsten aktiviert, wenn das Windows nach Umbauten ein neues Netz sieht und man dieses als "öffentlich" einstuft anstatt als "Heimnetzwerk".

1 Kommentare

Post a comment

Verwandter Inhalt