I’ve had the same frustration with WinRM. There are a few things on the way that should help:
1. This proposed change to the WinRM gem will allow for auth to work correctly when using Windows as the client (e.g. running knife on Windows): https://github.com/WinRb/WinRM/pull/62 2. Automation of winrm ssl config to make winrm configuration behave like ssh config with ssh-keygen, et al: https://github.com/opscode/chef-rfc/blob/adamed/rfc-winrm-listener/rfc0002-winrm-listener.md, https://github.com/opscode/chef-rfc/pull/4
You could play with #1 now – it’s being reviewed and tested at the moment so we don’t have a version of knife integrated with it, you’d have to use it directly.
#2 is being prototyped, comments welcome on the pull request.
-Adam
Hi,
I have all but given up on WinRM. It is very temperamental, I find. I have to admit that the environment I am in is a bit messy. Last year I got winrm working on 95% of our hardware. Now we are moving to a new domain and there I am incapable to get it to work. The old approach fails and any attempt to follow online help with winrm has gone no-where.
Instead I use PsExec that is part of (http://technet.microsoft.com/en-us/sysinternals/bb842062 ). It works pretty well. PsExec only works over the company network… so that is probably a limitation for some. Anyway, I have re-written all of my scripts based on PsExec and it works pretty well.
I am thinking I could wrap this up into a gem but I have zero experience with that… time is also an issue.
About windows exit codes… I have found a lot of cases where they are not respected and you get a 0 exit code even though there was an error or vice versa… it’s another real pain!
Cheers, Florian
In this case I wouldn’t blame WinRM – the knife plugin really should return the exit code.
You can definitely get a true / false status of a remotely executed command, though the process exit code for non-powershell cmdlets is tricker. For example, $? is $true in the first success case below, $false in the second:
Invoke-command {echo hi} # $? == $true Invoke-command {throw ‘sad’} # $? == $false
Throwing an exception will cause invoke command to set $? to $false. Since cmdlets only return $true or $false as an exit status, that’s as good as it gets.
If you want to translate that into a process exit code, you can add logic to your script to check $LASTEXITCODE. If you just want a failure status, you can throw an exception. If you’d like the actual code, you’ll need to do as suggested below – parse it, possibly by encoding all script output as xml or json, or simply emitting the exit code as the last line of your script.
Regarding the original issue, I would expect knife winrm to return a nonzero exit code if the command it is executing fails.
-Adam
WinRM is… special. Ok, that’s being too nice. It’s an abomination, but it’s all we have on Windows unless you want to install an SSH daemon. There is not, as far as I can tell, any way to get the exit code of a process called via WinRM. Your best bet is to parse the output, unless someone else knows of something that I have overlooked.
Larry Wright
On Feb 10, 2014, at 9:17 AM, Brian Anderson < "> > wrote:
LEGAL DISCLAIMER |
Archive powered by MHonArc 2.6.16.