Feature Requests: Windows Software Repository and Windows File Version

[ghost]

Hi,

I have 2 feature requests, which would be very useful under Windows, especially for updating software.

1. In some cases previous versions are unavailable. Google Chrome or for example, there is #only one URL provided for a standalone installation of Google Chrome.

The disadvantage is that even if the version has not changed, the software is reinstalled every time the state is executed. From my point of view, there would be a way how this could be avoided for most installers under Windows.

On many installers, the "File version", "Product version" or "Comments" field contains the correct version, which could be compared with the version displayed under "Program and Files" if the software is installed.

The installer must still be downloaded for comparison, but the software will not be reinstalled every time the state is running. This is not a perfect solution, but still a good improvement.

For this, winrepo functionality would have to be extended by an additional parameter, if latest was selected in the version specification.

2. A related topic, because in the first case the file version should be checked as well.

Currently no module or state exists, which can get the file version under windows, comparable to the ansible module win_file_version
https://docs.ansible.com/ansible/latest/modules/win_file_version_module.html
It`s possible to check the file hash or other workarounds for Installers / DLLs, but it is also much more effort intensive. This would also be very helpful under Windows.

@twangboy - Feature Request is created!

Best,
Stefan

[damon-atkins]

From memory this should only happen if you use latest in the state vs not indicating a version at all. What version of salt are you using. For example just a plan salt server pkg.install chrome will say its already installed all the other non-windows platforms would upgrade chrome. It was a design decision to be different to prevent the very issue you have mention. It also means it behaves more like yum and other unix package managers which do not auto upgrade software.

[damon-atkins]

#47702 fixed an upgrade issue. Best version to check with are 2017.7.6 and 2018.3.1

[ghost]

I use the current salt version 2018.3.3.
Shane said that when using latest, instead of a version number, the package is reinstalled each time a state is run.
It's even worse, I've tested it with vs_remotetools_2017 state from https://github.com/saltstack/salt-winrepo-ng/blob/master/vs_remotetools_2017
I installed it on 2 systems, then I ran the state again and it didn't happen.
The salt feedback was also insufficient for me:

salt 'win*' pkg.install vs_remotetools_2017
win2019:
----------
win10-x86:
----------

Then I have changed the version in the registry Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall{8503049A-527C-3361-AFB9-1A4E5E0AEF55}
to an older version and execute the state again, even then nothing happens.

Therefore I estimate that if the package is found by name, the installation will be suspended. However, this behavior could be improved when using latest as version.

I think it would be helpful, because windows behaves a little different than Linux.
Unfortunately there will be more and more applications which have a unique download link and the version can only be found via the file or product version.

1. better feedback than as in the example above
2. Additional optional parameter which additionally compares the file and / or product version with the registry values. Then an update will also be performed for the version specification latest, if a newer version can be found in the installer as in the registry.

This would help a lot, because otherwise there is only the workaround to uninstall and reinstall the software every time. Even if the version hasn't changed.

I would definitely not change the default behavior, but solve for this more specific topic with an additional parameter. In the future the problem of version and download links will definitely increase further.

[damon-atkins]

Current if the software is installed no action is taken unless you specify a version or specify latest. This is by design.

The following is the correct and expected behavior on windows.

C:\salt>salt-call --version
salt-call 2018.3.2 (Oxygen)
C:\salt>salt-call -l info pkg.version chrome
local:
    71.0.3578.98

This is the correct output for No Change. When using states, the "pkg state" puts some more words around it. The commands provided to you in the previous post are direct commands to the pkg module.

C:\salt>salt-call -l info pkg.install chrome  # call "module" pkg.install, this is what pkg.installed calls 
local:
    ----------

C:\salt>salt-call -l info state.single pkg.installed name=chrome  # call "state" pkg.installed
[INFO    ] state.call Executing state pkg.installed for [chrome]
[INFO    ] win_pkg.refresh_db Removing all *.sls files under 'c:\salt\var\cache\salt\minion\files\base\win\repo-ng'l
[INFO    ] win_pkg.refresh_db Fetching *.sls files from salt://win/repo-ng/
[INFO    ] fileclient.cache_dir Caching directory 'win/repo-ng/' for environment 'base'
[INFO    ] fileclient.get_file Fetching file from saltenv 'base', ** done ** 'win/repo-ng/chrome.sls'
[INFO    ] fileclient.get_file Fetching file from saltenv 'base', ** done ** 'win/repo-ng/swpd/winscp.sls'
[INFO    ] state.format_log All specified packages are already installed
[INFO    ] state.call Completed state [chrome] at time 03:30:27.438648 (duration_in_ms=7604.901)
local:
----------
          ID: chrome
    Function: pkg.installed
      Result: True
     Comment: All specified packages are already installed
    Duration: 7604.901 ms
     Changes:

Summary for local
------------
Succeeded: 1
Failed:    0
------------
Total states run:     1
Total run time:   7.605 s

As SLS Pkg definition file contains latest as a version, download and install the software as there is no other way too ensure the latest software is installed. Note until the software (latest) is installed you can not determine its version.

C:\salt>salt-call -l info pkg.install chrome version=latest
[INFO    ] cmdmod._run Executing command '"C:\WINDOWS\system32\cmd.exe" /s /c ""msiexec" /I "c:\salt\var\cache\salt\minion\extrn_files\base\dl.google.com\edgedl\chrome\install\Goog
leChromeStandaloneEnterprise.msi" ALLUSERS=1 /qn /norestart"' in directory 'c:\salt\var\cache\salt\minion\extrn_files\base\dl.google.com\edgedl\chrome\install'
local:
    ----------
    chrome:
        ----------
        new:
            67.138.32849
        old:
            71.0.3578.98  # I suspect the retail version maybe ahead of the enterprise version.

Here is the sls definition

chrome:
  latest:
    full_name: 'Google Chrome'
    installer: 'https://dl.google.com/edgedl/chrome/install/GoogleChromeStandaloneEnterprise.msi'
    install_flags: '/qn /norestart'
    uninstaller: 'https://dl.google.com/edgedl/chrome/install/GoogleChromeStandaloneEnterprise.msi'
    uninstall_flags: '/qn /norestart'
    msiexec: True
    locale: en_US
    reboot: False

This is design to prevent an endless loop of installs every-time the state is run. Which you can still have by using pkg.latest i.e. salt-call -l info state.single pkg.latest name=chrome will download and install on every run.

So specific to states with the "latest" listed as a available version.

C:\salt>salt-call -l info pkg.list_available chrome
local:
    - latest

Use "installed" if you want to ensure any version is installed. Best for software which has its own auto updates process e.g. chrome.
Use "latest" if you want latest version downloaded every-time and then installed every-time.

[ghost]

You're right, with software like Chrome it's usually better to use the user installer that updates itself. In my request, I have the view of an enterprise company where users have very limited rights and where software and updates are usually rolled out via a central deployment tool. Or in some cases, for security reasons, it may be necessary to update to the latest version instead of waiting for the autoupdate or the user to perform the update.

I think the example with the Remote Tools for Visual Studio 2017 is a better as Chrome.
Maybe you have an idea for me how to solve this better.
Because this software have no update functionality, but newer bugfix versions appear regularly, which can also be downloaded via the same download link and the installer have always the same name. Theoretically the version could be found on the installer details under product or file version.
Currently the software is installed about 1000 systems, but with different build versions, some have the latest build, some have an older version.
I don't like to work with salt modules or does not want to work much in the CLI, it should be in a state, so I can just do a highstate or can store it as a job in the Enterprise Console for other admins with less no CLI rights.
The goal is to keep up to date the systems and only install updates on systems that have an older version installed and not on all.

My current workaround is, that I download the software and put it in to the local winrepo and define the version number.
Of course this works, however, this always costs unnecessary time and I have to check for updates regularly.
It would be a significant improvement to have a check of the installed version, which then decides on the basis of the file or product version of the downloaded installer whether the software has to be updated or not.
Otherwise I would have to update all systems, no matter if the latest version is already installed or not.

[damon-atkins]

I understand where your coming from. Its a pain. The only solution I can think of is a dedicated Windows VM. Which once a week downloads the software, installs it checks the version, and if the version changes takes a copy of the installer, and places on the salt server or some other location locally, and sends you a notification, so you can decide to use it or not. When you have your change request ready update all the clients.

Or on the salt master a cron job fetches the file once a week and if the changes, updates the file on the salt server and force a reinstall.

It is possible to automate if you have a spare windows vm.

The next version of this software will:

• cache http requests, and only download if necessary.
• scan a web page for available versions.

However none of the above helps here.

From an enterprise point of view should never download directly from the internet. As there should be a verification step, to ensure the software has not been replace by malware. Like to see downloads signed by PGP so downloads could be checked with confidence. As checksum can be changed.

I do have code which pulls the file version and product version out of an exe, but its not part of the new code release yet. It was more intended for software which does not place a version in the registry.

[ghost]

Good tip, the VM solution is probably the best solution in this case. If I understand this correctly, the Windows Repo function will be improved in the future.

I think it makes really sense to implement your code in the official salt version. Because especially with self-written tools and services, not everything is always written cleanly into the registry or when a certain exe / dll file version should be checked.

I have 2 other points, which very time consuming, maybe these things could be improved...
The maintenance of source hashes and a copy retry function for failed file copies.

If the installer is located in the local winrepo, source_hash parameter is a good option to ensure that a file has been successfully transferred from salt-master to salt-minion. Especially if the systems are distributed worldwide, this check makes sense.
As soon as several versions of a software have to be maintained, the administration effort becomes very high, because for each installer the checksum has to be determined and maintained in the states.

Could this parameter be extended to include the possibility that the saltmaster / saltminion independently checks and compares the source hash with the target hash or do you have another idea to improve this case? I know that this will probably create more load on the salt-master and the state will need more time.

Copy retry function:
On some reasons the file transfer fails or the checksum does not match, the state will fail, as expected.
But is there any plan to implement some kind of copy retry function?
Where you can define how often you want to retry the file copy.
I think about our case, we have our salt-master in europe and use it for many servers worldwide. High latency is not a problem, the download of a file only takes longer, but with package loss or other problems the state has to be executed multiple times. But we don't want to run a salt-master in every country now either, even if we were to move the winrepo to a CDN, this could still happen.

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

[stale[bot]]

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