OpenSSH vs WinRM

[markhuber]

@joefitzgerald Really loving this project, it has been a good starting point for some of our work.

I've modified the windows 2008r2 build to no longer depend on OpenSSH and instead use the WinRM support built into Packer 1.8. I was considering sending a PR to remove OpenSSH and use WinRM instead but I realize not everyone might actually want that. What's your opinion on SSH vs WinRM and whether or not to drop the OpenSSH server?

[joefitzgerald]

Hey @markhuber, I'm glad you're getting some use out of it. I think we should make WinRM the default mode but make it super easy to enable OpenSSH should someone wish to. This may involve just un-commenting one or a few lines in a script or an invocation of a script.

If you could help with that I would welcome the assistance!

[markhuber]

@joefitzgerald I'm going to wait until at least packer 1.8.3 to make this conversion. After having worked with the winrm communicator for several days, I don't feel like it's ready for primetime.

I'm specifically waiting for:
hashicorp/packer#2443
hashicorp/packer#2505

In addition to those two pulls, I'm still seeing sporadic failures on the winrm communicator (subsequent reruns work perfectly fine... so much for idempotent builds). There are some smaller improvements I'll add in preparation on a separate PR.

[cbednarski]

@markhuber hashicorp/packer#2443 and hashicorp/packer#2505 are merged so if you want to start working on this you can pull from packer master.

I'm still seeing sporadic failures on the winrm communicator

I've seen this too in the packer test suite. There is at least one race condition that causes winrm to fail frequently. go test -race from go 1.5 identified dozens of issues in some of our upstreams. I spent a few hours looking at it but it's too many for me to fix. Related tickets: hashicorp/packer#2312 masterzen/winrm#27

[mrled]

I've been using WinRM successfully with some of my builds, but I had to make a couple of changes to the templates. If anyone is interested, this is what I had to do:

1. I changed the vagrant user's password to something that passes Windows' complexity requirements: V@grant123. Before I did this, I was using the default password of vagrant, and Windows wouldn't let Packer log in as the vagrant user over WinRM, even though logging in to the console would work just fine. I am guessing they are trying to prevent weak local passwords from allowing a remote compromise, but I haven't looked into it.
2. I changed the packerfile to attach the guest additions ISO as an emulated CD, rather than uploading the ISO file and extracting it in the VM with 7-zip. Uploading files over SSH is very reliable, but WinRM doesn't really seem to have been designed for it, and I kept getting frequent yet inconsistent failures when uploading the ISO over my WinRM connection. As a bonus, you don't need to manage the extraction/cleanup process of the ISO. Adding the following line to each of my builder stanzas in my packerfile fixed the problem for me: "guest_additions_mode": "attach",

[StefanScherer]

@mrled Thanks for sharing your steps. Please have a look at the PR #181 where we have started to port the templates to WinRM.

1. We still use the default password vagrant which works fine. See the autounattend.xml for details (PasswordExpires=false)
2. The upload of the VMware tools / guest additions is disabled and we download it from the Internet. Advantage. Even if you are using an older version of eg. VMware fusion you can build the VM with the latest tools installed.

[sneal]

Closing as general consensus is to move to WinRM as the default.

As @mrled remarked, don't upload large files over WinRM, as the protocol was not designed for that type of operation. There are various ways to get around that are easy enough to use.

[ghost]

Just a quick question: I am using winrm. I notice that it takes about two or three minutes before the winrm connection is ready. When I start the machine in VirtualBox it only takes a few seconds, so apparently most of the time we are just waiting for winrm to start up.
I was wondering if that would be better if I would use ssh instead of winrm.

[StefanScherer]

Check the start type of the winrm service. The start type delayed-auto starts a service 120 seconds later.

[ghost]

Aha... changed the start type and and time went down to less then a minute. Super!