test-kitchen / winrm-transport

WinRM transport logic for re-using remote shells and uploading files
Other
8 stars 9 forks source link

Unpacking files not working on Windows Server 2008R2 Core #11

Closed Annih closed 9 years ago

Annih commented 9 years ago

Hi!

First, thanks for your amazing work on this winrm-transport and the rest on test-kitchen. I know you already worked hard to support unpacking on Windows Server 2012R2 Core, using the .NET 4.5 features; but now I have to ask you if you could please try to support the previous version of Windows Core server :)

As for 2012R2 Core, there is no zip module in 2008R2 Core, so the shell.Namespace command fails. In contrast to 2012R2 Core, .NET 4.5 is not present by default on 2008R2 Core, so we have to find another way.

Currently I only have the following idea to support it:

As far as I'm concerned I would fallback to the tar binary Embedded with chef :)

What do you think?

Annih commented 9 years ago

Another solution could be to use the CAB format, which works on all Windows version from 2008. To extract the CAB it's easy with EXPAND.exe but to create the archive ... it's more complexe in ruby. There are 2 libraries that can be used, bo no real gem ...

I don't know if it's worth it :/

fnichol commented 9 years ago

I'm wondering if #8 resolves this issue. @Annih, would you have the bandwidth to try against master? Thanks!

xmik commented 9 years ago

@fnichol, I already asked @Annih to do that in https://github.com/test-kitchen/test-kitchen/issues/625. Back then https://github.com/test-kitchen/winrm-transport/tree/smurawski/fix_com_unpacking was the same as https://github.com/test-kitchen/winrm-transport/pull/8.

Annih commented 9 years ago

Sorry @fnichol, still not working:

Message: Failed to complete #converge action: [[WinRM::Transport::FileTransporter] Upload failed (exitcode: 1) Exception calling "NameSpace" with "1" argument(s): "Unspecified error (Excepti on from HRESULT: 0x80004005 (E_FAIL))" At line:49 char:106

  • else {Try {$s = New-Object -ComObject Shell.Application; ($s.NameSpace($unp ack)).CopyHere(($s.NameSpace <<<< ($src)).Items(), 0x610)} Finally {[void][Runt ime.Interopservices.Marshal]::ReleaseComObject($s)}}
    • CategoryInfo : NotSpecified: (:) [], ParentContainsErrorRecordE xception
    • FullyQualifiedErrorId : ComMethodTargetInvocation ]
tyler-ball commented 9 years ago

@smurawski Can I call in some heavyweight PS help on this one? Do you know of another way to unzip in 2008R2 core?

smurawski commented 9 years ago

The easiest (and best) solution would be to install PowerShell 3, 4, or 5 and .NET 4+ on the box. If that isn't an option, we'd have to look at supporting custom commands - like letting folks shell out to 7zip or winzip. That gets a bit ugly, since you would have to make sure they unpacked consistently like the current methods.

There are also third-party .NET libraries, like SharpZipLib, but that would require getting that dependency over to the target machine as well.

Converting to using the included tar command from Chef is one idea, but that will mean winrm-transport will have a dependency on chef-client or chefdk being present, which isn't idea for other provisioners.

smurawski commented 9 years ago

For a bit more context, Server 2008 R2 went out of mainstream support at the beginning of this year. It's on extended support until 2020 - so it'll get security updates for a bit yet. But there have been two major OS version releases since 2008 R2 and a third will be coming up. I don't think it is worth putting a ton of time into supporting an edge case for an aging OS. (Server core with Server 2008 R2 wasn't widely adopted - despite its benefits).

That said, I'd definitely be open to a pull request and happy to help review/test it.

erikk-spindance commented 9 years ago

Hi,

Just wanted to check in since it looks like this issue is already open. I am experiencing what is likely the same problem on a 2008r2 standard vm. With winrm-transport (1.0.0), I am able to converge my test VMs, but if I update to winrm-transport (1.0.1) then the test-kitchen run fails with a cookbook not found error. After some digging I traced it back to some file transfer/extraction issues in the kitchen cache directory.

Ironically, one of the things that happens in my chef-run is the installation of .net4, .net4.5 and powershell 4.

Mostly I just came here to say: 1) Your gem is awesome, and I appreciate all your work. This is so much nicer than messing around with SSH clients!!!! 2) Try version 1.0.0 (Unless you need one of the newer features) 3) This issue may occur on more than just core.

smurawski commented 9 years ago

@erikk-spindance 1.0.2 fixes the breakage for unpacking on Server 2008R2 with a GUI (non-core).

Steve

ServerNinja commented 9 years ago

Yup, 1.0.2 fixes the problem! Just installed it and was able to use it with 2008R2 without any problem...

:+1:

erikk-spindance commented 9 years ago

@smurawski, Thank you for quickly resolving the issue. Confirm fixed.

tyler-ball commented 9 years ago

Just to make sure I'm up to date - unzipping works in 2008R2 but not in 2008R2 core, correct?

smurawski commented 9 years ago

@tyler-ball Yeah. Basically, if we don't have .NET 4+ (which has support for working with zips in the Framework), we fall back on a COM component to unpack the zip. On Server Core, we don't have that COM namespace.

If we install chef, we could fall back to tar but that leaves out other provisioners. And supporting random unzipping tools would be difficult at best, making sure they unpack to the proper location with the proper folder depth (becomes an n+1 problem) and for folks who want to use "random unzipping tool", they'd have to know the expected folder structure and depth, which would be a pretty big usability hurdle.

This is a lot of work to support an OLD platform in a configuration that is not widely deployed. Don't get me wrong, I'm a fan of Server Core and wish there had been more uptake earlier. However, there has not. I'd be open to someone contributing a PR to deal with this and I can help validate, but it won't make it on my radar to build out from scratch.

ServerNinja commented 9 years ago

You don't necessarily need .NET4 to extract ZIP files. I've been able to accomplish this via Powershell 2.0 on 2008R2 without any .NET installed (I've not tried on Core but it should work for both. Core just 2008R2 without the GUI):

#Function to unzip a file (Backwards compatible with Powershell v2.0)
function unzipSomeFile($zipfile,$dest)
{
$shellApplication = new-object -com shell.application
$zip = $shellApplication.NameSpace($zipfile)
$destFolder = $shellApplication.NameSpace($dest)
$destFolder.CopyHere($zip.Items(),20)
}
smurawski commented 9 years ago

@johnr-spindance That's the COM namespace that's missing on Server Core. That's the method we use if we don't have .NET 4.

ServerNinja commented 9 years ago

Thats strange that 2008R2 wouldn't have the COM namespace in Core.

smurawski commented 9 years ago

@johnr-spindance Not really, the namespace is shell.application. The shell is explorer.exe, which doesn't exist on Server Core.

ServerNinja commented 9 years ago

That makes sense now. Like I said, haven't tried any of this on 2008 R2 core yet. Hopefully Microsoft is continuing to improve Core in recent versions to improve on these things. I think Core has potential but even some of Microsoft's products (like Exchange Server) can't support Core yet. They have a lot of work to do.

fnichol commented 9 years ago

I'm hoping we're all good here now, but if I'm wrong we can re-open. Thanks all!

Annih commented 9 years ago

Nope sorry @fnichol the unpacking is still not working on 200R2 CORE but works on normal 2008 R2 (with GUI).

But as far as I'm concerned, I abandonned Core boxes ith 2008R2 and use them only on 2012R2. So if you wan't to close this issue for a won't fix reason I'm ok

csallen1204 commented 8 years ago

Hi folks. Just letting you know that Powershell 5 was just released. I had the same issue on 2008 core and Powershell 4, but it seems to be fixed with 5