-
Notifications
You must be signed in to change notification settings - Fork 170
PowerShell Wrappers: Docs assume elevation since Windows cannot access modules directory when non-elevated #472
Comments
cc @smurawski |
Cc @ksubrama |
Context seems to be the blog post / other docs on how to install the PowerShell wrappers: https://www.chef.io/blog/2015/08/17/chefdk-0-7-0-released/ |
Hmm - a system module path should work, even as a user. Was the powershell session restarted after chef-dk was installed? |
Yes it was, the environment variable is visible in a CMD prompt, however it seems PowerShell does its own thing with it - this blog post describes the behavior better than I can: https://www.sapien.com/blog/2012/05/22/psmodulepath-discrepancies/ In fact now I've run PowerShell as an administrator once, I appear to have a PSModulePath that is set whether I am running privileged or not. Need to repro on a clean machine. |
@stuartpreston Can you tell us what $PSVersionTable prints in powershell. I now suspect that we're seeing some strange behavior depending on powershell version involved. Also, what version of windows are you running? |
Sure thing, though I would say it's fairly low priority to chase down, I'm running Windows 10 Enterprise (build 10240) in this case. PS C:\Users\StuartPreston> $PSVersionTable
Name Value
---- -----
PSVersion 5.0.10240.16384
WSManStackVersion 3.0
SerializationVersion 1.1.0.1
CLRVersion 4.0.30319.42000
BuildVersion 10.0.10240.16384
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion 2.3 |
Thanks for that. We'll keep an eye on it and run some tests on non-admin scenarios across powershell versions to see if there's some behavior change. |
We identified a possible issue where if a reboot is pending, windows installer wasn't broadcasting updates to PSModulePath until after a reboot (or unless you restarted explorer.exe). I'm not sure how much of what you're seeing is due to that @stuartpreston but it could be one possible issue. |
Assuming you have installed ChefDK on Windows to |
Confirmed @cjuerg 's fix works on Windows 10 with ChefDK 0.9.0. I love my new ChefDK Icon! |
Version ChefDK with a static version number
I get the same error -
cjuerg's fix does not work for me, however running as administrator does fix the message. The executionpolicy is set to restricted FWIW: |
After trying to debug this for a while, I ran across something that is probably a clue, but I can't explain: |
Hey everyone, I poked around a bit today and found the following: The start-chefdk.ps1 spawns a new PowerShell process without the -ExecutionPolicy Bypass parameter so the policy defaults back to restrcted (or whatever you system default policy was set to) and are therefore blocked again. I just extended the spawn to
now with the policy arguments and everything works fine. So, I guess the script just needs to be adjusted and everything will be fine? |
Is it a problem to sign |
Can you just sign chef.psm1? |
ChefDK 0.7.0
When running in a non-elevated PowerShell window, PSModulePath does not contain the path to the modules directory. This is because PSModulePath and Path appear to be set at a SYSTEM level only by the installer.
The workaround is to set a USER environment variable to
%windir%\system32\WindowsPowerShell\v1.0\Modules;%PSModulePath%
Also the usual rules apply about setting the Execution Policy correctly otherwise you run into this:
Perhaps the docs/blog posts need to reflect the above. Unless you are running Chef-Client locally on your workstation for scenarios that require admin access, most of the commands do not require elevation in Windows so this could be a common issue.
The text was updated successfully, but these errors were encountered: