Detecting cygwin via PATH contents can result in false positives
resulting in errors when using Vagrant on Windows outside of a
cygwin shell. Use environment based detection instead.
If a user provides the gem version using an explicit version or a
constraint, the update action should honor that constraint and not
simply replace it with an unbound constraint.
This also removes system plugin specifications from being matched
and preferred which prevents updates and can result in unexpected
downgrades when running the update.
Flat command can cause issues with arguments. Creating new
string instances from arguments forces common encoding of
all strings used for exec.
Fixes#8690
Prior to this commit, if a user set the env var VAGRANT_HOME to be the
same directory where the project home is, Vagrant would load that file
twice and merge its config. This caused various provisioner and other
provider blocks to unexpectedly run twice. This commit updates the
config loader to look and see if the `:root` and `:home` procs are
equal, and if so, removes the `:home` object so that it isn't loaded and
duplicated. This commit however does not prevent duplicate loading if an
identical Vagrantfile exists in the home and project dir if those
locations are different.
Prior to this commit, if a user ran a vagrant command within a subdir,
it would warn about the cwd changing which is not actually the case.
This commit adds an additional check to see if vagrant is being invoked
within a subdirectory so that it doesn't warn the user.
This commit allows the user to configure two additional options that
were previously not configurable: Compression and DSAAuthentication.
Each config option is set as a boolean, and if left out of the config
will default to its previous behavior which is included and set to
"yes". If the user explicitly sets it to false, it will not be included
as an ssh option.
In case a user (perhaps inadvertently, or for particular reasons) has POSIXLY_CORRECT
set in their environment, make sure to clear it before calling optparse.optparse!() since
we don't really want POSIXLY_CORRECT argument parsing.
This commit adds some better handling around the snapshot restore and
delete commands for the virtualbox provider. If a user attempts to restore from
a vm that does not exist, instead of exiting 0 it will raise an
exception saying the virtual machine has not been created yet.
Addtionally, if a user attempts to restore from a snapshot id that does
not exist, instead of printing a complicated exception from the
virtualbox cli tool, it prints a more useful error message telling the
user that the snapshot does not exist.
Whenever the path where the machine was first created changes, Vagrant
will now show just one warning when an action is run on the machine.
The idea is that if a user copies the machine over to a different
directory with the idea of running two different machines, this warning
will now help the user determine how to make that work.
Prior to this commit, if a user ran the `vagrant ssh -c CMD` command, it
would not allow the user to configure pseudo-terminal allocation. This
commit introduces a -t flag for the `vagrant ssh` command which defaults
to true if not specified.
Prior to this commit, if a user set a URL for the name of a box, vagrant
would not warn the user about using box_url instead. This would lead to
some difficult user experiences around the various box commands due to
the box name being a full URL. This commit introduces a warning to the
user and lets them know to instead use box_url.
Prior to this commit, if a user attempted to use the `vagrant snapshot
save` or `vagrant snapshot list` commands on a vm whose provider did not
support snapshots, it would simply print a warning. This commit changes
that behavior by instead raising an error.
Prior to this commit, the vagrant snapshot plugin would save snapshots
with existing names which lead to duplicate snapshot names being saved.
This commit fixes that by checking to see if the given snapshot name
already exists and if so, fails telling the user the given snapshot name
already exists. If a user passes a --force flag, vagrant will first
delete the existing snapshot, and take a new one with the given name.
Enables proper setup of VMs started from within WSL rootfs paths. Updates
setup for Windows access when working within the WSL to auto-detect settings
instead of relying on user defined environment variables.
Properly detects NetworkManager on guest as well as devices controlled
by NetworkManager. Provides configuration option to enable/disbale
NetworkManager control on devices.
In some cases the SSH connection may be aborted while waiting
for setup. This includes aborted connections in the list of
applicable exceptions to retry on while waiting for the connection
to become available.
Fixes#8520
While VirtualBox has commented that they do not support UNC remote
paths (but do for long paths) it seems that remote paths can work.
If user provides UNC path, allow it to be used as-is.
Fixes#7011
This resolves issues where directly passing arguments individually
to Kernel.exec causes encoding errors due to arguments being forced
command/shell encoding which is not always correct.
This updates the behavior of the provision action to never run a provisioner
that is specified to "never" run unless it has been explicitly requested. Also
adds test coverage to the provision action.
This allows custom paths that include special characters like `~`
to be properly expanded instead of resulting in joined root path
with special characters included.
Installation solution sets in 2.2.5 can end up out of order (not seen
in 2.3.1) causing LoadErrors when the specification is in the solution
set during validation. This detects the missing spec within the solution
and if found will move spec to the start of the solution set and retry
solution activation.
Refactors reusable actions into isolated methods. Supports installation/removal
without activation to prevent unintended conflicts during upgrades and cleanup.
Introduced custom resolver set to handle multiple installed versions of gems
which enables proper cleanup.
Allows checksum validation on downloaded files via Util::Downloader
using MD5 and/or SHA1 checksums. This also integrates checksum validation
support with the shell provisioner for downloaded remote files.
This is required since Gem::Version will mangle pre-release version
numbers.
To get around this, we keep a mapping of
`Gem::Version.to_s => versiondir.`
This allows us to properly sort by version when picking a box while
still returning pristine versiondirs when required.
The `pkg_add` command will return `0` when a package requested for
installation is not found. This adds a validation check to ensure
the rsync package is actually installed on the guest.
Previously, there was no way to close the STDIN stream of a subprocess,
so commands that read from stdin in a subprocess would hang forever,
such as `/bin/sh -s`. If one tried to close the stdin, the
IO.select() call in Subprocess#execute would raise an error for calling
select() on a closed IO.
Here's a concrete example of a command that needs to close STDIN to work
properly:
```ruby
script = SOME_VERY_LONG_STRING
command = %w(ssh foo.example.com /bin/sh -s foo bar)
result = ::Vagrant::Util::Subprocess.execute(*command) do |type, data_or_io|
if type == :stdin
data_or_io.write(script)
data_or_io.write("\n")
data_or_io.close
next
end
puts "Remote: #{data_or_io}"
end
```
BSD-based guests do not support VirtualBox shared folders. This is a
common source of confusion in Vagrant. This new error clearly explains
that this is not a bug in Vagrant and provides instructions on how to
disable them.
Currently, the supported way (see GH#1922) to disable the default port
2222 port forward is:
config.vm.network :forwarded_port, guest: 22, host: 2222, disabled: true
However, the port collision detection runs on all ports, regardless of
the `disabled` flag. This leads it to attempt to connect to port
2222, notice it is taken, and abort with a port conflict -- even
though it will not be attempting to use the port at all.
Skip disabled ports when doing port conflict detection.
A workaround that does not require a Vagrant upgrade to one containing
this fix is to instead set `auto_correct` on the disabled port:
config.vm.network :forwarded_port, guest: 22, host: 2222, disabled: true, auto_correct: true
This allows the disabled port to be reshuffled off to some other
unused port.
The docs for Ruby say Pathname#rmtree will recursively delete, but
apparently that is a lie, at least on Windows (see GH-7496). Switch to
using FileUtils to ensure the directory is deleted.
Fixes GH-7496
This commit changes Vagrant::Util::Platform to cache the result of some
common operations. These values are highly unlikely to change over the
course of a single Vagrant run and they are only cached for that run.
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 commit basically grepped the code base for all uses of Dir.mktmpdir
and Tempfile.new/open and ensures the value is unique within the
code base and also prefixed with `vagrant-`.
Previously, most invocations of these commands simply used "vagrant",
thus making them indistinguishable when trying to identify leaks.
The only reason we were using Tempfile was to generate the path. This
commit switches to using `Dir::Tmpname.create`, which accomplishes the
same thing without the overhead of creating and removing a tempfile.
This commit separates the scratch and output directory creation from the
main package middleware into its own PackageSetupFolders middleware.
Additionally, the validation that ensures an output file does not exist
is moved into a validation function that can be shared across multiple
methods.
This refactor permits a pre-flight check to ensure box packaging would
be successful before actually stopping the VM.
Fixes GH-7351
This commit bumps the box resume delay time to 24h and makes it a
constant because I had a bugger of a time actually finding this in the
code :frowny:.
Fixes GH-7272
Ensure multi machine access of other machine state information through
iterating `active_machines` and retrieval of cached machines cannot
have multiple threads update the state of machines simultaneously as
this triggers a Machine Lock exception.
Machine state information retrieved from the index, returns a locked
object. Since iteration of active_machine, and retrieval of each
machine from the cache can be triggered by any plugin, it is possible
for another machine to inadvertently access the state and trigger an
update, which the thread owning the machine is currently in the process
of updating it already. This results in a Machine Locked exception
occurring if the attempt to retrieve the cached state from the index
occurs before the other thread calls release.
Partially-Fixes: #6526
Added support for Port forwarding in an IP aliased environment. The change
makes the following forwarding rule(s) possible.
Ex: eth0 is ip aliased to have a range of IP addresses 10.20.30.0/24.
In the Vagrant file, we can now have an entry like the following and
it will just work! Note the host port 8081 is the same for both .1 and .2.
Vagrant.configure("2") do |config|
config.vm.network "forwarded_port", guest: 80, host: 8080
config.vm.network "forwarded_port", guest: 81, host: 8081, host_ip: 10.20.30.1
config.vm.network "forwarded_port", guest: 82, host: 8081, host_ip: 10.20.30.2
end
Without this change, the version string may be mutated when passed through
Gem::Version.new(version).to_s before being used to construct the box
directory. This is a problem when using prerelease version numbers because,
for example, it will look for "~/.vagrant.d/boxes/1.0.0.pre.alpha.1" when it
should be looking for "~/.vagrant.d/boxes/1.0.0-alpha.1".
This helps with some confusion caused in GH-2538, since the output says:
> Running cleanup tasks for 'shell' provisioner...
But that's actually not true. It is running the cleanup tasks iff the
provisioner defined a cleanup task. This commit changes the
provisioner_cleanup middleware to only run cleanup tasks if the subclass
defines a cleanup task.
The reason we can't just check if the provisioner `respond_to?` the
`cleanup` method is because the parent provisioner base class (which
all provisioners inherit from) defines a blank cleanup method. This is
important because it means we never risk calling an unimplemented
cleanup function, and it also helps define the public API for a
provisioner.