Follow up: I never got this bit of Chef to work through vagrant
provisioning. Digging into the vagrant source I noticed that rather than
directly running provisioner code in a winrm session, it is scheduled to
run through the windows scheduler. Apparently this extra hoop is required
to gain the elevated permissions needed that cannot be gained directly
through a winrm session. Perhaps the powershell techinique to spawn a
process as a different user doesn't work when executed in the context of a
scheduled task.
Anyway, since openssh is installed and sshd configured as part of the
greater recipe used in this case, I ended up using ssh to masquerade as the
other user and accomplished what was needed that way.
On Wednesday, June 3, 2015 at 7:20:46 PM UTC-5, Skip Sopscak wrote:
>
> I'm using a basic windows box created from a fresh 2012r2 VirtualBox VM.
> All works is done as the typical Administrator user. I have a Chef recipe
> that works when run from the command line in an rdp session on a freshly
> up'd machine.The same recipe behaves differently when configured to run
> through the chef_solo provisioner in the Vagrantfile.
>
> After installing the svn chocolatey package and creating a local user, svn
> credentials need to be cached for the new user. I'm doing this by running a
> generic svn command, as the user, against the server in question. Using a
> Chef powershell_script resource:
>
> powershell_script "cache-svn-creds" do
> cwd "C:\\Program Files (x86)\\Subversion\\bin"
> code <<-PS_Script
> $local_user = New-Object System.Management.Automation.PsCredential(
> "local_user",(ConvertTo-SecureString "P@ssword" -AsPlainText -Force))
> $svn_args =
> @("ls","https://mysvn.com/svn/repos/foo/trunk";,
> "--username", "svn_user", "--password", "svn_password",
> "--non-interactive")
> Start-Process "svn.exe" -ArgumentList $svn_args -Credential
> $local_user -NoNewWindow -Wait
> PS_Script
> end
>
>
> This does not cause an error, and the Chef output explicitly indicates the
> resource ran successfully. But in the provisioner case it fails to have any
> affect. If run from the command line after rdp'ing into a freshly up'd
> (non-provisioned) box, it works exactly as expected.
>
> I suspect there is something about the winrm session established for the
> provisioner that affects the behavior, but that is a wild guess. Does
> anyone have a suggestion for getting this to work through the provisioner?
>
> Here's my Vagrantfile:
>
> Vagrant.require_version ">= 1.6.0"
>
>
> Vagrant.configure(2) do |config|
> config.vm.box = "2012r2_01"
> config.vm.communicator = "winrm"
> config.winrm.username = "Administrator"
> config.winrm.password = "Foo1Bar!"
> config.vm.network "forwarded_port", host: 33389, guest: 3389
> config.vm.network "forwarded_port", host: 22222, guest: 22
>
>
> config.vm.provision "chef_solo" do |chef|
> chef.add_recipe "foo::jenkins_winagent"
> end
> end
>
>
> When testing on the box, I comment out the provisioner above, rdp as
> Administrator and run:
>
> chef-client --local-mode --runlist 'recipe[foo::jenkins_winagent]'
>
>
>
>
--
You received this message because you are subscribed to the Google Groups
"Vagrant" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
