[BUG] [RC1 Sodium] Windows - traceback on grain pending_reboot.pending_reboot

[dafyddj]

Description
Sodium RC1 generates a traceback while loading the grain pending_reboot.pending_reboot.

       [CRITICAL] Failed to load grains defined in grain file pending_reboot.pending_reboot in function <function pending_reboot at 0x00000200E6FAED38>, error:
       Traceback (most recent call last):
         File "C:\salt\bin\lib\site-packages\win32com\client\dynamic.py", line 89, in _GetGoodDispatch
           IDispatch = pythoncom.connect(IDispatch)
       pywintypes.com_error: (-2147221021, 'Operation unavailable', None, None)
       
       During handling of the above exception, another exception occurred:
       
       Traceback (most recent call last):
         File "C:\salt\bin\lib\site-packages\salt-3001rc1-py3.7.egg\salt\loader.py", line 859, in grains
           ret = funcs[key](**kwargs)
         File "C:\salt\bin\lib\site-packages\salt-3001rc1-py3.7.egg\salt\grains\pending_reboot.py", line 31, in pending_reboot
           return {"pending_reboot": salt.utils.win_system.get_pending_reboot()}
         File "C:\salt\bin\lib\site-packages\salt-3001rc1-py3.7.egg\salt\utils\win_system.py", line 522, in get_pending_reboot
           if check():
         File "C:\salt\bin\lib\site-packages\salt-3001rc1-py3.7.egg\salt\utils\win_system.py", line 488, in get_pending_windows_update
           return salt.utils.win_update.needs_reboot()
         File "C:\salt\bin\lib\site-packages\salt-3001rc1-py3.7.egg\salt\utils\win_update.py", line 1095, in needs_reboot
           obj_sys = win32com.client.Dispatch("Microsoft.Update.SystemInfo")
         File "C:\salt\bin\lib\site-packages\win32com\client\__init__.py", line 95, in Dispatch
           dispatch, userName = dynamic._GetGoodDispatchAndUserName(dispatch,userName,clsctx)
         File "C:\salt\bin\lib\site-packages\win32com\client\dynamic.py", line 114, in _GetGoodDispatchAndUserName
           return (_GetGoodDispatch(IDispatch, clsctx), userName)
         File "C:\salt\bin\lib\site-packages\win32com\client\dynamic.py", line 91, in _GetGoodDispatch
           IDispatch = pythoncom.CoCreateInstance(IDispatch, None, clsctx, pythoncom.IID_IDispatch)
       pywintypes.com_error: (-2147024891, 'Access is denied.', None, None)

Setup
(Please provide relevant configs and/or SLS files (be sure to remove sensitive info).
See dafyddj/openvpn-formula for test setup.

Steps to Reproduce the behavior
(Include debug logs if possible and relevant)
This happens during testing of openvpn-formula using either Vagrant locally or can be seen in GitHub Actions CI.
See here

Expected behavior
No traceback.

Screenshots
If applicable, add screenshots to help explain your problem.

Versions Report

salt --versions-report

(Provided by running salt --versions-report. Please also mention any differences in master/minion versions.)

       Salt Version:
           Salt: 3001rc1
        
       Dependency Versions:
           cffi: 1.12.2
       cherrypy: 17.4.1
       dateutil: 2.8.0
             docker-py: Not Installed
         gitdb: 2.0.5
             gitpython: 2.1.10
         Jinja2: 2.10.1
        libgit2: Not Installed
       M2Crypto: Not Installed
           Mako: 1.0.7
          msgpack-pure: Not Installed
        msgpack-python: 0.5.6
          mysql-python: Not Installed
             pycparser: 2.19
       pycrypto: Not Installed
          pycryptodome: 3.9.7
         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.4
         PyYAML: 5.1.2
          PyZMQ: 18.0.1
          smmap: 2.0.5
        timelib: 0.2.4
        Tornado: 4.5.3
            ZMQ: 4.3.1
        
       System Versions:
           dist: msys_nt-10.0-17763 3.0.7 
         locale: cp1252
        machine: AMD64
        release: 2019Server
         system: Windows
        version: 2019Server 10.0.17763 SP0

Additional context
Add any other context about the problem here.

[xeacott]

File "C:\salt\bin\lib\site-packages\win32com\client\dynamic.py", line 91, in _GetGoodDispatch
           IDispatch = pythoncom.CoCreateInstance(IDispatch, None, clsctx, pythoncom.IID_IDispatch)
       pywintypes.com_error: (-2147024891, 'Access is denied.', None, None)

I see "Access is denied" which indicates that the process running your salt-minion, salt-call, whomever in this case doesn't have privledges to launch a "SystemInfo" instance. Basically, the grain that loads up at startup has to get through this block of code and it clearly isnt:

    with salt.utils.winapi.Com():
        # Create an AutoUpdate object
        obj_sys = win32com.client.Dispatch("Microsoft.Update.SystemInfo")
        return salt.utils.data.is_true(obj_sys.RebootRequired)

Two things should happen on our part:

1. Throw that guy in a try catch, let the application continue if it does fail?
2. Indicate to the user that the grain couldn't be loaded, and all subsequent window's COM related functions may fail unless they run salt with admin privileges.

@cmcmarrow @twangboy any thoughts on that?

[xeacott]

@dafenko When you had this failure, what user was running salt?

[dafyddj]

Hi, this is in a Kitchen test environment, so in this case the user is kitchen and in the group Administrators.

These commands are called over winrm, so I have a feeling that this has to do with the fact that Win Update commands can't be called remotely.

[xeacott]

To my knowledge we have passing tests for this and our tests run in kitchen env's so I'm still wondering about that, I personally haven't experienced issues calling COM related win32 stuff remotely. It could be something else (COM object is already initialized and running under a different security context) and in this case, that is throwing both errors "Access is denied" and "Operation unavailable"...

Trying to repro this

[xeacott]

I also see the minion isn't failing, and the CI pipeline continues just fine. Maybe we'll make this grain optional in some capacity.

[twangboy]

@dafyddj Are you still seeing this error?

[dafyddj]

Yes, we are. It still affects our test environment.

[marbx]

@twangboy, do you have a workaround for disabling the "pending reboot" grain on a salt-minion 3001?

salt-call test.version
[CRITICAL] Failed to load grains defined in grain file pending_reboot.pending_reboot in function <function pending_reboot at 0x0000018754F65DC8>, error:
Traceback (most recent call last):
File "C:\salt\bin\lib\site-packages\win32com\client\dynamic.py", line 89, in _GetGoodDispatch
IDispatch = pythoncom.connect(IDispatch)
pywintypes.com_error: (-2147221021, 'Vorgang nicht verfⁿgbar.', None, None)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "C:\salt\bin\lib\site-packages\salt-3001-py3.7.egg\salt\loader.py", line 859, in grains
ret = funcskey
File "C:\salt\bin\lib\site-packages\salt-3001-py3.7.egg\salt\grains\pending_reboot.py", line 31, in pending_reboot
return {"pending_reboot": salt.utils.win_system.get_pending_reboot()}
File "C:\salt\bin\lib\site-packages\salt-3001-py3.7.egg\salt\utils\win_system.py", line 522, in get_pending_reboot
if check():
File "C:\salt\bin\lib\site-packages\salt-3001-py3.7.egg\salt\utils\win_system.py", line 488, in get_pending_windows_update
return salt.utils.win_update.needs_reboot()
File "C:\salt\bin\lib\site-packages\salt-3001-py3.7.egg\salt\utils\win_update.py", line 1095, in needs_reboot
obj_sys = win32com.client.Dispatch("Microsoft.Update.SystemInfo")
File "C:\salt\bin\lib\site-packages\win32com\client_init_.py", line 95, in Dispatch
dispatch, userName = dynamic._GetGoodDispatchAndUserName(dispatch,userName,clsctx)
File "C:\salt\bin\lib\site-packages\win32com\client\dynamic.py", line 114, in _GetGoodDispatchAndUserName
return (_GetGoodDispatch(IDispatch, clsctx), userName)
File "C:\salt\bin\lib\site-packages\win32com\client\dynamic.py", line 91, in _GetGoodDispatch
IDispatch = pythoncom.CoCreateInstance(IDispatch, None, clsctx, pythoncom.IID_IDispatch)
pywintypes.com_error: (-2147024891, 'Zugriff verweigert', None, None)
local:
3001

[twangboy]

Looks like this has been addressed by this PR: #58495

[xeacott]

Closing this issue unless you're still experiencing @dafyddj