Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Windows 3004 move config not working for EXE #15

Open
1 of 6 tasks
bsoldhogg opened this issue Jan 19, 2022 · 6 comments · Fixed by #24
Open
1 of 6 tasks

[BUG] Windows 3004 move config not working for EXE #15

bsoldhogg opened this issue Jan 19, 2022 · 6 comments · Fixed by #24
Assignees
Labels
bug Something isn't working needs-triage

Comments

@bsoldhogg
Copy link

Description
When running the exe installer from the command line with the /move-config switch, Salt is upgraded, the new registry keys are created but they point to the existing C:\salt locations, root_dir and config_dir are not updated.

The GUI, however, works and will move config if instructed.

Setup
I used the provided state from the salt-winrepo-ng repo and added the /move-config switch

  • on-prem machine
  • VM (Virtualbox, KVM, etc. please specify)
  • VM running on a cloud service, please be explicit and add details
  • container (Kubernetes, Docker, containerd, etc. please specify)
  • or a combination, please be explicit
  • jails if it is FreeBSD

Steps to Reproduce the behavior
A Windows Server 2019 (2012R2 and 2016 also tested) VM running 3003.3 was used to test the above state against which results in Salt being upgrade but the binaries and config are not moved. Moving to running the installer locally without Salt and with the /minion-name and /master switches, alongside /move-config, the same was observed. In both situations, C:\ProgramData\Salt Project\Salt is created, no files are migrated.

When running locally without Salt involved

If I remove all switches C:\ProgramData\Salt Project\Salt is created but the config is not migrated, the registry keys are created and point to C:\salt. If I only specify /move-config then C:\ProgramData\Salt Project\Salt is not created

When attempting to force configuration to remain in C:\salt by using /master /minion-name and /install-dir, the configuration is moved from C:\salt\conf to C:\ProgramData\Salt Project\Salt\conf - including the pki files - but creates new defaults in C:\salt which then causes the minion key to be denied as coming from the same minion_id

Expected behavior
The binaries are expected to be moved to C:\Program Files and config to C:\ProgramData with C:\salt removed

Versions Report

salt --versions-report

Master

Salt Version:
          Salt: 3003.3

Dependency Versions:
          cffi: Not Installed
      cherrypy: Not Installed
      dateutil: 2.6.1
     docker-py: Not Installed
         gitdb: 2.0.3
     gitpython: 2.1.8
        Jinja2: 2.10
       libgit2: 0.26.0
      M2Crypto: Not Installed
          Mako: Not Installed
       msgpack: 0.5.6
  msgpack-pure: Not Installed
  mysql-python: Not Installed
     pycparser: Not Installed
      pycrypto: 2.6.1
  pycryptodome: 3.4.7
        pygit2: 0.26.2
        Python: 3.6.9 (default, Dec  8 2021, 21:08:43)
  python-gnupg: 0.4.1
        PyYAML: 3.12
         PyZMQ: 17.1.2
         smmap: 2.0.3
       timelib: Not Installed
       Tornado: 4.5.3
           ZMQ: 4.2.5

System Versions:
          dist: ubuntu 18.04 Bionic Beaver
        locale: UTF-8
       machine: x86_64
       release: 4.15.0-159-generic
        system: Linux
       version: Ubuntu 18.04 Bionic Beaver

Minion

Salt Version:
              Salt: 3003.3

    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.11.3
           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.4.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: 2012ServerR2
            system: Windows
           version: 2012ServerR2 6.3.9600 SP0

Additional context
This may just be the nature of the MSI installer but I am unable to use this inplace of the EXE in the state provided as it uninstalls Salt and seems to kill the installer in the process so you are left in an uninstalled state.

However, performing an upgrade with the MSI installer, outside of any salt state and provided the installer is not inside C:\salt, works and will move the config using MOVE_CONF.

@bsoldhogg bsoldhogg added bug Something isn't working needs-triage labels Jan 19, 2022
@twangboy twangboy assigned twangboy and unassigned frogunder Jan 19, 2022
@baby-gnu
Copy link

baby-gnu commented Feb 7, 2022

I confirm the bug, the pki keys are not moved so the 3004 minion generate a new key and try to authenticate to the master which denied the access for that minion.

The strange thing is that when I logging to the windows workstation with the running minion and execute manually the following command:

Salt-Minion-3004-3-Py3-AMD64-Setup.exe /S /move-config

It's working fine, the pki keys are move to %ProgramData\Salt Project\Salt\config.

So, to me, the issue only comes when I use:

salt 'my-windows-minion' pkg.install salt-minion-py3 version=3004-3

I'm using salt-minion-py3.sls with the following patch:

--- salt-minion-py3.sls.orig	2022-02-07 16:37:12.755547613 +0100
+++ salt-minion-py3.sls	2022-02-07 16:40:42.571193281 +0100
@@ -7,6 +7,13 @@
 # 2015.8.2 you will not be able to use pkg.install to upgrade Salt again. You
 # will have to upgrade Salt through another means.
 # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+{%- set arch = grains['cpuarch'] %}
+{%- set install_flags_map = {
+      '3004-3': ' /move-config',
+      '3004-2': ' /move-config',
+      '3004': ' /move-config',
+      } %}
+
 salt-minion-py3:
   {%
       for version in [
@@ -20,15 +27,11 @@
   %}
   '{{ version }}':
     full_name: 'Salt Minion {{ version }} (Python 3)'
-    {% if grains['cpuarch'] == 'AMD64' %}
-    installer: 'https://repo.saltstack.com/windows/Salt-Minion-{{ version }}-Py3-AMD64-Setup.exe'
-    {% else %}
-    installer: 'https://repo.saltstack.com/windows/Salt-Minion-{{ version }}-Py3-x86-Setup.exe'
-    {% endif %}
+    installer: 'https://repo.saltstack.com/windows/Salt-Minion-{{ version }}-Py3-{{ arch }}-Setup.exe'
     {% raw %}
     # install_flags: "/S /master={{ salt['pillar.get']('salt:master', 'salt.domain.tld') }} /minion-id={{ salt['pillar.get']('salt:minion:ids:' ~ grains['host'] }}"
     {% endraw %}
-    install_flags: '/S'
+    install_flags: {{ '/S' ~ install_flags_map.get(version, '') }}
     uninstaller: 'C:\salt\uninst.exe'
     uninstall_flags: '/S'
     msiexec: False

@twangboy twangboy transferred this issue from saltstack/salt Feb 15, 2022
@keslerm
Copy link

keslerm commented Feb 25, 2022

I think it has something to do with the existing running salt process if salt is calling the update itself?

We've been rolling the upgrade out with 3004-3 installer using our older, soon to be retired Ansible pipeline and it works great but trying to use the salt-minion-py3 pkg installer still results in the files never being moved.

I'm using the above salt-minion-py3 patch @baby-gnu provided with the /move-config parameter.

@TheBigBear
Copy link

@twangboy what is the ETA of a fix for this? All of our new windows minions now have the salt app installed under the new Program Files location, BUT the minion_id and pki files etc ( and presumably the cache too under c:\salt\var but don't care about old cache ,) are still left behind under "c:\salt\conf"

@twangboy
Copy link
Contributor

I'll try to look at this today

@twangboy
Copy link
Contributor

As I'm looking at this... I'm wondering if there's still a process running with a lock on something in that directory when it tries to move it...

@keslerm
Copy link

keslerm commented May 20, 2022

@twangboy From my testing that's more than likely what's going on, it works flawlessly if I use an outside method to do the install but running it from within the salt formula/winpkg is when it fails.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working needs-triage
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants