Before this minor change, the '--limit' and '--start-at-task'
ansible-playbook command line arguments were enclosed into single
quotes. Using double quotes adds a bit more flexibility, especially
about the task name referred by `start_at_task` option.
It also aligns with the handling of the '--extra-vars' parameter
(see cb80286).
Without this change, the JSON string generated from the `extra_vars`
Ruby hash is passed without enclosing quotes and is then not parseable
by the ansible-playbook command when exectuted in a usual shell context.
In this changeset, the ansible (remote) unit test coverage is improved
to cover both usage of `extra_vars` (ansible_local unit tests are still
missing).
Additional Notes:
- Double quotes are favored to single quotes in order to allow usage of
any character for the variable values. For this reason additional
escaping is appended to JSON-inner double quotes and backslashes.
- This problem was not affecting the `ansible` remote provisioner
(which is running the ansible-playbook command via the childprocess
Ruby library). But with this change, the `verbose` output will also
now be correct for a copy-paste reuse.
- After this change, all the "--extra-vars" arguments (also a var
file passed with the @-syntax or anything coming via the
`raw_arguments` option) are "blindly" and systematically enclosed
in double quoted and double-escaped.
This is not optimal and can potentially break with peculiar values
(e.g. a double quote character (") cannot be used in a json value
when using `raw_arguments`). That said, I think that the current
solution is a reasonable trade-off, since the official `extra_vars`
option should now be able to cover a great majority of use cases.
Fix#6726
The sentinal file was always being ignored when running the
resume command. This is fixed along with allowing provision
options to be used with resume. Fixes#6787
Fixed error remains in other versions:
return [] if e.extra_data[:stdout].include?("does not have")
should be
return [] if e.extra_data[:stderr].include?("does not have")
Many methods are the same in different version_X, and should be moved to Base class.
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
Previously the default channel was "current", but after discussion with
@coderanger on GH-6979, it seems like this was a poor design decision.
Instead, we should use the stable channel and allow users to opt-in to
prerelease versions.
Fixes GH-6979
Before this change, the detection of a non-existing path on the guest
machine was considered as an error and lead to interrupt the current vagrant
action. This was actually a mistake to do so, since the config checks
are performed before many other vagrant actions than `provision`.
The config.validate phase is also intended to primarily check the options
sanity, but it cannot be too strict with the guest state (which can easily
get "out of automatic control").
With this change, we still apply these checks (when possible), but only warn
about possible configuration problems. This way, the subsequent
statements will happen anyway (e.g. ansible commands will be
executed, vagrant machine will be destroyed, etc.)
In our test environments, it's good to be able to roll back to the same,
anonymous, snapshot repeatedly. This patch adds a `--no-delete` option
to the `snapshot pop` command allowing this.
This makes the new core snapshot behaviour more consistent with what we
were doing with vagrant-multiprovider-snap
(https://github.com/scalefactory/vagrant-multiprovider-snap)
At least for ansible 2.0.0.1 the command `ansible-galaxy --help` is inappropriate for testing if ansible is installed, as it yields an error:
```
vagrant@vagrant-ubuntu-trusty-64:~$ ansible-galaxy --help && echo "OK"
Usage: ansible-galaxy [delete|import|info|init|install|list|login|remove|search|setup] [--help] [options] ...
Options:
-h, --help show this help message and exit
-v, --verbose verbose mode (-vvv for more, -vvvv to enable connection
debugging)
--version show program's version number and exit
ERROR! Missing required action
```
In cd93721, I relied on a suprising combination of quotes to protect ssh
execution to strip the quoted path to the private key file.
Since any ssh command line argument can be passed via
`ANSIBLE_SSH_ARGS`, it is quite more readable and easy to rely on the
`-i` argument, which is not affected like `-o IdentityFile=...` and also
supports multiple occurences.
See also http://sourceforge.net/p/fuse/mailman/message/30498048/
Finally fix#6671
Note that I decided to not squash both commits for better
documentation and traceability.
Surprisingly (to me at least), a simple quote enclosure was not enough
to fix the problem.
Caveat: the stringified ansible-playbook command logged in verbose mode
is wrongly formatted (no quotes are escaped).
Fix#6671
Set the IPv6 adapter IP to be <prefix>::1. Otherwise, guest to host
communication over IPv6 is not routed correctly. This means that
consumers should not specify <prefix>::1 IP addresses to VirtualBox,
which should be a reasonable restriction.
Fixes#6658
Like in the (remote) `ansible` provisioner, it is preferred to pass the
directory that contains the generated inventory file. This way, advanced
inventory usages can be achieved by adding more inventory files into the
same directory.
Related to #2103 and #6500
[ci skip]
Vagrant should only consider the host-only interfaces used by the
virtual machine in the IPv6 fixup code. There may be other interfaces
present on the system with IPv6 addresses that for various reasons
would fail the routing check (for example, an interface with no
machines attached).
The patch changes the behavior to not scan all of the host-only
interfaces and adds a unit test for the behavior (that the correct IP
is validated).
Lastly, there is a small fix here that may not be an issue for most
people where the IPv6 prefix was asummed to be a multiple of 16 for
the purposes of constructing the UDP probe datagram. This assumption
has been removed.
Fixes#6586
String and Symbol types are different when used as a Hash key. By
default the Vagrant machine names are set in Symbol format, but users
may write their `host_vars` entries with String keys. This is a very
simple way to ensure smooth experience, without having to coerce the
data types during the config validation (e.g. with a library like
Hashie, which is currently not in the Vagrant dependencies)
See also:
- https://bugs.ruby-lang.org/issues/5964#note-17
- https://github.com/intridea/hashie#keyconversion
Refactor and repair regular expression attempting to match present interfaces.
The refactored regular expression will match on enp* ens* eth* variants.
I missed to rename the refactored exceptions as AnsibleCommandFailed in
the guest-based parts. The lack of unit tests for these parts hurts...
on my agenda, I swear!
See c1f3d114f5
This is required because the Chef Server almost always needs a node name to
interact. This will default to the hostname, but that's always going to be
`vagrant.vm`, which will collide easily.
This generates a random hostname with `vagrant-` as the prefix and stores the
result in the machine's data directory.
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 fixes GH-6395 by only appending the access_token once. It also fixes a
bug that was never reported. If a user supplied an access_token for a box URL,
Vagrant would silently overwrite it.
After this commit, Vagrant only appends an access_token to the URL if no
value exists at the key.
This patch introduces a new parameter --all for the remove
command of the box plugin. Setting this parameter will remove
all available versions of a specific box.
Example usage:
```
$ vagrant box list
ubuntu/trusty64 (virtualbox, 20150427.0.0)
ubuntu/trusty64 (virtualbox, 20150430.0.0)
ubuntu/trusty64 (virtualbox, 20150506.0.0)
```
```
$ vagrant box remove ubuntu/trusty64
You requested to remove the box 'ubuntu/trusty64' with provider
'virtualbox'. This box has multiple versions. You must
explicitly specify which version you want to remove with
the `--box-version` flag. The available versions for this
box are:
* 20150427.0.0
* 20150430.0.0
* 20150506.0.0
```
With the --all parameter it is possible to remove all versions at once.
```
$ vagrant box remove --all ubuntu/trusty64
Removing box 'ubuntu/trusty64' (v20150506.0.0) with provider 'virtualbox'...
Removing box 'ubuntu/trusty64' (v20150430.0.0) with provider 'virtualbox'...
Removing box 'ubuntu/trusty64' (v20150427.0.0) with provider 'virtualbox'...
```
With this change, the existing host-based Ansible provisioner is
refactored to share a maximum of code with this new guest-based Ansible
provisioner.
At this stage of development, the existing unit tests are intentionally
modified as little as possible, to keep safe the existing funtionalities.
Other issues resolved by this changeset:
- Display a warning when running from a Windows host [GH-5292]
- Do not run `ansible-playbook` in verbose mode when the `verbose` option
is set to an empty string.
The current docker installer attempt to install the linux-image-extra-`uname -r` DEB package on Debian systems.
This package may not exist, for example on custom kernels (e.g., Linode servers).
If this happens, Vagrant halts the provisioning. However, this package is not really needed in newer Debian releases (such as Ubuntu 14.04).
This small patch checks if the linux-image-extra-`uname -r` package exists, and it will install it if it does. In either case, it will continue provisioning.
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.
Changed the name of the error LinuxRDesktopNotFound to
LinuxRDPClientNotFound and re-worded error text in
templates/locales/en.yml to include `xfreerdp` when listing supported
RDP clients.
The benefits of the following "breaking change" are the following:
- default behaviour naturally fits with most common usage (i.e. always
connect with Vagrant SSH settings)
- the autogenerated inventory is more consistent by providing both the
SSH username and private key.
- no longer needed to explain how to override Ansible `remote_user` parameters
Important: With the `force_remote_user` option, people still can fall
back to the former behavior (prior to Vagrant 1.8.0), which means that
Vagrant integration capabilities are still quite open and flexible.
Starting with vagrant 1.7.3
(commit 1152b4e1df) we don't
save the command to be executed in the file anymore, but we send
it as a parameter, thus the back tick makes things worse.
Previously, configuring and enabling network interfaces failed with:
"The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!
/usr/sbin/biosdevname --policy=all_ethN -i bash: /usr/sbin/biosdevname:
No such file or directory
Stdout from the command:
bash: /usr/sbin/biosdevname: No such file or directory"
The previous attempt to fix this (ccc4162) doesn't work since it doesn't
properly parse the 'bash: /usr/sbin/biosdevname: No such file or
directory' error message.
This patch works around that problem and adds a comment explaining the
meaning of the return codes.
puppet_server provisioner fails with Puppet Collection 1 with the
following error:
```bash
==> default: Running provisioner: puppet_server...
The `puppet` binary appears not to be in the PATH of the guest. This
could be because the PATH is not properly setup or perhaps Puppet is not
installed on this guest. Puppet provisioning can not continue without
Puppet properly installed.
```
Currently `configure_networks` guest cap configures NICs following the device order and fails
when the device order is mixed. We should detect the appropriate NIC by its MAC address.
Slackware's version file is /etc/slackware-version not
/etc/slackware-release.
pidof is not on PATH by default (not running as root) so call it using
full path
VirtualBox has a bug where the IPv6 route is lost on every other
configuration of a host-only network. This is also triggered when a VM
is booted.
To fix this, we test the route-ability of all IPv6 networks, and
reconfigure if necessary. This is very fast but we still only do this if
we have any IPv6 networks.
The problem demonstrated in #6065 is that a string has incorrectly been
encoded with US-ASCII even though it contains invalid US-ASCII byte
sequences (any byte with the most significant bit on is invalid in the
US-ASCII encoding).
The thing about doing newline normalization is that it is not actually
sensitive to the presence of US-ASCII byte sequenzes. Additionally, it
is very unlikely that a user will ever be using an encoding where \r\n
is not encoded the same as it would be in ASCII.
This patch first tries the existing method of normalizing the newlines
in the provided script file, if that fails for any reason it force
encodes the string to ASCII-8BIT (which allows the most significant bit
to be on in any individual byte) and then performs the substitution in
that byte space.
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"
Windows offers no out-of-the-box rsync utility. By far, the most
commonly used external utilities for Windows rsync are built with the
GNU Cygwin libraries. The cost for this convenience is that rsync on
Windows has to be provided paths that begin “/cygdrive/c” rather than
“c:/“ like other Windows-API utilities. Compounding the situation,
rsync doesn’t create paths/to/sub/targets and so the vagrant plugin
code, when performing an rsync, is responsible for creating
intermediate directories in guest paths if there are any. Furthermore,
the mkdir utility in Windows is not another Cygwin utility like rsync
but the routine mkdir of Windows command.com. Therefore, while rsync
needs the /cygwin paths, mkdir uses the Windows paths. Later, the
chef_solo.rp provisioner running within the guest will expect to find
Windows-style paths in its solo.rb configuration file. Due to all this,
vagrant has to keep track of both the original, possibly dirty Windows
guest path and the cygwin-scrubbed guest path.
When the network's type is :dhcp, the :ip option is used to derive the DHCP server configuration, and it doesn't actually indicate the IP that will be received by the VM(s).
This fixes error for Win 10 Enterprise:
An error occurred while executing a PowerShell script. This error
is shown below. Please read the error message and see if this is
a configuration error with your system. If it is not, then please
report a bug.
Script: get_vm_status.ps1
Error:
C:\HashiCorp\Vagrant\embedded\gems\gems\vagrant-1.7.4\plugins\providers\hyperv\scripts\get_vm_status.ps1 : Unable to
find type [Microsoft.HyperV.PowerShell.VirtualizationOperationFailedException].
At line:1 char:1
+ &('C:\HashiCorp\Vagrant\embedded\gems\gems\vagrant-1.7.4\plugins\prov ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (Microsoft.Hyper...FailedException:TypeName) [get_vm_status.ps1], Ru
ntimeException
+ FullyQualifiedErrorId : TypeNotFound,get_vm_status.ps1
This allows Vagrant to calculate if a container's arguments (such as the run
arguments) have changed in the Vagrantfile since the original run.
Fixes GH-3055
When provisioning multiple machines in sequence (the default vagrant
behaviour), it doesn't make sense to require to provide the private ssh
key(s) via the custom ansible inventory script/file.
To align with the handling of multiple ssh keys per machine, we won't
rely any longer on `--private-key` command line argument, but only pass
the keys via `ANSIBLE_SSH_ARGS` environment variable.
Note that when vagrant generates the ansible inventory and that only one
key is associated to a VM, this step would be redundant, and therefore
won't be applied.
This change fixes the breaking change introduced by 3d62a91.
Vagrant 1.7.1 creates and injects new ssh keys for each virtual machine.
When it started ansible with the "parallel provisioning trick",
it would only send the ssh key of the targeted virtual machine.
With this change, vagrant now stores the ssh key for each virtual
machines directly in the generated ansible inventory, and thus allow
ansible parallelism.
Note that this change is not sufficient, as it would break vagrant
configuration based on a custom inventory (file or script). This issue
will be addressed in a next commit.
Signed-off-by: Luis Pabón <lpabon@redhat.com>
The Ansible Vagrant provisioner has a race where the inventory file is
updated every time the provisioner runs unless a file is provided.
Therefore if Ansible attempts to provision two nodes in parallel, you
may see the following race:
* System A writes the inventory file and calls Ansible.
* System B starts to provision and truncates the file before
creating a new one.
* Ansible on system A now attempts to read the inventory
file, which is blank. Ansible bombs out with "ERROR: provided
hosts list is empty".
To fix this, we only allow Vagrant to update the inventory file if
it needs to.
Revert 1c884fa4e5 which introduced the
following bug:
Instead of allowing to dump the `ansible-playbook` command details when
VAGRANT_LOG=debug was defined, it was then impossible to disable this
console output when VAGRANT_LOG was undefined (in such case,
``@logger.debug? systematically returns `true`)
In order to keep things simple and focused, it is preferable to drop the
bad idea to mix Ansible verbosity and Vagrant log level.
Fix#5803
Configuring by :interface doesn't work very well because Vagrant has
no idea about what interfaces are present in the VM, for example if
the image has 'docker' installed but not biosdevname, then
interface_names[0] = "docker0" which is usually not what you want
mapped to the first network from the Vagrantfile.
So if the plugins (like vagrant-libvirt) or the Vagrantfile has
given us a network with a MAC address, use that to find the interface
name for the network. Otherwise use slot numbers as before.
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.