Experimental Windows Support

[maxlinc]

There are some things in this PR I think probably shouldn't be merged, at least without changes, but I thought the diff would be useful for discussion.

Vagrant 1.6 has been released, and includes better support for Windows Guests. I have a working spike of vagrant-rackspace with Windows, which creates a server from a base windows image and uses simple winrm (combined with chocolatey) to install ruby + ruby devkit, git, clone fog, and run fog's unit tests.

The minimal set of changes I think are required to get WinRM working are:

• [ ] Allow vagrant-rackspace to choose the admin password, or find a way to store the generated password for later use. This is the vagrant counterpart to https://github.com/fog/fog/pull/2802.
• [x] Make sure vagrant-rackspace doesn't block waiting for SSH or rsync, and uses the sync'ed folder plugins that are now in vagrant core. Related to https://github.com/mitchellh/vagrant-rackspace/issues/84. I did this by ripping out our rsync support completely, but that's only compatible with vagrant 1.5+. (Resovled by #104)
• [ ] Upload a bootstrap.cmd script to configure WinRM. I did this by letting vagrant set the personality options for the server. (Note that I also had to convert *nix to Windows line-endings)

@krames, @elight - can you review those three items?

Known limitations - server-side (i.e. needs a solution that's specific to Rackspace server provisioning):

• Security: I did not setup SSL for WinRM. This needs to be done on the server side. I also haven't experimented with Certificate-based auth, which would likely require vagrant core changes as well.

Known limitations - client-side (i.e. might be resolved by generic vagrant core changes):

• Sync'ed Folders: I don't know a good way to sync folders from OSX to Win yet. Vagrant does have support for NFS and Samba, but I haven't checked they didn't work in the OSX->Win scenario
• Authentication: I am using basic auth with a known username/password. I know the password because I am setting it explicitly during server creation (rather than letting the service generate a password). I haven't tested a setup with Kerberos (which may be tricky on OSX) or [Certificate-based auth], and I'm not sure vagrant core currently supports them.

Despite these limitations, the support is still useful for some workflows. I think the main thing, though, is just making sure vagrant-rackspace is out of the way so users can take advantage of Windows Guest support as it improves in vagrant core.

[maxlinc]

I updated with a working example that uses a personality file (bootstrap.cmd) to setup WinRM.

Regarding security:

• I added a new warning, similar to the SSH security warning, that's displayed if WinRM isn't using SSL:

      Warning! Vagrant is using plaintext communication for WinRM. While
      this isn't much of a big deal for local development, this is quite
      insecure for remote servers. Please configure WinRM to use SSL.

• The Gemfile has the two security related PRs I'm tracking, so uncomment these lines (and comment out the other gem 'vagrant' line) if you want to try it with SSL.
• If we want to be even more secure (or annoying?) we could add something like rackspace.allow_insecure = true that controls whether security concerns are warnings or errors.

I think the remaining questions are:

• Do we want a nicer API for setting personality files?
• Dropping old RSync code... bump the major version and require Vagrant 1.5+, or keep around rsync legacy code?

[krames]

My concern with exposing the personality functionality is that it is not very intuitive. I am also afraid that we might see a lot of issues related to exceeding the personality files storage size. I am still leaning towards something like winrm_bootstrap true.

What are your thoughts?

As far as dropping the legacy rsync code, has vagrant-aws increased their dependency yet? I would like to as stay compatible with the other providers as possible.

[elight]

I’m unfamiliar with the personalities (in this context…).

On June 17, 2014 at 3:20:03 PM, Kyle Rames (notifications@github.com) wrote:

My concern with exposing the personality functionality is that it is not very intuitive. I am also afraid that we might see a lot of issues related to exceeding the personality files storage size. I am still leaning towards something like winrm_bootstrap true.

What are your thoughts?

As far as dropping the legacy rsync code, has vagrant-aws increased their dependency yet? I would like to as stay compatible with the other providers as possible.

— Reply to this email directly or view it on GitHub.

[maxlinc]

I'm not sure "compatible with vagrant-aws" and "minimum required vagrant version" are two sides of the same coin.

The current situation seems to be:

• vagrant-aws still has rsync, but it looks like it's blocking Windows support (unless you install SSH & RSync on Windows servers) (https://github.com/mitchellh/vagrant-aws/issues/180)
• We currently have an issue open for conflicts with vagrant-core's rsync folders and Possible to disable default rsync behavior?. In fact 8 out of 20 open issues mention rsync. I think the best way to "fix conflicts" with both AWS and core (and documentation) is to stop maintaining our own fork of rsync code, and just get everyone to use the implementation that's in core.
• Both vagrant-rackspace and vagrant-aws say they are "Vagrant 1.2+" plugins, but Vagrant 1.2 is now so old that it's not even on the old versions download page.
• Vagrant added "real dependency resolution" in 1.5, so the chances of a conflict between vagrant-aws and vagrant-rackspace a higher with the older versions.
• Most of the required Windows features are in 1.5, so even if you maintain 1.2 support it'll like be "1.2+ for Linux; 1.5+ for Windows"

So my vote is still:

• Vagrant 1.2 thru 1.4: use vagrant-rackspace 0.1.x
• Vagrant 1.5 thru latest: use vagrant-rackspace 0.2.x (or 1.0.0)

[maxlinc]

Re: personalities

Most people shouldn't need to mess with personalities, but I can't create a single winrm_bootstrap script that'll satisfy everyone. I think a more flexible API is needed, either by exposing the data directly, like the current PR, or something like this:

# This is the normal file provisioner. The personality file will be similar.
# This is *usually* preferable, but cannot be used to configure winrm or ssh security, since it happens after Vagrant connects.
config.vm.provision :file, source: 'hello.txt', destination: "/home/vagrant/hello.txt"

# Personality file provisioning - happens before server is created
config.vm.provider :rackspace do |rs|
  # This are put on the machine when it's first built, before vagrant connects
  rs.personality_file source: '~/.ssh/config', destination: "/home/vagrant/.ssh/config"
  # We could also convert line endings unless the file is binary, like the normal shell provisioner
  rs.personality_file source: 'my_key.p12', destination: "/home/vagrant/.ssh/my_key.p12", :binary => true
end

[krames]

@maxlinc do you see opening up the personality functionality as generating more support tickets with people trying to use it to upload larger than allowable files?

@elight Here is the personality documentation. You can see that file names and file sizes are limited.

[maxlinc]

@krames If it blows up with an ugly error, than perhaps. If we raise a clear error message, than probably not.

The rules about file size and maximum # of files are easy to validate (they are available via the limits API) or rescue and display clear error messages.

These things are harder, because the rules aren't available via a limits API and they may be ignored rather than raising an error on server creation:

• admin_pass: Windows password complexity (see the bottom of this article)
• personality files: No binary files
• personality files: path length limit

It might be worth checking the configuration against those rules. I don't like the idea of hardcoding the checks, but I also don't think these rules are as likely to change as the size limits.

[maxlinc]

We've got real support now, not just experimental support!