feat: add machine exec command

[iRazvan2745]

No description provided.

[iRazvan2745]

This PR has been fully ai generated. I don't expect this to be merged but thought it may be useful

[psviderski]

Thanks! Code is cheap now. I would appreciate a discussions about your use cases and problems you want to solve with this. And security concerns. I'm really missing the uc machine ssh command to quickly jump into a shell on the machine but I'm still hesitant to add it because without proper access controls in place it just gives too much permissions, essentially root on every machine in the cluster and no way to restrict this.

[iRazvan2745]

I needed to run git pull on every server to get my configs, couldnt do it with pre-deploy hooks, since they are in a container, so the other options was a bash script that SSHes to every machine

Doesnt uncloud use ssh for connecting to the machines? why not just run ssh root@machine? Maybe over the internal network? You could also alias to uc machine exec machine-1 /bin/bash (just tested, you cannot)

[psviderski]

I needed to run git pull on every server to get my configs, couldnt do it with pre-deploy hooks, since they are in a container, so the other options was a bash script that SSHes to every machine

Wait, why are you deploying configs with git pull on the machines and not as part of your deployments, e.g. using https://uncloud.run/docs/concepts/configs?

[iRazvan2745]

whaaa- might need new glasses

[iRazvan2745]

the newest commit adds bidirection streaming like uc exec does therefor uc machine exec machine1 /bin/bash would work

[psviderski]

Doesnt uncloud use ssh for connecting to the machines? why not just run ssh root@machine? Maybe over the internal network?

It does, but you may not have your public ssh key on all machines (working in a team and only someone else has access to all machines), some machines may not be directly reachable, e.g. behind NAT in the office/home network when you're remote. You can have ssh access to only one machine in the cluster to work with it (uncloud config can have only one machine connection: https://uncloud.run/docs/cli-config-reference#connections).
So it's a bit nuanced.

[miekg]

I needed to run git pull on every server to get my configs, couldnt do it with pre-deploy hooks, since they are in a container, so the other options was a bash script that SSHes to every machine

you can also bind-mount (from a container) the directory where you want to have your configs and just do the git pull from the container too

[joeblew999]

Use cases from our side (running a handful of single-compose recipes on uncloud nodes), since you asked:

1. One-off inspection/debug on a node — container state, disk usage, open ports — without re-deriving the node IP and pointing ssh at the right key. We currently shell out with ssh root@<ip> '…'; uc machine exec <machine> '…' over the connection uncloud already holds would be cleaner and team-safe (per your point — you don't need your pubkey on every machine).
2. Streaming data off a node — our Windows-desktop nodes snapshot by streaming the qcow2 off the box (ssh … 'gzip < … | aws s3 cp - …'). Running that through uc machine exec (with the bidirectional streaming you added) would drop the separate key/host plumbing.
3. Interactive shell — uc machine ssh <machine> (the one you mentioned missing) would replace our debug:ssh helper outright.

Security thoughts: scope it to the same auth as uc machine init/deploy (whoever can deploy can exec); the win is precisely not needing a personal pubkey on each host — uncloud brokers it. A -y/confirmation for non-interactive exec, and an audit line (who ran what, when) in the machine log, would make it comfortable to hand to a team. Big +1 on uc machine ssh regardless of where exec lands.