states.archive doesn't support gzip, whereas modules.archive does

[froztbyte]

Found this: https://github.com/saltstack/salt/blob/develop/salt/states/archive.py#L209

Seems that states.archive could possibly make use of the same code that modules.archive does, but right now it doesn't. A general usecase for this would be something like the Maxmind Geolite DBs: http://geolite.maxmind.com/download/geoip/database/GeoLite2-City.mmdb.gz

[jfindlay]

@froztbyte, I have been equally annoyed at this divergence and it is on my list of things to fix, although I would gratefully support anyone else fixing it. Generally states should consist of higher level code that use execution modules to do the lower level work. Thanks for the report.

[froztbyte]

@jfindlay no stress. I don't reckon I could really do much in the way of code on this atm (although I will give it a read to see, maybe I surprise myself). Fully willing to test it my side and see if I can break it, though

[evanpurkhiser]

Ran into this today while trying to have the GeoLite2 databases downloaded. They are just gzipped files.

Actually a little surprised this wasn't supported!

Here's the solution I came up with to work around this:

GeoIP database:
  # The archive.extracted state doesn't currently support gunzip.
  # https://github.com/saltstack/salt/issues/23588
  file.managed:
  - name: /usr/local/share/GeoLite2-City.mmdb.gz
  - source: http://geolite.maxmind.com/download/geoip/database/GeoLite2-City.mmdb.gz
  - source_hash: md5=160e35291d399326f097a65f4935c2fa
  - unless: ls /usr/local/share/GeoLite2-City.mmdb

  module.run:
  - name: archive.gunzip
  - gzipfile: /usr/local/share/GeoLite2-City.mmdb.gz
  - onchanges: [ { file: /usr/local/share/GeoLite2-City.mmdb.gz } ]

[zolech]

Exactly same problem here with downloading geolite db. Thanks for the solution @evanpurkhiser !

[lorengordon]

Can someone provide an example state and the debug output where it is not working? I can maybe squeeze in some time this week to investigate the issue.

Also, the archive.extracted state looks to have gotten a ton of work for the Carbon (2016.11) release. So, maybe test against that first to see if maybe this is working now...

[jellisii]

Ubuntu 16.04 has the package 'php-apcu'. It includes /usr/share/doc/php-apcu/apc.php.gz.

me@mybox:~# lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 16.04.4 LTS
Release:	16.04
Codename:	xenial
me@mybox:~# ls -la /usr/share/doc/php-apcu/
total 76
drwxr-xr-x   2 root root  4096 Feb 22 12:13 .
drwxr-xr-x 662 root root 24576 Apr  9 11:19 ..
-rw-r--r--   1 root root 10634 Jan 15  2016 apc.php.gz
-rw-r--r--   1 root root   756 Apr  4  2016 changelog.Debian.gz
-rw-r--r--   1 root root  3721 Jan 26  2016 copyright
-rw-r--r--   1 root root  1738 Jan 15  2016 NOTICE
-rw-r--r--   1 root root   714 Jan 26  2016 README.Debian
-rw-r--r--   1 root root  1257 Jan 15  2016 README.md
-rw-r--r--   1 root root  4994 Jan 15  2016 TECHNOTES.txt.gz
-rw-r--r--   1 root root  1413 Jan 15  2016 TODO
me@mybox:~# 

Given these, it's assumed that the following should work:

test_extract_apcu:
    archive.extracted:
        - name: /tmp/
        - source: /usr/share/doc/php-apcu/apc.php.gz

However, it responds with the following:

----------
          ID: test_extract_apcu
    Function: archive.extracted
        Name: /tmp
      Result: False
     Comment: Could not guess archive_format from the value of the 'source' argument. Please set this archive_format to one of the following: tar, rar, zip
     Started: 11:28:40.723009
    Duration: 1.721 ms
     Changes:  

Setting archive_format to any of the options listed fails, but you can unzip the file using module_run

extract_apcu:
    file.managed:
        - name: /var/www/apcu/apc.php.gz
        - source: /usr/share/doc/php-apcu/apc.php.gz
    module.run:
        - name: archive.gunzip
        - gzipfile: /var/www/apcu/apc.php.gz

----------
          ID: extract_apcu
    Function: file.managed
        Name: /var/www/apcu/apc.php.gz
      Result: True
     Comment: File /var/www/apcu/apc.php.gz is in the correct state
     Started: 11:29:55.217235
    Duration: 1.158 ms
     Changes:   
----------
          ID: extract_apcu
    Function: module.run
        Name: archive.gunzip
      Result: True
     Comment: Module function archive.gunzip executed
     Started: 11:41:18.760133
    Duration: 14.044 ms
     Changes:   
              ----------
              ret:

versions report from mybox

me@salt:~# salt mybox test.versions_report
mybox:
    Salt Version:
               Salt: 2017.7.4
     
    Dependency Versions:
               cffi: Not Installed
           cherrypy: Not Installed
           dateutil: 2.4.2
          docker-py: Not Installed
              gitdb: Not Installed
          gitpython: Not Installed
              ioflo: Not Installed
             Jinja2: 2.8
            libgit2: Not Installed
            libnacl: Not Installed
           M2Crypto: Not Installed
               Mako: 1.0.3
       msgpack-pure: Not Installed
     msgpack-python: 0.4.6
       mysql-python: 1.3.7
          pycparser: Not Installed
           pycrypto: 2.6.1
       pycryptodome: Not Installed
             pygit2: Not Installed
             Python: 2.7.12 (default, Dec  4 2017, 14:50:18)
       python-gnupg: Not Installed
             PyYAML: 3.11
              PyZMQ: 15.2.0
               RAET: Not Installed
              smmap: Not Installed
            timelib: Not Installed
            Tornado: 4.2.1
                ZMQ: 4.1.4
     
    System Versions:
               dist: Ubuntu 16.04 xenial
             locale: UTF-8
            machine: x86_64
            release: 4.14.17-x86_64-linode99
             system: Linux
            version: Ubuntu 16.04 xenial
     
me@salt:~# 

[mglaske]

This is kinda silly. any response yet on this? It would also be nice if this supported file_mode and dir_mode.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

[mchugh19]

Not stale

[stale[bot]]

Thank you for updating this issue. It is no longer marked as stale.