Elevated shell runner doesn't work

[dylanmei]

The elevated shell runner in file communicators/winrm/communicator.go does not work - it fails to be deleted and subsequent shell commands fail.

More detail to follow, but for now I will remove it as it's currently working much more reliably without.

issue brought over from https://github.com/dylanmei/packer-communicator-winrm/issues/3

[dylanmei]

We want this feature as part of the winrmcp throttling. I haven't had any trouble getting it working there, but what has become obvious is that we will want this upstream in masterzen/winrm. That's the goal I'm working towards.

As the Powershell provisioner comes online, we'll soon be able to expose this as part of its configuration.

[dylanmei]

To summarize, certain operations can't always be performed over winrm (such as running winrm get winrm/config on Win 2008 or installing some .NET MSIs). We get around it by creating the scheduled task on the guest using the user's name and password. The task fires immediately, and creates an output file which is read back to the host. We then delete the task and the output file.

The code for this looks something like: elevated_info_query/winrmcp/elevated.go

The winrmcp project needs to run winrm get winrm/config in order to throttle uploads efficiently, but we also need it here so I'm having trouble deciding the best course of action.

1. move the elevated shell workflow into a forked masterzen/winrm and hope @masterzen takes it. I'm hesitant to overload the winrm library with behaviors it wasn't intended for.
2. keep it in communicator and pass winrm info into winrmcp so it's throttled correctly. This gimps the standalone winrmcp executable. Not a big deal.
3. create a new project for just winrm-oriented powershell scripts that are then bundled into the winrmcp and communicator executables (not libraries), similar to this suggestion: Externalize the powershell code? winrmcp#4

@mefellows Thoughts?

[mefellows]

I must admit my initial feeling was that this belongs in masterzen's WinRM package, but the more I think on it the more ambivalent I become.

The idea of packaging and sharing a PS module across disparate projects + languages makes a lot of sense to me (I can't help but feel there is a lot of duplication between Packer and Vagrant, which is a shame). Right now, I think #3 is the way to go. Do you have a good idea of how you might go about it?

As an aside, it would be nice if this kind of logic was abstracted from the client, or at least put behind an 'elevated' type switch. I actually use the winrm CLI quite often and it would be great if it supported these kinds of features.

[dylanmei]

Thanks for giving it thought. It's been puzzling me for awhile now.

Do you have a good idea of how you might go about it?

I was quite literally thinking of using something like go-bindata to bundle the scripts. When StepConnectWinRM runs, after it confirms a connection, we can "enhance" the guest with scripts.

With winrmcp the scripts would be compiled as part of the executable, not the library, so as not to burden people wanting to use the library. In our plugin, the equivalent level is: communicator-winrm/main.go

[masterzen]

@dylanmei, @mefellows I'm fine adding this feature to masterzen/winrm, but it sounds a bit far stretched. If that's something we need in several projects, then I'd prefer solution 3, and if we also need it in the winrm executable, then I think we should make masterzen/winrm the library and externalize the cli into winrm-cli that could depend on all the needed subprojects.
Does it make sense?

[mefellows]

@dylanmei that go-bindata option looks quite interesting, I'll have to investigate further.

What would be ideal is that at the end, we have a WinRM library/CLI that is able to perform remote commands from a non-elevated and elevated user, whilst still interacting with that library in a uniform manner. Secondly, we additionally end up with a re-usable set of PowerShell scripts that can be shared\collaborated amongst disparate projects for performing the elevated shell dance.

I'm not sure how achievable the former is but the latter seems quite possible. That's just my 2c, but I'm happy to defer to you Dylan as you have a much better grasp of the problem and solutions.

[dylanmei]

@masterzen Thank you very much for your feedback. It's clear that we should keep it out of the library, although enhancing the cli with "elevated" behavior is a possibility.

@mefellows Here's a simple example project using go-bindata to bundle powershell scripts: https://github.com/dylanmei/winrmls. I'm interested in your reaction.

[mefellows]

@dylanmei I can certainly see the appeal with go-bindata. For a trivial example like the above it would appear to be overkill but if multiple files were involved I can see how it could add value and keep things much cleaner; I'm starting to understand suggestion 3 from above a bit better now and thinking it is definitely the better option and we should just go for it.

With go-bindata, is it easy enough to pull in resources say, via a repository? That way we could integrate the latest 'blessed' PS resources into our build process a bit easier and CI latest changes before we pull into the mainline. Just a thought. I supposed there are a number of ways we could do that.

[mefellows]

Update on this issue: I have continued the great work @dylanmei started in the elevated_powershell_commands branch, to the point it appears to be working for me, with the added addition of environment_vars support too.

Tests
Aside from unit tests, I have attempted the following minimal test case - installing the .NET Devpack 4.5.2 package using Chocolatey: choco install netfx-4.5.2-devpack, across the following scenarios which requires elevated privileges to work:

• Windows 2012r2 Virtualbox OVF
• Windows 2008r2 Virtualbox OVF (with Windows updates applied): https://gist.github.com/mefellows/bde689b1f0722a16c8a8. This also involved upgrading WMF to 4+ (using the elevated feature) to support Chocolatey install
• Amazon EBS instance (2012r2 AMI)

@dylanmei do you mind reviewing this when you get some time? It's likely I've missed something and I know you have put a lot of time/research into this.

[mefellows]

Closed due to #29.