Skip to content
This repository has been archived by the owner on Oct 30, 2018. It is now read-only.

lookup password does not deal well with spaces in the path #1968

Closed
muelli opened this issue Aug 25, 2015 · 3 comments · Fixed by ansible/ansible#12256
Closed

lookup password does not deal well with spaces in the path #1968

muelli opened this issue Aug 25, 2015 · 3 comments · Fixed by ansible/ansible#12256

Comments

@muelli
Copy link

muelli commented Aug 25, 2015

In fact it breaks as can be seen in debops/debops-playbooks#185

>cat ansible/playbook.yml 

---

- hosts: localhost

  vars:

    dir: '/tmp/dir with spaces'

  tasks:

    - name: Lookup the password
      set_fact:
        pass: '{{ lookup("password", dir + "/subdir/password") }}'

    - name: Display password
      debug: var=pass
>
ansible-playbook --inventory-file=ansible/vagrant_ansible_inventory  -vv  ansible/playbook.yml 
 [WARNING]: provided hosts list is empty, only localhost is available


PLAY [localhost] ************************************************************** 

GATHERING FACTS *************************************************************** 
<localhost> REMOTE_MODULE setup
ok: [localhost]

TASK: [Lookup the password] *************************************************** 
fatal: [localhost] => Failed to template {{ lookup("password", dir + "/subdir/password") }}: need more than 1 value to unpack

FATAL: all hosts have already failed -- aborting

PLAY RECAP ******************************************************************** 
           to retry, use: --limit @/home/muelli/playbook.retry

localhost                  : ok=1    changed=0    unreachable=1    failed=0   

Removing the spaces helps.

@abadger
Copy link
Contributor

abadger commented Sep 1, 2015

This is a tough one as the password lookup plugin doesn't take structured parameters.... it takes a string of values and then attempts to parse it for sets of space separated parameters. The space separated nature conflicts with spaces embedded in file paths. It looks like this was an older style of writing lookup plugins that we'd like to move away from but it would be backwards incompatible to do so. Have to think about how best to achieve that.

@abadger
Copy link
Contributor

abadger commented Sep 1, 2015

After some discussion, we probably want to add an additional standard ways to specify and parse parameters to lookup plugins. So we'd officially support something like the following (examples only. Exact syntax subject to change as it's thought through):

- pass: "{{ lookup( 'password', [{ term: "/dir with spaces/", length: 25, } ]) }}"
- debug:
  msg: "{{ item }}"
  with_password:
  - term: "/dir with spaces/"
    length: 25
- debug:
  msg: "{{ item }}"
  with_password:
    - "/dir with spaces"

We would deprecate the former methods of specifying parameters:

- pass: "{{ lookup('password', '/dir_without_spaces length=25') }}"

I don't know if we'd continue to support the current style of arg passing that has support from the code when used via lookup() but not when used via when_* and that some plugins (for instance, password), are currently ignoring.

- pass: "{{ lookup('password', ["/dir with spaces"], length=25) }}"
# No when_password: style equivalent of the above.

These are ideas for post-2.0... not enough time until then to work one of these solutions to completion.

I'll look at whether we can add some sort of quote handling (A less hacky solution but quote parsing gets tricky quickly) or not parsing out key=value pairs if there's no "=" present (to indicate k=v pairs). The latter would be quite hacky but should work for your specific usecase.

@abadger
Copy link
Contributor

abadger commented Sep 4, 2015

@muell Okay, that's only fixed in devel (will be 2.0) but it should fix your issue. I don't think I'm going to push it back to 1.9.x as quite a bit of that code has been reorganized and refactored so there may be subtle bugs if I just try to copy it over. You can watch ansible/ansible#12255 if you are interested in how we make parameter passing more normalized in future releases. Don't expect anything before 2.0 is out the door though :-)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants