Monthly Archives: August 2016

Problem mit Nvidia Treiber NVIDIA-Linux-x86_64-367.35, ssh -X und KDE/QT5-Anwendungen

Posted on by

Manchmal erlebt man mit Linux Dinge, die glaubt man erst gar nicht. Die anschließende Analyse hält einen dann vom produktiven Arbeiten ab – und das Problem entpuppt sich letztlich als eines, das durch einen neuen Treiber induziert wurde. (Nicht, dass das unter MS Win anders wäre ….) Um anderen Betroffenen ein wenig Arbeit zu sparen, deshalb hier ein kurzer Hinweis zum aktuellen Nvidia-Treiber:

Der proprietäre Treiber NVIDIA-Linux-x86_64-367.35 ist mit Vorsicht zu genießen. Er verursacht offenbar unter bestimmten Umständen Segmentation Faults – im Besonderen bei Remote-Verbindungen per “ssh -X” auf den Host, auf dem der Treiber installiert ist.

Ich schildere hier kurz die Probleme, die bei mir aufgetreten sind – siehe aber auch https://devtalk.nvidia.com/default/topic/952373/linux/367-35-driver-fedora-24-glx-segmentation-faults/.

Das Problem

Der Treiber NVIDIA-Linux-x86_64-367.35 wurde bei mir auf einem Opensuse Leap 42.1 Host installiert. Auf diesen Host muss ich manchmal von anderen Systemen aus über “ssh -X” zugreifen. Ein solcher SSH-Client ist ein Laptop mit einem Optimus-System, auf dem der Intel Driver i915 für das prozessor-interne Grafik-Device Intel HD Graphics 4000 läuft. (Die auch vorhandene Nvidia-Karte wird nur wenn nötig über Bumblebee aktiviert). Folgende Schritte führen reproduzierbar ins Nirwana:

1) Man öffnet vom Laptop eine “ssh -X”-Sitzung auf dem Opensuse Leap System.
2) In der geöffneten Shell startet man bestimmte KDE Anwendungen, die QT5 nutzen
=> segmentation fault

Wann tritt der Bug nicht auf:

  • Der Bug tritt nicht auf für KDE-Anwendungen, die QT4 verwenden.
  • Der Bug tritt nicht auf für normale simple X11-Anwendungen oder GTK-Anwendungen wie Firefox.
  • Der Bug tritt aber interessanterweise auch nicht auf, wenn ich Verbindungen von anderen Systemen mit Opensuse 13.1/13.2 oder Opensuse Leap 42.1 aufnehme, auf denen selbst (ältere) Nvidia-Treiber installiert sind. Was immer das nun bedeuten mag ….

Workaround

Der Bug tritt auch nicht auf, wenn auf dem Opensuse Leap 42.1-System der ältere Treiber NVIDIA-Linux-x86_64-361.42 installiert wird. Zwischenversionen von Nvidia-Treibern habe ich (noch) nicht getestet.

Es sieht also danach aus, dass zwischen den angegebenen Treiberversionen etwas Seltsames passiert ist. Wieder mal zeigt sich, dass man mit (proprietären) Grafikkarten-Treibern aufpassen muss – das Aktuellste ist nicht immer das Beste.

Opensuse Leap 42.1 – Problem mit direktem X11 Remote Access (ohne SSH)

Posted on by

Es gibt manchmal – wenn auch sehr selten – Situationen, da will man im LAN ohne den Einsatz von SSH den graphischen Output einer Anwendung direkt in einem Fenster auf einem anderen Linux-System – genauer auf dessen X11-Server – ausgeben.

Unter Opensuse Leap 42.1 mit KDE geht das leider nicht mehr so ohne weiteres – selbst dann nicht, wenn man per Yast2 explizit den Zugriff auf den X-Server von außen erlaubt und lokal auf dem Zielsystem z.B. “xhost +” abgesetzt hat, um den Zugriff auf das Display zu erlauben. Was ist die Ursache und wie kann man dieses Problem beheben?

Das Problem

Nehmen wir an, das System auf dem die Applikation (z.B. kate) läuft, habe die IP 192.168.2.45 und der Host auf dem der X11-Server unter OS LEAP 42.1 läuft (und auf dem der Output von kate) erscheinen soll, habe die IP 192.168.2.4. Dazu sind dann drei Voraussetzungen zu erfüllen:

  • Der X-Server auf dem LEAP-System 192.168.2.4 muss eingehende TCP-Verbindungen auf einem definierten Port (Standard: 6000) entgegen nehmen können.
  • Auf dem X-Client 192.168.2.45, auf dem die Applikation läuft, muss die Umgebungsvariable DISPLAY richtig gesetzt sein; in unserem Fall muss dort ein
    “export DISPLAY:192.168.2.4:0”
    abgesetzt werden.
  • Der User, auf dem Remote-System 192.168.2.4, der den X11-Schirm geöffnet hat, muss den Zugang zu diesem Schirm per “xhost +192.168.2.45” freigeben – oder besser, viel sicherer und userspezifisch gestaltbar: es müssen Regeln/Secrets definiert und in einem .Xauthority File hinterlegt sein, anhand derer der X-Server den Gegenpart (auf 192.168.2.45) als berechtigt einstuft (z.B. per Xauth-Mechanismus).

Nehmen wir weiter an, dass wir die letzten beiden Punkte erledigt haben. Dann kann das Problem nur noch daran liegen, dass der X-Server keine TCP-Pakete entgegennimmt. Früher (bis Opensuse 13.2) konnte man über YaST2 konfigurieren, wie der X-Server gestartet werden soll. Dazu wählte man unter

“Yast2 >> Sicherheits-Center und Systemhärtung >&gT; Sicherheitsüberblick”

den Punkt “Fernzugriff auf den X-Server” und aktivierte ihn. Das führte dann zu einem Eintrag in der “/etc/sysconfig/displaymanager” der Form

DISPLAYMANAGER_XSERVER_TCP_PORT_6000_OPEN=”yes”

Der wurde dann später beim Starten des Displamanagers ausgewertet. Wenn man das unter Opensuse Leap mit KDE macht, erfolgt der Eintrag in der “/etc/sysconfig/displaymanager” zwar auch – er bleibt aber ohne Wirkung. Ein “netstat -an | grep 6000” zeigt leider rein gar nichts.

Lösung / Workaround

Eine Analyse ergab, dass der X11-Server nach wie vor vom Display-Manager gestartet wird. Der ist bei mir nach einer Standardinstallation aber nicht mehr “KDM” sondern “SDDM”. Aber auch mit dem alten “kdm” ließ sich der X-Server bei mir nicht zum Arbeiten mit TCP bewegen. Also das Problem lieber gleich für SDDM lösen.

Nun fragte ich mich, wo “SDDM” eigentlich konfiguriert wird. Im Verzeichnis “/etc” wurde ich fündig. Dort gibt es eine Datei “/etc/sddm.conf”. Ein Blick in die zugehörige man-Seite (“man sddm.conf”) zeigt, dass es eine Option namens “ServerArguments” gibt.

Früher war es wohl so, dass ein Entfernen der Option “-no-listen tcp” aus der Konfiguration diverser Displaymanager automatisch zum Start eines X-Servers führte, der TCP-fähig war. Analog beim Start über “xinit” oder “startx”, wenn man keinen besonderen Optionen angab. Dies scheint seit X-Version 1.17 anders zu sein (s. die Links weiter unten):
Man muss dem X-Server beim Start nun explizit “-listen tcp” mitgeben.

Geht das auch mit SDDM?

Also in der /etc/sddm.conf:


[XDisplay]
DisplayCommand=/etc/X11/xdm/Xsetup
MinimumVT=7
ServerPath=/usr/bin/X
SessionCommand=/etc/X11/xdm/Xsession
#ServerArguments=-listen tcp +iglx
ServerArguments=-listen tcp

Speichern, ausloggen, X-Server an Konsole stoppen (z.B. mit init 3), X-Server neu starten (init 5) und dann Ports checken: 

mysystem:~ # netstat -an | grep 6000
tcp        0      0 0.0.0.0:6000            0.0.0.0:*               LISTEN      
tcp        0      0 :::6000                 :::*                    LISTEN

 

Ja, es funktioniert!

Nun muss man nur noch dafür sorgen, dass jedwede zwischen den Hosts installierte Firewall, wie etwa die SuSEFirewall2 den Port 6000 für den Zugriff von bestimmten IP-Adressen aus zulässt. (Bei der SuSEFirewall2 legt man am besten eine benutzerdefinierte Regel an).

Wenn man weiß, wonach man eigentlich zu suchen hat, findet man schließlich auch einen Bug bei Opensuse, der sich um das Thema dreht und dessen Kommentare einem noch ein wenig mehr mitteilen (s. den entspr. Link am Ende des Beitrags). Ich finde, trotz des Kommentars von W. Bauer von SuSE, dass YaST so modifiziert werden sollte, dass die notwendigen Einträge auch für SDDM vorgenommen werden, wenn man per YaST die Sicherheitseinstellungen für das System ändert. Oder man sollte wenigstens einen Hinweis darauf bekommen, welche Einstellungen manuell zu ändern sind. Man kann nicht erwarten, dass jeder Nutzer weiß, dass man die SDDM-Konfigurationsdatei ändern muss.

Indirektes OpenGL Rendering ?

Bei der Gelegenheit: Wenn man indirektes OpenGL-Rendern über X haben möchte, muss man zusätzlich die Option “+iglx” angeben (s. die auskommentierte Zeile oben). Der übliche Eintrag in der “/etc/X11/xorg.conf”

Section “ServerFlags”
Option “AllowIndirectGLX” “on” # or “off”
EndSection

allein scheint auch nicht mehr zu genügen.

Links

SDDM
https://wiki.archlinux.org/index.php/SDDM

Remote X
http://askubuntu.com/questions/615139/how-to-make-x-org-listen-tcp-port-to-remote-connections
https://lists.freebsd.org/pipermail/freebsd-x11/2015-October/016874.html
http://www.sbras.ru/cgi-bin/www/unix_help/man-cgi?startx
http://www.tldp.org/HOWTO/Remote-X-Apps-6.html
http://www.kai-hildebrandt.de/linux/xauth.html

YaST und X-Serverstart-Bug
https://bugzilla.opensuse.org/show_bug.cgi?id=978262

Hacking X11
http://colesec.inventedtheinternet.com/hacking-x11/

Nützliche Webseiten zur Analyse von DNS-Problemen mit gehosteten Web-Domainen

Posted on by

Gestern rief meine Frau an, die sich z.Z. bei Bekannten in Norwegen aufhält; Firefox würde eine von ihr betreute norwegische Homepage eines Kunden nicht mehr anzeigen – weder auf dem Windows-Desktop noch auf ihrem Mobil-Telefon. Bei einem Kollegen ginge es aber anstandslos. Andere Webseiten konnte sie problemlos aufrufen; nur eben nicht die Seiten der von ihr betreuten norwegischen Web-Domaine.

Das sind so Themen, die einen durchaus eine Weile beschäftigen können, da in einer solchen Situation potentiell mehrere Provider ins Spiel kommen. Da ist einerseits mal der Internet-Provider der Verwandtschaft in Norwegen; über den erhält der dortige Router in der Standardkonfiguration automatisch DNS-Server-Adressen zugewiesen. Der Kunde hingegen hatte seinen Web-Space bei einem sog. “norwegischen Web-Hotel” – also bei einem kleineren norwegischen Web-Server-Provider – gehostet. (Der Vertrag ist außerhalb von unserer Verantwortung und Beratung geschlossen worden).

Natürlich war hinter der ganzen Angelegenheit ein DNS-Problem zu vermuten. Allerdings war auch klar, dass das ein etwas ungewöhnliches Problem sein musste, da es nur domain-spezifisch auftrat. Ich beschreibe nachfolgend kurz das Vorgehen zur Analyse mit Hilfe von im Internet verfügbaren Diensten und einiger nützlicher Webseiten. Das Ergebnis war für mich zudem etwas überraschend; man lernt ja nie aus.

Zunächst ließ ich checken, welche DNS-Server dem Router in Norwegen zugeordnet waren; dann, ob diese Server überhaupt ihren Dienst taten. Letzteren Schritt konnte ich nicht von Deutschland aus mit einem der üblichen Linux-Kommandos “dig”, “host” oder dem alten “nslookup” erledigen. Grund: Der Provider verweigert den Zugriff auf seinen DNS-Server aus dem Ausland.
Also musste meine Frau die Windows-Variante von “nslookup” in der MS Windows Eingabe-Aufforderung benutzen. (Die Syntax – s. “nslookup /?” – ist sehr linux-ähnlich). Ergebnis: Die DNS-Server des Providers funktionierten zwar, konnten den Namen der Problem-Domaine aber tatsächlich nicht in eine IP-Adresse auflösen – andere Domainnamen hingegen schon.

Ein Gegentest mit verschiedenen anderen, öffentlich zugänglich DNS-Servern in Norwegen (http://public-dns.info/nameserver/no.html) ergab dann, dass einige dieser DNS-Server die Namensauflösung vornahmen, einige wenige aber nicht.

Für andere Länder findet man öffentlich zugängliche DNS-Server übrigens mit

http://public-dns.info/nameserver/LANDESKUERZEL.html

Ein ähnliches Ergebnis lieferte dann eine Stichprobe für deutsche DNS-Server: die allermeisten DNS-Server führten die Namensauflösung für die betroffene norwegische Web-Domaine durch, einige aber auch hierzulande nicht. Dadurch misstrauisch geworden, überprüfte ich als nächstes, was denn die Datenkrake Google zu der ganzen Sache meinte.

So kann man beispielsweise mal

host xyz.no 8.8.8.8 oder host xyz.no 8.8.4.4

ausführen (xyz ist natürlich durch den korrekten Domainnamen zu ersetzen). die IP-Adressen entsprechen öffentlichen DNS-Servern von Google.

Und siehe da – auch Google verweigerte die Namensauflösung mit der Meldung “SERVFAIL”; das Ergebnis erhielt ich natürlich auch über https://dns.google.com.

Interessant – aber ein Seitenaspekt – ist in einer solchen Situation auch, wie eigentlich eine Domaine nach außen im Internet erscheint, wer darauf verlinkt und ob die zugeordnete IP von mehreren anderen Web-Domainen geteilt wird. Hierzu kann man mal einen Blick auf den Web-Dienst

http://domainstats.io/

werfen und dort seinen Domainnamen eingeben (oder gleich http://domainstats.io/domainname). Man erhält dann in der Mitte der Seite mit vielen Analyse-Ergebnissen auch eine Info zur IP – und wie oft die geteilt wird.
Ein Klick auf die Zahl oder aber die Eingabe von

http://domainstats.io/IP-ADRESSE

in der HTTP-Adresszeile des Browsers liefert dann mehr und übersichtliche Informationen über die Web-Domainen zur gleichen IP-Adresse.

Für uns interessant war das Ergebnis trotz keiner direkten DNS-bezogenen Auskunft trotzdem. Denn auf diesem Wege erfuhren wir, dass die betreute Domaine (inzwischen?) auf einem US-amerikanischen Server gehostet und dass die Web-Server-IP mit 48 anderen Domainen (meist norwegische Domainen) geteilt wird. Davon wusste weder unser Kunde etwas, noch bislang wir.

Im Klartext: Der Web-Hoster in Norwegen kooperiert offenbar mit einem amerikanischen Provider – und nutzt dessen Hosting-Dienste – wohl um selbst Kosten zu sparen. Inkl. der an die Domaine angeschlossene Mail-Dienste. Ohne allerdings den Kunden über dieses Faktum zu informieren …

Off Topic: Dass in den USA ein anderer Datenschutz gehandhabt wird als in der EU ist wohl auch Norwegern inzwischen bekannt … Aber, was solls, Norwegen ist ja selbst auch nicht in der EU und sein Geheimdienst betreibt angeblich auch Supercomputeranlagen zur Dechiffrierung kryptierter Information
http://www.golem.de/news/spionage-supercomputer-soll-norwegen-beim-entschluesseln-helfen-1404-106115.html
http://www.spiegel.de/netzwelt/web/steelwinter-supercomputer-norwegens-geheimdienst-kooperiert-mit-nsa-a-966541.html
https://netzpolitik.org/2014/steelwinter-nsa-verkauft-supercomputer-an-norwegischen-geheimdienst/
Unabhängig davon gilt wohl: Augen auf bei der Provider-Wahl für Web-Hosting in Norwegen …. Man sollte sich als Betroffener vorab informieren, wo die eigenen Daten letztlich wirklich gehostet werden – und dann entscheiden, ob man das für gut hält …

Nun war es endgültig an der Zeit, sich darüber zu informieren, aus welchen Gründen es z.B. bei Google Probleme mit der Namensauflösung geben kann. Weiter half dabei die Seite
https://developers.google.com/speed/public-dns/docs/troubleshooting
Sie liefert einige nützliche Informationen und verweist auf weitere Seiten, die eine übersichtliche Analyse der DNS-Situation für eine Web-Domaine liefern können; für eine solche Analyse müsste man auch als Linuxer einigen Aufwand betreiben und sich viele Optionen der Kommandos nslookup, dig, host zu eigen machen :

http://intodns.com/

Das dortige Toolset analysiert zwar nur Haupt- und keine Sub-Domainen; das reicht ja aber in der Regel. Ich kann jedem nur raten, sich das ausführliche Ergebnis mal für die eigene Domainen anzusehen und über evtl. monierte Punkte nachzudenken und diesbzgl. auch ggf. seinen Provider zu kontaktieren.

Interessant war auch im Fall des norwegischen Hosters wieder eine Abweichung von deutschen Gepflogenheiten festzustellen – hierzulande werden zumindest bei den großen Providern die autoritativen DNS-Nameserver zu einer .de-Domaine in getrennten Netz-Segmenten und unabhängig von den Web-Servern betrieben. Eine Zusammenstellung der Anforderungen (im Jahr 2012) findet man z.B. hier
http://www.inmotionhosting.com/support/community-support/dns-nameserver-changes/nameserver-requirements-to-de-domain-name,
http://manage.resellerclub.com/kb/
answer/1132,
https://de.godaddy.com/help/about-de-domains-5825.
Der TÜV stellt im Rahmen von Firmenzertifizierungen noch weitergehende Anforderungen wie z.B. echte unabhängige Internet-Uplinks etc.. Im Falle des norwegischen (besser amerikanischen Hosters war ein Nameserver mit dem Webserver identisch. Ein zweiter lag im selben C-Segment.

In Norwegen ist übrigens die Organisation NORID für die übergeordneten Domain-Services zuständig. Allerdings erfährt man aus den “whois”-Einträgen anders als bei der DENIC nicht direkt die IP-Adressen der autoritativen Name-Server für eine Domaine. Hier helfen auf die Schnell die Informationen von intodns.com. Oder:

host -C domain-name

Es lohnt sich generell, mal die man-Seiten zu nslookup, host und dig bzgl. der möglichen Optionen zu scannen.

Im Falle unserer norwegischen Problem-Domaine spuckte intodns.com zwar einige kleinere Warnhinweise aus – nichts davon erschien mir aber die fehlende Namensauflösung erklären zu können. Aber Google weist ja freundlicherweise auch auf

http://dnsviz.net/

hin. Die dortigen DNS-Tools untersuchen die Einhaltung von DNSSEC-Standards. Es geht dabei um die Signierung von DNS-Informationen mit Hilfe kryptografischer Schlüssel und Zertifikate. Siehe für eine Kurzdarstellung:
https://de.wikipedia.org/wiki/Domain_Name_System_Security_Extensions

Eine wesentlich ausführlichere und gute Einführung liefert folgender Artikel von U. Wisse, der unter den Webseiten von Heise publiziert wurde :
http://www.heise.de/netze/artikel/Domain-Name-System-absichern-mit-DNSSEC-903318.html

Nachvollziehbare Kritik zum DNSSEC-Verfahren findet man z.B. hier:
http://www.golem.de/news/imho-dnssec-ist-gescheitert-1506-114940.html

Interessant finde ich, dass das ganze DNSSEC-System allein von US-amerikanischen Root-Zonen-Servern und der dortigen DNSSEC-Schlüssel-, genauer Zertifikats-Verwaltung abhängig ist. Als neutrale Verfikationsinstanz für die Zertifikatsechtheit fungiert wiederum ein amerikanisches Unternehmen. Das aber nur nebenbei …

Der Einführung von Hrn. Wisser entnimmt man, dass schon kleine Fehler beim Aufsetzen der DNSSEC-Informationen auf DNS-Servern, die DNSSEC unterstützen, zur Nicht-Erreichbarkeit einer Web-Domaine führen können. Das Gleiche gilt, wenn Umzüge von Domainen zu Providern stattfinden, die z.B. DNSSEC nicht unterstützen – der originale Provider aber auf seinen Servern noch DNSSEC-Einträge vorhält. Darauf weist auch die oben genannte Google-Seite hin.

Tja, was soll ich noch mehr sagen: “http://dnsviz.net/” lieferte gestern substanzielle Fehler bzgl. der verfügbaren DNSSEC Information zu unserer Problem-Domaine. Kein Wunder, dass Google und andere DNSSEC-fähige DNS-Server die Namensauflösung verweigerten. Viele andere DNS-Server prüfen DNSSEC-Information übrigens nicht – was einen Teil des obigen Befunds erklärt.

Der norwegische Hosting-Provider unseres Kunden hat inzwischen auf seinen Webseiten zugegeben, dass für einige “Konten” Fehler beim Update von DNSSEC-Informationen aufgetreten seien. Die würden behoben. Tatsächlich liefert dnsviz heute keine Fehler mehr. Der irritierte Kunde ist jetzt auch wieder glücklich – ich habe nebenbei etwas über DNSSEC gelernt – und auch darüber, wie sehr der Betrieb von DNSSEC von Amerika abhängig ist. Gelernt habe ich ferner, dass DNS-Probleme durch DNSSEC-Fehlern von Hosting-Providern verursacht sein können.

Dass Provider wiederum Provider nutzen, ist dagegen keine neue Erkenntnis. Dass Hosting-
Provider in Nicht-EU-Ländern gehostete Websites aber auf Server in ein anderes Land – hier: die USA – verschieben, ohne dass der Kunde etwas davon erfährt, war ein anderes interessantes Lehrstück. Ich hoffe, derlei ist in Deutschland unmöglich.

Ansonsten: Viel Spaß beim Anwenden der oben angegebenen Analyseseiten auf die von euch betreuten Web-Domainen.

P.S.: DNS-Analysen im Rahmen von Penetrationstests
Wer sich mehr für DNS-Analysen z.B. im Rahmen von Penetrationstests interessiert, sollte auch mal einen Blick auf folgende Seite werfen: http://resources.infosecinstitute.com/dns-hacking/
Auch “dnsrecon” und “dnsenum” sind interessante Tools, die in Penetrationstests aber mit Bedacht eingesetzt werden muss (s. https://w3dt.net/tools/dnsrecon). Brute Force-Einsätze sind zu unterlassen, wenn keine entsprechenden Einwilligungen des Netzbetreibers vorliegen.