Windows commands that run over SSH are wrapped in a script that writes a
special marker to the two output streams (stdout and stderr). This
allows Vagrant to consume the output streams.
Unfortunately, this leads to a sort of chicken-and-egg problem where no
commands can be run before a wrapper script exists. For example, you
can't make a destination directory to upload the wrapper script without
first creating a wrapper script to make the directory. :)
This commit changes the behavior of the WinSSH communicator to assume
that the destination directory already exists for provisioning scripts.
It also moves the default `upload_path` from the shell provisioner
config so we can have OS-specific defaults.
Finally, it introduces a Windows-specific #upload method which will
properly use a Windows path separator on a non-Windows host.
This change allows the vagrant user to see the systemd process in the
event that the hidepid mount option is enabled.
Also adds sudo: true to other tests that use `systemd?`
This reverts commit 81553263ab812a7fd0a2ab0f627bee139ad6397c.
This fixes a regression with Windows port detection which led to port
collisions not being fixed on `vagrant up`.
PR #8517 changed `IsPortOpen#is_port_open?` to rescue
Errno::EADDRNOTAVAIL, but when we merged it into master, there was code
in `HandleForwardedPortCollisions#port_check` that depended on that
error bubbling up.
Prior to this commit, the file_checksum class used the `Vagrant::Errors`
class as if it were apart of the Vagrant module. However, since the
file_checksum class is an interface and not part of the Vagrant module,
it doesn't have access to that Error class like other Vagrant modules.
This commit fixes that by ensuring the `"vagrant/errors"` class is
loaded, and that the proper namespace is used.
Since plugin installation happens when the environment is first
initialized, attempt to determine the provider in use and load
any box provided Vagrantfiles to include any plugin configuration
they may include.
Since a full path to the ssh executable is being used and is expected
at a specific location, default to providing that location when looking
up the executable. This prevents errors from occurring when a host
system provides an `ssh` match at a different path.
