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
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.
Also Wireshark angeworfen und mit geschnüffelt.
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.
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.
Aber der Sniffer zeigt, dass ich auf dem richtigen Weg bin:
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!
Hurra! Die Kommunikation tut wieder!
1 Kommentare