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?
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.
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.
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.
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/
