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

Created on 12 May 2015  路  10Comments  路  Source: saltstack/salt

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

Feature Platform State Module

Most helpful comment

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

All 10 comments

@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.

@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

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 } ]

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

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...

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:~#

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

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.

Not stale

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

Was this page helpful?
0 / 5 - 0 ratings