je viens de passer en Linux 18 Sarah alias 16.04 LTS (Xenial Xerus) avec
XFCE. (Shell fish)
(avant j'étais en Ubuntu 14.04)
le problème que je rencontre quand je me connecte via ssh à un portable
sous macOS Sierra :
┬─[yt@d620:~]─[16-11-21 17:52:58]
╰─>$ ssh yt@mbp.local
Last login: Mon Nov 21 17:35:18 2016 from 192.168.0.48
]1337;RemoteHost=yt@mbp.local]1337;CurrentDir=/Users/yt]1337;ShellIntegrationVersion=2;shell=fish]1337;RemoteHost=yt@mbp.local]1337;CurrentDir=/Users/ytWelcome
to fish, the friendly interactive shell
Type help for instructions on how to use fish
type: Could not find 'acpi'
]133;D;0]133;A.-[yt@mbp.local:~]-[16-11-21 17:53:30]
'->$ ]133;Bexit
]133;C;
Connection to 192.168.0.41 closed.
les "]" devant 1337; (une escape séquence ?) ne sont pas visualisés
ainsi au terminal mais par un rectangle avec des petits chiffres illisibles.
il ne semble pas que ce soit un pb de police de caractère sur le
terminal que j'utilise (Guake), j'ai changé de police, ça ne change rien...
changer de terminal non plus : xfce4-terminal 0.6.3 donne la même chose
que guake.
je pense que c'est une sorte de banière venant du ssh de macOS Sierra
(je n'avais pas ça avant).
par ailleurs, côté macOS mon fichier /etc/ssh/ssh_config n'a pas
vraiment changé.
au cas où quelqu'un connaitrait ce genre de pb.
ou au moins une indication pour savoir où chercher.
Elle est bien envoyée (we sent a publickey packet, wait for reply). Le sshd ne reconnait pas cette clé. Faudrait vérifier si ta clé publique est bien enregistrée dans ~/.ssh/authorized_keys et surtout si les droits sur .ssh sont corrects sur le linux (ca doit être 700 pour ce répertoire).
bêtement j'avais oublié le ssh-copy-id. maintenant ça roule. reste -quand même à régler le pb, côté linux des caractères à la con quand je me log sur le mac. si je me log sur un autre linux pas de pb.
Le 23/11/2016 à 12:45, Bruno Ducrot a écrit :
Elle est bien envoyée (we sent a publickey packet, wait for reply).
Le sshd ne reconnait pas cette clé. Faudrait vérifier si ta clé publique est
bien enregistrée dans ~/.ssh/authorized_keys et surtout si les droits
sur .ssh sont corrects sur le linux (ca doit être 700 pour ce
répertoire).
bêtement j'avais oublié le ssh-copy-id.
maintenant ça roule.
reste -quand même à régler le pb, côté linux des caractères à la con
quand je me log sur le mac.
Elle est bien envoyée (we sent a publickey packet, wait for reply). Le sshd ne reconnait pas cette clé. Faudrait vérifier si ta clé publique est bien enregistrée dans ~/.ssh/authorized_keys et surtout si les droits sur .ssh sont corrects sur le linux (ca doit être 700 pour ce répertoire).
bêtement j'avais oublié le ssh-copy-id. maintenant ça roule. reste -quand même à régler le pb, côté linux des caractères à la con quand je me log sur le mac. si je me log sur un autre linux pas de pb.
Une Bévue
Le 23/11/2016 à 12:55, Philippe Weill a écrit :
je sais que le probleme est resolu mais attention j'avais dit un repertoire de toute la chaine
oui, je comprends que avant d'atteindre le répertoire ~/.ssh ssh traverse /home, puis /home/yt (yt c'est mon login) il faut donc un x à tous ces répertoires au moins pour u. C'est ça ?
Le 23/11/2016 à 12:55, Philippe Weill a écrit :
je sais que le probleme est resolu
mais attention j'avais dit un repertoire de toute la chaine
oui, je comprends que avant d'atteindre le répertoire ~/.ssh
ssh traverse /home, puis /home/yt (yt c'est mon login) il faut donc un x
à tous ces répertoires au moins pour u.
je sais que le probleme est resolu mais attention j'avais dit un repertoire de toute la chaine
oui, je comprends que avant d'atteindre le répertoire ~/.ssh ssh traverse /home, puis /home/yt (yt c'est mon login) il faut donc un x à tous ces répertoires au moins pour u. C'est ça ?
Une Bévue
Le 21/11/2016 à 18:31, Une Bévue a écrit :
le problème que je rencontre quand je me connecte via ssh à un portable sous macOS Sierra :
bon, comme j'ai un autre portable sous : Linux Mint 17.2 Rafaela alias Ubuntu 14.04.2 LTS je viens d'essayer une connection ssh à mon macbook, j'ai exactement le même problème de caractères : ┬─[:~]─[16-11-23 13:40:26] ╰─>$ ssh Last login: Wed Nov 23 13:33:14 2016 from 192.168.0.15 ]1337;RemoteHost=]1337;CurrentDir=/Users/yt]1337;ShellIntegrationVersion=2;shell=fish]1337;RemoteHost=]1337;CurrentDir=/Users/ytWelcome to fish, the friendly interactive shell Type help for instructions on how to use fish type: Could not find 'acpi' ]133;D;0]133;A.-[:~]-[16-11-23 13:41:18] '->$ ]133;Bexit ]133;C; Connection to 192.168.0.41 closed. ┬─[:~]─[16-11-23 13:41:30] ╰─>$
Le 21/11/2016 à 18:31, Une Bévue a écrit :
le problème que je rencontre quand je me connecte via ssh à un portable
sous macOS Sierra :
bon, comme j'ai un autre portable sous :
Linux Mint 17.2 Rafaela alias Ubuntu 14.04.2 LTS
je viens d'essayer une connection ssh à mon macbook, j'ai exactement le
même problème de caractères :
┬─[yt@vostro:~]─[16-11-23 13:40:26]
╰─>$ ssh yt@mbp.local
Last login: Wed Nov 23 13:33:14 2016 from 192.168.0.15
]1337;RemoteHost=yt@mbp.local]1337;CurrentDir=/Users/yt]1337;ShellIntegrationVersion=2;shell=fish]1337;RemoteHost=yt@mbp.local]1337;CurrentDir=/Users/ytWelcome
to fish, the friendly interactive shell
Type help for instructions on how to use fish
type: Could not find 'acpi'
]133;D;0]133;A.-[yt@mbp.local:~]-[16-11-23 13:41:18]
'->$ ]133;Bexit
]133;C;
Connection to 192.168.0.41 closed.
┬─[yt@vostro:~]─[16-11-23 13:41:30]
le problème que je rencontre quand je me connecte via ssh à un portable sous macOS Sierra :
bon, comme j'ai un autre portable sous : Linux Mint 17.2 Rafaela alias Ubuntu 14.04.2 LTS je viens d'essayer une connection ssh à mon macbook, j'ai exactement le même problème de caractères : ┬─[:~]─[16-11-23 13:40:26] ╰─>$ ssh Last login: Wed Nov 23 13:33:14 2016 from 192.168.0.15 ]1337;RemoteHost=]1337;CurrentDir=/Users/yt]1337;ShellIntegrationVersion=2;shell=fish]1337;RemoteHost=]1337;CurrentDir=/Users/ytWelcome to fish, the friendly interactive shell Type help for instructions on how to use fish type: Could not find 'acpi' ]133;D;0]133;A.-[:~]-[16-11-23 13:41:18] '->$ ]133;Bexit ]133;C; Connection to 192.168.0.41 closed. ┬─[:~]─[16-11-23 13:41:30] ╰─>$
Francois Lafont
On 11/23/2016 01:27 PM, Une Bévue wrote:
oui, je comprends que avant d'atteindre le répertoire ~/.ssh ssh traverse /home, puis /home/yt (yt c'est mon login) il faut donc un x à tous ces répertoires au moins pour u. C'est ça ?
Oui c'est l'idée. En fait, un compte qui n'a pas le droit x sur un répertoire ne peut pas faire grand chose. Sans "x" sur un répertoire point de salut. ;) En fait, au niveau des droits sur les répertoires, il me semble que tout devient compréhensible si tu vois un répertoire juste comme une _sorte_ de fichier texte contenant simplement la liste des noms des fichiers qu'il contient. Imaginons que j'ai un répertoire /tmp/d qui contient un sous répertoire dd/, et deux fichiers « standards » titi et toto. Et bien le répertoire /tmp/d c'est un peu comme si c'était le fichier texte : dd titi toto Et "x" c'est le droit de pouvoir "exécuter ton fichier répertoire" ce qui pourrait se traduire par "pouvoir le traverser" et aller regarder un des fichiers qu'il contient. Avec un telle approche, il me semble qu'on comprend aussi pourquoi il est possible parfois de supprimer un fichier f d'un répertoire D quand on a les droits en écriture sur D alors qu'on n'a absolument aucun droit sur le fichier f. -- François Lafont
On 11/23/2016 01:27 PM, Une Bévue wrote:
oui, je comprends que avant d'atteindre le répertoire ~/.ssh
ssh traverse /home, puis /home/yt (yt c'est mon login) il faut donc un x à tous ces répertoires au moins pour u.
C'est ça ?
Oui c'est l'idée. En fait, un compte qui n'a pas le droit x sur
un répertoire ne peut pas faire grand chose. Sans "x" sur un
répertoire point de salut. ;)
En fait, au niveau des droits sur les répertoires, il me semble
que tout devient compréhensible si tu vois un répertoire juste
comme une _sorte_ de fichier texte contenant simplement la liste
des noms des fichiers qu'il contient.
Imaginons que j'ai un répertoire /tmp/d qui contient un sous
répertoire dd/, et deux fichiers « standards » titi et toto.
Et bien le répertoire /tmp/d c'est un peu comme si c'était le
fichier texte :
dd
titi
toto
Et "x" c'est le droit de pouvoir "exécuter ton fichier répertoire"
ce qui pourrait se traduire par "pouvoir le traverser" et aller
regarder un des fichiers qu'il contient.
Avec un telle approche, il me semble qu'on comprend aussi pourquoi
il est possible parfois de supprimer un fichier f d'un répertoire D
quand on a les droits en écriture sur D alors qu'on n'a absolument aucun
droit sur le fichier f.
oui, je comprends que avant d'atteindre le répertoire ~/.ssh ssh traverse /home, puis /home/yt (yt c'est mon login) il faut donc un x à tous ces répertoires au moins pour u. C'est ça ?
Oui c'est l'idée. En fait, un compte qui n'a pas le droit x sur un répertoire ne peut pas faire grand chose. Sans "x" sur un répertoire point de salut. ;) En fait, au niveau des droits sur les répertoires, il me semble que tout devient compréhensible si tu vois un répertoire juste comme une _sorte_ de fichier texte contenant simplement la liste des noms des fichiers qu'il contient. Imaginons que j'ai un répertoire /tmp/d qui contient un sous répertoire dd/, et deux fichiers « standards » titi et toto. Et bien le répertoire /tmp/d c'est un peu comme si c'était le fichier texte : dd titi toto Et "x" c'est le droit de pouvoir "exécuter ton fichier répertoire" ce qui pourrait se traduire par "pouvoir le traverser" et aller regarder un des fichiers qu'il contient. Avec un telle approche, il me semble qu'on comprend aussi pourquoi il est possible parfois de supprimer un fichier f d'un répertoire D quand on a les droits en écriture sur D alors qu'on n'a absolument aucun droit sur le fichier f. -- François Lafont
Bruno Ducrot
On 2016-11-23, Une Bévue wrote:
Le 23/11/2016 à 12:51, Bruno Ducrot a écrit :
Même après un ssh-copy-id ?
Si ça y est, côté mac, après ssh-copy-id, ça roule. le "serveur" m'a demandé la passphrase une première fois puis plus rien. Par contre j'ai toujours les caractères bizarre dans l'autre sens (de linux vers macOS). j'ai une autre portable sous linux et là je n'ai pas de caractères à la con quand je m'y connecte, depuis linux comme depuis mac.
Une recherche google sur : ^[]1337; escape sequences tombe plus ou moins sur https://www.iterm2.com/documentation-escape-codes.html Je viens d'installer iTerm2, mais rien à faire. Je n'arrive toujours pas à reproduire les caractères chelous. -- Bruno Ducrot A quoi ca sert que Ducrot hisse des carcasses ?
On 2016-11-23, Une Bévue wrote:
Le 23/11/2016 à 12:51, Bruno Ducrot a écrit :
Même après un ssh-copy-id ?
Si ça y est, côté mac, après ssh-copy-id, ça roule.
le "serveur" m'a demandé la passphrase une première fois puis plus rien.
Par contre j'ai toujours les caractères bizarre dans l'autre sens (de
linux vers macOS).
j'ai une autre portable sous linux et là je n'ai pas de caractères à la
con quand je m'y connecte, depuis linux comme depuis mac.
Une recherche google sur :
^[]1337; escape sequences
tombe plus ou moins sur
https://www.iterm2.com/documentation-escape-codes.html
Je viens d'installer iTerm2, mais rien à faire. Je n'arrive toujours
pas à reproduire les caractères chelous.
Si ça y est, côté mac, après ssh-copy-id, ça roule. le "serveur" m'a demandé la passphrase une première fois puis plus rien. Par contre j'ai toujours les caractères bizarre dans l'autre sens (de linux vers macOS). j'ai une autre portable sous linux et là je n'ai pas de caractères à la con quand je m'y connecte, depuis linux comme depuis mac.
Une recherche google sur : ^[]1337; escape sequences tombe plus ou moins sur https://www.iterm2.com/documentation-escape-codes.html Je viens d'installer iTerm2, mais rien à faire. Je n'arrive toujours pas à reproduire les caractères chelous. -- Bruno Ducrot A quoi ca sert que Ducrot hisse des carcasses ?
Philippe Weill
Le 23/11/2016 à 13:27, Une Bévue a écrit :
Le 23/11/2016 à 12:55, Philippe Weill a écrit :
je sais que le probleme est resolu mais attention j'avais dit un repertoire de toute la chaine
oui, je comprends que avant d'atteindre le répertoire ~/.ssh ssh traverse /home, puis /home/yt (yt c'est mon login) il faut donc un x à tous ces répertoires au moins pour u. C'est ça ?
non le probleme que je soulevais c'est que pour raison de sécurité ssh désactive l'utilisation des clefs si un des répertoires traversé pour atteindre le fichier authorized_keys est en ECRITURE (w) pour le groupe ou pour other exemple je fais un ssh je rentre vec la clef [ ~]$ ssh sirocco mer. nov. 23 14:39:06 CET 2016 ~> ls -ld $HOME drwxr-xr-x 272 weill group 40960 23 nov. 14:39 /home/weill ~> chmod g+w $HOME ~> ls -ld $HOME drwxrwxr-x 272 weill group 40960 23 nov. 14:39 /home/weill ~> logout Connection to sirocco.aero.jussieu.fr closed. je me deconnecte et relance la connexion il me demande le password [ ~]$ ssh sirocco Password:
Le 23/11/2016 à 13:27, Une Bévue a écrit :
Le 23/11/2016 à 12:55, Philippe Weill a écrit :
je sais que le probleme est resolu
mais attention j'avais dit un repertoire de toute la chaine
oui, je comprends que avant d'atteindre le répertoire ~/.ssh
ssh traverse /home, puis /home/yt (yt c'est mon login) il faut donc un x à tous ces répertoires au moins pour u.
C'est ça ?
non le probleme que je soulevais c'est que pour raison de sécurité
ssh désactive l'utilisation des clefs si un des répertoires traversé
pour atteindre le fichier authorized_keys est en ECRITURE (w) pour le groupe ou pour other
exemple
je fais un ssh je rentre vec la clef
[weill@tsunami2 ~]$ ssh sirocco
mer. nov. 23 14:39:06 CET 2016
weill@sirocco ~> ls -ld $HOME
drwxr-xr-x 272 weill group 40960 23 nov. 14:39 /home/weill
weill@sirocco ~> chmod g+w $HOME
weill@sirocco ~> ls -ld $HOME
drwxrwxr-x 272 weill group 40960 23 nov. 14:39 /home/weill
weill@sirocco ~> logout
Connection to sirocco.aero.jussieu.fr closed.
je me deconnecte et relance la connexion
il me demande le password
je sais que le probleme est resolu mais attention j'avais dit un repertoire de toute la chaine
oui, je comprends que avant d'atteindre le répertoire ~/.ssh ssh traverse /home, puis /home/yt (yt c'est mon login) il faut donc un x à tous ces répertoires au moins pour u. C'est ça ?
non le probleme que je soulevais c'est que pour raison de sécurité ssh désactive l'utilisation des clefs si un des répertoires traversé pour atteindre le fichier authorized_keys est en ECRITURE (w) pour le groupe ou pour other exemple je fais un ssh je rentre vec la clef [ ~]$ ssh sirocco mer. nov. 23 14:39:06 CET 2016 ~> ls -ld $HOME drwxr-xr-x 272 weill group 40960 23 nov. 14:39 /home/weill ~> chmod g+w $HOME ~> ls -ld $HOME drwxrwxr-x 272 weill group 40960 23 nov. 14:39 /home/weill ~> logout Connection to sirocco.aero.jussieu.fr closed. je me deconnecte et relance la connexion il me demande le password [ ~]$ ssh sirocco Password:
Une recherche google sur : ^[]1337; escape sequences tombe plus ou moins sur https://www.iterm2.com/documentation-escape-codes.html Je viens d'installer iTerm2, mais rien à faire. Je n'arrive toujours pas à reproduire les caractères chelous.
Ah super, merci beaucoup ! En fait j'ai un : test -e {$HOME}/.iterm2_shell_integration.fish ; and source {$HOME}/.iterm2_shell_integration.fish à la toute fin de mon fichier .config/fish/config.fish je vais commenter cette ligne, pour voir. bon, c'est bien ça je n'ai plus le bronx depuis linux. maintenant reste à trouver un moyen pour inhiber .iterm2_shell_integration.fish quand le login se fait par ssh si je me souviens bien, il y a des variables d'environement qui sont settées avec ssh.
Le 23/11/2016 à 14:36, Bruno Ducrot a écrit :
Une recherche google sur :
^[]1337; escape sequences
tombe plus ou moins sur
https://www.iterm2.com/documentation-escape-codes.html
Je viens d'installer iTerm2, mais rien à faire. Je n'arrive toujours
pas à reproduire les caractères chelous.
Ah super, merci beaucoup !
En fait j'ai un :
test -e {$HOME}/.iterm2_shell_integration.fish ; and source
{$HOME}/.iterm2_shell_integration.fish
à la toute fin de mon fichier .config/fish/config.fish
je vais commenter cette ligne, pour voir.
bon, c'est bien ça je n'ai plus le bronx depuis linux.
maintenant reste à trouver un moyen pour inhiber
.iterm2_shell_integration.fish
quand le login se fait par ssh
si je me souviens bien, il y a des variables d'environement qui sont
settées avec ssh.
Une recherche google sur : ^[]1337; escape sequences tombe plus ou moins sur https://www.iterm2.com/documentation-escape-codes.html Je viens d'installer iTerm2, mais rien à faire. Je n'arrive toujours pas à reproduire les caractères chelous.
Ah super, merci beaucoup ! En fait j'ai un : test -e {$HOME}/.iterm2_shell_integration.fish ; and source {$HOME}/.iterm2_shell_integration.fish à la toute fin de mon fichier .config/fish/config.fish je vais commenter cette ligne, pour voir. bon, c'est bien ça je n'ai plus le bronx depuis linux. maintenant reste à trouver un moyen pour inhiber .iterm2_shell_integration.fish quand le login se fait par ssh si je me souviens bien, il y a des variables d'environement qui sont settées avec ssh.
Une Bévue
Le 23/11/2016 à 14:43, Philippe Weill a écrit :
non le probleme que je soulevais c'est que pour raison de sécurité ssh désactive l'utilisation des clefs si un des répertoires traversé pour atteindre le fichier authorized_keys est en ECRITURE (w) pour le groupe ou pour other exemple je fais un ssh je rentre vec la clef [ ~]$ ssh sirocco mer. nov. 23 14:39:06 CET 2016 ~> ls -ld $HOME drwxr-xr-x 272 weill group 40960 23 nov. 14:39 /home/weill ~> chmod g+w $HOME ~> ls -ld $HOME drwxrwxr-x 272 weill group 40960 23 nov. 14:39 /home/weill ~> logout Connection to sirocco.aero.jussieu.fr closed. je me deconnecte et relance la connexion il me demande le password [ ~]$ ssh sirocco Password:
AH d'accord, merci pour le tuyau !
Le 23/11/2016 à 14:43, Philippe Weill a écrit :
non le probleme que je soulevais c'est que pour raison de sécurité
ssh désactive l'utilisation des clefs si un des répertoires traversé
pour atteindre le fichier authorized_keys est en ECRITURE (w) pour le
groupe ou pour other
exemple
je fais un ssh je rentre vec la clef
[weill@tsunami2 ~]$ ssh sirocco
mer. nov. 23 14:39:06 CET 2016
weill@sirocco ~> ls -ld $HOME
drwxr-xr-x 272 weill group 40960 23 nov. 14:39 /home/weill
weill@sirocco ~> chmod g+w $HOME
weill@sirocco ~> ls -ld $HOME
drwxrwxr-x 272 weill group 40960 23 nov. 14:39 /home/weill
weill@sirocco ~> logout
Connection to sirocco.aero.jussieu.fr closed.
je me deconnecte et relance la connexion
il me demande le password
non le probleme que je soulevais c'est que pour raison de sécurité ssh désactive l'utilisation des clefs si un des répertoires traversé pour atteindre le fichier authorized_keys est en ECRITURE (w) pour le groupe ou pour other exemple je fais un ssh je rentre vec la clef [ ~]$ ssh sirocco mer. nov. 23 14:39:06 CET 2016 ~> ls -ld $HOME drwxr-xr-x 272 weill group 40960 23 nov. 14:39 /home/weill ~> chmod g+w $HOME ~> ls -ld $HOME drwxrwxr-x 272 weill group 40960 23 nov. 14:39 /home/weill ~> logout Connection to sirocco.aero.jussieu.fr closed. je me deconnecte et relance la connexion il me demande le password [ ~]$ ssh sirocco Password:
AH d'accord, merci pour le tuyau !
Une Bévue
Le 23/11/2016 à 16:16, Une Bévue a écrit :
si je me souviens bien, il y a des variables d'environement qui sont settées avec ssh.
sur linux j'ai : .-[:~]-[16-11-23 16:17:26] '->$ ENV | grep SSH SSH_CLIENT2.168.0.48 36638 22 SSH_CONNECTION2.168.0.48 36638 192.168.0.41 22 SSH_TTY=/dev/ttys006 (enfin linux connecté à mac) sur mac je n'ai que : SSH_AUTH_SOCK=... sur linux soi-même (en local) : ┬─[:~]─[16-11-23 16:23:01] ╰─>$ env | grep SSH SSH_AGENT_PID18 SSH_AUTH_SOCK=/tmp/ssh-jFOV4AhKSpLF/agent.1917 donc, dans mon fichier config.fish, côté mac, je dois ajouter un test pour savoir si SSH_CONNECTION est setté ou non...
Le 23/11/2016 à 16:16, Une Bévue a écrit :
si je me souviens bien, il y a des variables d'environement qui sont
settées avec ssh.
sur linux j'ai :
.-[yt@mbp.local:~]-[16-11-23 16:17:26]
'->$ ENV | grep SSH
SSH_CLIENT2.168.0.48 36638 22
SSH_CONNECTION2.168.0.48 36638 192.168.0.41 22
SSH_TTY=/dev/ttys006
(enfin linux connecté à mac)
sur mac je n'ai que :
SSH_AUTH_SOCK=...
sur linux soi-même (en local) :
┬─[yt@d620:~]─[16-11-23 16:23:01]
si je me souviens bien, il y a des variables d'environement qui sont settées avec ssh.
sur linux j'ai : .-[:~]-[16-11-23 16:17:26] '->$ ENV | grep SSH SSH_CLIENT2.168.0.48 36638 22 SSH_CONNECTION2.168.0.48 36638 192.168.0.41 22 SSH_TTY=/dev/ttys006 (enfin linux connecté à mac) sur mac je n'ai que : SSH_AUTH_SOCK=... sur linux soi-même (en local) : ┬─[:~]─[16-11-23 16:23:01] ╰─>$ env | grep SSH SSH_AGENT_PID18 SSH_AUTH_SOCK=/tmp/ssh-jFOV4AhKSpLF/agent.1917 donc, dans mon fichier config.fish, côté mac, je dois ajouter un test pour savoir si SSH_CONNECTION est setté ou non...
Francois Lafont
On 11/23/2016 02:43 PM, Philippe Weill wrote:
C'est ça ?
non [...]
Ah, donc j'ai donc un peu raconté de la merde dans ma réponse... enfin répondu à côté tout au moins. Au temps pour moi. ;) -- François Lafont
On 11/23/2016 02:43 PM, Philippe Weill wrote:
C'est ça ?
non [...]
Ah, donc j'ai donc un peu raconté de la merde dans ma réponse... enfin
répondu à côté tout au moins.
