Configurer le transfert X11 de YaST via SSH

Si YaST se ferme avec XIO: fatal IO error 11 (Resource temporarily unavailable)une erreur SSH, essayez d'abord la solution de contournement Qt documentée par SUSE : QT_XCB_GL_INTEGRATION=none yast.ssh. Pour un système SLES installé et un module YaST spécifique, utilisez la même variable avant ce module, par exemple QT_XCB_GL_INTEGRATION=none yast2 disk. Si aucune application graphique ne s'ouvre, commencez par réparer le transfert X11 : connectez-vous avec ssh -X, vérifiez que le shell distant possède une DISPLAYvaleur et assurez-vous que le transfert X11 est activé sur le serveur.

Le guide de déploiement de SLES 15 SP7 de SUSE documente précisément cette erreur XIO et propose une solution de contournement avec Qt ainsi qu'une alternative utilisant ncurses. Ce passage apparaît dans le contexte d'une installation à distance ; il convient donc de l'utiliser comme solution ciblée pour le comportement similaire de YaST via SSH. Il n'implique pas que tous les échecs de lancement de YaST aient la même cause. Les vérifications ci-dessous permettent de distinguer ce cas d'une absence de serveur X local, d'un transfert SSH désactivé ou d'un problème d'authentification X.

1. Vérifiez que le transfert X11 fonctionne avant de dépanner YaST.

Le transfert X11 redirige le trafic des fenêtres d'une application distante via SSH vers un serveur X sur votre ordinateur local. Votre machine locale doit donc avoir un serveur X actif, et le client SSH doit demander le transfert. Sur un bureau X11, ouvrez un nouveau terminal et connectez-vous comme suit :

ssh -X admin@server.example.com

Remplacez le compte et l'hôte par les vôtres. Après vous être connecté, exécutez :

echo "$DISPLAY"

Une valeur comme celle-ci localhost:10.0indique que SSH a configuré un affichage redirigé. Il s'agit d'un exemple, et non d'une valeur fixe : le numéro d'affichage peut varier. Si l'affichage est vide, déconnectez-vous et reconnectez-vous -X. S'il reste vide, consultez les paramètres SSH côté client et la configuration du serveur dans la section suivante. Ne définissez pas manuellement DISPLAYune valeur au hasard ; SSH crée un affichage proxy pour la session.

Si vous utilisez PuTTY sous Windows, activez le transfert X11 dans les paramètres de la session (Connexion > SSH > X11) et assurez-vous qu'un serveur X local est en cours d'exécution. Le guide de déploiement de SUSE mentionne cette exigence. Un hôte distant ne peut pas afficher de fenêtre si la machine locale ne dispose pas de serveur X, même si la connexion SSH réussit.

2. Vérifiez le serveur SSH SLES et l'authentification X

Sur l'hôte SLES, un administrateur peut examiner la configuration du démon SSH :

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

La politique du serveur doit autoriser le transfert X11 et xauthêtre disponible pour l'authentification. La documentation SUSE X11Forwarding Yesindique que cette politique est définie côté serveur et que SSH configure le serveur distant DISPLAYlorsqu'un client se connecte -X. Une simple commande greppeut omettre des paramètres dans les fichiers de configuration inclus ou Matchles blocs conditionnels ; si le résultat semble incohérent avec le comportement attendu, demandez à l'administrateur SSH de vérifier la configuration effective plutôt que d'ajouter des lignes en double.

Si vous modifiez sshd_configle fichier, veuillez le valider avant de recharger le démon :

sudo sshd -t
sudo systemctl reload sshd

Exécutez ces commandes uniquement avec les droits d'administrateur. Gardez votre session SSH ouverte pendant le test d'une nouvelle session afin d'éviter qu'une erreur de configuration ne vous bloque l'accès. Déconnectez-vous puis reconnectez-vous ; les paramètres de redirection sont négociés au démarrage de la session SSH. Évitez d'ouvrir le port TCP 6000 sur le serveur ou de l'utiliser xhost +comme raccourci. La redirection SSH est conçue pour encapsuler le trafic X et gérer son authentification ; un accès direct à X peut exposer l'affichage à d'autres machines.

3. Appliquer la solution de contournement Qt spécifique à YaST

Si DISPLAYcette option est activée et qu'une autre application X transférée s'ouvre, mais que YaST échoue avec l'erreur XIO ci-dessus, essayez la modification d'environnement documentée pour ce lancement :

QT_XCB_GL_INTEGRATION=none yast.ssh

Pour un système installé de manière classique, lancez le module requis plutôt que de supposer que l'assistant d'installation est présent. Par exemple, SUSE documente ce module sous la forme suivante :

QT_XCB_GL_INTEGRATION=none yast2 disk

Cette variable s'applique uniquement à la commande qui la suit ; elle ne modifie pas de façon permanente les paramètres Qt ni la politique SSH. La yast.sshcommande exacte est utilisée par SUSE pour son système d'installation, tandis qu'un hôte SLES installé lance généralement les modules YaST avec ` yast2.`. Si un autre module échoue, remplacez `.` par son nom documenté disk. Ne considérez pas ce paramètre d'environnement comme une solution pour une installation vide DISPLAYou pour un client sans serveur X.

4. Utilisez l'interface texte de YaST lorsqu'une fenêtre n'est pas nécessaire.

Si vous avez uniquement besoin d'effectuer des tâches d'administration et n'avez pas besoin d'interface graphique, utilisez l'interface ncurses de YaST dans le terminal SSH. Pour le module disque, consultez la documentation SUSE :

yast2 disk --ncurses

Vous pouvez également demander explicitement le backend ncurses pour le module :

YUI_PREFERRED_BACKEND=ncurses yast2 disk

L'interface texte évite complètement le transfert X11 et constitue souvent le choix le plus simple pour un serveur distant. Elle utilise toujours YaST et modifie la configuration système ; vérifiez attentivement les modifications apportées au disque, aux partitions, au pare-feu et au réseau avant de les confirmer. Pour les systèmes d'installation SLES, SUSE indique que YaST fournit une interface ncurses lorsqu'un serveur X local est indisponible.

Vérifier la correction

Ouvrez une nouvelle session SSH ssh -X, vérifiez que echo "$DISPLAY"le répertoire n'est pas vide, puis lancez YaST avec la commande appropriée. Si YaST s'affiche sur votre bureau ou si vous avez choisi le module ncurses, lancez-le dans le terminal. Si le transfert fonctionne correctement mais que l'erreur XIO exacte persiste après la substitution de Qt, capturez l'erreur complète du terminal et consultez les notes de version de SLES ou la base de connaissances du support SUSE pour identifier un problème spécifique à cette version. Cette procédure ne permet pas d'identifier un défaut de Qt ou de YaST à partir du seul fragment d'erreur.

Références officielles

• Guide de déploiement de SUSE Linux Enterprise Server 15 SP7 — installation à distance par SSH, exigences de transfert X, solution de contournement documentée YaST XIO et commandes ncurses.
• Guide de sécurité et de renforcement de SUSE SLES 15 SP7 : OpenSSH — transfert X11 côté serveur et applications graphiques distantes.
• Manuel OpenBSD OpenSSH ssh(1) — options client pour le transfert X11, y compris la distinction entre non fiable -Xet fiable -Y.