You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description
win_pkg installer is allowed to be located in s3 while uninstaller is not. The impact is that a cleanup of that way deployed third party software is not possible with workarounds.
Setup
In order to reproduce this, a salt minion running on Windows is required.
Steps to Reproduce the behavior
Using salt 3003 (issue also present on master branch) it is easy possible to define a winrepo-ng package description like this:
2021-09-16 07:09:05,750 [salt.loaded.int.module.cmdmod:415 ][INFO ][1136] Executing command '"C:\Windows\system32\cmd.exe"' in directory 'C:\Windows\system32\config\systemprofile'
2021-09-16 07:09:06,014 [salt.loaded.int.module.cmdmod:853 ][ERROR ][1136] Command '"C:\Windows\system32\cmd.exe"' failed with return code: 1619
2021-09-16 07:09:06,014 [salt.loaded.int.module.cmdmod:855 ][ERROR ][1136] stdout: This installation package could not be opened. Verify that the package exists and that you can access it, or contact the application vendor to verify that this is a valid Windows Installer package.
2021-09-16 07:09:06,014 [salt.loaded.int.module.cmdmod:859 ][ERROR ][1136] retcode: 1619
2021-09-16 07:09:06,014 [salt.loaded.int.module.win_pkg:2185][ERROR ][1136] Failed to remove python2_x64
2021-09-16 07:09:06,015 [salt.loaded.int.module.win_pkg:2186][ERROR ][1136] retcode 1619
2021-09-16 07:09:06,015 [salt.loaded.int.module.win_pkg:2187][ERROR ][1136] uninstaller output: This installation package could not be opened. Verify that the package exists and that you can access it, or contact the application vendor to verify that this is a valid Windows Installer package.
This is caused by this line of code and following:
# Where is the uninstaller
if uninstaller.startswith(("salt:", "http:", "https:", "ftp:")):
# Check for the 'cache_dir' parameter in the .sls file
This is an inconsistency as for the installer the following is done:
# Is the installer in a location that requires caching
if __salt__["config.valid_fileproto"](installer):
# Check for the 'cache_dir' parameter in the .sls file```
Expected behavior
Use the same logic for uninstaller as for the installer to determine if the uninstaller needs to be cached locally prior uninstallation to enable removal of packages using an installer located in S3.
Versions Report
Salt Version:
Salt: 3003
Dependency Versions:
cffi: 1.14.5
cherrypy: 18.6.0
dateutil: 2.8.1
docker-py: Not Installed
gitdb: 4.0.5
gitpython: Not Installed
Jinja2: 2.10.1
libgit2: Not Installed
M2Crypto: Not Installed
Mako: 1.1.4
msgpack: 1.0.2
msgpack-pure: Not Installed
mysql-python: Not Installed
pycparser: 2.20
pycrypto: Not Installed
pycryptodome: 3.9.8
pygit2: Not Installed
Python: 3.7.4 (tags/v3.7.4:e09359112e, Jul 8 2019, 20:34:20) [MSC v.1916 64 bit (AMD64)]
python-gnupg: 0.4.6
PyYAML: 5.3.1
PyZMQ: 18.0.1
smmap: 3.0.4
timelib: 0.2.4
Tornado: 4.5.3
ZMQ: 4.3.1
System Versions:
dist:
locale: cp1252
machine: AMD64
release: 2019Server
system: Windows
version: 2019Server 10.0.17763 SP0
The text was updated successfully, but these errors were encountered:
Description
win_pkg installer is allowed to be located in s3 while uninstaller is not. The impact is that a cleanup of that way deployed third party software is not possible with workarounds.
Setup
In order to reproduce this, a salt minion running on Windows is required.
Steps to Reproduce the behavior
Using salt 3003 (issue also present on master branch) it is easy possible to define a winrepo-ng package description like this:
And
salt <minion> pkg.install python2_x64
works like a charm. Which is really great, especially the ability to define hash here.Unfortunately the package installed that way cannot be uninstalled
salt <minion> pkg.remove python2_x64
as the module errors out with messageLog messages are:
This is caused by this line of code and following:
This is an inconsistency as for the installer the following is done:
Expected behavior
Use the same logic for uninstaller as for the installer to determine if the uninstaller needs to be cached locally prior uninstallation to enable removal of packages using an installer located in S3.
Versions Report
The text was updated successfully, but these errors were encountered: