unarchive does not work on initial unpacking remote archive #2936
Comments
|
I'm having the exact same problem for 2.0.0.2. The problem doesn't occur when i unarchive within the same host. |
|
The problem is that the unarchive module first performs a idempotency check to see if the archive is already extracted. This is done using It looks like there is no option to make tar ignore non-existing files. A possible solution might be to redirect stderr output from the |
|
Getting this error on 2.0.1.0 as well while unarchiving on a remote host. |
|
Btw @Hubbitus, this problem is not limited to remote downloads. I also get error messages with local archive files, so the issue title should reflect that. |
|
Not sure if this is one of those anti-plus-one repos, but uhh... +1. |
|
I have also just encountered this issue on Ubuntu 14.04. This is quite strange since I've successfully run this command on many prior hosts with the same environment. Does anyone know under which conditions this command could fail? If I separate the downloading to a separate step using get_url, then extracting locally, it seems to be fine. |
|
I think I narrowed this issue down slightly. It suddenly popped up in a previously working playbook so I did some experiments and apparently it only happens when Ansible is running in pipelining mode (which I had just recently turned on). |
|
@angryzor Ah yes, you are correct! I have also just recently turned on pipelining, and it must be that change that started to cause this failure. |
|
+1, happens only when pipelining is on! |
|
I am just dying to know how a "core-module" can be shipped in such a state. Have you ever heard of this thing called "automated testing"? Or do you just enjoy attention (which you get when it breaks)? If any prospective new users of Ansible are reading this; my recommendation is to not use Ansible. |
|
+1, happens only when pipelining is on! |
|
I can see Ansible is very well tested... |
|
This has been fixed for 2.1.0, I believe with this commit: 983cdd0 @Hubbitus I also saw your separate remark: "And it creates /opt/jmeter/apache-jmeter-2.13 directory for some reason. It also is not desired as I want see its content directly in /opt/jmeter/." Unfortunately, that's out of scope for the unarchive module. apache-jmeter-2.13 is part of the directory structure inside of the tarball. tar does not have a way to rewrite the directory structure from inside the tarball on the fly so unarchive doesn't either. Closing as fixed in 2.1.0. |
|
@Hubbitus If we implement a native/pure-python unarchive, we could easily add an option to strip paths from the archive which would work for all archive types. Stay tuned... |
|
@abadger thank you for the fixing. @dagwieers could you please post links to documentation on that new plugin and that particular option? |
|
@Hubbitus Cannot post links to something that does not exist yet. |
|
I checked the commit, and it adds a regex to check for missing files :
Which means it only works if the remote server is running in English... No such luck here, my remote server is in French, so the message is : "Aucun fichier ou dossier de ce type". You shouldn't rely on English messages in modules. |
|
@ShortyFR What commit did you check ? It helps to be explicit in your communication. We have no other option than to parse the output from gtar (unless we reimplement using |
|
I checked the commit mentioned in the fix message : 983cdd0 (AFAIK it's the only commit mentioned here). The locale does indeed seem to be a concern since I actually have errors like this on Ansible 2.1 :
|
|
If you look in the devel branch, you will see that it is already fixed. We are forcing |
|
I can't update to 2.2 because ansible comes with SLEP 11 and I have no way to install from source due to a number of errors. My question is how to patch 2.0.2.0 with the bug-fixed unarchive. |
|
It's not impossible, but you have to start from the unarchive module from the devel branch. Then remove all the newer functionality in the module API. E.g. the parameter typing, diff-mode, etc... Unfortunately, because of the various changes in the interface, we cannot take newer modules and use them as-is on older Ansible releases. (This used to work, but not lately) |
|
I had a same issue. I think that .tgz extension is not supported 2.1.0.0? |
|
The task is: unarchive: src={{pkgrepo}}/apache/maven/apache-maven-{{mvnver}}-bin.tar.gz dest=/usr/local creates=/usr/local/apache-maven-{{mvnver}} copy=no And the error I was facing is: path /usr/local/apache-maven-3.3.9/boot/plexus-classworlds-2.5.2.jar does not exist But it worked when the LANG=C was defined in the command: LANG=C ansible-playbook playbook.yml On Ansible 2.1.0.0. |
|
It also works when were defined the following environment variables, inside the playbook: |
|
This fix is the dirtiest of them all. As ShortyFR said: "You shouldn't rely on English messages in modules." |
|
Guys, read the various reports instead of stating the obvious (over and Using gtar is a real pain, but it's what we currently have. I wish it was
|
|
This is still an issue for me with 2.2.0.0. yields: Tried the lang and pipeline workaround above to no avail. Re-running on failed hosts until they all worked worked. (50% of hosts, each run, would work) |
|
Still broken on 2.2.1.0 no extra options -- works---
- hosts: localhost
connection: local
become: no
gather_facts: no
tasks:
- name: install protoc to allow for protobuf generation
unarchive:
src: https://github.com/google/protobuf/releases/download/v3.0.2/protoc-3.0.2-linux-x86_64.zip
copy: no
dest: /tmp/testextra options -- fails and also writes to the filesystem!---
- hosts: localhost
connection: local
become: no
gather_facts: no
tasks:
- name: install protoc to allow for protobuf generation
unarchive:
src: https://github.com/google/protobuf/releases/download/v3.0.2/protoc-3.0.2-linux-x86_64.zip
copy: no
extra_opts: ['bin/protoc']
dest: /tmp/test |
and others
Issue Type:
Ansible Version:
Ansible Configuration:
Fedora installation without much changes
Environment:
Fedora 23
Summary:
Remote download future which introduced in ansible 2.0 does not work when you run it for new archive.
Steps To Reproduce:
Playbook role:
Default variables:
Expected Results:
Tarball downloaded and content unpacked into /opt/jmeter
Actual Results:
There MUCH of output, which is discussed in #74
So if I try run that command manual on server (CentOS 7) got similar result:
If I change
--diffto--extractit will be run correct:And it creates
/opt/jmeter/apache-jmeter-2.13directory for some reason. It also is not desired as I want see its content directly in/opt/jmeter/.But what more interesting, all subsequent
--diffinvocation will run fine:The text was updated successfully, but these errors were encountered: