Commit SHA: 87b1cf45 that put temp files in `$HOME/.ansible` instead of `/home/<user>/.ansible` was producing a directory literally called `$HOME` (no expansion) with non-sudo remote execution. I'll take the blame for this one, as `ParamikoConnection.exec_command()` was not using the shell for non-sudo commands. This does sudo and non-sudo execution the same way, using the shell, so environment variables should get expanded.
Reading the docs, I was a bit confused as to how to specify multiple hosts/groups in a playbook. Being YAML, I assumed a normal YAML list would work:
---
- hosts: [host1, host2]
But this crashes when inventory._matches() assumes hosts is a string. This patch just checks if hosts is a list, and turns it into a string joined by ';'.
runner._return_from_module() normally returns a list (?) of `[str,bool,dict,str]`, but on error it returns `[str,bool,str,str]`. runner._chain_file_module() then tries to call .get() on the third item (`data2`), which fails when it's a string. This patch only accesses `data2` if the return value was `ok`. It might be better to return consistent types in both cases, but I'm not sure where/how else the return value is used.
The basic idea is sudo /bin/sh -c 'quoted_command'. We use Paramiko's low-level API to set a timeout, get a pseudo tty, execute sudo and the (shell quoted) command atomically, wait just until sudo is ready to accept the password before sending it down the pipe, and then return the command's stdout and stderr.
This should be faster, as there are no unneeded sleeps. There are no permissions issues reading the output. It will raise socket.timeout if the command takes too long. However, this is a per-read timeout, not a total execution timeout, so as long as the command is writing output and you are reading it, it will not time out.
Local and non-sudo commands remain unchanged, but should probably adopt a similar approach.
Since this is a significant change, it needs a lot of testing. Also, someone smarter than I should double-check the quoting and execution, since it is a security issue.
You still need jinja2 if using /usr/bin/ansible vs /usr/bin/ansible-playbook though
this could change later by fetching the ansible file with a 'slurp' module.
