jibe74
Salut,
J'essaie x2go sur fedora (et découvre Fedora depuis à peine plus d'un mois et x2go depuis 2 jours). Dans l'ensemble, ça fonctionne bien et je suis assez satisfait des performances de x2go à distance : il semble bien mériter sa réputation d'être rapide !
J'ai par contre un petit truc bizarre lorsque je veux prendre la main sur une session ouverte, en utilisant donc x2godesktopsharing : je peux bien prendre la main avec le même utilisateur sur le client que sur le serveur, mais pas avec un utilisateur différent. Or, d'après la doc ça devrait fonctionner, et d'ailleurs ça fonctionne si le serveur est un Linux Mint.
En fait, c'est un peu curieux avec les deux distribs comme serveur, parce que dans les deux cas, le comportement est le même que le partage de bureau (x2godesktopsharing) soit lancé ou non, autorisé ou interdit ! Avec Mint, si une session a été ouverte par toto, tata sur le client fedora voit toujours le display :0 et y a accès, alors que si toto ouvre une session sur un serveur fedora, tata sur le client ne voit que le display :50, et n'a jamais l'accès au bureau de toto...
L'autorisation/interdiction d'accès qui ne fonctionne pas n'a probablement rien à voir avec fedora ou Mint (bug dans x2go ?), par contre ce qui est surprenant, c'est que selon que le serveur est Mint ou Fedora, je ne vois pas le même display et que je n'ai jamais accès avec Fedora...
Des idées ?
VINDICATORs
Les réglages de ssh sont les mêmes? tu utilise l'authentification par clef ou mdp? Regarde aussi les fichiers de config de x2go si il n'y a pas des différences de réglages par défaut, ça arrive souvent.
Après je sais que selinux pose des soucis quand l'auth sort un peu du cadre de base.
jibe74
VINDICATORs wrote:Les réglages de ssh sont les mêmes?
A priori oui. Je vais quand même faire un diff pour être sûr.
VINDICATORs wrote:tu utilise l'authentification par clef ou mdp?
Pour les essais, j'ai autorisé les deux. Et du coup, je ne sais pas trop laquelle j'ai utilisée pour quoi, puisque le client x2go après une première déconnexion (la première connexion ayant été faite par clés dans mon cas) propose de se ré-authentifier par mot de passe... Je vais voir si ça change quelque chose en m'authentifiant toujours par clé.
VINDICATORs wrote:Regarde aussi les fichiers de config de x2go si il n'y a pas des différences de réglages par défaut, ça arrive souvent.
Je regarde ça après le casse-croûte. C'est vrai que j'aurais dû y penser.
VINDICATORs wrote:Après je sais que selinux pose des soucis quand l'auth sort un peu du cadre de base.
Pour ces essais effectués dans mon LAN seulement, j'ai désactivé selinux. Donc, un truc de sûrement éliminé.
Mais tu crois qu'un de ces trucs là pourrait faire que je ne voie pas le même display depuis le client ? Je rappelle que x2go fonctionne parfaitement et sans différences (au moins apparentes) que le serveur soit Mint ou Fedora. Le problème est uniquement avec le partage de bureau.
jibe74
SSH :
Il y a effectivement un tas de différences dans /etc/ssh/sshd_config entre la version Fedora et la version Mint, au point qu'il est bien difficile de s'y retrouver... ssh_config en a peu, mais comme c'est surtout sshd_config qui nous intéresse ici, du coup j'ai purement et simplement installé dans Fedora les fichiers de config Mint en croisant les doigts, puis redémarré sshd avec l'extincteur à la main okazou. Non seulement ça n'a pas fumé, mais ça fonctionne !
Par contre, comme je m'y attendais un peu, ça ne change rien au niveau de x2go.
Authentification clé/mot de passe :
J'ai fait attention de m'authentifier à chaque essai avec la clé dsa. Le comportement reste celui décrit plus haut (impossible d'avoir le bureau de toto en se loggant tata, que x2godesktopshare soit lancé ou non, et que la connexion soit autorisée ou non. A chaque fois, ça m'ouvre une session tata au lieu de me donner accès au bureau de toto. Et toujours pas de display *:0 de proposé, je n'ai que tata:50.
config x2go :
Il y a beaucoup de fichiers dans /etc/x2go ! A priori, on a les mêmes sur les deux distribs, hormis la présence dans Mint d'un script nommé xsession.sh et d'un fichier de conf xsession.conf qui ne figurent pas dans Fedora. Est-ce à cause de x2go-xsession qu'on nous fait installer dans les distribs dérivées de Debian ? Probablement... Reste à savoir pourquoi il faut ça avec Debian et pas avec Red Hat...
En tous cas, x2goserver.conf est strictement identique dans les deux distribs.
Donc, je ne suis guère plus avancé qu'avant ! Faut-il comparer tous les fichiers de /etc/x2go/ ? Hormis x2goserver.conf, je n'en ai pas vu qui semblent pouvoir être à l'origine du problème...
Ce qui m'étonne, c'est que le client x2go ne semble pas "voir" les sessions ouvertes sur le serveur Fedora, alors qu'il les voit sur le serveur Mint...
VINDICATORs
dsa est désactivé par défaut. Mieux vaudrait passer à rsa. Je sais pas si c'est lié.
Pour la différence c'est surtout que ta le manuel inclus dans les fichiers de configurations généralement chez debian. Ce qui fait que ça fait des fichiers à rallonge et que c'est indigeste.
Sans doute, je me prend la tête quand je passe de l'un à l'autre monde.
Je me demande si ça serait pas liée aux autorisations, je regarderai demain avec deux machines virtuels n'ayant pas d'autres postes physiques.
jibe74
Je persiste à douter que ça vienne de l'authentification... Mais bon, il ne faut rien négliger, et si j'ai un moment je changerai mes clés dsa par des clés rsa pour voir.
J'ai refait d'autres essais, et j'ai bel et bien un problème avec ce partage de bureau (je rappelle que l'ouverture de sessions distantes fonctionne à merveille). J'ai ouvert deux sessions toto et titi sur mes deux serveurs Mint et Fedora.
Si j'essaie de voir les bureaux Mint :
- En me loggant toto, x2go me présente deux sessions : toto:0 et toto:20. En choisissant toto:0, j'ai bien le bureau de toto. Normal. Mais en choisissant toto:20, je n'ai qu'un écran tout noir.
- En me loggant tata, x2go me présente aussi deux sessions : tata:0 et tata:20. En choisissant tata:0, j'ai le bureau de toto. Mais en choisissant tata:20, je n'ai là aussi qu'un écran tout noir.
Si j'essaie de voir les bureaux Fedora, c'est comme quand je n'ai qu'une session ouverte : x2go ne m'en présente qu'une, t*t*:50...
Je pencherais donc plutôt vers un truc que j'ai loupé à l'install de x2godesktopsharing ou dans sa config... Mais il n'y a pas trop de détails dans les docs que j'ai trouvées, ni trop de posts sur ce sujet dans les forums...
VINDICATORs
Question, tu utilise quoi comme environnement? Est ce que ça serait pas lié à wayland alors que sur mint tu dois être en xorg?
Je me pose la question, parce qu'il y a pas mal de changement avec des fonctions qui manquent encore. Est ce que ça ne jouerait pas là dessus? J'ai pas retesté depuis qqes temps, donc je peux pas voir si ça a évolué entre temps.
jibe74
Bon, j'ai essayé avec une clé rsa, c'est exactement pareil.
Wayland ? Effectivement, ça me paraîtrait plus plausible. Mais est-ce wayland pour Fedora21/Mate (installée depuis le CD du même nom) ? Je ne me suis pas trop posé la question, et j'ai plein de paquets xorg, contre seulement 6 où wayland apparaît... ps ax | grep -i wayland ne me renvoie rien, par contre j'ai des process qui font apparaître Xorg => AMHA, je n'ai pas wayland.
Donc, mon client est Fedora/Mate, et mes serveurs Fedora/Mate également et Mint/Mate (jamais pu me faire à gnome3...).
VINDICATORs
Je monte un réseau virtuel avec du F21 mate demain pour voir, car j'ai rajouté x2go sur mon CV ça craint si j'ai ce genre de souci sans savoir pourquoi :-P.
Tu peux aussi regarder du coté de rdp, repiqué du monde MS windows, mais il parait que ça fonctionne pas trop mal. Voir SPICE du coté de RedHat, mais perso je ne le maitrise pas vraiment pour le moment ayant d'autres priorités. Mais ça fonctionnait pas mal la dernière fois que j'ai testé.
jibe74
Oui, je sais : il y a des alternatives qui semblent assez intéressantes. On verra si vraiment je n'arrive pas à faire ce que je veux avec x2go et son desktop sharing. Mais en fait, je me contente de ssh depuis des années, c'est juste un peu par curiosité et avoir un petit plus pour quelques bricoles qu'il est difficile de faire autrement que par l'interface graphique. Donc, le simple fait de pouvoir ouvrir une session graphique me suffit largement pour l'instant. Après, c'est juste pour le fun et parce que j'ai du mal à accepter qu'une bécane puisse être plus têtue que moi :-D
Et puisque le sujet t'intéresse aussi, on va essayer de faire marcher ça !
Je suis comme toi, je n'aime pas trop le monde Debian et dérivées. Mais ce qui se passe avec Mint me semble intéressant à comprendre aussi : normalement, si j'ai bien compris la doc x2go, lorsque deux sessions sont ouvertes, on devrait pouvoir récupérer le bureau des deux. Je ne serais pas surpris que le fait qu'on ne puisse pas le faire soit lié avec ce que je constate sur le serveur Fedora... Si j'ai le temps, je vais essayer moi aussi de monter une VM avec CentOS ou Scientific Linux pour voir ce que ça donne.
VINDICATORs
Quand ta la bécane qui va bien c'est plaisant à mettre en place. Sauf quand tu tombe sur des problématiques à la con dans ce style. L'avantage de la virtualisation c'est que tu te monte un truc complet pour tenter de voir comment résoudre, apprendre et mettre en place des choses rapidement.
Comme je suis en plein dedans (pas qu'un peu d'ailleurs) et que j'avais apprécié x2go quand j'étais en formation pour taffer sur mon poste à distance. Mais bon pas à ce point. Donc si en plus je peux t'aider à resoudre ce défaut c'est volontier.
Vu que mes scripts pour ce que j'ai mis en place fonctionne , je vais pouvoir me remettre a ce genre de choses.
Tu constate quoi sur l'édition serveur?
jibe74
Salut,
VINDICATORs wrote:Tu constate quoi sur l'édition serveur?
Ooops ! Je crains d'avoir été un peu confus... Quand je parle de serveur, c'est le serveur x2go !
Pour mes essais, j'ai utilisé :
- Deux PCs sous Fedora21-Mate, installés à partir de l'ISO Fedora-Live-MATE_Compiz-x86_64-21-5, relativement à jour (je lance une MAJ complète au moins tous les 8-10 jours)
- Un PC installé avec l'ISO Linux Mint Maya 32 bits, relativement à jour (MAJ tous les 8-10 jours)
J'ai monté sur un des Fedora et sur le Mint le serveur x2go + x2godesktopsharing, et sur le second Fedora le client X2go.
Chaque PC a divers logiciels additionnels installés, mais rien de bien spécial sauf que tous font partie du LAN d'un serveur
SME sur lequel les utilisateurs s'authentifient via Samba. Il pourrait y avoir des conséquences pour x2go, puisque les utilisateurs s'authentifiant sur SME ne sont pas créés sur les postes. Par contre, j'ai fait quelques essais avec des utilisateurs normalement créés sur le poste, sans constater de différences. Le seul essai que je n'ai pas fait est de créer deux utilisateurs "normaux", qui ouvriraient chacun une session sur les serveurs x2go.
Le client x2go parvient à ouvrir une session que ce soit avec un utilisateur "normal" ou un utilisateur authentifié par SME.
fgland
ne connaissant pas cette utilisation de x2go, je viens de la tester entre deux postes fedora21 et je n'ai rencontré aucune difficulté à me connecter sur le display proposé : 0
Dans ton client, comme session type, tu as bien mis "connexion au bureau local" ?
Gérard
VINDICATORs
J'avais pas ce souci quand je l'utilisais non plus, mais bon j'ai pas testé depuis qqes mois perso.
Dsl, j'ai pas eu le temps de revenir là dessus ce week end préparant pas mal de choses.
Je me demande aussi si ça peut pas venir du pare feu, sachant qu'il y a des différences notables entre celui de mint et celui de fedora il me semble (iptables versus netfilter/firewalld). J'avais eu quelques galère avec lui fut une époque, ainsi que les réglages ssh avec la gestion des clefs autorisés ou non.
fgland
j'ai trouvé que cela marche pas mal mais la qualité n'est pas fameuse, les écrans n'étant pas de même taille ni même format, en mettant plein écran comme il le recommande, c'est déformé. À partir d'une taille prédéfinie qu'on peu ajuster après, c'est mieux mais assez dégradé, as-tu remarqué cela ?
Je voudrais ajouter cette fonctionnalité dans le wiki mais il faudra que je précise cette pêrte de qualité si elle est réelle.
Gérard
VINDICATORs
Cela dépend surtout de la connexion en upload. En local/virtualisé ça tourne pas mal, à distance par contre... Après si ta du débit tu peux augmenter la qualité de compression, car ça compresse en jpeg et donc normal que ça dégrade 😉.
Après le but n'est pas d'avoir du 100% fidèle, car de toute manière tu perd l'accélération matériels 3D par exemple. Perso je lancé les mises à jours, pour la gestion de mon réseau virtualisé (16 machines en tout... Serveurs/Clients inclus), des tests que les machines que j'avais à disposition à la formation n'étaient pas assez puissantes pour les lancer (bah oui passer d'un petit penthium 2 cœurs 8Go à un I7 4coeurs/8 threads 16Go ça ce sent :-P). Cela fonctionné très bien, sauf que l'affichage était dégradé à cause des 200ko/s, voir 380ko/s d'envois et les 4Mb/s au centre de formation. Sans compter le cryptage 2048bits qui pompe un peu plus.
jibe74
Salut,
Pas eu le temps non plus de me re-pencher sur la question, et je vais être assez pris pendant quelques jours...
fgland wrote:ne connaissant pas cette utilisation de x2go, je viens de la tester entre deux postes fedora21 et je n'ai rencontré aucune difficulté à me connecter sur le display proposé : 0
Ça aurait tendance à confirmer le bug dans l'ICC que je soupçonne, mais pas moyen de le trouver... Quand je re-ferai des essais, je noterai bien tout précisément : je dois louper une étape quelque part, pourtant ça parait on ne peut plus simple...
fgland wrote:Dans ton client, comme session type, tu as bien mis "connexion au bureau local" ?
Toutafé. D'ailleurs, si on met autre chose, ça ouvre une nouvelle session dans tous les cas.
VINDICATORs wrote:Je me demande aussi si ça peut pas venir du pare feu
Je m'assurerai de ne pas l'avoir oublié parfois, mais normalement j'ai dû faire les essais en le désactivant momentanément.
VINDICATORs wrote:ainsi que les réglages ssh avec la gestion des clefs autorisés ou non.
Tu es revenu plusieurs fois sur ce point. Peux-tu préciser quels étaient les effets ?
Perso, je ne vois aucune différence que je m'authentifie par clés ou par mot de passe, et je comprends mal en quoi ça pourrait influer une fois qu'on est connecté ? SSH établit le tunnel ou le refuse, mais une fois qu'il est établi, il laisse passer tout ce qu'on y envoie sans rien modifier ou filtrer, non ?
fgland wrote:en mettant plein écran comme il le recommande, c'est déformé. À partir d'une taille prédéfinie qu'on peu ajuster après, c'est mieux mais assez dégradé
Oui, il adapte en déformant pour remplir au mieux l'écran du client. J'ai trouvé ça assez sympa : je n'aime pas trop les "ascenseurs" (=scroll bars) que mettent certains autres systèmes de partage de bureau, quand l'écran du serveur est trop grand par rapport à celui du client. Mais bon, c'est une question de goût, et on ne peut pas avoir le beurre (l'écran serveur qui tient entièrement dans celui du client dans tous les cas) et l'argent du beurre (affichage sans déformation). Quant à la dégradation, comme le dit VINDICATORs, c'est dû à la compression, qui permet d'avoir un affichage plus rapide. J'ai vu que ça se règle (mais je ne sais pas si on peut faire en sorte de ne rien perdre en qualité : pas testé). En ce qui me concerne, je trouve que le réglage par défaut est très correct. Mais c'est sûr que si tu veux faire à distance du dessin de haute précision, ça n'ira pas !
VINDICATORs
Je réceptionne mon nouvel écran demain, je suis pas trop à l'aise sur mon bureau que j'ai ici à Toulouse. Les deux écrans ne sont pas bien placé, ils ce chevauchent, pour pouvoir tout mettre en place et j'ai du mal sur 1 seul en 19" pour avoir les affichages des deux machines en plein ecran. Ce bureau manque de profondeur, donc je me retrouve en biais.
Ça ira mieux j'espère avec le 27". Là je me tue les yeux placé comme c'est.
Sinon il me semble qu'il faut bien regler le sshd_config, mais commz je l'ai dit ça doit faire 6 mois que j'ai pas retouche, car je me bloquer les accès à cause de mauvais reglages et de l'acceptation des clef autorisées dans les .ssh/authorisedkey (dsl pour le nom si c'est pas le bon, je corrige tout à l'heure).
D'ailleurs faudrait refaire la doc sur fail2ban elle est incomplète. Pour la sécurité, car rien que d'avoir ssh ouvert à distance même sur un port différents il y a des tentatives d'intrusion permanente. Dsl du hors sujet.
Faudrait aussi revoir celle sur ssh, pas mal de choses obsolète et d'autres utiles mais manquantes.
fgland
jibe74 wrote:Salut,
fgland wrote:en mettant plein écran comme il le recommande, c'est déformé. À partir d'une taille prédéfinie qu'on peu ajuster après, c'est mieux mais assez dégradé
Oui, il adapte en déformant pour remplir au mieux l'écran du client. J'ai trouvé ça assez sympa : je n'aime pas trop les "ascenseurs" (=scroll bars) que mettent certains autres systèmes de partage de bureau, quand l'écran du serveur est trop grand par rapport à celui du client. Mais bon, c'est une question de goût, et on ne peut pas avoir le beurre (l'écran serveur qui tient entièrement dans celui du client dans tous les cas) et l'argent du beurre (affichage sans déformation). Quant à la dégradation, comme le dit VINDICATORs, c'est dû à la compression, qui permet d'avoir un affichage plus rapide. J'ai vu que ça se règle (mais je ne sais pas si on peut faire en sorte de ne rien perdre en qualité : pas testé). En ce qui me concerne, je trouve que le réglage par défaut est très correct. Mais c'est sûr que si tu veux faire à distance du dessin de haute précision, ça n'ira pas !
en fait je comparais avec ce qu'on obtient avec une nouvelle session mais il n'y a pas de comparaison possible, ce sont deux modes très différents.
je n'ai pas bien compris ta description entre les toto, titi et tata.
Quand tu parles "des bureaux de mint" ce sont des sessions réelles ouvertes en même temps sur mint ?
même chose sur Fedora ?
mes essais n'ont porté que sur une session
Gérard
VINDICATORs
A ce que je me souvient aussi, c'est que c'est pas trop fait pour la prise en main à distance. Plus du xssh.
Faudrait que j'étudie cela.