saltstack / salt-winrepo-ng Goto Github PK

View Code? Open in Web Editor NEW

104.0 36.0 179.0 3.3 MB

Jinja templated winrepo

License: Other

SaltStack 82.30% Python 2.68% Batchfile 4.52% PowerShell 10.50%

salt-winrepo-ng's People

Contributors

Stargazers

Watchers

Forkers

thebigbear twangboy fastmarkets-devops-archive kitplummer alkivi-sas sjd-risca breshead averroes xetus-oss oro trdenton rrzaripov morningsong msielicki m03 spillmantech moebiuseye msarahan danielcb nicoschoenicke marwooj nevins-b adnanjp ehealth-oncall blade2005 lorengordon travix-international utahdave sdemura jmacfar mrueg tnahak lubyou 71mb0 jbest84 dafyddj kevops michaelh-fb liquidblack blackstoneaudio westurner xenokd myii damon-atkins timelord901 alexproca tully32 jzacharie vlcinsky fizmat kaiqinetwork nmb88 ch3ll necroscope lifan3333 nbirnel marceloneil cruscio kenoboss couilllard45682 mm-angelalonso heinleinsupport riagit kaluznyt kaikugler songkamongkol vernondcole vcsi grepler gabrielloberg dwoz mradzio scriptingwithpython ermalk thaligar micsoftvn eole bradleyjokinen prensing andrii-rymar pauldalewilliams poddo samjhandley markuskont kussatom nicccccccccccck watchmen-test itamarjp clarcom-sparkcog anthokad nickj pratibhashah1 lf13579 apoloniogg pombredanne viorelfoamete spacefish stratusjerry johnripperdec ltcsystems

salt-winrepo-ng's Issues

Chocolatey as requisite in SLS

My SLS file:

chocolatey:
  pkg.installed:
    - require:
      - pkg: dotnet

visualstudio2015professional:
  chocolatey.installed:
    - require:
      - pkg: chocolatey

when I run highstate I get:

          ID: chocolatey
    Function: pkg.installed
      Result: False
     Comment: The following packages failed to install/update: chocolatey=0.9.9
     Started: 17:00:22.464000
    Duration: 7612.0 ms
     Changes:
              ----------
              chocolatey:
                  ----------
                  install status:
                      success
----------
          ID: visualstudio2015professional
    Function: chocolatey.installed
      Result: False
     Comment: One or more requisite failed: tester.chocolatey
     Started:
    Duration:
     Changes:

please note that:

chocolatey actually installs and works
it even returns:

                  install status:
                      success

but salt treats this as error:
packages failed to install/update

I tried both installing chocolatey via chocolatey.bootstrap or using SLS as stated above. Both times choco installed and worked just fine.

May be that's because it:
https://github.com/saltstack/salt-winrepo-ng/blob/master/chocolatey.sls
actually installs the latest choco, which is 0.10, not 0.9.9 as mentioned in registry keys.

I know there is another issue about choco exit codes:
saltstack/salt#34099

but that issue bescribes installing software with choco, whereas my - installing choco itself.

salt 2016.3.2 (Boron)
salt-minion 2016.3.2 (Boron)
minion os: Windows 7

duplicate ID errors

For a view weeks now I keep seeing these errors:

failed:
        3
    failed_list:
        ----------
        salt-winrepo-ng\duplicati.sls:
            - package 'duplicati', repo data for version number skip_urltest is not defined as a dictionary
        salt-winrepo-ng\intellij-community.sls:
            - Failed to compile 'salt-winrepo-ng\intellij-community.sls': Conflicting ID '1'
        salt-winrepo-ng\intellij-ultimate.sls:
            - Failed to compile 'salt-winrepo-ng\intellij-ultimate.sls': Conflicting ID '1'

Is this related to my setup? As far as I can see both packages use different IDs and a for loop with just one version. I'm not sure where the conflicting ID is coming from.

64bit ProgramFiles: question

I'm seeing this convention in the package definitions and it seems backward to me... maybe I am not understanding properly where windows puts 64bit executables.

# just 32-bit x86 installer available
{% if grains['cpuarch'] == 'AMD64' %}
    {% set PROGRAM_FILES = "%ProgramFiles(x86)%" %}
{% else %}
    {% set PROGRAM_FILES = "%ProgramFiles%" %}
{% endif %}

Illegal tab character in putty.sls

sudo salt -G 'os:windows' pkg.refresh_db yields the following (elided) error message.

    ERROR: Error occurred while generating repo db. Additional info follows:
    
    failed:
        1
    failed_list:
        ----------
        salt-winrepo-ng\putty.sls:
            - Failed to compile 'salt-winrepo-ng\putty.sls': Illegal tab character; line 8

salt 2018.03: installer command line switch changes

Just flagging up that the salt-minion package will require changing based on changes to the installer's handling of config files. Link

Add removal of out of date JRE versions to JRE8 installers?

I would like to propose to add

REMOVEOUTOFDATEJRES=1 (remove out of date JRE versions)
(and maybe AUTO_UPDATE=0 (disable autoupdate) also)

to the JRE8 states, since I think those are sane defaults for those installers (remove out of date for obvious reasons and auto update because we manage JRE via saltstack and this way we don't have any other tools interfering. Also jres auto_updater does not work unattended anyways, so..)

https://docs.oracle.com/javase/8/docs/technotes/guides/install/config.html#table_config_file_options

Any opinions on this?

inkscape.sls

I believe the revision has increased to 0.92 for all platforms now.. Proposed revision to inkscape.sls;

inkscape: '0.92': full_name: 'Inkscape 0.92' {% if grains['cpuarch'] == 'AMD64' %} installer: 'https://inkscape.org/en/gallery/item/10559/Inkscape-0.92.0-x64.msi' uninstaller: 'https://inkscape.org/en/gallery/item/10559/Inkscape-0.92.0-x64.msi' {% elif grains['cpuarch'] == 'x86' %} installer: 'https://inkscape.org/gallery/item/10558/Inkscape-0.92.0.msi' uninstaller: 'https://inkscape.org/gallery/item/10558/Inkscape-0.92.0.msi' {% endif %} install_flags: '/qn /norestart' uninstall_flags: '/qn /norestart' msiexec: True locale: en_US reboot: False

current Cyberduck version - uninstall issue

Hi,

I want to update the Cyberduck state (salt version 2018.3.3 + Windows Server 2019 Client), because newer versions also as MSI package available and the uninstall procedur has been changed
But I don't understand why only the installation works and not also the uninstall as well. I have tried it with various MSI uninstall parameters, unfortunately always with no success. With the exe installer I have the same problem.

cyberduck:
{% for major, subversions in versions.items() %}
{% for minor in subversions %}
  '{{major}}.{{minor}}':
    full_name: 'Cyberduck {{major}}'
    installer: '{{source_path}}/Cyberduck-Installer-{{major}}.{{minor}}.msi'
    uninstaller: '{{source_path}}/Cyberduck-Installer-{{major}}.{{minor}}.msi'
    install_flags: '/qn'
    uninstall_flags: '/qn'
    msiexec: True
    locale: en_US
    reboot: False
{% endfor %}
{% endfor %}

Console Output

> salt 'win2019' pkg.install cyberduck
win2019:
    ----------
    Cyberduck:
        ----------
        new:
            6.9.0.29768
        old:
    cyberduck:
        ----------
        install status:
            success
salt 'win2019' pkg.remove cyberduck
win2019:
    ----------
    cyberduck:
        ----------
        current:
            not installed

Seeking advice on how to handle installers that do not set DisplayVersion in the registry

I have an sls that installs CouchDB:

couchdb:
  '1.6.1':
    full_name: 'Apache CouchDB 1.6.1'
    installer: 'https://dl.bintray.com/apache/couchdb/win/1.6.1/setup-couchdb-1.6.1_R16B02.exe'
    install_flags: '/VERYSILENT /DIR={{ grains['program_files'] }}\\CouchDB'
    msiexec: False
    reboot: False

but after installing, salt is unaware which version was installed:

----------
          ID: couchdb
    Function: pkg.installed
      Result: False
     Comment: The following packages failed to install/update: couchdb=1.6.1
     Started: 17:03:55.342000
    Duration: 82181.0 ms
     Changes:   
              ----------
              couchdb:
                  ----------
                  new:
                      Not Found
                  old:

I finally tracked down the issue and it is because the CouchDB installer doesn't set the DisplayVersion registry entry needed by salt. I have worked around this issue by using the windows registry state:

{% set COUCHDB_VERSION = '1.6.1' %}
couchdb:
  pkg:
    - version: {{ COUCHDB_VERSION }}
    - installed

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\ApacheCouchDB_is1:
  reg.present:
    - vname: DisplayVersion
    - vdata: {{ COUCHDB_VERSION }}
    - vtype: REG_SZ

But using this workaround, a highstate always reports a failure the first time it is executed (then success every time afterwards). I attempted to set the registry entry before running the installer, but the installer overwrites the key during the installation process.

Looking for advice on on any better way to solve this issue.

atom.sls syntactically broken (pkg.refresh_db fails)

In salt-winrepo-ng/atom.sls, the syntax:

atom:
  {% for version in ['1.23.3', '1.8.0', '1.7.3] %}
  '{{ version }}':

is broken, and trying to do a pkg.refresh_db fails with the error:

        salt-winrepo-ng\atom.sls:
            - Failed to compile 'salt-winrepo-ng\atom.sls': Jinja syntax error: expected token ',', got '{'; line 3

              ---
              atom:
                {% for version in ['1.23.3', '1.8.0', '1.7.3] %}
                '{{ version }}':    <======================

To fix, we simply need an extra ' mark at the end of the last version number:

atom:
  {% for version in ['1.23.3', '1.8.0', '1.7.3'] %}
  '{{ version }}':

Using grains['locale_info']['defaultlanguage'] as a locale

I'm thinking this is probably a good idea for package
that were translated in a very large number of languages, especialy GUI applications.

(I have to say I'm very frustrated that the only available
option is to install things in american english)

For packages that do not provide all translations,
I may systematicaly try something like this, for every sls file:

# Using defaultlanguage only for available translations
{% if grains['locale_info']['defaultlanguage'] in ['en_US', 'es_ES', 'fr_FR', 'de_DE', 'etc.'] %}
{% set locale = grains['locale_info']['defaultlanguage'] %}
{% else %}
{% set locale = "en_US" %}
{% endif %}

And then using that locale variable for the installer:

    - locale: {{locale}}

Please tell me if something is preventing us from doing this.
If we can do this, I'll make a pull request for the following sls files:

libreoffice
openoffice
firefox
gimp
chrome

I will be testing and validating this with Windows Server 2008 RC2 and Windows Seven Pro.

Please tell me if you know of other software that you think can be safely added to this list.

Thank you.

Spybot anti-beacon

Can we have a .sls file for spybot anti-beacon?

Allowing relocation of repo downloaded binaries

Now that it's technically possible due to the Jinja templating, could we allow relocation of the downloaded binaries without having to fork the repo and maintain patches?

For example, lines like:

installer: 'salt://win/repo-ng/cpu-z/cpu-z_1.71.1-setup-en.exe'

Could become:

installer: 'salt://{{ salt["pillar.get"]("repo_binary_root", "win/repo-ng") }}/cpu-z/cpu-z_1.71.1-setup-en.exe'

I don't think there's a way to fetch the actual configuration value without enabling the option that makes the master config visible on minions.

If people agree this is a reasonable idea I'd be happy to send a PR.

nsclient.sls: Wrong version string

Hi,

just tried to install the nsclient package in the latest available version, which is 0.5.0.62 according to the SLS. However, after installation I get:

----------
          ID: nsclient
    Function: pkg.installed
      Result: False
     Comment: The following packages failed to install/update: nsclient=0.5.0.62
     Started: 14:41:06.488000
    Duration: 20734.0 ms
     Changes:
              ----------
              nsclient:
                  ----------
                  new:
                      0.5.0062
                  old:
----------

Please fix.

vim installation requires GUI input

While installing vim from winrepo-ng from the minion, I got a dialog asking whether I wanted to install gvim. I suspect that's what caused the salt apply to hang if I do it from the master.

AFAIK, the standard vim installer does not support unattended installation, but the one from the cream project does

Installation of GNU Coreutils sums references bad path

Description of Issue/Question

Installation of GNU sums on a Windows 2012 R2 minion with 2017.7.2 fails with the following error:

[root@saltmaster salt]# salt -G 'os:windows' pkg.install sums
winmin4:
    ERROR: Specified cwd '@powershell -NoProfile -ExecutionPolicy unrestricted -Command "$shell = new-object -com shell.application
    $shell = new-object -com shell.application
    $source = "http:\\www.nfllab.com\sums\sums611.zip"
    $destination = "c:\tmp\sums611.zip"
    Invoke-Webrequest $source -OutFile $destination
    $shell2 = new-object -com shell.application
    $zip = $shell.NameSpace('c:\tmp\sums611.zip')
    foreach($item in $zip.items()) { $shell.Namespace('c:' either not absolute or does not exist

Setup

Follow instructions for configuring Winrepo and then attempt to install the sums package with salt '<windows minion>' pkg.install sums

Versions Report

Salt Version:
           Salt: 2017.7.2
 
Dependency Versions:
           cffi: 1.10.0
       cherrypy: 10.2.1
       dateutil: 2.6.0
      docker-py: Not Installed
          gitdb: 2.0.3
      gitpython: 2.1.3
          ioflo: Not Installed
         Jinja2: 2.9.6
        libgit2: Not Installed
        libnacl: Not Installed
       M2Crypto: Not Installed
           Mako: 1.0.6
   msgpack-pure: Not Installed
 msgpack-python: 0.4.8
   mysql-python: Not Installed
      pycparser: 2.17
       pycrypto: 2.6.1
   pycryptodome: Not Installed
         pygit2: Not Installed
         Python: 2.7.13 (v2.7.13:a06454b1afa1, Dec 17 2016, 20:53:40) [MSC v.1500 64 bit (AMD64)]
   python-gnupg: 0.4.0
         PyYAML: 3.11
          PyZMQ: 16.0.2
           RAET: Not Installed
          smmap: 2.0.3
        timelib: 0.2.4
        Tornado: 4.5.1
            ZMQ: 4.1.6
 
System Versions:
           dist:   
         locale: cp1252
        machine: AMD64
        release: 2012ServerR2
         system: Windows
        version: 2012ServerR2 6.3.9600  Multiprocessor Free

new 2015.8.4 is on repo , shall I change the salt-winrepo and salt-winrepo-ng sls files?

@twangboy @jfindlay I see the new 2015.8.4 is uploaded to the saltstack repo in https://repo.saltstack.com/windows/ is it 'OK' for me to change the salt-winrepo and salt-winrepo-ng salt-minion sls files now?

Or should I wait it out a little longer?
Until the 2015.8.4 release is official and the ubuntu/debian/rhel etc pkgs are out as well?

[libreoffice] pkg.install gets 404 error while downloading MSI

Seems the package isn't available anymore on the given mirror:

      File "c:\salt\bin\lib\site-packages\salt\fileclient.py", line 628, in get_url
        raise MinionError('Error: {0} reading {1}'.format(query['error'], url))
    MinionError: Error: HTTP 404: Not Found reading http://mirror.catn.com/pub/tdf/libreoffice/stable/5.2.1/win/x86_64/LibreOffice_5.2.1_Win_x64.msi

Please update to a newer version or use a different mirror.

Jinja syntax error: xming.sls

Seeing this in my windows minion logs. Do the backslashes need to be escaped in the uninst path?

2015-11-13 06:13:31,439 [salt.fileclient  ][INFO    ][1964] Fetching file from saltenv 'base', ** done ** u'win/repo-ng
/salt-winrepo-ng/xming.sls'
2015-11-13 06:13:31,831 [salt.utils.templates][ERROR   ][1964] Rendering exception occurred :Jinja syntax error: Unexpe
cted end of template. Jinja was looking for the following tags: 'endfor' or 'else'. The innermost block that needs to b
e closed is 'for'.; line 13

---
[...]
ccleaner:
  '{{ version }}':
    full_name: 'CCleaner'
    installer: 'http://download.piriform.com/ccsetup{{ dl_version }}.exe'
    install_flags: '/S'
    uninstaller: '{{ PROGRAM_FILES }}\CCleaner\uninst.exe'    <======================
    uninstall_flags: '/S'
    msiexec: False
    locale: en_US
    reboot: False

---
2015-11-13 06:13:33,453 [salt.utils.templates][ERROR   ][1964] Rendering exception occurred :Jinja variable 'Program_Files' is undefined�

Jenkins CI Testing for salt-winrepo-ng

Suggestion

Pull down the latest production release.
Setup a Master Linux and Minion Windows
Run pkg.refresh_db on the Windows Minion
Check for errors.

Install dotnet: Unable to locate package dotnet

For some reason I can't install dontnet package.
All other packages (git, npp, 7zip) installed properly.

I called:
sudo salt-run winrepo.update_git_repos
sudo salt '*7' pkg.refresh_db
which printed a big list of packages including dotnet:
c:\salt\var\cache\salt\minion\files\base\win\repo-ng\salt-winrepo-ng\dotnet.sls

this file actually exists on minion, but when I try to install it:
sudo salt '*7' pkg.install dotnet

I get the following:

    dotnet:
        Unable to locate package dotnet

salt version: 2016.3
minion os: Windows 7 x64

Hash distribution files (feature request)

In some other package building frameworks such as PKGBUILD and Pkgsrc, distribution files can be checked against a hash to ensure the file that is being installed is identical to the file used during package creation by the packager. This seems even more valuable to salt-winrepo-ng as we are installing binaries from many other untrusted locations.

I propose something like the following

mypkg:
  '1.0.0':
    full_name: 'My Package 1.0.0'
    installer: 
        - url: 'https://ihopethisdomaindoesntgettakenoveroneday.com/mypkg.exe'
        - sha256: 16aba5393ad72c0041f5600ad3c2c52ec437a2f0c7fc08fadfc3c0fe9641d7a3

One temporary workaround is to fork all desired packages on this repo and use an installer: url that points to a trusted location hosting all needed installers.

How to best handle custom installation paths

I need to install most packages (aside from salt itself) into the path D:\Program Files to achieve this I have used a custom grain called program_files in my package sls files:

nodejs:
  '5.7.1':
    full_name: Node.js
    installer: 'https://nodejs.org/dist/v5.7.1/node-v5.7.1-x64.msi'
    install_flags: 'INSTALLDIR="{{ grains['program_files'] }}\\Node.js" /qb'
    msiexec: True
    locale: en_US
    reboot: False

But using the grain in this fashion requires me to fork any packages that I want to change and prevents me from sharing these packages upstream. Is there a better way to override the installation path? I experimented with using the environ state to override the %ProgramFiles% environment variable without any success.

Git 2.6.3 fails to install correctly

Git 2.6.3 (64 bit) installation fails on my Windows Server 2012R2 system according to Salt (although the software is actually installed).

Git's installer seems to be writing the uninstall key to the registry at:-

HCKU\Software\Microsoft\Windows\CurrentVersion\Uninstall

The code in win_pkg.py only iterates:-

HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall
HKLM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall

Therefore the package manager always thinks it has failed to install even when it has and reports a failure.

Git 2.6.2 seems to be OK.

activeperl_x64 repo outdated

the uris changed to:
http://downloads.activestate.com/ActivePerl/releases/
i would really appreciate it if someone could update the sls. Thank you!

Ruby installer not being listed as installed, entry missing from 'pkg.list_pkgs'

The ruby installer sls does not show the pkg as being installed on the system after it has been. The issue seems to be that it is not listed in salt 'minion' pkg.list_pkgs saltenv=NotARealEnv.

Not sure where else to look for the correct pkg name. Could also just be a problem with how the ruby installer works?

Python 2.7 install fails with following error: retcode: 3010

Not sure if this is an issue with the package definition, or my target minion.

2015-11-13 17:44:24,159 [salt.loaded.int.module.cmdmod][ERROR   ][1836] Command ['msiexec', '/i', 'c:\\salt\\var\\cache
\\salt\\minion\\extrn_files\\base\\www.python.org\\ftp\\python\\2.7.10\\python-2.7.10.amd64.msi', '/qn', 'ALLUSERS=1','/norestart', 'ALLUSERS="1"'] failed with return code: 3010
2015-11-13 17:44:24,160 [salt.loaded.int.module.cmdmod][ERROR   ][1836] retcode: 3010
2015-11-13 17:45:44,240 [salt.state       ][ERROR   ][1836] {'_comment': 'Registry not updated.', 'python2_x64': {'new': '2.7.10150', 'old': ''}}

Chrome reports failure after installation

Installed chrome via salt and it reported failure, logged into server and it was installed correctly. Opened chrome, set as default browser and still reports failure:

init.sls:

chrome:
     pkg:
         - installed

highstate result:

          ID: chrome
    Function: pkg.installed
      Result: False
     Comment: The following packages failed to install/update: chrome=latest
     Started: 14:21:48.846000
    Duration: 52285.0 ms
     Changes:   
              ----------
              _comment:
                  Registry not updated.

Using module:

[root@salt ~]# salt wintendo pkg.install chrome
wintendo:
    ----------
    _comment:
        Registry not updated.

[root@salt ~]# salt wintendo pkg.list_pkgs
...
    chrome:
        49.0.2623.87
...

Version info:

[root@salt ~]# salt -L master,wintendo test.versions_report
master:
    Salt Version:
               Salt: 2015.8.5

    Dependency Versions:
             Jinja2: unknown
           M2Crypto: 0.20.2
               Mako: Not Installed
             PyYAML: 3.10
              PyZMQ: 14.3.1
             Python: 2.6.6 (r266:84292, Jul 23 2015, 15:22:56)
               RAET: Not Installed
            Tornado: 4.2.1
                ZMQ: 3.2.5
               cffi: Not Installed
           cherrypy: Not Installed
           dateutil: Not Installed
              gitdb: 0.5.4
          gitpython: 0.3.2 RC1
              ioflo: Not Installed
            libgit2: Not Installed
            libnacl: Not Installed
       msgpack-pure: Not Installed
     msgpack-python: 0.4.6
       mysql-python: Not Installed
          pycparser: Not Installed
           pycrypto: 2.6.1
             pygit2: Not Installed
       python-gnupg: Not Installed
              smmap: 0.8.1
            timelib: Not Installed

    System Versions:
               dist: centos 6.7 Final
            machine: x86_64
            release: 2.6.32
             system: CentOS 6.7 Final

wintendo:
    Salt Version:
               Salt: 2015.8.5

    Dependency Versions:
             Jinja2: 2.7.3
           M2Crypto: Not Installed
               Mako: Not Installed
             PyYAML: 3.11
              PyZMQ: 14.7.0
             Python: 2.7.11 (v2.7.11:6d1b6a68f775, Dec  5 2015, 20:40:30) [MSC v.1500 64 bit (AMD64)]
               RAET: Not Installed
            Tornado: 4.2.1
                ZMQ: 4.1.2
               cffi: Not Installed
           cherrypy: Not Installed
           dateutil: 2.4.2
              gitdb: Not Installed
          gitpython: Not Installed
              ioflo: Not Installed
            libgit2: Not Installed
            libnacl: Not Installed
       msgpack-pure: Not Installed
     msgpack-python: 0.4.6
       mysql-python: Not Installed
          pycparser: Not Installed
           pycrypto: 2.6.1
             pygit2: Not Installed
       python-gnupg: 0.3.7
              smmap: Not Installed
            timelib: Not Installed

    System Versions:
               dist:   
            machine: AMD64
            release: 2012ServerR2
             system: 2012ServerR2 6.3.9600  Multiprocessor Free

Compile Issues pkg.refresh_db result

salt-winrepo-ng\check-mk-agent.sls:
    - failed to compile, check syntax, Conflicting ID 'Not Found'
salt-winrepo-ng\duplicati.sls:
    - pkgname "duplicati", version "skip_urltest" is not defined as a dictionary(hash) key
salt-winrepo-ng\intellij.sls:
    - failed to compile, check syntax, Conflicting ID '1'

Cheers

new 7zip jinja syntax leads to 'bad' version numbers

@twangboy @fizmat The change in the 7zip.sls syntax as interesting as it looks, but unfortunately I think it leads to compiled sls files that are wrong.
As far as I can tell it results in version that is not put in single quote and therefore will be read and misinterpreted as a floating point instead, and trailing zeros can be particularly 'bad' if memory serves me right? (and 7zip has loads ending in trailing zeroes ...)

this is what it compiles to now, I believe the resulting 'version' ought to be in quotes?

  7zip:
    16.00.00.0:
      arch: x64
      full_name: 7-Zip 16.00 (x64 edition)
      install_flags: /qn /norestart
      installer: http://d.7-zip.org/a/7z1600-x64.msi
      locale: en_US
      msiexec: true
      reboot: false
      uninstall_flags: /qn /norestart
      uninstaller: http://d.7-zip.org/a/7z1600-x64.msi
    16.02.00.0:
      arch: x64
      full_name: 7-Zip 16.02 (x64 edition)
      install_flags: /qn /norestart
      installer: http://d.7-zip.org/a/7z1602-x64.msi
      locale: en_US
      msiexec: true
      reboot: false
      uninstall_flags: /qn /norestart
      uninstaller: http://d.7-zip.org/a/7z1602-x64.msi
    16.03.00.0:
      arch: x64
      full_name: 7-Zip 16.03 (x64 edition)
      install_flags: /qn /norestart
      installer: http://d.7-zip.org/a/7z1603-x64.msi
      locale: en_US
      msiexec: true
      reboot: false
      uninstall_flags: /qn /norestart
      uninstaller: http://d.7-zip.org/a/7z1603-x64.msi
    16.04.00.0:
      arch: x64
      full_name: 7-Zip 16.04 (x64 edition)
      install_flags: /qn /norestart
      installer: http://d.7-zip.org/a/7z1604-x64.msi
      locale: en_US
      msiexec: true
      reboot: false
      uninstall_flags: /qn /norestart
      uninstaller: http://d.7-zip.org/a/7z1604-x64.msi
    9.20.00.0:
      arch: x64
      full_name: 7-Zip 9.20 (x64 edition)
      install_flags: /qn /norestart
      installer: http://d.7-zip.org/a/7z920-x64.msi
      locale: en_US
      msiexec: true
      reboot: false
      uninstall_flags: /qn /norestart
      uninstaller: http://d.7-zip.org/a/7z920-x64.msi

as shown by salt mywinminion winrepo.show_sls salt-winrepo-ng.7zip --out=yaml

Dynamically populate Uninstaller option

I am able to query a registry value like:
salt reg.read_value HKEY_LOCAL_MACHINE 'SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\Wireshark' 'UninstallString'

I get my required data in the field vdata:

vdata:
    "D:\Program Files\Wireshark\uninstall.exe"

I need to assign this value to a variable in my sls file. How can I do it?

Here is my use case where I need to do this:
Consider the wireshark.sls file in this repo. I want to ensure that none of my windows servers have wireshark installed on them. If a user installs wireshark, may be he will install it on D drive rather than what we are hard coding in our sls file i.e. on C drive. ( uninstaller: 'C:\Program Files\Wireshark\uninstall.exe' )

Instead of this, I want to read the above registry, and use that path in our uninstaller option. Any pointer?

firefox-esr.sls and firefox.sls consideration to simplify latest installer url

The existing .sls pair does work nicely for both versions of Firefox. However, if we are always looking for the latest installer revision, consider this and this to download the latest every time without regular firefox-esr.sls and firefox.sls changes;

Latest Firefox ESR release (Win32): "https://download.mozilla.org/?product=firefox-esr-latest&os=win&lang=en-US"
Latest Standard Firefox release (Win32): "https://download.mozilla.org/?product=firefox-latest&os=win&lang=en-US"

For other operating systems replace 'os=win' with:
Windows 64bit os=win64
OS X os=osx
Linux x86_64 os=linux64
Linux i686 os=linux

I am using these urls with success with bash scripts to download the latest Firefox versions for multiple OSes, it seems like it may be easier to maintain inside an sls as well.

Chrome never show "Package chrome is already up-to-date"

Chrome is always displayed as "The following packages were successfully installed/upgraded" and not as "up-to-date" every time I start "state.highstate". The same works with "jre8" without any problems. Here is an example:

# cat default-windows-packages-always-latest.sls 
alway-latest-jre8:
  pkg.latest:
    - name: jre8

alway-latest-chrome:
  pkg.latest:
    - name: chrome

# salt 'win' pkg.list_pkgs             
win:                                     
    ----------
    chrome:
        69.0.3497.92
    jre8:
        8.0.1610.12

# salt 'win' pkg.list_upgrades
win:
    ----------
    chrome:
        latest

# salt 'win' state.highstate  
win:                                           
----------
          ID: alway-latest-jre8
    Function: pkg.latest
        Name: jre8
      Result: True
     Comment: Package jre8 is already up-to-date
     Started: 09:20:29.889101
    Duration: 46.532 ms
     Changes:   
----------
          ID: alway-latest-chrome
    Function: pkg.latest
        Name: chrome
      Result: True
     Comment: The following packages were successfully installed/upgraded: chrome
     Started: 09:20:29.935633
    Duration: 766.017 ms
     Changes:   
              ----------
              chrome:
                  ----------
                  current:
                      69.0.3497.92

Summary for win
------------
Succeeded: 2 (changed=1)
Failed:    0
------------
Total states run:     2
Total run time:  11.801 s

salt master --versions-report                 
Salt Version:                               
           Salt: 2018.3.2
 
Dependency Versions:
           cffi: Not Installed
       cherrypy: Not Installed
       dateutil: 2.5.3
      docker-py: Not Installed
          gitdb: 2.0.0
      gitpython: 2.1.1
          ioflo: Not Installed
         Jinja2: 2.9.4
        libgit2: Not Installed
        libnacl: Not Installed
       M2Crypto: Not Installed
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.4.8
   mysql-python: Not Installed
      pycparser: Not Installed
       pycrypto: 2.6.1
   pycryptodome: Not Installed
         pygit2: Not Installed
         Python: 2.7.13 (default, Nov 24 2017, 17:33:09)
   python-gnupg: Not Installed
         PyYAML: 3.12
          PyZMQ: 16.0.2
           RAET: Not Installed
          smmap: 2.0.1
        timelib: Not Installed
        Tornado: 4.4.3
            ZMQ: 4.2.1
 
System Versions:
           dist: debian 9.5 
         locale: UTF-8
        machine: x86_64
        release: 4.9.0-8-amd64
         system: Linux
        version: debian 9.5

naming of windows salt-minion? (saltstack.minion -> salt-minion)

@UtahDave @twangboy I see that in the process of updating from the old winrepo to the new winrepo-ng jinja2 templating enabled repo the windows salt-minion's package name got changed from salt-minion to saltstack.minion, BUT the repos sls file name stayed as salt-minion.sls

I would quite like to bring some consistency back and rename the pkg back to salt-minion. The odd name saltstack.minion does not seem to get mentioned on the website or in the docs.

Was there a deliberate choice to rename the pkg for the windows salt-minion when going from winrepo to winrepo-ng?

If renaming it is not desired, for fear of upsetting and breaking things in any formulas etc, can I at least then rename the actual sls file itself to saltstack.minion.sls instead? It would make it the one and only windows ls file that use the '.' (full stop) as a 'name' separator. But at least the names of the sls file itself and the pkg name would be back in 'sync' again?

salt-minion upgrade reports as failed although was successful

It appears when you run these states to upgrade the salt-minion that it always reports as a failure. I'm assuming because it has to stop the salt-minion service when the background task is running the upgrade. Is there a way to change how this reports? Example output below of a failed state, but in actuality the salt-minion was upgraded successfully.

Minion version upgrade from 2018.3.2 to 2018.3.3 Py2.

wintestserver:
----------
          ID: windows_salt_minion
    Function: pkg.installed
        Name: salt-minion-py2
      Result: False
     Comment: The following packages failed to install/update: salt-minion-py2=2018.3.3
     Started: 14:43:37.108000
    Duration: 2125.0 ms
     Changes:
              ----------
              salt-minion-py2:
                  ----------
                  install status:
                      task started

Summary for wddcsdiaas12.mkappsdev.com
------------
Succeeded: 0 (changed=1)
Failed:    1
------------
Total states run:     1
Total run time:   2.125 s

State File:

windows_salt_minion:
  pkg.installed:
    - name: salt-minion-py2
    - version: latest
    - allow_updates: True

Command:
salt 'wintestserver' state.apply win.salt-minion

Master:

Salt Version:
           Salt: 2018.3.3

Dependency Versions:
           cffi: 1.6.0
       cherrypy: unknown
       dateutil: 2.7.3
      docker-py: Not Installed
          gitdb: 2.0.4
      gitpython: 2.1.11
          ioflo: Not Installed
         Jinja2: 2.7.2
        libgit2: 0.26.3
        libnacl: 1.6.1
       M2Crypto: 0.21.1
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.5.6
   mysql-python: Not Installed
      pycparser: 2.14
       pycrypto: 2.6.1
   pycryptodome: Not Installed
         pygit2: 0.26.4
         Python: 2.7.5 (default, May 31 2018, 09:41:32)
   python-gnupg: Not Installed
         PyYAML: 3.11
          PyZMQ: 15.3.0
           RAET: Not Installed
          smmap: 2.0.4
        timelib: Not Installed
        Tornado: 4.2.1
            ZMQ: 4.1.4

System Versions:
           dist: redhat 7.5 Maipo
         locale: UTF-8
        machine: x86_64
        release: 3.10.0-862.14.4.el7.x86_64
         system: Linux
        version: Red Hat Enterprise Linux Server 7.5 Maipo

Why are 7zip stable in 7zip beta?

I don't understand why "7zip_beta.sls" has version that are not clearly labeled as beta on there sourceforge page. https://sourceforge.net/projects/sevenzip/files/7-Zip/

Visual Studio 2010 Redistributeable install hangs.

Hi using 2015.8.8.2

I reported the issue here: https://groups.google.com/forum/#!topic/salt-users/Y3aeRDb4Rqs

Using salt on Ubuntu 14.04 to manage some Windows 2008 and 2012 servers.

Everything is setup and running correctly I managed to do some IIS stuff, I even installed firefox as per the docs. But when I run...

sudo salt '*' pkg.install ms-vcpp-2010-sp1-mfc-redist_x64

The command seems to hang. Looking at the minion logs...

2016-05-16 16:27:53 [salt.loaded.int.module.cmdmod][INFO    ] Executing command 'Powershell -NonInteractive "Import-Module ServerManager"' in directory 'C:\\Windows\\system32\\config\\systemprofile'
2016-05-16 16:27:53 [salt.minion    ][INFO    ] Starting a new job with PID 2812
2016-05-16 16:27:53 [salt.minion    ][INFO    ] Returning information for job: 20160516162749915989
2016-05-16 16:27:54 [salt.loaded.int.module.cmdmod][INFO    ] Executing command ['c:\\salt\\var\\cache\\salt\\minion\\extrn_files\\base\\download.microsoft.com\\download\\1\\6\\5\\165255E7-1014-4D0A-B094-B6A430A6BFFC\\vcredist_x64.exe', '/qn', '/norestart'] in directory 'c:\\salt\\var\\cache\\salt\\minion\\extrn_files\\base\\download.microsoft.com\\download\\1\\6\\5\\165255E7-1014-4D0A-B094-B6A430A6BFFC'
2016-05-16 16:28:03 [salt.minion    ][INFO    ] Starting a new job with PID 2012
2016-05-16 16:28:03 [salt.minion    ][INFO    ] Returning information for job: 20160516162759925343
2016-05-16 16:28:12 [salt.minion    ][INFO    ] Starting a new job with PID 3024

And it goes for ever. I then press ctrl-c get the job id and eventually kill the job manually.

According to this: How to perform a silent install of the Visual C++ 2010 redistributable packages there is no n flag.

Modified the ms-vcpp-2010-sp1-mfc-redist_64.sls file from /qn to /q
Updated the minion repo packages.
sudo salt '*' pkg.install ms-vcpp-2010-sp1-mfc-redist_x6

The result

mywinminion:
    ----------
    _comment:
        Software not found in the registry.
        Could be a problem with the Software
        definition file. Verify the full_name
        and the version match the registry exactly.
        Failed after 10 tries.
    vcredist2010_x64:
        ----------
        new:
            10.0.40219
        old:

It seems to be installing but with some error?

Missing ' in virtualbox.sls

virtualbox.sls is missing a closing ' in the following line

full_name: 'Oracle VM VirtualBox 5.1.16

Sensu.sls fails to compile on desktop OS

i.e. where grains['osrelease'] == '8.1'

remote ref does not exist

[root@blah salt]# salt-run winrepo.update_git_repos
[ERROR ] Failed to checkout master from winrepo remote 'https://github.com/saltstack/salt-winrepo-ng.git': remote ref does not exist
https://github.com/saltstack/salt-winrepo.git:
/srv/salt/win/repo/salt-winrepo

Just upgraded to 2018.3 from 2017 and i get the above error now, saw an old comment about changing repo provider in the master config but cannot find that entry.

ideas ?

travis-ci new sls file setting "skip_urltest" is leading to yaml compilation error

the new (and unofficial) setting 'skip_urltest' in sls file (e.g. duplicati.sls) leads to yaml compilation problem report. :-(

when running salt-run winrepo.genrepo on a 2016.3.0 master you get

event:
    ----------
    error:
        Failed to compile /srv/salt/win/repo/salt-winrepo/duplicati.sls.
suffix:
    progress
event:
    ----------
    error:
        Failed to compile /srv/salt/win/repo/salt-winrepo/duplicati_x86.sls.
suffix:
    progress

@moebiuseye was kind enough to help me, a non-programmer, to get the travis-ci tests running again and in the process he 'invented' a new switch in the sls file that allows travis-ci to know when the 404 urltest should not be run against a particular sls file.

This new setting 'skip_urltest' works just fine, but unfortunately it results in the above yaml compilation error.

Question mainly to @moebiuseye could you please think about re-working the 'skip_urltest' workaround and maybe add a 'skip_urltest' section to the .travis/travis.yml or maybe a new .travis/skip_urltest or .travis/urltest_skip file that would contain a simple one per line list of sls file names where the 404 url test should not be run against?

Also at same time it might be good to get the travis tests to start to be modular, so there can be other tests (and some of them might need 'skip' files or sections as well?) There are of course many other tests that could be added over time, and some of them I could possibly handle myself, even as a non-programmer. One of the first would be a simple flagging of any trailing whitespace at end of lines. Another a test for any use of TAB instead of characters to indent sls files.
Also generally those tests should be run only against the changed sls file that is being committed and not against every single file in the repo. That applies also to the URL test, it should be run only against the currently changed sls file in the submission. BUT there should be a cron or otherwise scheduled job that checks for URLs that have gone bad. A committer merging a PR should not be 'forced' to deal with a bad URL or 404 error in another unrelated sls file.

Basically the travis-ci files and setup should be 100% external to the actual winrepo sls files. They should not require new settings or even commented out lines to tell travis-ci how to work on them.

BTW saltstack might also look at moving the travis-ci files into their automated jenkins test-suite, so this travis-ci test suite might be superceeded at some point. Any ideas, or feedback or thoughts on this?

How do I run a 'dual value' or 'paired values' jinja2 for loop?

How can I modify this jinja2 for loop so it includes ONE build number along with ONE version number in each iteration of the loop?

So in first run of the for loop it has version set to '5.18.4' AND build set to '1805'
in second run of the for loop it should have version set to '5.20.2' AND build set to '2002'
and in third run of the for loop it should have version set to '5.22.0' AND build set to '2200'

in my salt winrepo-ng sls file. (basically a jinja2 templated salt sls file)

activeperl_x86:
  {% for version in '5.22.0', '5.20.2', '5.18.4' %}
  {{ version }}:
    full_name: 'ActivePerl {{ version }} Build {{ build }} (64-bit)'
    installer: 'http://downloads.activestate.com/ActivePerl/releases/{{ version }}.{{ build }}/ActivePerl-{{ version }}.{{ build }}-MSWin32-x86-64int-299195.msi'
    uninstaller: 'http://downloads.activestate.com/ActivePerl/releases/{{ version }}.{{ build }}/ActivePerl-{{ version }}.{{ build }}-MSWin32-x86-64int-299195.msi'
    install_flags: '/qn /norestart'
    uninstall_flags: '/qn /norestart'
    msiexec: True
    locale: en_US
    reboot: False
  {% endfor %}

In the end result the installer and uninstaller should have properly filled in URLs to match the actual URLs below.

http://downloads.activestate.com/ActivePerl/releases/5.18.4.1805/ActivePerl-5.18.4.1805-MSWin32-x86-64int-299195.msi
http://downloads.activestate.com/ActivePerl/releases/5.20.2.2002/ActivePerl-5.20.2.2002-MSWin32-x86-64int-299195.msi
http://downloads.activestate.com/ActivePerl/releases/5.22.0.2200/ActivePerl-5.22.0.2200-MSWin32-x86-64int-299195.msi

This question is also in a gist here https://gist.github.com/TheBigBear/07c31525bf2c2b2fba82

@eliasp ^^ @twangboy @jfindlay @UtahDave any help or hints form one of you folks?

Program_Files undefined

Seeing this in the logfile on minion:

2015-11-13 17:28:42,593 [salt.utils.templates][ERROR   ][1836] Rendering exception occurred :Jinja variable 'Program_Files' is undefined�                                                                                                 ���

Python 2.7.13 not included

The python2 packages do not have 2.7.13, which has been out for quite a while.

ERROR: unicode string

I wanted to update and improve the existing state ossec-agent.sls.
Now I received the following error message and don't know why.

Error Message:

[ERROR   ][2608] A command in 'pkg.refresh_db' had a problem: Error occurred while generating repo db. Additional info follows:

failed:
    1
failed_list:
    ----------
    ossec-agent.sls:
        - Failed to compile, while constructing a mapping
            in "<unicode string>", line 14, column 3:
                '2.9.4':
                ^
          found conflicting ID '3.2.0'
            in "<unicode string>", line 36, column 3:
                '3.2.0':
                ^ 
success:
    1
total:
    2

State:

{% set source_path = 'https://updates.atomicorp.com/channels/atomic/windows/' %}

{% if grains['cpuarch'] == 'AMD64' %}
    {% set PROGRAM_FILES = "%ProgramFiles(x86)%" %}
{% else %}
    {% set PROGRAM_FILES = "%ProgramFiles%" %}
{% endif %}

{% set versions = {
'3.2.0':['6132', '6122', '6096'],
'3.1.0':['5732', '5711', '5696'],
'3.0.1':['5667', '5639', '5637', '5636', '5635'],
'3.0.0':['5609', '5607', '5605', '5604', '5602'],
'2.9.4':['5177'],
'2.9.3':['4466', '3861', '3850', '3841', '3840', '2912', '2833', '2817'],
'2.9.2':['2760', '2758', '2154', '2067', '2035', '2021'],
'2.9.0':['2017', '1953', '1801', '1798', '1790', '1780', '1774', '1738'],
} %}

ossec-agent:
{% for major, subversions in versions.items() %}
{% for minor in subversions %}
  '{{ major }}':
    full_name: 'OSSEC HIDS {{ major }}'
    installer: '{{ source_path }}ossec-agent-win32-{{ major }}-{{ minor }}.exe'
    install_flags: '/S'
    uninstaller: '{{ PROGRAM_FILES }}\ossec-agent\uninstall.exe'
    uninstall_flags: '/S'
    msiexec: False
    locale: en_US
    reboot: False
{% endfor %}
{% endfor %}

But...

If I add {{minor}} to the version to the line 25, so that the line looks like:
'{{major}}{{minor}}:
Then I don't get an error message and can at least install the latest version of the agent. But this workaround is wrong, because the minor version specification is only needed for the download and not for install / uninstall.

Adobe Reader DC download links broken

Hello!

It looks like the download locations for Adobe Reader DC have changed.

Old Broken Link
https://ardownload2.adobe.com/pub/adobe/reader/win/AcrobatDC/1501020059/AcroRdrDC1501020059_en_US.exe

New Working Link
https://admdownload.adobe.com/bin/live/readerdc_en_ha_install.exe

https://github.com/saltstack/salt-winrepo-ng/blob/master/adobereader-dc.sls

Adobe reader dc

Hi all the adobe reader dc links are all dead (I asssume that's normal)
and there's a new one:
https://ardownload2.adobe.com/pub/adobe/reader/win/AcrobatDC/1501020060/AcroRdrDC1501020060_en_US.exe

I think that things just changed at adobe. The version you get isn't

2015.xxx.xxxxx

Instead it has type 15.xxx.xxxx

And explanation of the new versioning stuff is here:

http://www.adobe.com/devnet-docs/acrobatetk/tools/AdminGuide/whatsnewdc.html

The long and short of it is that we probably need to make new sls file called adobe-reader-dc-classic
(or something like that).

It can start off with

adobereader-dc-classic:
  '15.010.20060':
    full_name: 'Adobe Acrobat Reader DC'
    installer: 'https://ardownload2.adobe.com/pub/adobe/reader/win/AcrobatDC/1501020060/AcroRdrDC1501020060_en_US.exe'
    install_flags: '/msi EULA_ACCEPT=YES ALLUSERS=1 REMOVE_PREVIOUS=YES /qn'
    uninstaller: 'msiexec.exe'
    uninstall_flags: '/qn /x {AC76BA86-7AD7-1033-7B44-AC0F074E4100} /norestart'
    msiexec: False
    locale: en_US
    reboot: False