Issues with chef_client about packer-windows HOT 12 CLOSED

Sounds familiar hashicorp/packer#700

from packer-windows.

@sneal That does look very familiar. How did you end up working around it? I tried adding the SeServiceLogonRight role to the sshd_server user and disabling UsePrivelegeSeperation and it still doesn't work. I'm thinking of trying to move the scheduled task creation to the Autounattend.xml

2014/05/07 05:33:29 ui:     null: C:\Users\vagrant>cmd /c schtasks /create /tn "initial_chef_run" /tr c:\opscode\chef\bin\chef-client.bat /sc once /sd 01/01/3000 /st 00:00 /np /rl highest
    null: C:\Users\vagrant>cmd /c schtasks /create /tn "initial_chef_run" /tr c:\opscode\chef\bin\chef-client.bat /sc once /sd 01/01/3000 /st 00:00 /np /rl highest
2014/05/07 05:33:29 ui:     null: ERROR: Access is denied.
    null: ERROR: Access is denied.

from packer-windows.

Adding the scheduled task via Autounattend.xml worked. But running the task via the provisioner fails with "The wait operation timed out".

from packer-windows.

I remember seeing the same error creating scheduled tasks via a provisioner. I did get it working and was able to run Chef through several separate provisioner blocks including reboots between. The Chef runs were using a PowerShell script I ripped off from vagrant-windows to run Chef through a scheduled task.

Some things to try:

1. Is sshd running as the Administrator account?
2. I think my Packer hack that calls reconnect may be required...

This is the script I used in my Packer runs to install OpenSSH and correctly configure it to work with provisioners. Its possible this differs from what you're doing.

from packer-windows.

I ended up getting around this by using the chef-client windows service. All of my recipes completed without issue as the system user except for winrm -quickconfig. To get around that, I added logonasaservice rights to the vagrant user and have the service start as the vagrant user.

cmd /c c:\windows\temp\ntrights -u vagrant +r SeServiceLogonRight
cmd /c sc config chef-client obj= .\vagrant password= vagrant
cmd /c sc start chef-client

from packer-windows.

Nice idea. How did Packer know when your Chef run was complete?

from packer-windows.

@sneal still working on that :D

from packer-windows.

This seems to work but it won't catch errors in chef runs:

do {
    $chef_active = Get-Content C:\chef\cache\chef-client-running.pid
    $pid_running = Get-Process -Id $chef_active
    Start-Sleep 5
}
until ($pid_running -eq $null)

from packer-windows.

@sneal Similar to your comment in hashicorp/packer#700 , if I do a whoami as the first block in packer, I get sshd_server. Doing it via logging in with ssh I get vagrant.

from packer-windows.

Aw, interesting. I bet the difference is because of the way Go/Packer reuses the TCP connection - rightly or wrongly. I guess the Packer reconnect call is required to make OpenSSH happy. Sounds like a OpenSSH bug.

I'm not going to worry about it though, I've gotten pretty far with a WinRM communicator for Packer.

from packer-windows.

Looking forward to it. I'll close this off as openssh will likely be deprecated in the future.

from packer-windows.

Another workaround the lower privelege of the packer provisioner seems to be using psexec -u vagrant -p vagrant <cmd|bat>

from packer-windows.