At the moment, the vagrant ssh username is used as default username when
force_remote_user option is disabled, even for winrm-communiating
machines. This could be improved in the future, but people hitting this
problem can easily work around it by syncing `config.ssh.unsername` and
`config.winrm.username` in their Vagrantfile.
ref #5086
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.
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.
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 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.
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.
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.
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
After #5532 (e745436df3), it was no longer
possible to enable ansible colorized output. Even though
`ANSIBLE_NOCOLOR` has no effect *at the moment* in vagrant+ansible
integration, I agree to keep it for clarity and consistence.
The new `--no-color` behaviour (bug fix#5531) is now covered by a unit
test.
//cc @marsam, @sethvargo
This should fix the cleaning up of the default VirtualBox dhcpserver,
which we've been fighting with for ages over in #3083. We were checking
for a structure _including_ a netmask, but the driver was not populating
netmask.
This change helps to avoid troubles like reported in #5018 and #4860.
Note that for sake of configuration simplicity, no new `ansible.timeout`
option has been added. The users who want to set a different value can
rely on `ansible.raw_arguments`.
This SSH option is always set, except when Vagrant is running from an
operating system fo the Solaris-family, as this parameter is not
supported by SunSSH. Logic taken from
bed1f8335f/lib/vagrant/util/ssh.rb (L116-L121)Fix#5017
/cc @sethvargo - Some weirdness here but overall should work fine. I'm
not sure if there was a GH issue this should be attached to or close. To
explain:
We just use the first machine with the default provider. A
Vagrant::Environment guarantees there is at least one machine, so
`env.machine_names.first` will always work. And we can just use the
default provider because we don't really care. Finally, it can be any
old machine we pass in because we just want the "global" config to
validate and there is no way to say "don't validate machine-specific
configs", so we might as well just pick the first machine to validate.
fixes#3083
Detect the presence of the default DHCP server that comes in a fresh
VirtualBox install and clean it up to prevent it from colliding with
Vagrant-managed network config.
In order to accomplish this, we:
- add a `remove_dhcp_server` call to the virtualbox driver
- fix dhcp options parsing to allow `:dhcp_{ip,lower,upper}`
configuration options to make it through (so a user can override the
removal behavior with some explicit configuration)
- add the full `:network_name` to the details returned from
`:read_dhcp_servers`, so we can have a durable value to pass to
`:remove_dhcp_server`
Note that we do have to eat one more `VBoxManage list dhcpservers` for
each network interface to support this, but this seemed like a nominal
cost
This is just a refactor, no behavior change.
Instead of stitching together dhcpserver info in the structure returned
from `read_host_only_interfaces`, sprout a new driver method called
`read_dhcp_servers` to return that information separately.
This means that driver clients (well there's really only _one_ client in
`ProviderVirtualBox::Action::Network`) have to do a bit more work to get
interface and DHCP server information.
But this gives us (a) a cleaner and more consistent driver interface and
(b) groundwork for a fix for #3083, which will require interacting with
DHCP servers outside of the context of host-only interfaces.
test-only change
when rsync is not installed on the machine running the unit tests, the
prepare_nfs_settings tests end up calling the :nfs_installed capability
on the host, which fails on the fake host wired up in tests.
this adds some explicit stubbing to prevent the implicit assumption that
rsync is installed.
Like Vagrant's default SSH behaviors (e.g ssh or ssh-config commands),
the Ansible provisioner should by default not modify or read the user
known host file (e.g. ~/.ssh/known_hosts).
Given that `UserKnownHostsFile=/dev/null` SSH option is usually combined
with `StrictHostKeyChecking=no`, it seems quite reasonable to bind the
activation/disactivation of both options to `host_key_checking`
provisioner attribute.
For the records, a discussion held in Ansible-Development mailing list
clearly confirmed that there is no short-term plan to adapt Ansible to
offer an extra option or change the behavior of
ANSIBLE_HOST_KEY_CHECKING. For this reason, the current implementation
seems reasonable and should be stable on the long run.
Close#3900
Related References:
- https://groups.google.com/forum/#!msg/ansible-devel/iuoZs1oImNs/6xrj5oa1CmoJ
- https://github.com/ansible/ansible/issues/9442
- force `--connection=ssh` (any other modes like paramiko or smart are not
supported)
- give the highest priority to `raw_arguments` for sake of simplicity (in
usage, in code and in documentation)
- fix position of the `--limit` argument (the generated inventory could be
shadowed by `raw_arguments`, while ansible.limit was able to override
`raw_arguments`
ref #3396
When `--connection` argument is not specified, Ansible will use the
'smart' mode, which can either use `ssh` or `paramiko` transports,
depending of the version of OpenSSH available. If OpenSSH version is new
enough to support ControlPersist technology, `ssh` will be used.
See also http://docs.ansible.com/intro_configuration.html#transport.
In order to support some advanced features of Vagrant (e.g. multiple ssh
private key identities or ssh forwarding), the Ansible provisioner
already must force `ssh` connection mode.
Having to deal with the possible fallback to `paramiko` increase the
burden of special cases that Ansible provisioner must handle, without
any added value, as Vagrant is based on OpenSSH and its users are
usually using modern operating systems.
With this change, the Ansible provisioner will officially only support
`ssh`. It will still be possible to switch to another connection mode
via `raw_arguments`, but it will breach the "contract", and no
(community) support can be expected in such use case.
ref #3900, #3396
Christian Henz
Gilles Cornu
Seth Vargo
Mitchell Hashimoto
Mitchell Hashimoto
Seng Lin Shee
matthewcodes
Dan Dunckel
Brian Dwyer
tomfanning
Sam Phippen
Paul Hinze
Jeremy Roberts
konomae
Luis Pabón
Shawn Neal
Francesco
Tiago Mendes-Costa
Fabio Rapposelli
Jeff Johnson
Volodymyr Babchynskyy
Mario Rodas
Max Lincoln
Michael Lopez
Richard Guin
Paul Hinze
Torben Knerr
Ken Crowell