This adds two new SSH configuration options:
- `keys_only`
- `paranoid`
These values were previously hard-coded, but can now be user-specified.
Fixes GH-4275
This fixes a fairly large tempfile leak. Vagrant uses a template
renderer to write network configuration files locally to disk. Then,
that temporarily file is uploaded to the remote host and moved into
place. Since Vagrant is such a short-lived process, GC never came along
and cleaned up those tempfiles, resulting in many temporary files being
created through regular Vagrant usage.
The Util::Tempfile class uses a block to ensure the temporary file is
deleted when the block finishes. This API required small tweaks to the
usage, but provides more safety to ensure the files are deleted.
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.
This changes the ssh ready? method to treat ENETUNREACH the same way as
EHOSTUNREACH errors.
When attempting to SSH into a box, it tries up to 5 times to connect to
the box, ignoring various errors. Later it will catch and gracefully
handle most of those errors so that callers don't have to know the
details.
However, the Errno::ENETUNREACH error is not caught, which means that
callers that expect a clean boolean return from ready? don't get that,
and instead get an exception they probably aren't expecting.
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