Minor text formatting (#15991)

* Minor formatting

* Update intro_getting_started.rst

* Minor formatting

* Reserved words formatting.

* Reserved words formatting.
This commit is contained in:
Adriano C 2016-09-01 01:26:54 +02:00 committed by Michael Scherer
parent 2e857cfafd
commit dbb0ef40c0
3 changed files with 14 additions and 14 deletions

View file

@ -30,11 +30,11 @@ While primarily used to kickoff OS installations and manage DHCP and DNS, Cobble
layer that allows it to represent data for multiple configuration management systems (even at the same time), and has
been referred to as a 'lightweight CMDB' by some admins.
To tie Ansible's inventory to Cobbler (optional), copy `this script <https://raw.github.com/ansible/ansible/devel/contrib/inventory/cobbler.py>`_ to /etc/ansible and `chmod +x` the file. cobblerd will now need
To tie Ansible's inventory to Cobbler (optional), copy `this script <https://raw.github.com/ansible/ansible/devel/contrib/inventory/cobbler.py>`_ to ``/etc/ansible`` and ``chmod +x`` the file. cobblerd will now need
to be running when you are using Ansible and you'll need to use Ansible's ``-i`` command line option (e.g. ``-i /etc/ansible/cobbler.py``).
This particular script will communicate with Cobbler using Cobbler's XMLRPC API.
Also a cobbler.ini file should be added to /etc/ansible so Ansible knows where the Cobbler server is and some cache improvements can be used. For example::
Also a ``cobbler.ini`` file should be added to ``/etc/ansible`` so Ansible knows where the Cobbler server is and some cache improvements can be used. For example::
[cobbler]
@ -58,7 +58,7 @@ Also a cobbler.ini file should be added to /etc/ansible so Ansible knows where t
First test the script by running ``/etc/ansible/cobbler.py`` directly. You should see some JSON data output, but it may not have anything in it just yet.
Let's explore what this does. In cobbler, assume a scenario somewhat like the following::
Let's explore what this does. In Cobbler, assume a scenario somewhat like the following::
cobbler profile add --name=webserver --distro=CentOS6-x86_64
cobbler profile edit --name=webserver --mgmt-classes="webserver" --ksmeta="a=2 b=3"
@ -78,12 +78,12 @@ Which could be executed just like this::
ansible webserver -m template -a "src=/tmp/motd.j2 dest=/etc/motd"
.. note::
The name 'webserver' came from cobbler, as did the variables for
The name 'webserver' came from Cobbler, as did the variables for
the config file. You can still pass in your own variables like
normal in Ansible, but variables from the external inventory script
will override any that have the same name.
So, with the template above (motd.j2), this would result in the following data being written to /etc/motd for system 'foo'::
So, with the template above (``motd.j2``), this would result in the following data being written to ``/etc/motd`` for system 'foo'::
Welcome, I am templated with a value of a=2, b=3, and c=4
@ -123,7 +123,7 @@ You can test the script by itself to make sure your config is correct::
After a few moments, you should see your entire EC2 inventory across all regions in JSON.
If you use boto profiles to manage multiple AWS accounts, you can pass ``--profile PROFILE`` name to the ``ec2.py`` script. An example profile might be::
If you use Boto profiles to manage multiple AWS accounts, you can pass ``--profile PROFILE`` name to the ``ec2.py`` script. An example profile might be::
[profile dev]
aws_access_key_id = <dev access key>
@ -328,7 +328,7 @@ to include it in the project.
Using Inventory Directories and Multiple Inventory Sources
``````````````````````````````````````````````````````````
If the location given to -i in Ansible is a directory (or as so configured in ansible.cfg), Ansible can use multiple inventory sources
If the location given to ``-i`` in Ansible is a directory (or as so configured in ``ansible.cfg``), Ansible can use multiple inventory sources
at the same time. When doing so, it is possible to mix both dynamic and statically managed inventory sources in the same ansible run. Instant
hybrid cloud!

View file

@ -26,10 +26,10 @@ Before we get started, it's important to understand how Ansible communicates wit
machines over SSH.
By default, Ansible 1.3 and later will try to use native
OpenSSH for remote communication when possible. This enables ControlPersist (a performance feature), Kerberos, and options in ~/.ssh/config such as Jump Host setup. However, when using Enterprise Linux 6 operating systems as the control machine (Red Hat Enterprise Linux and derivatives such as CentOS), the version of OpenSSH may be too old to support ControlPersist. On these operating systems, Ansible will fallback into using a high-quality Python implementation of
OpenSSH for remote communication when possible. This enables ControlPersist (a performance feature), Kerberos, and options in ``~/.ssh/config`` such as Jump Host setup. However, when using Enterprise Linux 6 operating systems as the control machine (Red Hat Enterprise Linux and derivatives such as CentOS), the version of OpenSSH may be too old to support ControlPersist. On these operating systems, Ansible will fallback into using a high-quality Python implementation of
OpenSSH called 'paramiko'. If you wish to use features like Kerberized SSH and more, consider using Fedora, OS X, or Ubuntu as your control machine until a newer version of OpenSSH is available for your platform -- or engage 'accelerated mode' in Ansible. See :doc:`playbooks_acceleration`.
In releases up to and including Ansible 1.2, the default was strictly paramiko. Native SSH had to be explicitly selected with the -c ssh option or set in the configuration file.
In releases up to and including Ansible 1.2, the default was strictly paramiko. Native SSH had to be explicitly selected with the ``-c`` ssh option or set in the configuration file.
Occasionally you'll encounter a device that doesn't support SFTP. This is rare, but should it occur, you can switch to SCP mode in :doc:`intro_configuration`.
@ -46,7 +46,7 @@ Your first commands
Now that you've installed Ansible, it's time to get started with some basics.
Edit (or create) /etc/ansible/hosts and put one or more remote systems in it. Your
Edit (or create) ``/etc/ansible/hosts`` and put one or more remote systems in it. Your
public SSH key should be located in ``authorized_keys`` on those systems::
192.168.1.50
@ -116,7 +116,7 @@ Ansible 1.2.1 and later have host key checking enabled by default.
If a host is reinstalled and has a different key in 'known_hosts', this will result in an error message until corrected. If a host is not initially in 'known_hosts' this will result in prompting for confirmation of the key, which results in an interactive experience if using Ansible, from say, cron. You might not want this.
If you understand the implications and wish to disable this behavior, you can do so by editing /etc/ansible/ansible.cfg or ~/.ansible.cfg::
If you understand the implications and wish to disable this behavior, you can do so by editing ``/etc/ansible/ansible.cfg`` or ``~/.ansible.cfg``::
[defaults]
host_key_checking = False

View file

@ -8,7 +8,7 @@ Inventory
Ansible works against multiple systems in your infrastructure at the
same time. It does this by selecting portions of systems listed in
Ansible's inventory file, which defaults to being saved in
the location /etc/ansible/hosts.
the location ``/etc/ansible/hosts``.
Not only is this inventory configurable, but you can also use
multiple inventory files at the same time (explained below) and also
@ -19,7 +19,7 @@ pull inventory from dynamic or cloud sources, as described in :doc:`intro_dynami
Hosts and Groups
++++++++++++++++
The format for /etc/ansible/hosts is an INI-like format and looks like this::
The format for ``/etc/ansible/hosts`` is an INI-like format and looks like this::
mail.example.com
@ -186,7 +186,7 @@ available to them. This can be very useful to keep your variables organized when
file starts to be too big, or when you want to use :doc:`Ansible Vault<playbooks_vault>` on a part of a group's
variables. Note that this only works on Ansible 1.4 or later.
Tip: In Ansible 1.2 or later the group_vars/ and host_vars/ directories can exist in
Tip: In Ansible 1.2 or later the ``group_vars/`` and ``host_vars/`` directories can exist in
the playbook directory OR the inventory directory. If both paths exist, variables in the playbook
directory will override variables set in the inventory directory.