knife solo cook on Windows can't find Chef >=0.10.4

[dvlscm]

This is almost certainly user error on my part, but I'm stumped. I attempted to follow the Windows setup instructions here. I definitely wasn't sure where I was supposed to take all of those actions. Specifically, I wasn't sure where nodes/hostname.json was supposed to go.

Anywho, here's what I did:

1. I've already been using knife-solo for Linux nodes from my Mac OSX machine, so I didn't need to do knife solo init (I assumed)
2. Installed cygwin on the Windows machine, including openssh and rsync
3. Added c:\cygwin64\bin to my system path in Windows (i.e., via the control panel)
4. Downloaded and installed Chef via the msi (install put stuff in C:\chef and C:\opscode)
5. Added nodes\[hostname].json to the root of my C drive, with an empty runlist as instructed

Is that right? Have to believe I mucked it up somewhere, because I get this when I run:

± knife solo cook Administrator@ec2-....compute-1.amazonaws.com -i ~/path/to/key.pem
Running Chef on ec2-....compute-1.amazonaws.com...
Checking Chef version...
ERROR: RuntimeError: Couldn't find Chef >=0.10.4 on ec2-....compute-1.amazonaws.com. Please run `knife solo prepare Administrator@ec2-....compute-1.amazonaws.com -i /Users/me/.../key.pem` to ensure Chef is installed and up to date.

I'm happy to provide additional info if any of what I did is ambiguous. Like I said, I'm pretty sure the problem is me, but I'm stumbling in the dark.

[matschaffer]

Is chef-solo in the path? That'd be my first suspicion. Also try running with -VV, that should at least show the commands it's running to determine whether or not chef is installed.

On Monday, September 22, 2014, dvlscm notifications@github.com wrote:

This is almost certainly user error on my part, but I'm stumped. I attempted to follow the Windows setup instructions here http://matschaffer.github.io/knife-solo/. I definitely wasn't sure where I was supposed to take all of those actions. Specifically, I wasn't sure where nodes/hostname.json was supposed to go.

Anywho, here's what I did:

1. I've already been using knife-solo for Linux nodes from my Mac OSX machine, so I didn't need to do knife solo init (I assumed)
2. Installed cygwin on the Windows machine, including openssh and rsync
3. Added c:\cygwin64\bin to my system path in Windows (i.e., via the control panel)
4. Downloaded and installed Chef via the msi (install put stuff in C:\chef and C:\opscode)
5. Added nodes[hostname].json to the root of my C drive, with an empty runlist as instructed

Is that right? Have to believe I mucked it up somewhere, because I get this when I run:

± knife solo cook Administrator@ec2-54-164-69-216.compute-1.amazonaws.com javascript:_e(%7B%7D,'cvml','Administrator@ec2-54-164-69-216.compute-1.amazonaws.com'); -i ~/path/to/key.pem Running Chef on ec2-....compute-1.amazonaws.com... Checking Chef version... ERROR: RuntimeError: Couldn't find Chef >=0.10.4 on ec2-....compute-1.amazonaws.com. Please run knife solo prepare Administrator@ec2-....compute-1.amazonaws.com -i /Users/me/.../key.pem to ensure Chef is installed and up to date.

I'm happy to provide additional info if any of what I did is ambiguous. Like I said, I'm pretty sure the problem is me, but I'm stumbling in the dark.

— Reply to this email directly or view it on GitHub https://github.com/matschaffer/knife-solo/issues/407.

-Mat

about.me/matschaffer

[dvlscm]

I'm running cygwin, and honestly, I'm quite confused about where stuff is/goes. Here's what I get when I echo $PATH:

$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem:/cygdrive/c/Windows/System32/WindowsPowerShell/v1.0:/cygdrive/c/Program Files/Amazon/cfn-bootstrap

I don't see anything in there about chef-solo, so you're probably right about the path. What should be in there for chef-solo, and where should it be (at the start, or at the end)? I tried each of these (separately, not at the same time) in ~/.bash_profile for the Administrator user:

export PATH=$PATH:C:/opscode/chef/bin
export PATH=$PATH:/cygdrive/c/opscode/chef/bin

Each of those paths exits, but I still get the same error when I cook. When I run -VV, I get this:

± knife solo cook Administrator@ec2-....compute-1.amazonaws.com -i ~/path/to/key.pem -VV
Starting 'Run'
Running Chef on ec2-....compute-1.amazonaws.com...
Checking Chef version...
DEBUG: Initial command sudo chef-solo --version 2>/dev/null | awk '$1 == "Chef:" {print $2}'
DEBUG: Initial command sudo -V
DEBUG: Running processed command sudo -V
DEBUG: sudo -V stdout: bash: sudo: command not found

DEBUG: `sudo` not available on ec2-....compute-1.amazonaws.com
DEBUG: Running processed command  chef-solo --version 2>/dev/null | awk '$1 == "Chef:" {print $2}'
/Users/me/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/gems/knife-solo-0.4.2/lib/chef/knife/solo_cook.rb:278:in `check_chef_version': Couldn't find Chef >=0.10.4 on ec2-....compute-1.amazonaws.com. Please run `knife solo prepare Administrator@ec2-....compute-1.amazonaws.com -i /Users/me/path/to/key.pem` to ensure Chef is installed and up to date. (RuntimeError)
    from /Users/me/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/gems/knife-solo-0.4.2/lib/chef/knife/solo_cook.rb:86:in `block in run'
    from /Users/me/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/gems/knife-solo-0.4.2/lib/chef/knife/solo_cook.rb:208:in `time'
    from /Users/me/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/gems/knife-solo-0.4.2/lib/chef/knife/solo_cook.rb:75:in `run'
    from /Users/me/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/gems/chef-11.16.0/lib/chef/knife.rb:493:in `run_with_pretty_exceptions'
    from /Users/me/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/gems/chef-11.16.0/lib/chef/knife.rb:174:in `run'
    from /Users/me/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/gems/chef-11.16.0/lib/chef/application/knife.rb:139:in `run'
    from /Users/me/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/gems/chef-11.16.0/bin/knife:25:in `<top (required)>'
    from /Users/me/.rbenv/versions/2.1.2/bin/knife:23:in `load'
    from /Users/me/.rbenv/versions/2.1.2/bin/knife:23:in `<main>'

That suggests there's a cygwin issue with sudo. Is there one that you know of? Thought I remembered reading something about that in the last day or so, but can't find it now.

[matschaffer]

The sudo message is fine. Do you know where the chef-solo binary is installed?

-Mat

about.me/matschaffer

On Mon, Sep 22, 2014 at 8:51 AM, dvlscm notifications@github.com wrote:

I'm running cygwin, and honestly, I'm quite confused about where stuff is/goes. Here's what I get when I echo $PATH:

$ echo $PATH /usr/local/bin:/usr/bin:/bin:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem:/cygdrive/c/Windows/System32/WindowsPowerShell/v1.0:/cygdrive/c/Program Files/Amazon/cfn-bootstrap

I don't see anything in there about chef-solo, so you're probably right about the path. What should be in there for chef-solo, and where should it be (at the start, or at the end)?

When I run -VV, I get this:

± knife solo cook Administrator@ec2-....compute-1.amazonaws.com -i ~/path/to/key.pem -VV Starting 'Run' Running Chef on ec2-....compute-1.amazonaws.com... Checking Chef version... DEBUG: Initial command sudo chef-solo --version 2>/dev/null | awk '$1 == "Chef:" {print $2}' DEBUG: Initial command sudo -V DEBUG: Running processed command sudo -V DEBUG: sudo -V stdout: bash: sudo: command not found

DEBUG: sudo not available on ec2-....compute-1.amazonaws.com DEBUG: Running processed command chef-solo --version 2>/dev/null | awk '$1 == "Chef:" {print $2}' /Users/me/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/gems/knife-solo-0.4.2/lib/chef/knife/solo_cook.rb:278:in check_chef_version': Couldn't find Chef >=0.10.4 on ec2-....compute-1.amazonaws.com. Please runknife solo prepare Administrator@ec2-....compute-1.amazonaws.com -i /Users/me/path/to/key.pemto ensure Chef is installed and up to date. (RuntimeError) from /Users/me/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/gems/knife-solo-0.4.2/lib/chef/knife/solo_cook.rb:86:inblock in run' from /Users/me/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/gems/knife-solo-0.4.2/lib/chef/knife/solo_cook.rb:208:in time' from /Users/me/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/gems/knife-solo-0.4.2/lib/chef/knife/solo_cook.rb:75:inrun' from /Users/me/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/gems/chef-11.16.0/lib/chef/knife.rb:493:in run_with_pretty_exceptions' from /Users/me/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/gems/chef-11.16.0/lib/chef/knife.rb:174:inrun' from /Users/me/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/gems/chef-11.16.0/lib/chef/application/knife.rb:139:in run' from /Users/me/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/gems/chef-11.16.0/bin/knife:25:in<top (required)>' from /Users/me/.rbenv/versions/2.1.2/bin/knife:23:in load' from /Users/me/.rbenv/versions/2.1.2/bin/knife:23:in

'

That suggests there's a cygwin issue with sudo. Is there one that you know of? Thought I remembered reading something about that in the last day or so, but can't find it now.

— Reply to this email directly or view it on GitHub https://github.com/matschaffer/knife-solo/issues/407#issuecomment-56394359 .

[dvlscm]

Let me hunt that down... It's here:

C:\opscode\chef\bin\chef-solo

I believe that's the default install location. There's a batch file in there as well, called chef-solo.bat.

[matschaffer]

Yep. So that will need to be in your path for it to call chef.

On Monday, September 22, 2014, dvlscm notifications@github.com wrote:

Let me hunt that down... It's here:

C:\opscode\chef\bin\chef-solo

I believe that's the default install location. There's a batch file in there as well, called chef-solo.bat.

— Reply to this email directly or view it on GitHub https://github.com/matschaffer/knife-solo/issues/407#issuecomment-56408537 .

-Mat

about.me/matschaffer

[dvlscm]

Got it. Here's what I see when I echo the path in cygwin when I'm in the Administrator home dir:

$ echo $PATH
/usr/local/bin:/usr/bin:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem:/cygdrive/c/Windows/System32/WindowsPowerShell/v1.0:/cygdrive/c/Program Files/Amazon/cfn-bootstrap:/usr/bin:/cygdrive/c/opscode/chef/bin:/cygdrive/c/opscode/chef/embedded/bin

Does cygdrive/c/opscode/chef/bin point to the same place as C:\opscode\chef\bin\chef-solo? I have to assume so since I see this when I check my path via PowerShell:

C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\Am
azon\cfn-bootstrap\;C:\cygwin64\bin;C:\opscode\chef\bin;C:\opscode\chef\embedded\bin

So it looks to me like I already have C:\opscode\chef\bin in there. I don't have chef-solo stuck on the end of the path explicitly, but Windows should be able to find it if it's in bin, I assume. I went ahead and tried it with chef-solo on the end that made no difference.

Unfortunately, when I run knife solo cook (same command as before), I still get the "Couldn't find Chef" problem. It feels like I'm awfully close here, but I must be doing something fundamentally wrong.

[matschaffer]

Can you try sshing into the machine directly and running just 'chef-solo'?

Could be something else is tweaking the path.

Also since the chef check involves an awk call maybe check if you have that available. The whole command should be in the chef_version function in solo_cook.rb

On Monday, September 22, 2014, dvlscm notifications@github.com wrote:

Got it. Here's what I see when I echo the path in cygwin when I'm in the Administrator home dir:

$ echo $PATH /usr/local/bin:/usr/bin:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem:/cygdrive/c/Windows/System32/WindowsPowerShell/v1.0:/cygdrive/c/Program Files/Amazon/cfn-bootstrap:/usr/bin:/cygdrive/c/opscode/chef/bin:/cygdrive/c/opscode/chef/embedded/bin

Does cygdrive/c/opscode/chef/bin point to the same place as C:\opscode\chef\bin\chef-solo? I have to assume so since I see this when I check my path via PowerShell:

C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\Am azon\cfn-bootstrap\;C:\cygwin64\bin;C:\opscode\chef\bin;C:\opscode\chef\embedded\bin

So it looks to me like I already have C:\opscode\chef\bin in there. I don't have chef-solo stuck on the end of the path explicitly, but Windows should be able to find it if it's in bin, I assume. I went ahead and tried it with chef-solo on the end that made no difference.

Unfortunately, when I run knife solo cook (same command as before), I still get the "Couldn't find Chef" problem. It feels like I'm awfully close here, but I must be doing something fundamentally wrong.

— Reply to this email directly or view it on GitHub https://github.com/matschaffer/knife-solo/issues/407#issuecomment-56428632 .

-Mat

about.me/matschaffer

[dvlscm]

I can SSH directly and run chef-solo. It bombs because it couldn't find a cookbook, but it did run:

Administrator@WIN-BUB0S02DUTO ~
$ chef-solo
[2014-09-22T20:46:58+01:00] WARN: *****************************************
[2014-09-22T20:46:58+01:00] WARN: Did not find config file: C:\chef\solo.rb, using command line options.
[2014-09-22T20:46:58+01:00] WARN: *****************************************
[2014-09-22T20:46:58+01:00] WARN:
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
SSL validation of HTTPS requests is disabled. HTTPS connections are still
encrypted, but chef is not able to detect forged replies or man in the middle
attacks.
...

So it looks like SSH connects fine, and chef-solo is installed and usable.

I ran this command in the SSH session and got no result, but no error either:

sudo chef-solo --version 2>/dev/null | awk '$1 == "Chef:" {print $2}'

So it looks like maybe awk is available. Running awk -h gives me the help info, so I assume it's there. I know nothing about awk, but it looks like it's testing the Chef version there based on the output of the chef-solo version check. Since it doesn't print anything ... well, I don't know what that means.

By the way, chef-solo --version give me this:

$ chef-solo --version
Chef: 11.16.2

So that's okay, too.

[matschaffer]

The no output is definitely a problem. I wonder if the 2>/dev/null is swallowing the version number. Mind trying just

chef-solo --version | awk '$1 == "Chef:" {print $2}'

-Mat

about.me/matschaffer

On Mon, Sep 22, 2014 at 12:55 PM, dvlscm notifications@github.com wrote:

I can SSH directly and run chef-solo. It bombs because it couldn't find a cookbook, but it did run:

Administrator@WIN-BUB0S02DUTO ~ $ chef-solo [2014-09-22T20:46:58+01:00] WARN: [2014-09-22T20:46:58+01:00] WARN: Did not find config file: C:\chef\solo.rb, using command line options. [2014-09-22T20:46:58+01:00] WARN: [2014-09-22T20:46:58+01:00] WARN:

---

SSL validation of HTTPS requests is disabled. HTTPS connections are still encrypted, but chef is not able to detect forged replies or man in the middle attacks. ...

So it looks like SSH connects fine, and chef-solo is installed and usable.

I ran this command in the SSH session and got no result, but no error either:

sudo chef-solo --version 2>/dev/null | awk '$1 == "Chef:" {print $2}'

So it looks like maybe awk is available. Running awk -h gives me the help info, so I assume it's there. I know nothing about awk, but it looks like it's testing the Chef version there based on the output of the chef-solo version check. Since it doesn't print anything ... well, I don't know what that means.

By the way, chef-solo --version give me this:

$ chef-solo --version Chef: 11.16.2

So that's okay, too.

— Reply to this email directly or view it on GitHub https://github.com/matschaffer/knife-solo/issues/407#issuecomment-56431126 .

[dvlscm]

Ha, great minds, I guess. I was just futzing around with that. I still don't know exactly what that awk business is doing :) But I do see that it's sorta-kinda ignoring errors because of 2>/dev/null. When I run without that, I see this:

$ sudo chef-solo --version | awk '$1 == "Chef:" {print $2}'
-bash: sudo: command not found

Okay, so maybe sudo is getting in the way somehow. When I run without that, like you suggested, I get this:

$ chef-solo --version | awk '$1 == "Chef:" {print $2}'
11.16.2

Makes me wonder if maybe there's a combination of a sudo problem and error suppression conspiring against me. Thoughts?

[matschaffer]

Knife solo isn't actually calling it with sudo, though. See this bit:

DEBUG: Running processed command chef-solo

The sudo not found is it detecting whether or not sudo exists so it'll then get stripped out if it doesn't.

Does this also have no output?:

chef-solo --version | awk '$1 == "Chef:" {print $2}'

-Mat

about.me/matschaffer

On Mon, Sep 22, 2014 at 1:09 PM, dvlscm notifications@github.com wrote:

Ha, great minds, I guess. I was just futzing around with that. I still don't know exactly what that awk business is doing :) But I do see that it's sorta-kinda ignoring errors because of 2>/dev/null. When I run without that, I see this:

$ sudo chef-solo --version | awk '$1 == "Chef:" {print $2}' -bash: sudo: command not found

Okay, so maybe sudo is getting in the way somehow. When I run without that, like you suggested, I get this:

$ chef-solo --version | awk '$1 == "Chef:" {print $2}' 11.16.2

Makes me wonder if maybe there's a combination of a sudo problem and error suppression conspiring against me. Thoughts?

— Reply to this email directly or view it on GitHub https://github.com/matschaffer/knife-solo/issues/407#issuecomment-56434044 .

[dvlscm]

Okay, makes sense. The command without sudo gives me this:

$ chef-solo --version | awk '$1 == "Chef:" {print $2}'
11.16.2

So I get output there, in the form of the version number.

[matschaffer]

How about with the stderr redirected to null?

On Monday, September 22, 2014, dvlscm notifications@github.com wrote:

Okay, makes sense. The command without sudo gives me this:

$ chef-solo --version | awk '$1 == "Chef:" {print $2}' 11.16.2

So I get output there, in the form of the version number.

— Reply to this email directly or view it on GitHub https://github.com/matschaffer/knife-solo/issues/407#issuecomment-56439760 .

-Mat

about.me/matschaffer

[dvlscm]

Same result:

$ chef-solo --version 2>/dev/null | awk '$1 == "Chef:" {print $2}'
11.16.2

[dvlscm]

I don't know if this will shed any light on the problem or not, but I did a quick experiment. I modified solo_cook.rb->chef_version_satisfies? like so:

def chef_version_satisfies?(requirement)
  puts "got this version = #{chef_version}"
  Gem::Requirement.new(requirement).satisfied_by? Gem::Version.new(chef_version)
end

I added a puts statement to see what version number I'm getting. I also changed chef_version to remove the stderr redirection to null and see any error output, like so:

# Parses "Chef: x.y.z" from the chef-solo version output
def chef_version
  # Memoize the version to avoid multiple SSH calls
  @chef_version ||= lambda do
    # cmd = %q{sudo chef-solo --version 2>/dev/null | awk '$1 == "Chef:" {print $2}'}
    cmd = %q{sudo chef-solo --version | awk '$1 == "Chef:" {print $2}'}
    run_command(cmd).stdout.strip
  end.call
end

The output was this without debug mode:

± knife solo cook Administrator@ec2-....compute-1.amazonaws.com -i ~/Documents/Devellocus/Keys/pipeline.pem
Running Chef on ec2-....compute-1.amazonaws.com...
Checking Chef version...
got_this_version = bash: chef-solo: command not found
requirement = >=0.10.4
ERROR: ArgumentError: Malformed version number string bash: chef-solo: command not found

It looks like the chef-solo command isn't found. That would suggest a path problem, but when I SSH into the machine and run the same command, I get this:

Administrator@WIN-... ~
$ chef-solo --version | awk '$1 == "Chef:" {print $2}'
11.16.2

And my path on the machine, set globally via Control Panel->Environment Variables, is this via PowerShell (note C:\opscode\chef\bin at the end):

PS C:\Users\Administrator> $Env:path
C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\Amazon\cfn-bootstrap\;C:\cygwin64\bin;C:\opscode\chef\bin

To sum up,

• It looks like the path on the machine points to where chef-solo is
• It looks like running the command remotely via SSH with knife solo cook tells me the chef-solo command can't be found
• The result is that running knife solo cook can't identify the chef version on the machine and blows up

What I don't understand is why the cook command can't find chef-solo when I can run the same chef-solo --version command on the machine itself and get back a version number of 11.16.2. That's a mystery to me.

[matschaffer]

Thanks for trying that edit, that was the next thing I was thinking. The next thing that comes to my mind is adding a run_command("echo $PATH") call which should show what the environment thinks the path is when knife-solo is SSHing in. It could be that chef-solo ends up on your path via a profile script that is only loaded for an interactive shell.

If you can find out what profile script sets it you should be able to force knife-solo to load it using the --startup-script (or -s) option.

[dvlscm]

Hm, interesting thought. Not sure where you were suggesting I put that path echo statement, so I put it in chef_version. The results were:

± knife solo cook Administrator@ec2-....compute-1.amazonaws.com -i ~/path/to/key.pem -VV
Starting 'Run'
Running Chef on ec2-....compute-1.amazonaws.com...
Checking Chef version...
DEBUG: Initial command echo $PATH
DEBUG: Initial command sudo -V
DEBUG: Running processed command sudo -V
DEBUG: sudo -V stdout: bash: sudo: command not found

DEBUG: `sudo` not available on ec2-....compute-1.amazonaws.com
DEBUG: Running processed command echo $PATH
DEBUG: echo $PATH stdout: /bin:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem:/cygdrive/c/Windows/System32/WindowsPowerShell/v1.0:/cygdrive/c/Program Files/Amazon/cfn-bootstrap

That tells me your suspicion was correct. The path doesn't have anything that'll get to chef-solo. The system path in the Control Panel shows it, but maybe that's the end result of said profile script running.

Any idea how I can find the profile script that loads it? I admit I have no idea. I'm running a Windows 2012 server on AWS. Is that profile script likely to be a cygwin thing?

[matschaffer]

@tknerr is my usual windows guru, so I'll ping him here.

Short of that grep -R 'opscode/chef/bin' / might find it for you.

[tknerr]

@matschaffer @dvlscm sorry, no experience with setting up windows machines via Chef, but maybe @damphyr has an idea?

P.S.: I'm occasionally using windows as a control station for managing Linux VMs via Chef - if that's your concern too then https://github.com/tknerr/bills-kitchen might be worth a look.

[dvlscm]

@matschaffer I can find opscode/chef/bin without a problem. I know exactly where that is. And it ends up in my system path (and is visible in Environment Variables) when I RDP into the Windows machine. So I don't think having chef-solo in the right place is the issue.

The issue is that it's apparently not in the path when I SSH in with knife solo cook. If there's a profile script that puts it there, I need to find it, but I have no idea where it might be, or what it's called. Are you saying it should be in opscode/chef/bin? I looked in there but didn't see anything that looked like it might be such a script. Then again, I'm not sure what I'm looking for.

[matschaffer]

I was saying that the profile script would likely contain the string 'opscode/chef/bin'. So grepping across the whole FS for that night tell you where it is.

On Thursday, September 25, 2014, dvlscm notifications@github.com wrote:

@matschaffer https://github.com/matschaffer I can find opscode/chef/bin without a problem. I know exactly where that is. And it ends up in my system path (and is visible in Environment Variables) when I RDP into the Windows machine. So I don't think having chef-solo in the right place is the issue.

The issue is that it's apparently not in the path when I SSH in. If there's a profile script that puts it there, I need to find it, but I have no idea where it might be, or what it's called. Are you saying it should be in opscode/chef/bin? I looked in there but didn't see anything that looked like it might be such a script. Then again, I'm not sure what I'm looking for.

— Reply to this email directly or view it on GitHub https://github.com/matschaffer/knife-solo/issues/407#issuecomment-56793386 .

-Mat

about.me/matschaffer

[dvlscm]

Well, yes, I guess that would make sense. Silly me :) I'll take a look.

[damphyr]

OK, I will wade in now. First of all, ditch cygwin. It brings nothing but pain and tears.

If you want a bash shell that is usable on Windows then get msys. Actually get @tknerr 's BIll's Kitchen. Or go for the easy way and install git for windows (msysgit).

ChefDK + msysgit on a Windows machine will result in an environment that works without hassle from both bash and cmd.exe. msys takes over the Windows PATH values and converts it correctly and has a more sane convention for drive letters ( /c/foo instead of /cygdrive/c/foo). Also you'll be able to find /etc and all the bash goodness.

One caveat: When doing chef make sure that you have no other Ruby preceding the Chef paths in PATH, it will mess things up.

As for prepping a Windows machine to be provisioned by Chef and Vagrant, well that's a bit more elaborate. Basically OpenSSH and chef-client are the minimal requirements. I actually used packer and adapted the scripts from the box-cutter project (which unfortunately won't install without user intervention, but that is a Windows problem - it can be tweaked I just haven't had the time to write about it).

You might not want to create baseboxes but you can check the batch files in script/. The cmtool.bat batch file will install chef properly. From what I see they added chefdk as well so copy that batch file and run it in a cmd.exe cmtool.bat chef or cmtool.bat chefdk

Check the win7 json file. The correct setup is essentially calling the batch files in floppy/ and then the ones in script/ in the order defined in the packer config. While there's quite a bit of house cleaning and optimization (like running ultradefrag) there are also essential Windows tricks (installing winrm, deactivating UAC and the stupid firewall, creating the vagrant user etc.). Obviously if you don't care about vagrant you only need the Chef stuff, but I strongly suggest checking those batch files, they have some distilled Windows foo in them :smile:

[dvlscm]

Thanks for the input @damphyr.

I guess I chose unwisely with regard to cygwin. All I wanted from it was SSH connectivity, maybe rsync. But that's what I was hoping knife-solo would help me with. I'd rather not mess with "non-Windows" stuff on Windows (even though I'm growing to hate the OS for automation). As you read above, I've had no luck.

I'll check out the cmtool.bat you mentioned. Maybe that's a good way to bootstrap chef on a node, which will let me run chef-client. I hope.

This has been far more painful than I'd hoped it would be.

[sgtcoolguy]

So I ran into issues using the MS OpenSSH port (see #500). I then swapped over to use cygwin's openssh and that got further, but the chef version check failed as above. The redirection was suppressing the error between the chef embedded ruby.exe and the cygwin path to chef-solo:

$ chef-solo --version  | awk '$1 == "Chef:" {print $2}'
C:\opscode\chef\embedded\bin\ruby.exe: No such file or directory -- /cygdrive/c/opscode/chef/bin/chef-solo (LoadError)

It would appear that the intermixing of the cygwin paths and windows paths kills this.

Does anyone have a nice writeup on a sane and manageable way to use knife solo on Windows? I started enabling winrm so I could do knife bootstrap windows winrm and got that working, but then knife solo doesn't support winrm. Then I used the MS OpenSSH and that didn't work because it gives you a PowerShell session. Then I tried cygwin's openssh and the path clashes kill that (maybe I can get around it by installing ruby via cygwin? But the chef-solo script explicitly points at the check embedded ruby.exe windows path in it's shebang line).