* fix minion detection on Windows
* use new command-line option `-ConfigureOnly` to tell
bootstrap not to try installing minion (on Windows)
Fixes GH-10531
Would limit new console output to systems that do not already support EnhancedSessionTransportType. The vast majority of systems supports it and should not print additional messages.
When connecting over ssh using net-ssh use the non_interactive
argument must be set when authenticating with a password.
Add the keyboard-interactive default auth method
ref: 8a176a6ea0/lib/net/ssh/config.rb (L52)
This change will prepend "^" and append "/" if a start anchor is
detected in the regex string. This allows users to specify
relative paths to exclude.
It also removes replacing occurences of "*" with "[^/]*". "*"
already expresses itself accurately.
In the VM config file port forward information is captured in the
Snapshot defition as well as the VM definition. This causes duplicates
in port forward entries if the file is queried for all available
network adapters. Querying the VM config file for the the Network
Adapters only part of the Machine definition resolves this and
yields the most up to date port forward info.
Before installing dependencies run a check for the python-dev-is-python3
package and only install it if found (otherwise use python-dev). This
allows older versions of debian (and derivatives) to properly install
the defined dependencies.
Only load the dependencies needed for the serve command if the serve
command is being run. This allows Vagrant to properly load on platforms
where some of the dependency libraries may not be available due to
incompatibilities or being EOL.
If `lsb_release -rs` returns a value greater than 10 the package `python-dev-is-python3` will be installed. If it is equal or less than 10 the package will not be installed.
The 7.3.0 release of powershell cleaned up some stray things that
should require the import of the security module to be available.
It causes issues with pre-7.3 versions of powershell that attempt
to load the newer module so we run a check and restrict the module
version based on the powershell version.
Rescue any address errors logging them and ignoring the address. Update
how the host address is determined based on the network configuration.
Host address will be either the lowest address assignable via dhcp
configuration or first address available within the configured subnet.
This forces the LANG enviroment variable to be set to `"C"` when
executing VBoxManage commands. Doing this prevents localization of
output which causes failures of the VirtualBox driver when scanning
for information.
Adds an override for the #read_network_interfaces when hostonlynetworks
are in use to properly identify the hostonly network information from
the guest. This also adjusts the IP provided for the network to be
the first in the subnet.
If the value of the machine folder can not be found in the
system properties, report a user friendly error message and
include relevant information in the logs for debugging.
The error details message should just be one string without spacing
so the terminal can set a output length. This will allow messages
from Ruby and Go errors to have similar formating.
Instead of having to update these flavor.rb files every time a
new version of CentOS/RHEL come out let's dynamically pick up
the version (7,8,9) from the machine.
This was inspired slightly by the Rocky Linux guest flavor.rb.
This migrates the CentOS guest plugin to identify machines by
what is in os-release rather than based on if the /etc/centos-release
file exists.
It just so happens that the Rocky Linux plugin is set up to inherit
directly from :redhat (not :centos) and thus the CentOS flavor is
attempted before Rocky in the depth first search. For some reason
the rockylinux/8 vagrant box still has the /etc/centos-release file
in it even though it's only supposed to inherit from RHEL.
The almalinux/9 box does not have /etc/centos-release.
find_types works fine until you have a module which has the same name but different case. For example, the VagrantVmware package is HashiCorp::VagrantVMwareDesktop. All the protos are at Hashicorp::Vagrant::… So, you end up with this fun
Object.constants.select { |n| n.to_s.downcase == "hashicorp" }
=> [:HashiCorp, :Hashicorp]
So, when trying to walk down the modules to find the right type to unany to, Vagrant sometimes takes the wrong path (eg. Down the HashiCorp module instead of the Hashicorp module).
This change will keep a list of the parent modules when walking down the module list. This way if a dead end is reached then Vagrant can go a level back and keep searching for the correct class.
Turns out I misinterpreted the behavior of a ruby method with a default
being passed nil so I assumed :parallel was effectively defaulting to
true when it is the opposite.
Starting a rocky 9 box (having nfs shares) fails with: `No match for argument: nfs-utils-lib`.
Apparently Rocky 9 does not have a `nfs-utils-lib` but mounting nfs shares without nfs-utils-lib works fine.
So updating the nfs client install to only install `nfs-utils-lib` if the package is available. That way older rhel clones
should continue to work as well.
This removes the need for the validation workaround for Docker, because
box_updated is once again available in that context.
We don't technically need the SyncedFolder priorities back on the Ruby
side, but wiring them through for symmetry.
Depends on https://github.com/hashicorp/vagrant-plugin-sdk/pull/183
By pruning machines that are in "unknown" status after each operation,
the Go code path exposed the fact that the Docker provider was not
updating the machine index during an "up" - leaving the state as
"unknown".
This is basically a bug within the Docker provider, so I think it's okay
to update the plugin code to correct this rather than working around the
issue in Go.
All we need to do is call `machine.state` instead of reaching through to
`machine.provider.state` while waiting for the container to be started.
That causes the extra logic for updating the machine index in
`machine.state` to fire.
This reverts commit 1c26a4abb0, reversing
changes made to 186824a568.
The changes broke plugin loading when using subcommands so these
changes will be reverted until the underlying issue can be
investigated and resolved.
The HashWithIndifferentAccess will change all keys to strings when
merged with another regular hash. This causes errors in cases where
hashes are merged, for example in the action builder. Symbol/String
type data is kept over the wire, so there is no need to make the
mapped hash a HashWithIndifferentAccess.
We had some cases where calling a capability that returned a boolean was
not getting correctly unpacked, so instead of `true` or `false` the
capability was putting out
`VagrantPlugins::CommandServe::Type::Boolean`.
This may have been happening in _all_ cases where a boolean was returned
from a capability and we just didn't notice it yet because the return
value was always truthy.
These tweaks should help ensure that Ruby types make it out where they
are supposed to be in Args::Direct usage.
Relying on HashWithIndifferentAccess in Hash mappers results in
errors when hashes get merged in Ruby. When merges between regular
hashes and HashWithIndifferentAccess happens, then all the keys
from HashWithIndifferentAccess are transformed to strings.
- Defaultable needs to default to true when it's not specified
- We need to allow a non-defaultable provider to be selected if it shows
up in the config
* Populates ComponentOptions into plugin structs
* Maps options for legacy Provider Plugins into PluginOptions
* Demos use of PluginOptions in a stub provider
* Honors plugin priority and defaultable settings
It looks like I might have been the first to hit provider cabability
invocation in testing these changes, and so I found these few missing
methods on the client. They're just copied over from the other
capability hosts.
Calling capabilities on a provider also revealed that the wrong Machine
type was being pulled out of the funcspec args, so we had to correct
that too in order to get the capability calls working.
- Pulls in the SDK changes to Project.DefaultProvider and Project.Target
- Implements the hefty default provider method
- Un-hard-codes provider from Target, and sets it when a Target is
looked up from a Project
The "destroy_on_error" functionality for `vagrant up` is implemented in
the `recover()` action chain, and works by firing off a destroy action
from inside that chain.
This is all well and good, but it copies its existing `env` which has
had `action_name` set for the up action. This was causing action_hooks
for up actions to attach to this destroy action stack.
Setting the action_name explicitly in the env before firing the runner
should correct the behavior. I'm not sure if raw_action_name is used
anywhere but I figured it was better to be consistent vs conservative in
what we change.
