Read on Twitter
Ansible gotcha: You& #39;re not always who you think you are. In Ansible there are 3 identities you might be running as
1. user running the playbook
2. user that Ansible connects as (default: same as 1)
3. user that Ansible becomes (default: root)
1. user running the playbook
2. user that Ansible connects as (default: same as 1)
3. user that Ansible becomes (default: root)
The 1st is outside Ansible& #39;s control. The 2nd & 3rd can be set at almost any scope: globally, host group, host, play, even individual tasks. To write reusable roles, you can& #39;t assume a given value - they must be obtained at runtime. Doing so is harder than you think
ansible_user: a variable that reflects the 2nd case. It& #39;s often set in an inventory, or specified on the command line, but it doesn& #39;t have to be. If the connecting user is not defined in the inventory, then ansible_user can be undefined.
ansible_facts.user_id: a fact populated (usually at the start of a play). It may not reflect the current user if become: true was specified for the play, but become: false was specified for the current task. Or vice versa.
ansible_facts.env.USER - is a fact populated from an environment variable. It has the same caveats as ansible_facts.user_id
"{{ lookup(& #39;lines& #39;, & #39;whoami& #39;) }}": a template expression that returns the output of running the command whoami. However (like all lookup() calls) it runs this on the host running the playbook (aka the controller), *not* the target hosts
Test setup and results that were basis of this thread https://gist.github.com/moreati/36eb8d4143505d2e7ea641a61f00545c">https://gist.github.com/moreati/3...
