"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?






On Fri, Jan 3, 2014 at 5:00 AM, bryan hunt <picsolvebr...@gmail.com> wrote:

> 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.
>
>
>
>
>
>
>
>
> On Thursday, January 2, 2014 9:50:48 PM UTC, Michael DeHaan wrote:
>
>> 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.
>>
>>
>>
>>
>>
>> On Thu, Jan 2, 2014 at 6:05 AM, bryan hunt <picsol...@gmail.com> wrote:
>>
>>>
>>> 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.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>  --
>>> 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/
>>
>>   --
> 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-project+unsubscr...@googlegroups.com.
> To post to this group, send email to ansible-project@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>



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

-- 
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-project+unsubscr...@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to