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.
As described in /etc/sysconfig/network/ifcfg.template
Static template was already using the right one, but the dhcp configuration seems
to be copied from a Fedora/Redhat template.
This fixes the issue that the interface does not come up after reboot.
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.
Here we implement a naive solution to #5605 which catches the case that
a provided source contains an object which cannot be inspected, because
an object contained within in has an #inspect string that returns a
string that is incompatible with the encoding in
`Encoding.default_external` or a string which cannot be downcast to
7-bit ascii.
The Ruby VM implementation of "#inspect" implements this checking on
these lines of code: http://git.io/vZYNS. A Ruby level override of
this method does not cause this problem. For example:
```ruby
class Foo
def inspect
"😍".encode("UTF-16LE")
end
```
will not cause the problem, because that's a Ruby implementation and the
VM's checks don't occur.
However, if we have an Object which **does** use the VM implementation
of inspect, that contains an object that has an inspect string which
returns non-ascii, we encounter the bug. For example:
```ruby
class Bar
def inspect
"😍".encode("UTF-16LE")
end
end
class Foo
def initialize
@bar = Bar.new
end
end
Foo.new.inspect
```
Will cause the issue.
The solution this patch provides basically catches the encoding error
and inserts a string which attempts to help the user work out which
object was provided without blowing up. Most likely, this was caused
by a user having a weird encoding coming out of one of the sources
passed in, but without a full repro case, it's not clear whether a patch
should be applied to a different object in the system.
Closes#5605.
Seth Vargo
Mitchell Hashimoto
Mitchell Hashimoto
Seng Lin Shee
Duncan Mac-Vicar P
Gilles Cornu
matthewcodes
Dan Dunckel
Brian Dwyer
tomfanning
Sam Phippen