-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Some provisioner commands oddly fail on Windows guests #700
Comments
Is there anything on stdout/stderr to show what is going on? I'm not sure why this would help since if the session fails to grab... it attempts to reconnect anyways. So all I can think of here is that the SSH server is weird and is accepting the session but isn't actually working? |
Here's a small Go program the reproduces the exact problem on my Windows box with OpenSSH installed. Here is the dism command's stdout/stderr when it fails:
The log has an error (which isn't useful):
For whatever reason without a new tcp connection the command will fail with exit code 5. With a clean tcp connection the command runs without error. I ran Process Monitor on the guest when it was successful and unsuccessful and compared the 2 runs but didn't find anything that stood out. Up until the point of failure everything looked normal on the Windows side of things. The really odd thing is, most commands work just fine on a re-used connection. This dism command is the only case I've seen (so far) that seems to be affected by this. |
@sneal Well on first glance i thought that #200 might relate to this, but if the SSH session is still active and valid then the fix to 200 won't help out here. I know that @dylanmei switched from Cygwin/OpenSSH (http://cygwin.com/cgi-bin2/package-cat.cgi?file=x86_64%2Fopenssh%2Fopenssh-6.4p1-1-src&grep=ssh) to standalone OpenSSH (http://www.mls-software.com/opensshd.html) and I suspect that a diff of the configuration of each will reveal some important differences. I still have an image that was generated using the old method and can package it up and sent it to you to save you the time of building one again...? |
Could this be as simple as SSH v1 (which does not allow multiple commands to be executed) vs SSH v2 (which does)? |
I tried Cygwin SSH and it fails the same exact way using my test Go program. I even built a brand new box using misheska's Cygwin template. |
I'm declaring SSH bankruptcy on this one. There's definitely an issue here, but I have no idea what it is. Even if I figure this one out there are other issues with the SSH environment being just enough different to break other installers and scripts (like installing IIS). I've modified the vagrant-windows PowerShell scripts that execute chef-solo through a Windows scheduled task without making any changes to Packer. It works, its reliable, and its communicator independent. |
Interestingly the second command run through the SSH connection outputs a different $USERNAME.
Definitely a clue. |
It turns out this is either a bug in the Windows OpenSSH server or a feature of the Win32 API. I'm not sure which, but ultimately it doesn't matter. To workaround this issue you need to configure the OpenSSH service thusly:
|
I tried the above steps without any luck. |
This hit me hard as well. The only difference between packer und manual ssh I noticed was the difference in the This is very odd. |
Adding a reconnect call to the Communicator newSession method allows some Windows provisioning commands to succeed. The problem is I don't know why.
Without this change attempting to use an inline shell provisioner to install the Windows NetFx3 feature via dism will fail with an exit code of 5:
This originally started off as me running the chef-solo provisioner to install SQL Server which would fail. I paired the SQL install failure down to failing to install .NET 3.5.1, and using the shell provisioner I was able to reproduce the same odd behavior.
Running the same dism command from a standard SSH session works as does from a test Go program I wrote. This finally led me to me adding the reconnect call in Packer which made the shell provisioner work.
I also tried gutting the shell provisioner to have it skip uploading the shell script and just running the inline script directly
cmd := &packer.RemoteCmd{Command: p.config.Inline[0]}
, but then it only works if its the first command via SSH (i.e. first provisioner).Do you have any insight into why a added SSH reconnect fixed my provisioning command?
The text was updated successfully, but these errors were encountered: