bitfield / script

Making it easy to write shell-like scripts in Go
MIT License
5.55k stars 315 forks source link

Execute the scripts over ssh connection #162

Open tareksalem opened 1 year ago

tareksalem commented 1 year ago

I found the library is great and covers most of bash scripting, but you know most of the time when you do bash scripting, you do it on remote servers so how can I make the scripts that I write using this library to be executed over ssh, is there something like this for example?

script.SSH("connection here").EXEC()

thank you

bitfield commented 1 year ago

What about something like this:

script.Exec("ssh myhost ls").Stdout()
tareksalem commented 1 year ago

thanks for your reply, is this work for executing sub commands on that ssh connection using builder pattern?

script.Exec("ssh yhost ls").FIle("filepath").Stdout()

will this work?

bitfield commented 1 year ago

We can execute commands remotely using Exec("ssh..."), and append the results to local files using AppendFile, but since the compiled script program is running locally, all of the script operations will apply locally, not on the remote machine—is that what you're asking?

tareksalem commented 1 year ago

@bitfield yes, I am asking about why the script operations are runing locally and there is no a mechanism to run them over ssh, I know that I can run command over ssh using Exec("ssh ...remoteCommands") but my question is, why not defining something like a context to tell script library that I am using ssh context now or local context, something like this

script.Context("ssh").ssh("ssh connection here").DoSomeWorkOnRemoteServer().Context("local").doSomeWorkLocally()
bitfield commented 1 year ago

Well, how could we do any work on the remote server? Only by executing code there. How can we get the code on to the remote server? We'd have to deploy a binary there. If we can do that, why bother with SSH? Now we can just do the work locally.

tareksalem commented 1 year ago

@bitfield mmm, actually it differs from use case to another, my question came from a use case, which is a golang service running and listening for new created servers then this golang service should install some libraries and do some work on these new created servers, the only way to do that is using ssh connection, also in all cases to deploy the binary code on the remote servers you still need to do ssh so why not performing your actions directly on that remote server using the syntax I suggested?

gedw99 commented 1 year ago

Yeah I have similar use case

I am using script with nats

nats is the Transport , instead of ssh.

The binary ( that imports script ) needs to exist on both sides though !

I was thinking of add NATS as a formal transport provider to Script as a PR but my use case / prototype has not stabilised yet.

nats can stream anything. You can even bootstrap the client binary onto the server via nats and then your set .

The data and ops are just topics in the same way that file paths are namespaces. It’s pretty nice

you can add nats AAA security too so that only certain user roles can run over certain topics and so certain file paths on the server.

hit me up if your curious for more info

chrisgo commented 5 months ago

So basically, something that allows you to do it like this https://www.fabfile.org/

bitfield commented 2 months ago

I think we pretty much have this already, don't we? We can do something like:

script.File("hosts.txt").ExecForEach("ssh {{.}} ls").Stdout()

If we agree that deploying binaries to the remote hosts is out of bounds, but running plain shell commands and getting the output is okay, then yes, I think this is done.