ansible/community.general
1
0
Fork 0
mirror of https://github.com/ansible-collections/community.general.git synced 2024-09-14 20:13:21 +02:00
Code Releases Activity

Rename ansible_ssh_{host,port,user} in docs to ansible_*

Browse source 
The _ssh variants will continue to work, but the shorter, more generic
names are preferred now.
This commit is contained in:
Abhijit Menon-Sen 2015-09-10 19:41:47 +05:30
parent 6dac8512a1
commit f56a6e0951
6 changed files with 23 additions and 23 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
docsite/rst/faq.rst
View file

@ -24,8 +24,8 @@ Setting inventory variables in the inventory file is the easiest way.
For instance, suppose these hosts have different usernames and ports::
[webservers]
asdf.example.com ansible_ssh_port=5000 ansible_ssh_user=alice
jkl.example.com ansible_ssh_port=5001 ansible_ssh_user=bob
asdf.example.com ansible_port=5000 ansible_user=alice
jkl.example.com ansible_port=5001 ansible_user=bob
You can also dictate the connection type to be used, if you want::
@ -66,8 +66,8 @@ ssh command line when connecting to the relevant host(s), so it's a good
way to set a `ProxyCommand`. Consider the following inventory group:
[gatewayed]
foo ansible_ssh_host=192.0.2.1
bar ansible_ssh_host=192.0.2.2
foo ansible_host=192.0.2.1
bar ansible_host=192.0.2.2
You can create `group_vars/gatewayed.yml` with the following contents:

14
docsite/rst/guide_rax.rst
View file

@ -129,7 +129,7 @@ The rax module returns data about the nodes it creates, like IP addresses, hostn
local_action:
module: add_host
hostname: "{{ item.name }}"
ansible_ssh_host: "{{ item.rax_accessipv4 }}"
ansible_host: "{{ item.rax_accessipv4 }}"
ansible_ssh_pass: "{{ item.rax_adminpass }}"
groups: raxhosts
with_items: rax.success
@ -198,7 +198,7 @@ following information, which will be utilized for inventory and variables.
"_meta": {
"hostvars": {
"test": {
"ansible_ssh_host": "1.1.1.1",
"ansible_host": "1.1.1.1",
"rax_accessipv4": "1.1.1.1",
"rax_accessipv6": "2607:f0d0:1002:51::4",
"rax_addresses": {
@ -310,7 +310,7 @@ This can be achieved with the ``rax_facts`` module and an inventory file similar
region: "{{ rax_region }}"
- name: Map some facts
set_fact:
ansible_ssh_host: "{{ rax_accessipv4 }}"
ansible_host: "{{ rax_accessipv4 }}"
While you don't need to know how it works, it may be interesting to know what kind of variables are returned.
@ -516,9 +516,9 @@ Build a complete webserver environment with servers, custom networks and load ba
local_action:
module: add_host
hostname: "{{ item.name }}"
ansible_ssh_host: "{{ item.rax_accessipv4 }}"
ansible_host: "{{ item.rax_accessipv4 }}"
ansible_ssh_pass: "{{ item.rax_adminpass }}"
ansible_ssh_user: root
ansible_user: root
groups: web
with_items: rax.success
when: rax.action == 'create'
@ -601,9 +601,9 @@ Using a Control Machine
local_action:
module: add_host
hostname: "{{ item.name }}"
ansible_ssh_host: "{{ item.rax_accessipv4 }}"
ansible_host: "{{ item.rax_accessipv4 }}"
ansible_ssh_pass: "{{ item.rax_adminpass }}"
ansible_ssh_user: root
ansible_user: root
rax_id: "{{ item.rax_id }}"
groups: web,new_web
with_items: rax.success

2
docsite/rst/guide_vagrant.rst
View file

@ -103,7 +103,7 @@ inventory file may look something like this:
# Generated by Vagrant
machine ansible_ssh_host=127.0.0.1 ansible_ssh_port=2222
machine ansible_host=127.0.0.1 ansible_port=2222
If you want to run Ansible manually, you will want to make sure to pass
``ansible`` or ``ansible-playbook`` commands the correct arguments for the

14
docsite/rst/intro_inventory.rst
View file

@ -48,7 +48,7 @@ To make things explicit, it is suggested that you set them if things are not run
Suppose you have just static IPs and want to set up some aliases that live in your host file, or you are connecting through tunnels. You can also describe hosts like this::
jumper ansible_ssh_port=5555 ansible_ssh_host=192.168.1.50
jumper ansible_port=5555 ansible_host=192.168.1.50
In the above example, trying to ansible against the host alias "jumper" (which may not even be a real hostname) will contact 192.168.1.50 on port 5555. Note that this is using a feature of the inventory file to define some special variables. Generally speaking this is not the best
way to define variables that describe your system policy, but we'll share suggestions on doing this later. We're just getting started.
@ -69,8 +69,8 @@ You can also select the connection type and user on a per host basis::
[targets]
localhost ansible_connection=local
other1.example.com ansible_connection=ssh ansible_ssh_user=mpdehaan
other2.example.com ansible_connection=ssh ansible_ssh_user=mdehaan
other1.example.com ansible_connection=ssh ansible_user=mpdehaan
other2.example.com ansible_connection=ssh ansible_user=mdehaan
As mentioned above, setting these in the inventory file is only a shorthand, and we'll discuss how to store them in individual files
in the 'host_vars' directory a bit later on.
@ -201,11 +201,11 @@ Host connection::
SSH connection::
ansible_ssh_host
ansible_host
The name of the host to connect to, if different from the alias you wish to give to it.
ansible_ssh_port
ansible_port
The ssh port number, if not 22
ansible_ssh_user
ansible_user
The default ssh user name to use.
ansible_ssh_pass
The ssh password to use (this is insecure, we strongly recommend using --ask-pass or SSH keys)
@ -244,7 +244,7 @@ Remote host environment parameters::
Examples from a host file::
some_host ansible_ssh_port=2222 ansible_ssh_user=manager
some_host ansible_port=2222 ansible_user=manager
aws_host ansible_ssh_private_key_file=/home/example/.ssh/aws.pem
freebsd_host ansible_python_interpreter=/usr/local/bin/python
ruby_module_host ansible_ruby_interpreter=/usr/bin/ruby.1.9.3

6
docsite/rst/intro_windows.rst
View file

@ -86,14 +86,14 @@ In group_vars/windows.yml, define the following inventory variables::
# it is suggested that these be encrypted with ansible-vault:
# ansible-vault edit group_vars/windows.yml
ansible_ssh_user: Administrator
ansible_user: Administrator
ansible_ssh_pass: SecretPasswordGoesHere
ansible_ssh_port: 5986
ansible_port: 5986
ansible_connection: winrm
Notice that the ssh_port is not actually for SSH, but this is a holdover variable name from how Ansible is mostly an SSH-oriented system. Again, Windows management will not happen over SSH.
If you have installed the ``kerberos`` module and ``ansible_ssh_user`` contains ``@`` (e.g. ``username@realm``), Ansible will first attempt Kerberos authentication. *This method uses the principal you are authenticated to Kerberos with on the control machine and not ``ansible_ssh_user``*. If that fails, either because you are not signed into Kerberos on the control machine or because the corresponding domain account on the remote host is not available, then Ansible will fall back to "plain" username/password authentication.
If you have installed the ``kerberos`` module and ``ansible_user`` contains ``@`` (e.g. ``username@realm``), Ansible will first attempt Kerberos authentication. *This method uses the principal you are authenticated to Kerberos with on the control machine and not ``ansible_user``*. If that fails, either because you are not signed into Kerberos on the control machine or because the corresponding domain account on the remote host is not available, then Ansible will fall back to "plain" username/password authentication.
When using your playbook, don't forget to specify --ask-vault-pass to provide the password to unlock the file.

2
docsite/rst/playbooks_variables.rst
View file

@ -732,7 +732,7 @@ a use for it.
If multiple variables of the same name are defined in different places, they win in a certain order, which is::
* extra vars (-e in the command line) always win
* then comes connection variables defined in inventory (ansible_ssh_user, etc)
* then comes connection variables defined in inventory (ansible_user, etc)
* then comes "most everything else" (command line switches, vars in play, included vars, role vars, etc)
* then comes the rest of the variables defined in inventory
* then comes facts discovered about a system