When the configured directory for FTP push has too many files, it will
generate an exception and fail due to a stack overflow. When this happens
just rescue out the exception and re-raise a custom error to provide
some context to the user on the actual problem.
`vagrant up` may hang at the "Configuring and enabling network
interfaces..." step when private networks and PTY allocation for SSH
are used.
The newer version of `nmcli` that is part of CentOS now will open a
pager (i.e. `less`) for certain commands if it finds a tty. This
causes the invocations of `nmcli` in `guest_inspection.rb` to hang.
`nmcli` disables the use of a pager in 'terse' (`-t`) output mode,
while still returning enough information for the uses in
`guest_inspection.rb`.
Adds the final line of output to tests and properly simulates
failure. Fix with type casting to prevent calling methods on
nil and drop the final entry as it's not valid.
Fixes#9806
The base chef provisioner class will set the node name automatically
if not provided in the configuration. Since the chef apply provisioner
does not provide a node_name option, setting it will invalidate the
configuration. This checks for the node name before attempting to
use it.
Fixes#9901
Prior to this commit, when setting up private networks on Ubuntu using
netplan, it assumed that the guest was using systemd, the suggested
default tool to manage networking, and did not take into account devices
that could be managed with NetworkManager. This commit fixes that by
looking at the devices managed on the guest to see if its managed by
NetworkManager, and if so, use that renderer for netplan instead of
networkd.
This commit uses the internal helper SafeExec rather than using the
Kernel class directly. It also adds a test to ensure that if the `-t`
option is used, it will call SafeExec.
Due to the behavior of URI.parse on Ruby < 2.5 returning the string
value of the parsed URI object may modify the original URL. Specifically
it will remove the `//` prefix characters from SMB paths. When no
host modifications are being made, always return the original value.
Fixes#9636
This commit sets the structured_facts option to nil if its still
UNSET_VALUE at the finalize step. This was causing a bug when the facter
config was set but was not using structured facts.
This updates the permissions on the automatically generated private
key file to only be readable by the user. Includes support for file
permission modification on Windows platform.
This uses shellwords to split the command in the command filter
inside the winrm communicator. Using shellwords properly handles
things like quoted paths. Path arguments are also quoted to
prevent issues with paths that include spaces.
Fixes#9390
Always remap old hosts to target host when encountered. When custom
vagrant server is defined, warn when tokens may be attached and allow
time for user to cancel.
Fixes#9442
Prior to this commit, the regex matcher used with grep to determine if a
system was using systemd? was failing on systems that did not exactly
match the old regex. This commit updates that communications test to use
a different method of determining if systemd is in use with the ps
command.
Display warning to user about the VirtualBox SharedFoldersEnableSymlinksCreate
option with link to VirtualBox documentation and instructions on how the
setting can be disabled.
Prior to this commit, the virtualbox synced folder option
`SharedFoldersEnableSymlinksCreate` was always enabled. This commit
introduces a config option and an environment variable which allows
users to configure the option globally or per synced_folder in their
Vagrantfile.
As of `net-ssh` version 4.2.0, the key :paranoid has been deprecated in
favor of using :verify_host_key. This commit updates Vagrants ssh config
to use the new key, and deprecates the use of :paranoid.
Provides simple nfs service name detection via systemd or sys-v. Defaults
are provided if no match is found. Service name is defined via method
allowing derivative guests to only need to provide an updated name.
This bug (invalid method call) hasn't been caught by unit tests because
Vagrant::Plugin::V2::Config catches all invalid/bad configuration calls
and save them for generating error messages during the "validate" stage.
This way, the `ask_sudo_pass=(value)` method was not interrupted and the
`@ask_become_pass` attribute was (surprisingly) correctly set (allowing
the related unit tests to pass).
In order to avoid similar problem to happen again, the deprecation
message output is now fully verified.
This commit removes some duplicated code within the Solaris11 guest
implemnentation and instead relies on the Solaris guest for the majority
of its guest capabilities.
It should be valid to allow paths with spaces for the synced folder
guest path but since the guest path is used to generate the ID (if one
isn't provided), this will err out in VirtualBox because it doesn't
allow spaces for the --name argument. We should simply convert ' ' to
'_' as we do with other special characters.
Vagrant will verify that the current Ansible version does support the
requested compatibility mode (only applicable if not "auto", of course).
As mentioned in the documentation, there is no sanity checks between
`version` option and `compatibility_mode` option.
With this change, the host-based provisioner is also improved to
execute only once the "ansible" command (and store the gathered
information for multiple usages like version requirement and
compatibility checks). On the other hand, the guest-based provisioner
can still potentially execute "ansible" twice (once in the
AnsibleInstalled cap, and via "gather_ansible_version" function via
Base::set_compatibility_mode).
Before this change, only the ansible_local provisioner supported this
option (for ansible version requirement, and pip installation). Now, the
ansible host-based provisioner can also require a exact ansible version.
Resolve#8914
Note: this has been added as part of #6570 resolution, since the
introduction of the `compatibility_mode` auto-detection made both
provisioners made capable to detect ansible version.
Pending: optimize the code to avoid duplicated executions of "ansible
--version" command.
With this change, it is now possible to get rid of many deprecation
messages successively introduced in Ansible 1.9, and 2.0. More
interesting, the generated inventory will contain the recommended
variable names (e.g. `ansible_host` instead of `ansible_ssh_host`)
when the compatibility mode is set to '2.0'.
Details:
- Add `compatibility_mode` option to control the Ansible parameters
format to be used. The value corresponds to the minimal version
supported. For the moment, possible values are '1.8' (corresponding to
Vagrant's former behaviour) or '2.0'.
Note that a dynamic inventory generated in compatibility mode '2.0'
is not supported by Ansible 1.x. On the other hand, Ansible 2.x so far
supports inventory format generated by the compatibility mode '1.8'.
- Add compatibility mode auto-detection, based on the available Ansible
version. This is the default behaviour in order to bring a maximum of
user friendliness. The drawback of this approach is to let potential
compatibility breaking risks, for `ansible` provisioner setups that
already integrate Ansible 2.x **AND** rely on the existence of
the generated `_ssh` variable names. Thanks to the vagrant warnings
(and its release notes), I argue that it is worth to offer
auto-detection by default, which offers a sweet transition to most
users.
- Add `become`, `become_user` and `ask_become_pass` options and their
backwards compatible aliases. The legacy options are now deprecated.
Note that we intentionally didn't provide a '1.9' compatibility mode,
as it would add extra-complexity for practically no added-value.
To my knowledge, the Ansible 2.x series haven't introduced yet any major
changes or deprecations that would motivate to introduce a higher
version compatibility mode (to be confirmed/verified).
Resolve GH-6570
Still Pending:
- Optimization: Reduce the number of `ansible` command executions.
Currently two exec calls will be performed when the compatibility
mode auto-detection is enabled (i.e. by default). We could make the
provisioner a little bit smarter to only execute `ansible` only once
in any situation (by combining "presence" and "version" checks).
- User-friendliness: Add better validator on `compatibility_mode`
option, and shows a warning or an error instead of the silent
fallback on the auto-detection modus.
- Test coverage: All the added behaviours are not fully covered yet.
Prior to this commit, if you set up multiple folders to export with NFS
on linux with the exact same hostpath, the template used to write
/etc/exports would end up placing the same path with the same IP in
/etc/exports and cause an error preventing the folders from being
properly mounted. This commit fixes that by first looking at which
folders are being exported and if there are any duplicates. If so,
remove the duplicates and only export 1 hostpath folder. If these
duplicate folders have differing nfs linux options, an exception must be
thrown because we cannot assume which options the user intended to
export with.
The patterns "all" is a special keyword that target all hosts in the
inventory. Therefore it makes sense to accept "all:vars" as a group
variable name. Note that "*:vars" pattern is not valid in an Ansible
inventory.
See http://docs.ansible.com/ansible/latest/intro_patterns.html#patternsFix#7730
This commit aligns how the file provisioner should work on all host
machines. It ensures that a `/.` is only applied if the user intended
to upload a folder to a destination under a different name. It ensures
that if uploading to a windows guest with a different destination folder
name, it does not nest the source folder under that name so that it
works the same as it does on linux platforms. It also updates the
behavior of the winrm upload communicator by allowing an array of paths
to be uploaded instead of a single file or folder to allow for this new
functionality for windows guests.
This commit introduces the salt_arg option that allows a user to pass
additional command line flags to the `salt` tool when provisioning with
a master setup.
It also adds additional config validation to ensure that both
`salt_args` and `salt_call_args` is an array.
Prior to this commit, if the ssh-config command was invoked within
cygwin or msys2, it would show a regular windows style path for private
keys rather than a path that could be used within msys2 or cygwin. This
commit updates that behavior by converting all of the private key paths
to the proper msys2 or cygwin path if the platform is windows and the
command was invoked from one of those two shells.
Prior to this commit, when the guest capability attempted to expand a
path with spaces it would quote the path passed in. However if the path
also had a relative path those quotes would end up making `printf`
ignore it and not properly expand the path fully. This commit updates
that to first escape the quotes of a path and then pass in the new path
to be expanded.
Prior to this commit, when using a global id to bring up a vagrant vm,
vagrant would fail during the "install provider" step due to the fact
that the global vagrant machine was not configured for the local vagrant
environment. Since this global vm exists elsewhere, we disable the
install provider step so that vagrant can just bring up the global
vagrant machine.
Prior to this commit, the `vagrant validate` command would only validate
the first machine in a vagrant file. This commit improves that by
validating all known machines in the environment. If one is not found,
it will properly throw an exception instead of a stacktrace.
Prior to this commit, if a user passed in a script that was frozen,
the shell provisioner would fail to modify the script to replace line
endings for windows because the string was immutable. This commit fixes
that by dup'ing the string so that it can have its line endings replaced
Prior to this commit, if a user set the `destination` path to include a
space, the `shell_expand_guest_path` function would remove that space
and return a partial path. This commit updates that to quote the path to
be expanded to preserve the entire path.
This adds a prompt for a token description, which is now supported in
Vagrant Cloud. Pressing enter on the prompt uses the default description
of `"Vagrant login"`.
$ vagrant login
In a moment we will ask for your username and password to HashiCorp's
Vagrant Cloud. After authenticating, we will store an access token locally on
disk. Your login details will be transmitted over a secure connection, and
are never stored on disk locally.
If you do not have an Vagrant Cloud account, sign up at
https://www.vagrantcloud.com
Vagrant Cloud Username: justincampbell
Password (will be hidden):
Token description (Defaults to "Vagrant login"):
You are now logged in.
$
Which created a token with the default description of "Vagrant login":
![](http://c.justincampbell.me/2V0p0T0U0d0O/Screen%20Shot%202017-08-10%20at%205.08.21%20PM.png)
Entering a description:
Token description (Defaults to "Vagrant login"): Justin's MacBook Pro
![](http://c.justincampbell.me/2m1N0d1M3k3P/Screen%20Shot%202017-08-10%20at%205.09.39%20PM.png)
Prior to this commit, if a state was reached where the action_box_add
command needed a force flag, it would fail requesting the user to
provide that flag to override adding a new box. However that flag did
not exist on the box update command, and could not be passed onto the
action_box_add action. This commit updates that to include a force flag,
and if used, pass that value onto the action_box_add action.
- The 'ansible-galaxy' + 'ansible-playbook' sequence can now be verified
- The "final true" expectation trick can now be removed
- Fixed some little mistakes in 1a62743 rebase of original e8e248d
When preparing the NFS settings on VirtualBox the guest IP addresses
are pulled from VirtualBox directly and any static addresses are
pulled as well. This can lead to aquiring a host IP and machine IP
but results in a failure of NFS mount because the IPs are not on
the same network. This filters the machine IP result to validate
it is within the host adapter IP range.
Prior to this commit, the puppet provisioner would use the manifest dir
flag when running `puppet apply`. Not only is this flag redundant due to
how puppet apply works, but it is also deprecated in Puppet 4 and
removed in Puppet 5. This commit simply removes the flag when invoking
`puppet apply`.
Prior to this commit, rsync-auto would not properly rsync realtive dirs
outside the cwd if defined in the Vagrantfile. This commit updates that
to ensure that the command looks at the Vagrant config to ensure that
folder was intended to be rsync'd to the machine even if outside the
current working dir.
Prior to this commit, when users invoked the `rsync-auto` command using
the docker provider with boot2docker, vagrant would rsync all known
containers using the boot2docker vm rather than the current working dir.
This commit updates that behavior to ensure that only the current
working dirs vagrant machines will be rsynced.
Prior to this commit, if a user attempted to configure
`/etc/default/docker` through vagrant prior to installation, the package
manager would not override an existing configuration and installing
docker would then fail. This commit fixes this by introducing a
`post_install_provisioner` that allows users to define a provisioner
block that will run after docker has been installed, allowing users to
configure `/etc/default/docker` how they want.
This commit adds a variety of fixes for SmartOS guest support:
- Host name setting now works in the global zone and in non-global zones
- NFS now works in the global zone and the non-global zone.
- Tests are updated and moved to the (apparently) more modern style
Prior to this commit, Vagrant had no way internally to determine if a
provisioner object was unique if the `name` property was not set.
Because of this, when vagrant went to merge configs it would duplicate
an existing unnamed provisioner since it had no way of determining if a
user actually had added the same provisioner twice. This commit fixes
that by introducing an id which will default to `name` if its set, but
if not will be set by `SecureRandom.uuid`.
Prior to this commit, the ssh communicator would use the default cipher
list in Net::SSH to negociate which ciphers it should use between hosts.
Due to a bug in Net::SSH and the position of the `none` cipher in its
default cipher list, if a host supported the none cipher, but also
only supported other ciphers that came after none in the default list,
it would accept none and attempt to use that cipher instead of the other
supported ciphers. This commit fixes that behavior by copying the
default cipher list from Net::SSH and placing none last in the list so
that other ciphers can be used in the negotiation before attempting to
use the unsecure none cipher.
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.
This commit adds/changes the following for SmartOS guests:
- modifies the "Halt" capability to use /usr/sbin/poweroff in preference
to /usr/sbin/shutdown with parameters, and modifies the associated
test.
- adds an "InsertPublicKey" capability and tests.
- adds a "RemovePublicKey" capability and tests.
With this commit applied, the vast majority of typical Vagrant workflow
is available to SmartOS global zone guests (provided NFS mounts are used
rather than VMWare shared folders).
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.
Reduce the total number of commands run to configure interfaces. If
a service reload/restart is required, only execute it once instead
of once per device. When nm is managing a device, the explicit up
is not required.
Properly detects NetworkManager on guest as well as devices controlled
by NetworkManager. Provides configuration option to enable/disbale
NetworkManager control on devices.
Prevent sending empty data strings to defined blocks handling
stderr and stdout output. These can occur when the garbage
marker is identified and collected data pruned, but no remaining
data is left to send.
Fixes#8259
With the introduction of `pip_args` option, you can easily extend the
`:pip` installation mode behaviour. But some interesting/advanced usages
are still not possible because of the auto-generated parts ("ansible"
package, version selection, and the `--upgrade` flag).
By adding this "pip_args_only" install mode, it will be for instance
possible to:
- install unofficial releases, like release candidates published at
https://releases.ansible.com/
- install more pip packages (e.g. via a `requirements.txt` file), with
hash validation, etc.
Note that there is no config validation that requires `pip_args` option
to be defined when the :pip_args_only mode is selected. This would be
more elegant, and user friendly to raise a configuration error, but this
can wait. At least, running with an empty `pip_args` won't lead to any
command crash, since the rather dummy "pip install" shows an helper
notice and terminates with a zero (0) exit code.
This change is thought as a complement to the changes originally
proposed in pull request GH-8170.
With this new option, it is now possible to pass additional arguments to
pip command when the `install_mode` is "pip".
(@gildegoma reworded the original commit message of pull request GH-8170)