mirror of
https://github.com/ansible-collections/community.general.git
synced 2024-09-14 20:13:21 +02:00
Minor text formatting (#15991)
* Minor formatting * Update intro_getting_started.rst * Minor formatting * Reserved words formatting. * Reserved words formatting.
This commit is contained in:
parent
2e857cfafd
commit
dbb0ef40c0
3 changed files with 14 additions and 14 deletions
|
@ -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!
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
Loading…
Reference in a new issue