Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Linux Autres OS Linux Accès Í  distance

Accès Í  distance

20 réponses
Avatar
Marc SCHAEFER
Bonjour,

1) Pour l'accès Í  distance Í  un système GNU/Linux, le plus simple est le
mode texte avec SSH. Toutefois, parfois on a besoin de lancer UNE
application en mode graphique, avec ssh -X.

2) Et dans d'autres cas, on veut utiliser un système GNU/Linux complet, en
mode graphique, depuis une machine Linux ou non.

3) Enfin, parfois on veut simplement accéder Í  l'écran, voire interagir
avec une interface graphique existante.

Pour 1), les solutions sont claires. Pour 2), j'aime bien x2go:
toutefois, avec certains programmes, on ne peut pas être loggué plus
d'une fois ou alors il faut faire des contorsions (profils de Firefox
par exemple). x2go permet aussi de partager une session Í  plusieurs si
nécessaire. Et comme c'est du X11, c'est efficace et joli Í  la fois (pas
d'effet de pixellisation comme avec VNC). x2go permet de partager le
son, les fichiers et l'impression, et c'est assez facile Í  installer
avec Debian. On peut aussi faire quelque qui ressemble Í  ça, sans le
son, sans l'impression et sans le partage de fichirs, avec VNC
(X(tight)vncserver), Í  la main et pour une nouvelle session.

Pour 3), il y a longtemps, j'avais expérimenté avec un serveur X ou un
session-manager qui exportait une interface VNC et permettait de se
connecter Í  une session ouverte.

Est-ce que 3) fonctionne toujours avec les distributions modernes (p.ex.
Debian buster avec MATE) ? Avez-vous des expériences ? Ou faut-il
utiliser plutÍ´t GNOME ?
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2
Avatar
Marc SCHAEFER
Eric Demeester wrote:
De mon point de vue, souple, opensource, légère, « clientless », c'est
LA solution d'accès distant d'avenir, et je suis étonné qu'elle soit si
peu utilisée.

Je suppose que contrairement Í  x2go il n'y ni partage de fichiers ni
impression; mais y-a-t-il le son?
(je fais du montage vidéo Í  distance avec x2go)
Avatar
Eric Demeester
Bonjour,
Marc SCHAEFER (Thu, 25 Feb 2021 13:49:53 -0000 (UTC) -
fr.comp.os.linux.configuration) :
[Guacamole]
Je suppose que contrairement Í  x2go il n'y ni partage de fichiers ni
impression; mais y-a-t-il le son?

Je ne connais pas x2go, donc je manque de points de comparaison.
Il faut bien comprendre que Guacamole permet de se connecter Í  distance
sur une machine puis d'y faire ce qu'on vaut comme si on était en local.
Ni plus ni moins.
Donc, Í  ma connaissane (mais je n'ai pas creusé la question, je ne suis
qu'un utilisateur occasionnel de la chose) pas de transmission ou de
partage de fichiers comme avec VNC ou Teamviewer, on peut en revanche
lancer un logiciel FTP ou autre des deux cÍ´tés pour échanger des
fichiers.
Pour ce qui est de l'impression, elle ne dépend pas de Guacamole mais du
système client distant. Pour reprendre l'exemple de notre serveur
Windows accessible Í  la fois via le bureau Í  distance de Windows et via
Guacamole, il est configuré de manière Í  permettre aux clients
d'imprimer les divers états proposés dans notre logiciel.
Cela nécessite souvent l'installation de pilotes d'imprimantes
spécifiques en fonction de celles dont dispose le client, mais le plus
souvent ça se passe bien.
Le son ? Je viens de me connecter via Guacamole sur notre serveur
Windows 2016, de lancer Firefox, de choisir une chanson au hasard sur
Youtube, et... Pas de son.
Pas mieux via la connexion RPC au bureau distant, donc non, il n'y a pas
le son, mais je ne sais pas si c'est dÍ» Í  Guacamole ou Í  un autre
facteur.
Avatar
Eric Masson
Eric Demeester writes:
'Re,
Il faut bien comprendre que Guacamole permet de se connecter Í  distance
sur une machine puis d'y faire ce qu'on vaut comme si on était en local.
Ni plus ni moins.

Selon la doc
https://guacamole.apache.org/doc/gug/configuring-guacamole.html
"
Device redirection
Device redirection refers to the use of non-display devices over RDP.
Guacamole's RDP support currently allows redirection of audio, printing,
and disk access, some of which require additional configuration in order
to function properly.
Audio redirection will be enabled by default. If Guacamole was correctly
installed, and audio redirection is supported by your RDP server, sound
should play within remote connections without manual intervention.
Printing requires GhostScript to be installed on the Guacamole server,
and allows users to print arbitrary documents directly to PDF. When
documents are printed to the redirected printer, the user will receive a
PDF of that document within their web browser.
Guacamole provides support for file transfer over RDP by emulating a
virtual disk drive. This drive will persist on the Guacamole server,
confined within the drive path specified. If drive redirection is
enabled on a Guacamole SSH connection, users will be able to upload and
download files as described in Chapter 16, Using Guacamole.
"
Donc probablement de la configuration Í  voir coté serveur, cela vaut
peut-être le coÍ»t de regarder du coté des images Docker du projet afin
de se faire une idée sur une configuration "officielle" :
https://hub.docker.com/r/guacamole/guacamole
--
J'aimerais bien les plans de la lampe !
Que feront les générations futures avec tous nos CD ?
Des pieds de table peut-être ? Avec des plateaux en disquettes ???
-+- CH in Guide du Macounet Pervers : CDs MacWorld FR: Enfin utiles! -+-
Avatar
Marc SCHAEFER
zeLittle wrote:
- j?ouvre une session-login, au lancement du poste, en tant que root

ah bon? je ne ferais jamais ça.
par contre, je n'ai pas d'idées précises sur comment débugger un fichier
Desktop, sinon qu'on peut y lancer un script bash, rediriger la sortie
d'erreur et voir.
ça pourrait être tout bonnement un problème de PATH
Avatar
G̓©rald Niel
Le Mercredi 24 février 2021 Í  19:54 UTC, Marc SCHAEFER écrivait sur
fr.comp.os.linux.configuration :
2) Et dans d'autres cas, on veut utiliser un système GNU/Linux complet, en
mode graphique, depuis une machine Linux ou non.

J'utilise RealVNC pour ça.
Client et serveur.
J'ai aussi installé le serveur RealVNC sur mon macOS.
Le compte gratuit permet de référencer jusque 5 machine dans le
«Â cloud » sans avoir besoin de faire du VNC over SSH.
Quand les machines ne sont pas sur le même réseau. Sinon c'est
illimité.
C'est le serveur/client VNC qui rend le mieux, sans pixelisation, avec
le vrai pointeur, sans latence, et redimensionnément Í  la taille de la
fenêtre.
Pour l'installer sur une Ubunutu 20.10 arch64 (sur un RPI) :
gemini://home.gegeweb.org/rpi/rpi_ubuntu_realvnc.gmi
@+
--
On ne le dira jamais assez, l'anarchisme, c'est l'ordre sans le
gouvernement ; c'est la paix sans la violence. C'est le contraire
précisément de tout ce qu'on lui reproche, soit par ignorance, soit
par mauvaise foi. -+- Hem Day -+-
Avatar
zeLittle
zeLittle wrote:
- j?ouvre une session-login, au lancement du poste, en tant que root

ah bon? je ne ferais jamais ça.

J'ai le problème décrit aussi quand j'ouvre une session avec un user normal,
qui a un /home. Donc, je commence en voulant résoudre avec un user qui a les
droits les plus permissifs: root.
par contre, je n'ai pas d'idées précises sur comment débugger un fichier
Desktop, sinon qu'on peut y lancer un script bash, rediriger la sortie
d'erreur et voir.

Oui, je cerne mon problème Í  comment faire causer la couche X11. J'imagine
que même si c'est un problème de droits (ACL de fichiers ou répertoires, ou
ACL du serveur X11 vis Í  vis d'un user physique ou système), il doit bien
exister un moyen d'étaler, de dumper ça quelque part de façon verbeuse.
ça pourrait être tout bonnement un problème de PATH

Non, le PATH n'a pas Í  intervenir: le champ exec du fichier .desktop
(Exec=/opt/ze_appli/usr/bin/ze_appli.elf) est un full pathname menant de
bout en bout, de façon absolue au fichier *.elf Í  lancer. C'est du direct
"live": pas besoin du PATH, ou d'un loader intermédiaire quelconque.
Avatar
Nicolas
Marc SCHAEFER wrote:
1) Pour l'accès Í  distance Í  un système GNU/Linux, le plus simple est le
mode texte avec SSH. Toutefois, parfois on a besoin de lancer UNE
application en mode graphique, avec ssh -X.
2) Et dans d'autres cas, on veut utiliser un système GNU/Linux complet, en
mode graphique, depuis une machine Linux ou non.
3) Enfin, parfois on veut simplement accéder Í  l'écran, voire interagir
avec une interface graphique existante.

Sur les machines Debian de mon boulot, on utilise xrdp et xfce. Ca
fonctionne très bien. A noter que la majorité du temps les connexions
RDP vers ces machines se font depuis des postes/serveurs sous Windows,
mais je ne sais pas si cela change quelquechose.
--
Nicolas
Avatar
zeLittle
Pour info., le débogage d'un .desktop qui lance une application visuelle se
fait mieux déjÍ  en disant que le .desktop lance une application depuis le
terminal (il faut donc mettre la ligne Terminal=true), puis faire un cd
/opt/ze_appli/usr/bin et lancer dans un terminal avec bash
./ze_appli.elf.
Maintenant, une fois tout corrigé ce qui apparait en erreur dans le
terminal, une persistance de problèmes d'IHM-GUI montre que la petite
application "Í  2 centimes" que j'essaie d'installer Í  un problème de
conception quelque part. La couche X est une API et aussi un protocole en
fait. Elle peut se déboguer:
- https://www.x.org/wiki/Development/Documentation/ServerDebugging/ (Debian
et dérivés)
- https://wiki.ubuntu.com/X/Backtracing (Ubuntu incorpore un outil déjÍ 
prêt)
Avatar
David Larochette
Le 25/02/2021 Í  12:17, Marc SCHAEFER a écrit :
Nicolas George <nicolas$ wrote:
Je te conseille d'essayer «Â xpra shadow », qui est plus efficace que VNC.

Intéressant, merci. Mais c'est du X11, donc pas de compatibilité sur OS
non standard,

Xpra peut servir sur X11, MacOS et Windows, les mêmes OS peuvent être
client ainsi qu'Android et n'importe quel navigateur html5.
un peu Í  la x2go (x2go utilise-t-il lbx ou Xpra?)

X2Go et Xpra sont tous les deux des forks de FreeNX (devenu propiétaire).
Avatar
dyrmak
En 44 lignes dyrmak a écrit
dans news:
le mercredi, 24 février 2021 Í  22:13:31 :
Dans la machine distante ( supposée derrière firewall sans serveur
ssh ) il faut effectivement lancer x11vnc et autoriser cette machine
distante Í  créer le tunnel inversé vers notre machine (serveur ssh)
et avec le vinagre, installé sur le serveur ssh ou une autre machine
de notre réseau local le connecter au port correspondant du tunnel:
Tout ça est le principe, mais je vais chercher le script que je donne
Í  la machine distante pour qu'elle lance la procédure de son coté et
que son écran apparaisse sur une machine du lan ou sur le serveur ssh.

..... Mon script ne fait pas le poids devant tous ces
logiciels de bonne facture ....
Mais l'idée derrière c'est qu'il ne faut pas appeler
directement un client v-n-c pour après aller chercher lire
un man de l'application ou faire une recherche pour pouvoir
enfin s'en servir...
v c'est la machine cliente, vis-Í -vis de
la machine c distante, Í  ce stade, c
n'est pas un serveur v-n-c, et n est, lui,
un serveur ssh, accessible pour v et pour c
On lance dans v un script :
Alors voilÍ , le script de l'agent v doit pouvoir valider l'agent n
et créer un script pour l'agent c:
le script de l'agent c doit contenir une partie "sèche" :
un script de code avec des $1 $2 $4 ( variables de bash )
et une partie "mouillée" : les données pour pigeon voyageur
.... Et ce n'est qu'après cela que le client v-n-c
devra s'afficher Í  l'écran, avant j'avais vncviewer
Et il ne faut plus attendre pour livrer la
partie sèche et la partie mouillée du script
au bof ou la s½ur de la tante.
... Et si on en reste lÍ , préparez le mot de passe vnc
généré eventuellement pour l'agent c
vncviewer localhost:port
Le script de l'agent v et le script de l'agent c
vont devoir créer des tunnels et surtout gérer leur
destruction, sinon les deux systèmes deviendraient
des gruyères inutilisables, par exemple, dans le script
de l'agent c on a :
ssh -S /tmp/.ssh-$3 -O exit $3
Dans le script de l'agent v on a une expression similaire:
ssh -S /tmp/.ssh-$tunnel_server -O exit $tunnel_server
Le schéma de principe que vncviewer savait gérer est:
V ---------> N ---------> C
donc il faut un tunnel direct ( type L dans le script v)
et un tunnel inversé (type R dans le script c)
Mais les versions récentes de vinagre savent gérer aussi
les connexions inversées, un peu comme les serveurs ftp passif
et actif, dans ce cas, pour les connexions inversées
le schéma de principe est:
V <--------- N <---------- C
donc il faut un tunnel inversé dans le script v et
un tunnel direct dans le script c
Pour créer le scripts v et c il faut choisir UN schéma de
principe et oublier l'autre, ne plus jamais y penser non
non et non ne plus jamais y penser plus jamais
plus jamais plus jamais.... De sorte que vous allez
configurer d'une fois pour toutes vinagre et
ne plus jamais y toucher ....
Un problème que j'avais rencontré lors de la création des
scripts c'est qu'on n'arrive pas Í  récupérer le pid du
ssh et même en utilisant l'option socket
il fallait prouver l'existence de la connexion avec -S et
pas avec -f, on peut s'arracher quelques cheveux c'est garanti !
dyrmak
--
La duda que hace avanzar
++++ --- ++++
Linux operating system
++++ --- ++++
1 2