search

chef / chef

Chef Infra, a powerful automation platform that transforms infrastructure into code automating how infrastructure is configured, deployed and managed across any environment, at any scale
http://www.chef.io/chef/
Apache License 2.0
7.61k stars 2.51k forks source link

windows_path doesn't effect ISE #10354

Open jaymzh opened 4 years ago

jaymzh commented 4 years ago

Description

This is somewhere between a bug and a enhancement request.

The windows_path resource is - at least it seems to me - somewhat useless on modern systems, because it sets the old kind of path which is not applicable to powershell or anything that leverages the so-called "ISE" framework. I think.

If you use windows_path to add an element to the path then pop open powershell and do echo $env:Path, it will not be there. If you dig up wherever cmd.exe is and do echo %PATH%, it will be there. How can this be? Well this page was the closest thing to an explanation I've found... it talks through the 6 different profiles - 3 types that affect "classic" stuff and then 3 types for "ISE" environments.

Again, Windows is not my strong-suit, and I could be missing things. But based on this I think it'd be useful if windows_path could set ISE paths.

Chef Version

15 and 16, various versions.

Platform Version

Windows 10, Windows Server 2016

gaelcolas commented 4 years ago

I don't know how you set your path and all, but does your problem persist after a reboot?

jaymzh commented 4 years ago

@gaelcolas it's something-something WMI queries? https://github.com/chef/chef/blob/f05dc3618241eaac5755b9904fc9ceb43e59a455/lib/chef/provider/windows_env.rb#L199

FTR reboot does not help. Though, honestly, if I have to reboot a production system to add something to the search path for the system, we've already failed. It's not a kernel parameter, it's just a default for an environment variable.

As far as I can tell from my research, the old places path goes are seen by 'classic' applications like cmd.exe and friends. Powershell or anything that falls under ISE use new paths, but I could be totally wrong.

mwrock commented 4 years ago

There is really just one definitive set of environment variables on windows. The set has 2 scopes. A "system" (or machine) and "user" scope. Foe the PATH variable, the "user" scope paths are appended to the "system" scoped paths to form the complete PATH for a given process environment.

Looking at the Chef resources, it looks like chef uses WMI to set the path at the "user" scope. This will update the variable in the Windows registry which is the authoritative location for all "persistent" environment variables. "Persistent" meaning that the variable is expected to be available to any process at startup. However, this will not export the value into the current process or shell. Maybe that is where the problem is occurring here? Once the converge completes, assuming you are running chef-client in a Powershell ISE environment, the PATH variable would look exactly the same as it did before chef-client ran. You would need to close the ISE and reopen to see the new value.

Even if you simple set $env:PATH using a powershell resource, it would not impact the PATH of the current ISE shell since that is the parent process of the chef process and would therefore not inherit any environment changes.

This all said, I might be completely misunderstanding your scenario. It would be helpful to get a more detailed set of repro steps to understand what you are seeing @jaymzh.

jaymzh commented 4 years ago

That sounds about right. How does one set the "system" scope? I can send a PR to fix it.

mwrock commented 4 years ago

Going over the code again it looks like I missed a key point, the variable is scoped to the <SYSTEM> user which effectively scopes it for everyone.

I'm not certain what your repro steps are but assuming you were in an ISE environment and converged a windows_path resource. I would not expect the environment to change until you closed and reopened the ISE.