X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 2 (X_ChangeWindowAttributes)
Resource id in failed request: 0x1a5
Serial number of failed request: 55
Current serial number in output stream: 56
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 2 (X_ChangeWindowAttributes)
Resource id in failed request: 0x1a5
Serial number of failed request: 55
Current serial number in output stream: 56
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 2 (X_ChangeWindowAttributes)
Resource id in failed request: 0x1a5
Serial number of failed request: 55
Current serial number in output stream: 56
On 2007-02-02 15:49:28 +0100, Bayrouni wrote:X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 2 (X_ChangeWindowAttributes)
Resource id in failed request: 0x1a5
Serial number of failed request: 55
Current serial number in output stream: 56
Essaie avec le trusted forwarding. Sans cela, il y a un certain
nombre d'applications qui plantent avec une erreur similaire à
celle ci-dessus. Tu peux utiliser soit "ssh -Y" (au lieu de -X)
ou mettre la ligne "ForwardX11Trusted yes" dans ton ".ssh/config".
On 2007-02-02 15:49:28 +0100, Bayrouni wrote:
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 2 (X_ChangeWindowAttributes)
Resource id in failed request: 0x1a5
Serial number of failed request: 55
Current serial number in output stream: 56
Essaie avec le trusted forwarding. Sans cela, il y a un certain
nombre d'applications qui plantent avec une erreur similaire à
celle ci-dessus. Tu peux utiliser soit "ssh -Y" (au lieu de -X)
ou mettre la ligne "ForwardX11Trusted yes" dans ton ".ssh/config".
On 2007-02-02 15:49:28 +0100, Bayrouni wrote:X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 2 (X_ChangeWindowAttributes)
Resource id in failed request: 0x1a5
Serial number of failed request: 55
Current serial number in output stream: 56
Essaie avec le trusted forwarding. Sans cela, il y a un certain
nombre d'applications qui plantent avec une erreur similaire à
celle ci-dessus. Tu peux utiliser soit "ssh -Y" (au lieu de -X)
ou mettre la ligne "ForwardX11Trusted yes" dans ton ".ssh/config".
Comme quoi l'affichage X via ssh n'est pas encore tout à fait au point
je pense.
Comme quoi l'affichage X via ssh n'est pas encore tout à fait au point
je pense.
Comme quoi l'affichage X via ssh n'est pas encore tout à fait au point
je pense.
On 2007-02-04 17:37:34 +0100, Bayrouni wrote:Comme quoi l'affichage X via ssh n'est pas encore tout à fait au point
je pense.
AMHA, le problème est peut-être que xawtv utilise une fonctionnalité
non X, qui ne marche donc pas à distance. Ou alors, sans dga, c'est
peut-être juste trop lent pour fonctionner à distance.
On 2007-02-04 17:37:34 +0100, Bayrouni wrote:
Comme quoi l'affichage X via ssh n'est pas encore tout à fait au point
je pense.
AMHA, le problème est peut-être que xawtv utilise une fonctionnalité
non X, qui ne marche donc pas à distance. Ou alors, sans dga, c'est
peut-être juste trop lent pour fonctionner à distance.
On 2007-02-04 17:37:34 +0100, Bayrouni wrote:Comme quoi l'affichage X via ssh n'est pas encore tout à fait au point
je pense.
AMHA, le problème est peut-être que xawtv utilise une fonctionnalité
non X, qui ne marche donc pas à distance. Ou alors, sans dga, c'est
peut-être juste trop lent pour fonctionner à distance.
J'ai regardé de près le fichier de configuration sshd_config.
Entre autres il y a dedans ces options concernant l'export de l'affichage X.
X11Forwarding yes
X11DisplayOffset 10
Mais il y avait aussi X11UseLocalhost no.
Je ne la connaissait pas du tout cette option.
Je l'ai remise à yes et là après plus essais, xawtv s'est toujours
lancé avec succès avec xawtv -nodga.
J'en conclut que le problème venait de là
et que cette option permet (optionnellement d'exporter l'affichage
en local c'est à dire la machine serveur X et non pas la machine
distante cliente X.
Voici un warning de ssh quand je lance xawtv:
WARNING: remote display `localhost:11.0' not allowed, using `:11.0' instead.
Et sauf erreur de ma part c'est exactement ce que l'on attend de ssh
pour l'export de l'affichage .
J'ai regardé de près le fichier de configuration sshd_config.
Entre autres il y a dedans ces options concernant l'export de l'affichage X.
X11Forwarding yes
X11DisplayOffset 10
Mais il y avait aussi X11UseLocalhost no.
Je ne la connaissait pas du tout cette option.
Je l'ai remise à yes et là après plus essais, xawtv s'est toujours
lancé avec succès avec xawtv -nodga.
J'en conclut que le problème venait de là
et que cette option permet (optionnellement d'exporter l'affichage
en local c'est à dire la machine serveur X et non pas la machine
distante cliente X.
Voici un warning de ssh quand je lance xawtv:
WARNING: remote display `localhost:11.0' not allowed, using `:11.0' instead.
Et sauf erreur de ma part c'est exactement ce que l'on attend de ssh
pour l'export de l'affichage .
J'ai regardé de près le fichier de configuration sshd_config.
Entre autres il y a dedans ces options concernant l'export de l'affichage X.
X11Forwarding yes
X11DisplayOffset 10
Mais il y avait aussi X11UseLocalhost no.
Je ne la connaissait pas du tout cette option.
Je l'ai remise à yes et là après plus essais, xawtv s'est toujours
lancé avec succès avec xawtv -nodga.
J'en conclut que le problème venait de là
et que cette option permet (optionnellement d'exporter l'affichage
en local c'est à dire la machine serveur X et non pas la machine
distante cliente X.
Voici un warning de ssh quand je lance xawtv:
WARNING: remote display `localhost:11.0' not allowed, using `:11.0' instead.
Et sauf erreur de ma part c'est exactement ce que l'on attend de ssh
pour l'export de l'affichage .
On 2007-02-06 18:22:35 +0100, Bayrouni wrote:J'ai regardé de près le fichier de configuration sshd_config.
Entre autres il y a dedans ces options concernant l'export de l'affichage X.
X11Forwarding yes
X11DisplayOffset 10
Mais il y avait aussi X11UseLocalhost no.
Je ne la connaissait pas du tout cette option.
Je l'ai remise à yes et là après plus essais, xawtv s'est toujours
lancé avec succès avec xawtv -nodga.
J'en conclut que le problème venait de là
Peut-être. Je n'ai "X11UseLocalhost no" nulle part dans mes config,
et la valeur par défaut est "yes".
? Je rappelle qu'en temps normal, toutes les connexions doivent être
locales à la machine où tournent les clients: un client X se connecte
localement sur le proxy (c'est ensuite forwardé vers le serveur X,
mais ça, le client X n'est pas censé le voir).
Si je comprends bien la page man, si la valeur est "yes", seules les
connexions de localhost sont acceptées. Mais ça veut dire aussi que
toutes les connexions locales ne sont pas acceptées, parce qu'on peut
faire aussi d'autres types de connexion locale, e.g. via l'interface
de la carte Ethernet.Voici un warning de ssh quand je lance xawtv:
WARNING: remote display `localhost:11.0' not allowed, using `:11.0' instead.
D'après la page man de X, :11.0 permet d'avoir un transport local
plus efficace; je ne sais pas si c'est toujours le cas, mais c'est
peut-être pour cela que xawtv l'utilise. J'avais aussi remarqué
que quand on utilise une telle forme, le FQDN de la machine est
pris en compte. Ceci dit, avec ce warning, c'est tout de même
bizarre que "X11UseLocalhost yes" résolve quelque chose, puisqu'il
est plus restrictif.
On 2007-02-06 18:22:35 +0100, Bayrouni wrote:
J'ai regardé de près le fichier de configuration sshd_config.
Entre autres il y a dedans ces options concernant l'export de l'affichage X.
X11Forwarding yes
X11DisplayOffset 10
Mais il y avait aussi X11UseLocalhost no.
Je ne la connaissait pas du tout cette option.
Je l'ai remise à yes et là après plus essais, xawtv s'est toujours
lancé avec succès avec xawtv -nodga.
J'en conclut que le problème venait de là
Peut-être. Je n'ai "X11UseLocalhost no" nulle part dans mes config,
et la valeur par défaut est "yes".
? Je rappelle qu'en temps normal, toutes les connexions doivent être
locales à la machine où tournent les clients: un client X se connecte
localement sur le proxy (c'est ensuite forwardé vers le serveur X,
mais ça, le client X n'est pas censé le voir).
Si je comprends bien la page man, si la valeur est "yes", seules les
connexions de localhost sont acceptées. Mais ça veut dire aussi que
toutes les connexions locales ne sont pas acceptées, parce qu'on peut
faire aussi d'autres types de connexion locale, e.g. via l'interface
de la carte Ethernet.
Voici un warning de ssh quand je lance xawtv:
WARNING: remote display `localhost:11.0' not allowed, using `:11.0' instead.
D'après la page man de X, :11.0 permet d'avoir un transport local
plus efficace; je ne sais pas si c'est toujours le cas, mais c'est
peut-être pour cela que xawtv l'utilise. J'avais aussi remarqué
que quand on utilise une telle forme, le FQDN de la machine est
pris en compte. Ceci dit, avec ce warning, c'est tout de même
bizarre que "X11UseLocalhost yes" résolve quelque chose, puisqu'il
est plus restrictif.
On 2007-02-06 18:22:35 +0100, Bayrouni wrote:J'ai regardé de près le fichier de configuration sshd_config.
Entre autres il y a dedans ces options concernant l'export de l'affichage X.
X11Forwarding yes
X11DisplayOffset 10
Mais il y avait aussi X11UseLocalhost no.
Je ne la connaissait pas du tout cette option.
Je l'ai remise à yes et là après plus essais, xawtv s'est toujours
lancé avec succès avec xawtv -nodga.
J'en conclut que le problème venait de là
Peut-être. Je n'ai "X11UseLocalhost no" nulle part dans mes config,
et la valeur par défaut est "yes".
? Je rappelle qu'en temps normal, toutes les connexions doivent être
locales à la machine où tournent les clients: un client X se connecte
localement sur le proxy (c'est ensuite forwardé vers le serveur X,
mais ça, le client X n'est pas censé le voir).
Si je comprends bien la page man, si la valeur est "yes", seules les
connexions de localhost sont acceptées. Mais ça veut dire aussi que
toutes les connexions locales ne sont pas acceptées, parce qu'on peut
faire aussi d'autres types de connexion locale, e.g. via l'interface
de la carte Ethernet.Voici un warning de ssh quand je lance xawtv:
WARNING: remote display `localhost:11.0' not allowed, using `:11.0' instead.
D'après la page man de X, :11.0 permet d'avoir un transport local
plus efficace; je ne sais pas si c'est toujours le cas, mais c'est
peut-être pour cela que xawtv l'utilise. J'avais aussi remarqué
que quand on utilise une telle forme, le FQDN de la machine est
pris en compte. Ceci dit, avec ce warning, c'est tout de même
bizarre que "X11UseLocalhost yes" résolve quelque chose, puisqu'il
est plus restrictif.
X11UseLocalhost yes (par défaut) ne devrait pas exporter l'affichage,
n'est-ce pas?
X11UseLocalhost no doit exporter l'affichage (avec les autres options
bien réglées) vers la machine qui s'est connécté par ssh ?
X11UseLocalhost yes devrait afficher sur la machine ou sshd tourne,
est-ce vrai?
X11UseLocalhost yes (par défaut) ne devrait pas exporter l'affichage,
n'est-ce pas?
X11UseLocalhost no doit exporter l'affichage (avec les autres options
bien réglées) vers la machine qui s'est connécté par ssh ?
X11UseLocalhost yes devrait afficher sur la machine ou sshd tourne,
est-ce vrai?
X11UseLocalhost yes (par défaut) ne devrait pas exporter l'affichage,
n'est-ce pas?
X11UseLocalhost no doit exporter l'affichage (avec les autres options
bien réglées) vers la machine qui s'est connécté par ssh ?
X11UseLocalhost yes devrait afficher sur la machine ou sshd tourne,
est-ce vrai?
On 2007-02-08 15:15:42 +0100, Bayrouni wrote:X11UseLocalhost yes (par défaut) ne devrait pas exporter l'affichage,
n'est-ce pas?
La connexion se décompose en deux:
_ connexion client - proxy (non chiffrée)
_ tunnel chiffré proxy - serveur
"X11UseLocalhost yes" impose que la connexion client - proxy soit locale.
C'est normalement ce qu'on veut, mais cela impose en plus que le loopback
soit utilisé. Il est impossible de passer via le device Ethernet par
exemple (qui a généralement l'adresse IP de la machine, alors que le
loopback, c'est 127.*).
X11UseLocalhost no doit exporter l'affichage (avec les autres options
bien réglées) vers la machine qui s'est connécté par ssh ?
Non. Typiquement, le serveur tourne sur une machine A (machine
physiquement devant toi), tu fais un ssh vers une machine B, qui
va installer un proxy écoutant en B:6010 par exemple, afin de
pouvoir lancer un client X11 sur cette machine B. Mais le
"X11UseLocalhost no" va permettre de lancer un client sur une
machine C, qui va se connecter sur B:6010 (connexion standard
non chiffrée) pour afficher une fenêtre sur ta machine A (et
écouter ton clavier, etc.).
X11UseLocalhost yes devrait afficher sur la machine ou sshd tourne,
est-ce vrai?
Non, la connexion est locale, mais les données sont forwardées
chiffrées sur la machine qui a fait le ssh.
On 2007-02-08 15:15:42 +0100, Bayrouni wrote:
X11UseLocalhost yes (par défaut) ne devrait pas exporter l'affichage,
n'est-ce pas?
La connexion se décompose en deux:
_ connexion client - proxy (non chiffrée)
_ tunnel chiffré proxy - serveur
"X11UseLocalhost yes" impose que la connexion client - proxy soit locale.
C'est normalement ce qu'on veut, mais cela impose en plus que le loopback
soit utilisé. Il est impossible de passer via le device Ethernet par
exemple (qui a généralement l'adresse IP de la machine, alors que le
loopback, c'est 127.*).
X11UseLocalhost no doit exporter l'affichage (avec les autres options
bien réglées) vers la machine qui s'est connécté par ssh ?
Non. Typiquement, le serveur tourne sur une machine A (machine
physiquement devant toi), tu fais un ssh vers une machine B, qui
va installer un proxy écoutant en B:6010 par exemple, afin de
pouvoir lancer un client X11 sur cette machine B. Mais le
"X11UseLocalhost no" va permettre de lancer un client sur une
machine C, qui va se connecter sur B:6010 (connexion standard
non chiffrée) pour afficher une fenêtre sur ta machine A (et
écouter ton clavier, etc.).
X11UseLocalhost yes devrait afficher sur la machine ou sshd tourne,
est-ce vrai?
Non, la connexion est locale, mais les données sont forwardées
chiffrées sur la machine qui a fait le ssh.
On 2007-02-08 15:15:42 +0100, Bayrouni wrote:X11UseLocalhost yes (par défaut) ne devrait pas exporter l'affichage,
n'est-ce pas?
La connexion se décompose en deux:
_ connexion client - proxy (non chiffrée)
_ tunnel chiffré proxy - serveur
"X11UseLocalhost yes" impose que la connexion client - proxy soit locale.
C'est normalement ce qu'on veut, mais cela impose en plus que le loopback
soit utilisé. Il est impossible de passer via le device Ethernet par
exemple (qui a généralement l'adresse IP de la machine, alors que le
loopback, c'est 127.*).
X11UseLocalhost no doit exporter l'affichage (avec les autres options
bien réglées) vers la machine qui s'est connécté par ssh ?
Non. Typiquement, le serveur tourne sur une machine A (machine
physiquement devant toi), tu fais un ssh vers une machine B, qui
va installer un proxy écoutant en B:6010 par exemple, afin de
pouvoir lancer un client X11 sur cette machine B. Mais le
"X11UseLocalhost no" va permettre de lancer un client sur une
machine C, qui va se connecter sur B:6010 (connexion standard
non chiffrée) pour afficher une fenêtre sur ta machine A (et
écouter ton clavier, etc.).
X11UseLocalhost yes devrait afficher sur la machine ou sshd tourne,
est-ce vrai?
Non, la connexion est locale, mais les données sont forwardées
chiffrées sur la machine qui a fait le ssh.