Using tilde (~) in destination for unarchive module

766 views
Skip to first unread message

Chip Selden

unread,
Nov 19, 2014, 12:21:29 PM11/19/14
to ansible...@googlegroups.com
Hey all,

I'm trying to unzip a file into a directory relative to the home directory on a host server. The problem is that when Ansible runs the unarchive module, it replaces the tilde in the variable with master server's home directory instead of the host server's. The file module correctly creates the directory on the host server. Here's the playbook I'm using

- hosts: myhost
  vars:
    mydir: "~/folder1/folder2/"
  user: myuser
  tasks:
  - name: Ensure the parent directory is present
    file: >
      path={{ mydir }}
      state=directory
  - name: Unzip the file into the host
    unarchive: >
      src=/ansible/archive/file.zip
      dest={{ mydir }}

Is there some argument I can give to unarchive so that it tries to unzip into the right directory? I've tried setting the HOME environment variable to the correct home directory on the host, but that does not make a difference.

Thanks,
Chip

Brian Coca

unread,
Nov 19, 2014, 12:24:48 PM11/19/14
to ansible...@googlegroups.com
from the unarchive docs:

- copy
        if true, the file is copied from the 'master' to the target
        machine, otherwise, the plugin will look for src archive at
        the target machine. (Choices: yes, no) [Default: yes]


by default unarchive assumes you are copying the file from the master server, try adding copy=no to your tasks.


--
Brian Coca

Chip Selden

unread,
Nov 19, 2014, 12:33:07 PM11/19/14
to ansible...@googlegroups.com
Thanks for the reply.

I am copying the zip file from the master server to the host, so I cannot set copy to 'no'.

As a workaround, I could copy the zip file onto the host first, and then unarchive while setting copy to 'no', but I'd rather do it all in one step without copying the zip file to the 'host'.

Brian Coca

unread,
Nov 19, 2014, 1:20:22 PM11/19/14
to ansible...@googlegroups.com
I'm sorry, I misunderstood, unarchive should never resolve on master the 'dest' unless it is also the target.



--
Brian Coca

Toshio Kuratomi

unread,
Nov 20, 2014, 10:28:11 AM11/20/14
to ansible...@googlegroups.com

Do note, there were some places in the code that mistakenly expanded the tilde on the ansible controller side that were fixed recently.  Are you using ansible 1.7.2 or are you using a checkout of development?  If you can give us a minimal playbook to reproduce I could see if it has been fixed.

-Toshio

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAJ5XC8%3DvPofEx4whV%3Df0wcj5s7HLdN6h%3DoZCZ3LpNmANBy4fUQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Chip Selden

unread,
Nov 20, 2014, 8:07:08 PM11/20/14
to ansible...@googlegroups.com
Toshio,

I am currently using 1.7.2

The text above should be enough of a playbook for you to reproduce the issue. Here it is again below. Just use any host, user and zip file you have to try it out. The issue occurs when unarchiving into the host "dest" directory which doesn't exist because the tilde was evaluated as the home directory of the master server (for that reason, make sure the home directories of your master and host are not the same).

---
- hosts: [somehost]
  vars:
    mydir: "~/folder/subfolder/"
  user: [someuser]
  tasks:
  - name: Ensure the parent directory is present
    file: >
      path={{ mydir }}
      state=directory
  - name: Unzip the file into the host
    unarchive: >
      src=/some/master/directory/file.zip
      dest={{ mydir }}

Toshio Kuratomi

unread,
Nov 21, 2014, 10:47:37 AM11/21/14
to ansible...@googlegroups.com
Hey Chip, I can confirm that the unarchive module is not handling the
tilde correctly in 1.7.2 and the bug is fixed in the devel branch.

The following two commits implemented the fix:

https://github.com/ansible/ansible/commit/bc4272d2a26e47418c7d588208482d05a34a34cd

https://github.com/ansible/ansible/commit/565e5bbdfc42afe29c4f53b303352d7e8406dcba

We're hoping to have 1.8 out very soon which should have the fix in it.

-Toshio
> https://groups.google.com/d/msgid/ansible-project/5cd98f33-cc03-4cca-b670-c763a638275f%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages