Server 2003 Does Not Work With Chef about vagrant-windows HOT 8 CLOSED

As a work around to this issue I was able to get a chef-solo provisioning work with the following modifications. These modifications take many of the extended features of vagrant away, but could be potentially a basis for how to override the vagrant functions in the in the vagrant-windows gem.

Modify the chef-solo.bat file

copy chef-solo.bat to chef-solo-orig.bat
rename chef-solo to chef-solo-orig
edit chef-solo.bat to be only the line "chef-solo-orig %3 %4".  This strips the -c parameter from the vagrant call

Create a mklink.bat file

Create the file c:\windows\system32\mklink.bat
Place the line "echo Mounting %2 to %3 >> c:\Temp\mklink.log"

Create a solo.rb file

Create the file c:\etc\chef\solo.rb
Set cookbook_path "\\\\vboxsvr\\v-csc-1"
Set role_path "\\\\vboxsvr\\v-csr-2"
Set data_bag_path "\\\\vboxsvr\\v-csdb-3"

Set the following lines in the Vagrantfile

config.vm.share_folder "v-csc-1", "/tmp/vagrant-chef-1/chef-solo-1/cookbooks", "#{ENV['HOME'] || ENV['HOMEDRIVE']}/chef/chef-repo/cookbooks"
config.vm.share_folder "v-csr-2", "/tmp/vagrant-chef-1/chef-solo-2/roles", "#{ENV['HOME'] || ENV['HOMEDRIVE']}/chef/chef-repo/roles"
config.vm.share_folder "v-csdb-3", "/tmp/vagrant-chef-1/chef-solo-3/data_bags", "#{ENV['HOME'] || ENV['HOMEDRIVE']}/chef/chef-repo/data_bags"

Remove the following lines in the Vagrantfile

chef.cookbooks_path
chef.roles_path
chef.data_bags_path

This solution requires that v-csc-1 is set to cookbooks, v-csr-2 is set to roles and v-csdb-3 is set to data_bags

from vagrant-windows.

@leftathome Can you confirm this. I think that you are running on windows 2003 No?

from vagrant-windows.

Correct, this is windows server 2003. I should rephrase that it's not chef that does not run on server 2003 it's the vagrant/vagrant-windows things that don't work on server 2003 because it's calling in to the OS to do mklink. The workaround I posted above is what I had to do to get chef-solo to run on a server 2003 vagrant box.

from vagrant-windows.

Unfortunately I can't confirm this as I don't have a 2003 image handy. Our test framework is 2008R2-centric and concerned primarily with getting chef-client to run on a node. Version-specific features can be added via distro_dispatch without resorting to even more monkey-patching -- I added 2003 just as an example. Should be possible to patch in support for just about any other version of Windows.

@moserke, you might want to give my fork of this module a try and see if it fixes anything for you ... or, at least, that it's easier to work on.

It might not be, since you're using chef-solo and I'm using chef-client, but it might be worth a try anyway. (Good luck!)

from vagrant-windows.

@moserke It seems that using junction (from sysinternals) *could solve this problem. Are you interested in making a PR for it?

from vagrant-windows.

@moserke I am considering simply not supporting windows 2003. The problem that I run into is that I do not use windows 2003 in any of my environments and hence I do not have the testing resources to maintain this. I certainly would not be in objection to accepting a pull request that addresses this incompatibility. If I where implementing this, I would probably do a P/Invoke for creating junctions from powershell and add it to the resource script.

from vagrant-windows.

Yeah, the issue with this is that server 2003 does not allow remote paths/UNCs in their junctions. So although you can create the junction you can not map it to the virtualbox \vboxsvr path. I think we may have hit a wall on getting this fully supported in the same mode as server 2008. Maybe just putting a "Server 2003 Not Supported" is sufficient, people won't try that way. Besides, it's a ten year old OS right. :-)

from vagrant-windows.

Updated the README with the supported operating systems. Thanks for the feedback.

from vagrant-windows.