En DISPLAY/local, comment contrôlé une Debian pure distante

Salut,

Cela fait pas mal de temps que j’hésite à lancer se sujet, et pour cause!

En espérant que ce soit compréhensible pour vous … déjà le titre, hein … :unamused:

Durant ma quête sur la toile, et si j’ai bien tout compris, je résumerai le $DISPLAY par ce qui suit.

En local (chez moi).

DISPLAY (unité d’affichage) en gros: un écran, clavier et mulot en local et la bécane qui va avec, si si, :083 bon allez suffit.

Sur le distant (dédié ovh).

Un Debian pure, (pas de graphique)

Qu’est-ce que j’entends par là, me direz vous, peut être …

Ma foi, déjà d’entrée, pas de DISPLAY, ensuite (graphique ?) pas de Bureau (Kde, Gnome, Xfce, etc …)

Je crois avoir résumer la situation.

Vous l’aurez compris, je ne sais vraiment pas ce que je dois rechercher sur la toile.

Saperlipopette dit-il! C’est couillon hein, ouais surtout l’expression, pas vrai les gars, hein … Rhôoo les filles aussi hein … :005 Bon allez Suffit!

À présent ce que j’aimerai. Je vais prendre un exemple concret.

Sur le dédié, j’aimerai installé quelques VM, (chose que je ne peux faire avec ma bête de course/local) Virtualbox y est installé.

Sur le distant je (ne sais) ne peux lancer l’installation de ces VM graphiquement, bien sûr!

L’idée … Rapatrié en local ces installations!

Dites moi que c’est possible, et vers quoi dois-je m’orienter ?

A ke merci hein … :wink:

Bonjour,
exporter tout le display, via internet, d’une machine virtuelle sur un server OVH, c’est plus tordu.
Déjà assure toi que le serveur OVH accepte que tu installes de VM dessus, et que tu peux bien communiquer avec elle (liaison réseau de la VM accessible depuis le net, pas terrible niveau sécurité) …
Ensuite, si tu fais ça un peu brutalement, ça va ramer comme pas possible.
Je vois 2 solutions:

  • utiliser une solution comme VNC qui va comprimer le flux
  • utiliser ssh -X pour ne déporter qu’une seule fenêtre

Si c’est juste parceque tu n’as qu’un ordi poussif à la maison, tu peux toujours lancer ta VM dans une fenêtre graphique de 800x600, en faible résolution.

Et l’option RDP de VirtualBox ? Si je ne m’abuse elle est faite (entre autres) pour les situations headless comme tu veux faire.

Bien le bonsoir mes amis … :wink:

@piratebab

exporter tout le display, je ne suis pas sur de comprendre le tout. Je sous-entendais juste l’install, la suite se passe la-bas.(des VM à titre expérimental, simplement, pour ne pas foutre le bronx avec mes divers phases de tests, install, config, et tralala …)

À priori, les VM sur OVH ne posent pas de soucis.

Communiqué (?) Tel n’est pas mon but. Périodiquement au plus, pour les MAJ.
VNC (?) ne faut-il pas avoir de DISPLAY de part et d’autre, quoique, vu ce que tu en dis …

L’affichage déporté ne fonctionne pas chez moi, enfin je n’ai pas su.

Quant à ma bête de course, (plus que vieillissante et très mal pourvut, ram, processeur et compagnie) j’ai déjà (j’avais) chatouillé en 800x600, toutes autres applications éteintes, juste Virtualbox, une galère, et je rame et je rame …

@syam

(Cf. Phpvirtualbox, la console ne répond pas, install figé . .) c’est te dire.

[quote=“loreleil”]@syam

(Cf. Phpvirtualbox, la console ne répond pas, install figé . .) c’est te dire.[/quote]
Je connais pas du tout phpvirtualbox, donc je sais pas de quoi tu me causes… :wink:
Je verrai demain si j’arrive à monter un truc qui corresponde à ta config et je te tiens au courant de mes expérimentations.

Lu,
export-display devrais permettre cela non ?
formation-debian.via.ecp.fr/export-display.html

Salut,

@pitcat

Comme dit, cela ne fonctionne pas chez moi. J’ai passé de très nombreuses heures sur ce sujet, en quête sur la toile d’une solution, mais jusqu’à présent … :confused:

De plus, lorsque je croise (à maintes reprises) dans un Howto/Blog/Forum ce genre de mise en garde, j’ai tout naturellement tendance à prendre cela comme argent content.

Quelques exemples, vite fait en passant.

Source: tux-planet.fr/activer-lexpor … n-recente/

[quote="@Pinkilla"]le 4 avril 2012 à 13:41

A noter 3 choses importantes avec ssh -X :

  • Ca n’utilise pas les mêmes ports
  • Il n’y plus besoin de commandes xhost
  • Il ne faut surtout pas saisir une commande “export DISPLAY=xxx” une fois qu’on est connecté via ssh -X. C’est d’ailleurs pour ça en général que le transfert X ne fonctionne pas.

Perso avec ssh -X ca fait plusieurs années que je n’ai pas utilisé l’export DISPLAY

Bonne journée
Thomas [/quote]

Source: linux-kheops.com/doc/howto/MINI. … pps-6.html

[quote="@Vincent Zweije"]Trop peu de gens semble réaliser que permettre l’accès à leur unité d’affichage pose des problèmes de sécurité. Quelqu’un qui dispose d’un accès à votre unité d’affichage peut lire et écrire sur vos écrans, lire vos frappes au clavier, et suivre les déplacements de votre mulot.

La plupart des serveurs disposent de deux manières d’authentifier les demandes de connexions qui arrivent : le mécanisme de la liste d’hôtes (xhost) et le mécanisme du mot de passe secret (magic cookie) (xauth). De plus, il y a ssh, l’interpréteur de commande sécurisé, qui peut acheminer les connexions X.

Xhost permet les accès basés sur les nom d’hôtes. Le serveur entretient une liste des hôtes qui sont autorisés à se connecter à lui. Il peut aussi désactiver complètement la vérification des hôtes. Attention : cela signifie que plus aucun contrôle n’est effectué, et donc, que n’importe quel hôte peut se connecter!

Vous pouvez contrôler la liste des hôtes du serveur avec le programme xhost. Pour utiliser ce mécanisme dans l’exemple précédent, faites :

light$ xhost +dark.matt.er

Ceci permet toutes les connexions à partir de l’hôte dark.matt.er. Dès que votre client X a réalisé sa connexion et affiche une fenêtre, par sécurité, supprimez les permissions pour d’autres connexions avec :

light$ xhost -dark.matt.er

Vous pouvez désactiver la vérification des hôtes avec :

light$ xhost +

Ceci désactive la vérification des accès des hôtes et donc permet à tout le monde de se connecter. Vous ne devriez jamais faire cela sur un réseau où vous n’avez pas confiance dans tous les utilisateurs (tel internet). Vous pouvez réactiver la vérification des hôtes avec :

light$ xhost -

xhost - par lui-même ne supprime pas tous les hôtes de la liste d’accès (ce qui serait tout à fait inutile - vous ne pourriez plus vous connecter de n’importe où, pas même de votre hôte local).

Xhost est un mécanisme vraiment très peu sûr. Il ne fait pas de distinction entre les différents utilisateurs sur l’hôte à distance. De plus, les noms d’hôtes (en réalité des adresses) peuvent être manipulés. C’est mauvais si vous vous trouvez sur un réseau douteux (déjà, par exemple, avec un accès PPP téléphonique à Internet).
[/quote]
Fort est de constater qu’il n’est vraiment pas aisé de mettre en place l’export-display, suffit d’aller voir le nain du net.

Salut,

J’ai enfin réussi à déporter l’affichage. local << distant! :dance:

Prochain fil: ssh -X son lancement vous paraît-il “sécurisé” ?

J’aurai besoin de vos avis s’il vous plaît. :083

ps: je vous en serre cinq et vous remercie tous les trois … :wink: