# users and variables

**URL:** <https://forum.ansible.com/t/users-and-variables/11660>\
**Category:** Ansible Project\
**Tags:** ansible-project\
**Created:** [July 10, 2012, 2:08pm UTC](https://forum.ansible.com/t/users-and-variables/11660 "2012-07-10T14:08:03Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\
**Post date:** [July 10, 2012, 2:08pm UTC](https://forum.ansible.com/t/users-and-variables/11660/1 "2012-07-10T14:08:03Z")

</div>

> Hey there, I had two questions about users (i.e. the user that ansible uses for ssh) and variables:
> 
> 1. Is it possible to specify the user as a variable in a play? I tried this in a play:
> 
> - hosts: all  
> user: $deploy\_account
> 
> vars\_files:
> 
> - vars/main.yaml

This is a common question, and probably suggests vars\_files needs a small amount of more explanation in the docs.

vars\_files is evaluated in host specific context, because you can use host specific facts, like the distribution, to generate filenames.

As a result, you can use variables from vars\_files in action lines of tasks, and templates, sure, but higher level things that are evaluated before we start talking to hosts (task names, top level playbook variables) can’t make use of that data.

The solution is to make the vars\_files logic be smart, and notice that if it could fully template a vars\_files line entry to remove all template characters (that is, the line doesn’t contain any variables that will be provided later, from facts), it could load it earlier. This would be the “Do What I Mean” approach, and is probably better than introducing something like “vars\_files\_not\_host\_specific” (ugh). I would gladly take a patch for this and it would prevent a fair amount of user questions.

If you just want a workaround, you can use “vars” or --extra-vars=“user=timmy” from the command line, and both of those will work for supplying the value, as will variables in your inventory file (on the group or host).

> ## Where vars/main.yaml looks like this:
> 
> deploy\_account: deploy
> 
> But it didn’t work, when I tried to connect, I saw:
> 
> $[deploy\_account@192.168.33.11](mailto:deploy_account@192.168.33.11)’s password:
> 
> 1. Is it possible to get access the current user as a variable?

Believe this was asked in IRC yesterday.

Not presently. Currently we do have 'inventory\_hostname" as a similar magic variable, so having a similar variable called ‘current\_user’ be available seems reasonable, and patches would be accepted for this.

I suspect we might break some people if we called it “user”, so I kind of want to pick something less likely to be used.

If this is done, we probably also should set ‘sudo\_user’ equivalently, or leave it blank if not sudoing.