Go: x/build/cmd/coordinator : le proxy ssh doit prendre en charge scp

/cc @dmitshur

C'est l'un des problèmes que j'examine. En essayant d'imaginer comment cela fonctionnerait, la question suivante s'est posée.

Étant donné que nous avons gomote put , le support scp sera-t-il nécessaire et utile ? Est-ce que gomote put ne fait pas déjà ce que scp vous laisserait faire ? Ou existe-t-il des cas d'utilisation spécifiques dont nous sommes conscients qui en vaudraient la peine.

Une observation sur ssh vs scp . Gomote permet actuellement à l'utilisateur de "ssh dans" un buildlet en exécutant gomote ssh <instance> , mais cela fonctionne en créant un shell ssh et en laissant l'utilisateur l'utiliser. Le client ssh normal n'est pas pris en charge directement. Je ne pense pas que la même solution fonctionnerait pour scp , car nous ne voulons pas réimplémenter toute la syntaxe complexe prise en charge par le client scp .

gomote put et gomote gettar sont fastidieux et ne fonctionnent pas avec les outils existants comme rsync .

Le client ssh normal n'est pas pris en charge directement.

C'est si vous l'exécutez à la main. gomote ssh renvoie la commande que vous pourriez exécuter vous-même.

Tout ce qui est nécessaire pour corriger ce bogue (je pense) est de répondre aux demandes d'ouverture de canal "sftp" sur notre serveur ssh et d'ouvrir un nouveau canal "sftp" vers le backend et de les assembler avec une copie io.Copy goroutines.