unarchive requirements?

Archives Ansible Project
1

Greetings,

According to the documentation unarchive requires tar/unzip to work…

However it appears from my first attempt at using it that it requires GNU tar to work. Reading through the code it looks like it tries to determine what the archive format is and then supplies appropriate GNU tar options to the tar command in order to carry out its tasks.

I haven’t tested yet, but I suspect that I could provide it with an uncompressed tar file and have it work on AIX, but it certainly doesn’t work with a compressed one.

Does anyone have any thoughts on this? I’m not sure how you could improve the module though…

Adam

2

Since I'm already taking a look for issues with BSD directory detection, I
might take a stab at making sure it is 'POSIX tar' compliant, sadly I have
a lot of experience with that.

3

So it seems the big issue is having the compression support in tar (as GNU tar has), for other implementations we would need to always call the decompression program (gzip, etc).

4

Just encountered this on a HP-UX server…

ansible -i inventory/test_hosts rx2600-hpux11iv3-x64 -u root -m shell -a “which tar”

rx2600-hpux11iv3-x64 | success | rc=0 >>
/usr/bin/tar

I suppose it would be nice to test the detected tar command flags, if we detect a ‘z’ option, use it, if not - do this in 2 steps - uncomress and unarchive

ansible -i inventory/test_hosts rx2600-hpux11iv3-x64 -u root -m shell -a “tar z”

xavi-rx2600-hpux11iv3-x64 | FAILED | rc=1 >>
tar: z: unknown option

And failover to a 2 step solution.

5

We’re unlikely to want to run the extra steps to do the test all the time, and it would complicate the module considerably, I’d accept a PR to add a hint to the unarchive module though.

6

Thanks,

if we can have a new parameter to explicitly tell the module to use 2 steps, like, gunzip and then tar xf it would cover this non GNU tar situations.

7

gnu=no (default yes) maybe?

8

Hi,

gnu=no/yes is great.

BTW, if we have other commands inside modules relying on GNU perhaps it will be good to have also a system level parameter that will affect all such modules.

9

We don’t have any facility for module defaults like that at this time, so that may have to be considered later.

I’d consider it now if we didn’t have so many other things to consider first :slight_smile:

But yes, in this case, let’s make gnu=yes/no so.