As of https://golang.org/cl/50750 the build coordinator has an ssh server to proxy to buildlets. (That was bug #19956)
But there's no scp support yet.
This is a tracking bug to figure that out.
/cc @dmitshur
This is one of the issues I'm looking at. In trying to envision how it would work, the following question came up.
Given that we have gomote put
, is scp support going to be needed and helpful? Doesn't gomote put
already do what scp
would let you do? Or are there specific use cases we're aware of that would make this worthwhile.
One observation about ssh
vs scp
. Gomote currently lets the user "ssh into" a buildlet by running gomote ssh <instance>
, but it works by creating an ssh shell and letting the user use it. The normal ssh
client isn't supported directly. I don't think the same solution would work for scp
, because we don't want to re-implement all the complex syntax that the scp
client supports.
gomote put
and gomote gettar
are tedious and don't work with existing tools like rsync
.
The normal ssh client isn't supported directly.
It is if you run it by hand. gomote ssh
echos out the command you could run on your own.
All that's required to fix this bug (I think) is to respond to "sftp" channel open requests in our ssh server and open a new onward "sftp" channel to the backend and stitch them together with a copy io.Copy goroutines.
Most helpful comment
gomote put
andgomote gettar
are tedious and don't work with existing tools likersync
.It is if you run it by hand.
gomote ssh
echos out the command you could run on your own.All that's required to fix this bug (I think) is to respond to "sftp" channel open requests in our ssh server and open a new onward "sftp" channel to the backend and stitch them together with a copy io.Copy goroutines.