YaSTs X11-Weiterleitung über SSH zum Laufen bringen

Falls YaST XIO: fatal IO error 11 (Resource temporarily unavailable)über SSH mit einer Fehlermeldung beendet wird, versuchen Sie zunächst den in der SUSE-Dokumentation beschriebenen Qt-Workaround: QT_XCB_GL_INTEGRATION=none yast.ssh. Verwenden Sie für ein installiertes SLES-System und ein bestimmtes YaST-Modul dieselbe Variable vor dem Modulnamen, z. B. QT_XCB_GL_INTEGRATION=none yast2 disk. Falls sich keine grafische Anwendung öffnen lässt, reparieren Sie zuerst die X11-Weiterleitung: Stellen Sie eine Verbindung mit her ssh -X, prüfen Sie, ob die Remote-Shell einen DISPLAYWert hat, und vergewissern Sie sich, dass die X11-Weiterleitung auf dem Server aktiviert ist.

Der SUSE SLES 15 SP7 Deployment Guide dokumentiert genau diesen XIO-Fehler sowie die Qt-Problemumgehung und die ncurses-Alternative. Da die Passage im Kontext der Remote-Installation erscheint, sollte sie gezielt zur Behebung des entsprechenden YaST-over-SSH-Verhaltens verwendet werden; sie belegt jedoch nicht, dass jeder YaST-Startfehler dieselbe Ursache hat. Die folgenden Prüfungen unterscheiden diesen Fall von einem fehlenden lokalen X-Server, deaktivierter SSH-Weiterleitung oder einem X-Authentifizierungsproblem.

1. Stellen Sie sicher, dass die X11-Weiterleitung funktioniert, bevor Sie YaST debuggen.

X11-Weiterleitung sendet den Fensterverkehr einer Remote-Anwendung über SSH an einen X-Server auf Ihrem lokalen Rechner. Ihr lokaler Rechner benötigt daher einen laufenden X-Server, und der SSH-Client muss die Weiterleitung anfordern. Öffnen Sie auf einem X11-Desktop ein neues Terminal und stellen Sie die Verbindung wie folgt her:

ssh -X admin@server.example.com

Ersetzen Sie Konto und Host durch Ihre eigenen Angaben. Führen Sie nach der Anmeldung Folgendes aus:

echo "$DISPLAY"

Ein Wert wie dieser localhost:10.0zeigt an, dass SSH eine weitergeleitete Anzeige eingerichtet hat. Dies ist ein Beispiel, kein fester Wert: Die Anzeigenummer kann abweichen. Wenn die Ausgabe leer ist, melden Sie sich ab und stellen Sie die Verbindung mit dem Befehl `ssh` wieder her -X. Bleibt die Ausgabe leer, überprüfen Sie die clientseitigen SSH-Einstellungen und die Serverkonfiguration im nächsten Abschnitt. Setzen Sie den Wert nicht manuell DISPLAYauf einen beliebigen Wert; SSH erstellt eine Proxy-Anzeige für die Sitzung.

Wenn Sie PuTTY unter Windows verwenden, aktivieren Sie die X11-Weiterleitung in den Einstellungen der Sitzung unter Verbindung > SSH > X11 und stellen Sie sicher, dass ein lokaler X-Server ausgeführt wird. Die Bereitstellungsanleitung von SUSE weist ausdrücklich auf diese Anforderung hin. Ein Remote-Host kann kein Fenster anzeigen, wenn auf dem lokalen Rechner kein X-Server vorhanden ist, selbst wenn die SSH-Anmeldung erfolgreich war.

2. Überprüfen Sie den SLES-SSH-Server und die X-Authentifizierung.

Auf dem SLES-Host kann ein Administrator die Konfiguration des SSH-Daemons überprüfen:

sudo grep -i '^X11Forwarding' /etc/ssh/sshd_config
command -v xauth

Die effektive Serverrichtlinie muss X11-Weiterleitung zulassen und xauthfür die Authentifizierungsübergabe verfügbar sein. SUSE dokumentiert dies X11Forwarding Yesals serverseitige Einstellung und weist darauf hin, dass SSH den Remote-Server DISPLAYbeim Verbindungsaufbau eines Clients mit dem Server festlegt -X. Eine einfache Konfiguration grepkann Einstellungen in eingebundenen Konfigurationsdateien oder bedingten MatchBlöcken übersehen. Sollte die Ausgabe im Widerspruch zum tatsächlichen Verhalten stehen, bitten Sie den SSH-Administrator, die effektive Konfiguration zu überprüfen, anstatt doppelte Zeilen hinzuzufügen.

Wenn Sie Änderungen vornehmen sshd_config, überprüfen Sie die Datei, bevor Sie den Daemon neu laden:

sudo sshd -t
sudo systemctl reload sshd

Führen Sie diese Befehle nur mit Administratorrechten aus. Lassen Sie Ihre bestehende SSH-Sitzung während des Tests einer neuen Sitzung geöffnet, damit Sie bei einem Konfigurationsfehler nicht ausgesperrt werden. Trennen Sie anschließend die Verbindung und stellen Sie sie wieder her; die Weiterleitungseinstellungen werden beim Start der SSH-Sitzung ausgehandelt. Vermeiden Sie es, TCP-Port 6000 auf dem Server zu öffnen oder xhost +als Abkürzung zu verwenden. Die SSH-Weiterleitung dient dazu, X-Datenverkehr zu tunneln und dessen Authentifizierung zu verwalten; direkter X-Zugriff kann die Anzeige für andere Rechner zugänglich machen.

3. Wenden Sie den YaST-spezifischen Qt-Workaround an.

Wenn DISPLAYdies eingestellt ist und eine andere weitergeleitete X-Anwendung geöffnet wird, YaST jedoch mit dem oben genannten XIO-Fehler fehlschlägt, versuchen Sie, die dokumentierte Umgebungsüberschreibung für diesen einen Start zu verwenden:

QT_XCB_GL_INTEGRATION=none yast.ssh

Bei einem regulär installierten System starten Sie das benötigte Modul, anstatt davon auszugehen, dass der Installationsassistent vorhanden ist. SUSE dokumentiert dieses Modul beispielsweise wie folgt:

QT_XCB_GL_INTEGRATION=none yast2 disk

Die Variable gilt nur für den nachfolgenden Befehl; sie ändert weder Qt-Einstellungen noch die SSH-Richtlinien dauerhaft. Der yast.sshBefehl wird von SUSE für sein Installationssystem verwendet, und ein installierter SLES-Host startet YaST-Module üblicherweise mit `yast --start` yast2. Falls ein anderes Modul fehlschlägt, ersetzen Sie `yast --start` durch dessen dokumentierten Modulnamen disk. Diese Umgebungsvariable ist keine Lösung für ein leeres `yast --start`-System DISPLAYoder für einen Client ohne X-Server.

4. Verwenden Sie die Textschnittstelle von YaST, wenn kein Fenster benötigt wird.

Wenn Sie lediglich administrative Aufgaben erledigen müssen und keine grafische Benutzeroberfläche benötigen, verwenden Sie die ncurses-Oberfläche von YaST im SSH-Terminal. Für das Festplattenmodul finden Sie in der SUSE-Dokumentation Folgendes:

yast2 disk --ncurses

Sie können auch explizit das ncurses-Backend für das Modul anfordern:

YUI_PREFERRED_BACKEND=ncurses yast2 disk

Die Textschnittstelle umgeht die X11-Weiterleitung vollständig und ist oft die einfachste Wahl für einen Remote-Server. Es handelt sich weiterhin um YaST, das Systemkonfigurationen ändert; überprüfen Sie daher Änderungen an Festplatte, Partitionen, Firewall und Netzwerk sorgfältig, bevor Sie diese bestätigen. Für das SLES-Installationssystem stellt YaST laut SUSE eine ncurses-Schnittstelle bereit, wenn kein lokaler X-Server verfügbar ist.

Überprüfen Sie die Korrektur

Öffnen Sie eine neue SSH-Sitzung ssh -X, vergewissern Sie sich, dass die URL echo "$DISPLAY"nicht leer ist, und starten Sie YaST mit dem entsprechenden Befehl. Bei Erfolg erscheint das YaST-Fenster auf Ihrem Desktop oder, falls Sie dieses Backend gewählt haben, öffnet sich das ncurses-Modul im Terminal. Falls die Weiterleitung funktioniert, der XIO-Fehler aber nach der Qt-Überschreibung weiterhin besteht, erfassen Sie die vollständige Terminalfehlermeldung und prüfen Sie die SLES-Versionshinweise oder die SUSE Support Knowledgebase auf versionsspezifische Probleme. Dieses Verfahren kann anhand des Fehlerfragments allein keine unabhängigen Qt- oder YaST-Fehler identifizieren.

Offizielle Referenzen

• SUSE Linux Enterprise Server 15 SP7 Bereitstellungsleitfaden – Ferninstallation per SSH, Anforderungen an die X-Weiterleitung, der dokumentierte YaST XIO-Workaround und ncurses-Befehle.
• SUSE SLES 15 SP7 Sicherheits- und Härtungsleitfaden: OpenSSH – serverseitige X11-Weiterleitung und grafische Remote-Anwendungen.
• OpenBSD OpenSSH ssh(1) Handbuch — Clientoptionen für X11-Weiterleitung, einschließlich der Unterscheidung zwischen nicht vertrauenswürdig -Xund vertrauenswürdig -Y.