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.