possible bug with users

[bryan hunt]

Hi there,

I'm running via Vagrant, so everything should be executing by default as vagrant user.

My configuration looks like this

config.vm.provision "ansible" do |ansible|
        ansible.playbook = "../playbooks/docker.yml"
        ansible.sudo = true
        ansible.host_key_checking = false
        ansible.verbose =  'vvvv'
end

The docker.yml file (stripped down) looks like this:

---
- include: base.yml
- hosts: all
  sudo: no
  tasks:
   - name: get value of current user
     action: debug msg="Value of ansible_env['HOME'] is {{ansible_env['HOME']}}"
   - name: get home of current user
     action: debug msg="Value of ansible_env['USER'] is {{ansible_env['USER']}}"

And base.yml (stripped down) looks like this:
---
 - hosts: all

When including the (empty) base.yml file the output looks like this:

TASK: [get value of current user] *********************************************
<127.0.0.1> ESTABLISH CONNECTION FOR USER: vagrant
ok: [default] => {
    "msg": "Value of ansible_env['HOME'] is /root"
}

TASK: [get home of current user] **********************************************
<127.0.0.1> ESTABLISH CONNECTION FOR USER: vagrant
ok: [default] => {
    "msg": "Value of ansible_env['USER'] is root"
}

That's not what I wanted, I set sudo = no in the docker.yml.

Now I remove the inclusion of base.yml, run again, and I get correct output.

TASK: [get value of current user] *********************************************
<127.0.0.1> ESTABLISH CONNECTION FOR USER: vagrant
ok: [default] => {
    "msg": "Value of ansible_env['HOME'] is /home/vagrant"
}

TASK: [get home of current user] **********************************************
<127.0.0.1> ESTABLISH CONNECTION FOR USER: vagrant
ok: [default] => {
    "msg": "Value of ansible_env['USER'] is vagrant"
}

So the act of including another file seems to force ansible to execute everything as root.

My goal here is to try and create a disposable development environment that can be booted and up and running quickly on OSX.

[Michael DeHaan]

I'm not sure where you are saying a bug might lie, but you've only shown *PART* of the play above, so I can't tell what you are doing with it.

If there was a bug with our user handling, I'm pretty positive we would have heard about it 1000x over, but this list is for helping people out with questions.

I would only ask that people not first assume they have found a bug, but instead ask for help with a problem.

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Michael DeHaan <mic...@ansibleworks.com>
CTO, AnsibleWorks, Inc.
http://www.ansibleworks.com/

[Adam Morris]

I am no expert, but I think that what he is saying is that when he includes  base.yml then his setting of sudo:no in the file that includes base.yml is overridden.  

Thus his "possible bug with users" really translates as "possible bug with sudo being used when I don't expect it"

It's really to do with sudo usage and nothing to do with the user module (which was what I expected when I read the title).

I hope that this helps,

Adam

[bryan hunt]

Yes, to clarify, "possible bug with sudo being used when I don't expect it".

I deleted everything but the code needed to demonstrate the (possible) bug.

That code, when run - as is, demonstrates the problem.

It is part of a larger effort to create an Ansible config to provision a Vagrant box, install a couple of packages, and check out a couple of projects from github R/W.

The reason I don't want to hard code the vagrant username is that I want to use the playbooks to be independent of Vagrant, I want to reuse it on Amazon, Linode, etc.

The even larger goal is to create and share a couple of useful roles.

[Michael DeHaan]

"That code, when run - as is, demonstrates the problem."

That's not what I wanted, I set sudo = no in the docker.yml.

There's no variable called "sudo" you can just drop in a YAML file, which implies we need to see the full uncensored playbook to tell you what would need to be changed.

Can you perhaps share this with everyone on github or gist, etc?

[bryan hunt]

Hi Michael,

I've put a POC in g...@github.com:picsolvebryan/ansible-vagrant-poc.git

I've got it pinned down now.

What is actually happening, I'm guessing is the variable ansible_env is only getting set once per execution.

I was using {{ansible_env['HOME']}} to figure out the correct location into which I would put a $HOME/.ssh/known_hosts file.

Using ansible_env was unreliable. If I included something that ran using sudo, it would set ansible_env['HOME'] to /root for the entire execution rather then regenerate it per-playbook. 

My kludge is to get those vars from system utils and register them for use by tasks defined further down the file. Like so:

   - name: Get value of unpriv user
     shell: /usr/bin/id -un
     register: effective_username

   # And this here, gives the correct homedir
   - name: Get homedir of unpriv user
     shell: "echo $HOME"
     register: effective_homedir

[Brian Coca]

ansible_env gets set when facts are gathered and of course user variables depend on which user was used to gather those facts.

--
Brian Coca
Stultorum infinitus est numerus
0110000101110010011001010110111000100111011101000010000001111001011011110111010100100000011100110110110101100001011100100111010000100001

Pedo mellon a minno

[bryan hunt]

Yes. Well surmised. Is there any way to re-trigger the gathering inside a playbook? 

--
You received this message because you are subscribed to a topic in the Google Groups "Ansible Project" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ansible-project/mwfEWx6iCmY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ansible-proje...@googlegroups.com.

[bryan hunt]

I think this has been answered in a previous post.

https://groups.google.com/forum/#!searchin/ansible-project/$20facts$20gathered/ansible-project/AGuHOnCgpc4/XIKaAnP3I-UJ

re-run the setup module, to get updated ansible_env

tasks:
   - action: setup

Thanks guys!

On Friday, January 3, 2014 3:00:22 PM UTC, bryan hunt wrote:

Yes. Well surmised. Is there any way to re-trigger the gathering inside a playbook? 

On 3 Jan 2014, at 14:55, Brian Coca <bria...@gmail.com> wrote:

ansible_env gets set when facts are gathered and of course user variables depend on which user was used to gather those facts.

--
Brian Coca
Stultorum infinitus est numerus
0110000101110010011001010110111000100111011101000010000001111001011011110111010100100000011100110110110101100001011100100111010000100001

Pedo mellon a minno

--
You received this message because you are subscribed to a topic in the Google Groups "Ansible Project" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ansible-project/mwfEWx6iCmY/unsubscribe.

To unsubscribe from this group and all its topics, send an email to ansible-project+unsubscribe@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.