Starting with PowerShell 5, the progress bar can be observed via the
Write-Progress cmdlet. From WinRM, this appears as a stderr output.
Vagrant assumes that there is error if output appears on stderr.
This terminates various scripts which previously executed successfully
in Vagrant (prior to Windows 10).
This fix injects a variable assignment at various points of the script
execution process to disable display of the progress bar.
We gained a ton of improvemnts to WinRM error handling in
https://github.com/mitchellh/vagrant/pull/4943, but we also got one bug.
The new code raises an exception when `winrm_info` does not return right
away. This was preventing us from catching the retry/timout logic that's
meant to wait until boot_timeout for the WinRM communicator to be ready.
This restores the proper behavior by rescuing the WinRMNotReady
exception and continuing to retry until the surrounding timeout fires.
Adds a configurable value for WinRm and the elevated permission shell ExecutionTimeLimit.
Please see mitchellh/vagrant#5506
Ex: config.winrm.execution_time_limit = "P1D"
Leaving around plaintext username and passwords in a script on a box isn't the best from a security standpoint. This change ensures the scheduled task wrapper script for WinRM doesn't leave these around on the box, and instead passes them to the script as arguments.
StopOnIdleEnd was set in the task definition for elevated/privileged
windows guest scripts. This setting:
> specifies that the task stops when the idle condition ceases to be true [1]
The "idle condition" is something that Windows periodically checks for,
and it's defined by a bunch of criteria like user presence/absence, CPU
/ IO idle time, etc. [2]
Telling our provisioner to stop the task if the "idle condition" ceases
to be true is a recipe for some sporadically stopped tasks, which seems
like precisely the behavior being reported in #5362.
I'm pretty sure this fixes#5362
[1] https://msdn.microsoft.com/en-us/library/cc248332.aspx
[2] https://msdn.microsoft.com/en-us/library/windows/desktop/aa383561%28v=vs.85%29.aspx
In the situation where the SSH key has invalid permissions/owner, the reconnect-loop keeps failing repeatedly yet stays silent about the reasons. A message must be reported from the default exception handler (added). In addition, the situations where the SSH key owner or permissions are wrong must lead to a proper failure (added). Ideally, though, the owner/permissions check must happen before launching the VM, hence this is not a perfect fix.
With this change, any caller of machine.ssh_info is assured that best
efforts will be done to fix possible wrong permissions on the private
key files.
Fix#4652
Seng Lin Shee
Mitchell Hashimoto
Mitchell Hashimoto
Dan Dunckel
Marc Siegfriedt
Paul Hinze
Jeremy Roberts
Arlo Louis O'Keeffe
Bob
Shawn Neal
Matt Wrock
Aaron Quint
Paul Hinze
Max Lincoln
Vít Ondruch
Seth Vargo
Peter Ericson
Konstantin Tretyakov
Gilles Cornu