ansible_local does not work with connection: chroot

[ingomueller-net]

I can currently not able to run playbooks using connection: chroot with ansible_local. The problem is that the playbook is not run as root and there doesn't seem to be a mechanism to escalate privileges with the chroot connection plugin.

I guess that an option to choose the users that runs ansible-playbook would solve my problem.

Vagrant version

Vagrant 1.8.4

Files

Consider a setup with the following three files.

Vagrantfile

Vagrant.configure(2) do |config|
  config.vm.box = "ubuntu/trusty64"
  config.vm.provision "ansible_local" do |ansible|
    ansible.playbook = "playbook.yml"
    ansible.inventory_path = "inventory"
    ansible.limit = "all"
  end
end

playbook.yml

---
- hosts: all
  connection: local
  tasks:
  - debug: msg={{ inventory_hostname }}
    connection: chroot

inventory

/ # Do a "chroot" to /, this makes it unnecessary to setup a chroot environment for testing

Actual behavior

$ vagrant provision
==> default: Running provisioner: ansible_local...
    default: Running ansible-playbook...

PLAY [all] *********************************************************************

TASK [setup] *******************************************************************
ok: [/]

TASK [debug] *******************************************************************
fatal: [/]: FAILED! => {"failed": true, "msg": "chroot connection requires running as root"}

NO MORE HOSTS LEFT *************************************************************
        to retry, use: --limit @playbook.retry

PLAY RECAP *********************************************************************
/                          : ok=1    changed=0    unreachable=0    failed=1

Ansible failed to complete successfully. Any error output should be
visible above. Please fix these errors and try again.

Expected behavior

Running the playbook with sudo manually works:

vagrant@vagrant-ubuntu-trusty-64:/vagrant$ sudo ansible-playbook -i inventory playbook.yml

PLAY [all] *********************************************************************

TASK [setup] *******************************************************************
ok: [/]

TASK [debug] *******************************************************************
ok: [/] => {
    "msg": "/"
}

PLAY RECAP *********************************************************************
/                          : ok=2    changed=0    unreachable=0    failed=0

Steps to reproduce

1. Create above files in a folder
2. vagrant up

[gildegoma]

@ingomueller-net thanks for reporting this! This is so far the first ansible usage I see, where the become (aka sudo) per-task option cannot be used.

You said:

an option to choose the users that runs ansible-playbook would solve my problem.

For this problem, it would be enough to have the ability to run as root (i.e. via sudo call).

At first glance, I see three possible ways to fix it:

1. add a new privileged (boolean) option, similar to the shell provisioner.
2. add a new user (string) option (as suggested), and the ansible_local provisioner must try to run his commands as this user on the guest system
3. add a new raw_command_prefix (string) option (better naming still to be found). Here the idea would be to offer a multi-purpose unsafe™ to allow any kinds of customisations (in the same spirit of the existing raw_arguments and raw_ssh_args options). Better explained by some examples:

Example 1: to solve your problem: sudo ANSIBLE_TRANSPORT=chroot ⇨

cd /vagrant && sudo ANSIBLE_TRANSPORT=chroot \
PYTHONUNBUFFERED=1 ANSIBLE_FORCE_COLOR=true \
ansible-playbook --limit="all" --inventory-file=chroot-inventory chroot-test.yml

Example 2: to run as any user: sudo -u deploy ⇨

cd /vagrant && sudo -u deploy \
PYTHONUNBUFFERED=1 ANSIBLE_FORCE_COLOR=true \
ansible-playbook --limit="default" --inventory-file=/tmp/vagrant-ansible/inventory -v ping.yml

[gildegoma]

I need more thinking about the above ideas, but for now, I'd like to consider implementing the option 3, which has the advantage to give a wildcard for many (any?) advanced usages (e.g. any user, any ANSIBLE_... environment variable, etc.). That said, I am also in favour of the alternative 1 (privileged) which is quite trivial to implement and document.

---

@ingomueller-net In the meantime, you could build your own vagrant base box, where root would be the vagrant ssh user and it will work immediately.

[ingomueller-net]

Thanks @gildegoma, for the moment that works (although it is not ideal, I need to set a root password manually first).

[jhosteny]

@gildegoma Alternative 1 would be quite useful.

[alexahn]

@gildegoma I also think option one would be useful.