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
From an internal ticket:
> Just noticed that the Link to Virtualbox points to the not-www-Subdomain. And on Domain i got a https-error. If you change the link to the www-Subdomain, there’s no error.
There are two types of box metadata, both in JSON format, so
we need to minimise the potential for confusion between them.
Renaming the component outside the box file to include the
word "catalog" makes it clear that this JSON document can
catalog potentially multiple boxes in one go.
The metadata is optional whereas the box file is required, so it makes
sense to list the box file first. It's also easier on the reader's
brain to start with the more obvious and easily understandable item
(which they'll probably be expecting to read about anyway) and save
the more surprising item till later.
It doesn't make sense to use the present tense when saying box files are
split into two components, when one of those components is the box file
and one is something else.
One better way of phrasing it would be to use the past tense: "Box files
were split into two separate components" but even that's not completely
correct, because the old format did not include the metadata JSON
document which is one of the new components.
So it's safer to just say that today there are two different components.
v2/networking/index.html.md encourages the reader to seek
provider-specific information under the documentation for the provider,
so for consistency, any virtualbox-specific networking info should be
placed there, not in the general networking section.