Can't Ansible be used to achieve your objective?
Br,
-vu
On Sat, Mar 4, 2017 at 6:28 PM, Cameron Simpson <cs@xxxxxxxxxx> wrote:
On 04Mar2017 13:34, bruce <badouglas@xxxxxxxxx> wrote:
tried the SSH without the "-t"...
ssh -vvv crawl_user@67.205.151.11 "ls /crawl_tmp;" &
this works -- no prob... returns as expected...
this doesn't..
ssh -vvv -t crawl_user@67.205.151.11 "ls /crawl_tmp;"
Well, it has no trailing "&"...
-t causes the _remote_ end to allocate a terminal, which causes some things to run differently (eg you can use use screen or tmux; most "ls" commands will columnate output on a terminal, etc etc). However, for background/batch commands you usually don't want this at all. Ssh turns this on if attached to a terminal, and doesn't otherwise - that is what gets you samless terminal access with a plain ssh to a remote host.
Short answer: don't use -t.
You also don't want to read from standard input - this is the -n option.
The -f option is like -n, but completes the ssh connection/authentication before backgrounding it. FOr maximum parallelism you don't want -f.
Basicly you want a loop like this:
set -x # trace the shell so you can see what's happening
for host in a b c d
do
ssh -n "$host" "some command here" &
done
wait
You can compare that with the -f option flavour:
set -x # trace the shell so you can see what's happening
for host in a b c d
do
ssh -f "$host" "some command here"
done
The former is what you probably want; it is what I usually do.
The latter does the authentication phase serially, then backgrounds the ssh. It will be slower, but you could check which sshes failed connection/authentication if that is a concern. Note that the background ssh commands with -f are _not_ children of your shell, and you can't "wait" for them as you can in the first instance. (You can block for them by reading their (shared) stdout, but let us not go there.)
The -t option is a red herring here; its use is more special purpose and will only cause you trouble here.
Cheers,
Cameron Simpson <cs@xxxxxxxxxx>
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@lists.fedoraproject.org
_______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
