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
Use of $stdin, $stdout, and $stderr globals makes testing difficult. By
exposing the IO objects as writable attributes, input/output can be more
easily simulated using StringIO or doubles.
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
For FreeBSD guests, Virtualbox can sometimes report the private network
interface IP address as "0.0.0.0". This will cause an invalid NFS
exports file to be generated for FreeBSD and OS X hosts.
Fixed by not allowing Virtualbox to report a guest IP address of
"0.0.0.0".
With this change, any caller of machine.ssh_info is assured that best
efforts will be done to fix possible wrong permissions on the private
key files.
Fix#4652
Vagrant::Box.load_metadata did not provide a way to specify the HTTPS
download options that could be specified when downloading boxes
(ca cert, ca path, client cert, insecure). As a result, while it was
possible to add a box whose metadata file needed to be downloaded with one of
those options specified, it was impossible to check for updates. The following
changes have been made to address the situation:
1. Create a DownloadMixins module to provide the --insecure, --cacert, --capth,
and --cert command line options to all of `vagrant box add`,
`vagrant box update`, and `vagrant box outdated`.
2. Extend `Vagrant::Box.has_update?` and `Vagrant::Box.load_metadata` to accept
said download options.
3. Extend `box outdated` and `box update` commands to pass download options
down.
4. Extend `Vagrant::Builtin::Action::BoxCheckOutdated` to honour download
options.
5. Options specified on the command line take precedence over options specified
in the machine configuration, if any.
6. Fix bug in `vagrant box add` where client cert was being passed down using
the wrong environment key.
7. Unit test coverage in update_test and box_check_outdated_test.
Resolves#4420
When using pty=true, removing files using sudo may request confirmation,
which will hang the connection.
Similarly, sometimes assumptions about file existence may be wrong and
in those cases it seems better to continue on as long as the file does
not exist, so -f makes sense there, too.
This commits adds a new config setting `config.vm.box_server_url` to set
the URL of a local VagrantCloud instance in the Vagrantfile. If the
environment variable `VAGRANT_SERVER_URL` is set, it will still be
preferred.
Removed dependency upon netdom which is not always available on all Windows versions. This implementation that uses PowerShell and WMI should work on all OS and PowerShell versions.
Fixed another issue where host renames would always happen when the hostname was longer than 15 characters. The COMPUTERNAME environment variable only returns the first 15 characters so we no longer use that to check the current host name.
Command failures include the stdout and stderr in the error message just like the SSH communicator.
Its now possible to specify only an error_class and have that use the correct error_key by default.
Reboot the Windows guest after renaming the computer so changes take affect immediately before attempting to provision the box.
- Changed rename from wmic to netdom since netdom seems to work correctly in Windows 2008R2 and newer OSs.
- Fixed Windows guest error translations, the wrong namespace was specified in the yaml file.
Elevated command line is now rendered to a script which is uploaded to the guest and executed. This allows the command line itself to be less than 100 chars to start the script and any user commands are puts into the script which has unlimited* length.
I still cannot explain the cause of these random errors in this unit test,
but it is anyway safe and suitable to update the test code as following:
- use stricter regular expression matching (-l is included in --limit)
- array lengths substraction instead of array contents substraction
Motivation:
By printing out the ansible command used behind the scene, we can ease
the support effort to very quickly identify whether a problem is due to
Vagrant provisioner or Ansible itself.
There's very little difference between the command building on Linux and Windows other than path formatting. All Chef provisioners support the --no-color argument now.
Added unit tests to verify changes.
CommandBuilderWindows would not include the Chef binary in the command when the binary_path was specified in the config.
Backfilled unit tests for CommandBuilderWindows