Read on Twitter
Ansible gotcha: You'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'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'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's often set in an inventory, or specified on the command line, but it doesn'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('lines', 'whoami') }}": 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
