Merging upstream version 2.0.3+dfsg (Closes: #923993, #1042533, #1045145).

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 11 insertions, 21 deletions

diff --git a/packaging/installer/methods/ansible.md b/packaging/installer/methods/ansible.md
index 0aadeff91..82e4095f7 100644
--- a/packaging/installer/methods/ansible.md
+++ b/packaging/installer/methods/ansible.md
@@ -1,16 +1,6 @@
-<!--
-title: "Deploy Netdata with Ansible"
-description: "Deploy an infrastructure monitoring solution in minutes with the Netdata Agent and Ansible. Use and customize a simple playbook for monitoring as code."
-image: /img/seo/guides/deploy/ansible.png
-custom_edit_url: https://github.com/netdata/netdata/edit/master/packaging/installer/methods/ansible.md
-sidebar_label: "Ansible"
-learn_status: "Published"
-learn_rel_path: "Installation/Install on specific environments"
--->
-
 # Deploy Netdata with Ansible
 
-Netdata's [one-line kickstart](/packaging/installer/README.md#install-on-linux-with-one-line-installer) is zero-configuration, highly adaptable, and compatible with tons
+Netdata's [one-line kickstart](/packaging/installer/README.md) is zero-configuration, highly adaptable, and compatible with tons
 of different operating systems and Linux distributions. You can use it on bare metal, VMs, containers, and everything
 in-between.
 
@@ -22,7 +12,7 @@ code?
 Enter [Ansible](https://ansible.com), a popular system provisioning, configuration management, and infrastructure as
 code (IaC) tool. Ansible uses **playbooks** to glue many standardized operations together with a simple syntax, then run
 those operations over standard and secure SSH connections. There's no agent to install on the remote system, so all you
-have to worry about is your application and your monitoring software. 
+have to worry about is your application and your monitoring software.
 
 Ansible has some competition from the likes of [Puppet](https://puppet.com/) or [Chef](https://www.chef.io/), but the
 most valuable feature about Ansible is **idempotent**. From the [Ansible
@@ -42,9 +32,9 @@ minutes.
 
 ## Prerequisites
 
--   A Netdata Cloud account. [Sign in and create one](https://app.netdata.cloud) if you don't have one already.
--   An administration system with [Ansible](https://www.ansible.com/) installed.
--   One or more nodes that your administration system can access via [SSH public
+- A Netdata Cloud account. [Sign in and create one](https://app.netdata.cloud) if you don't have one already.
+- An administration system with [Ansible](https://www.ansible.com/) installed.
+- One or more nodes that your administration system can access via [SSH public
     keys](https://git-scm.com/book/en/v2/Git-on-the-Server-Generating-Your-SSH-Public-Key) (preferably password-less).
 
 ## Download and configure the playbook
@@ -71,9 +61,9 @@ cd ansible-quickstart
 
 The `hosts` file contains a list of IP addresses or hostnames that Ansible will try to run the playbook against. The
 `hosts` file that comes with the repository contains two example IP addresses, which you should replace according to the
-IP address/hostname of your nodes. 
+IP address/hostname of your nodes.
 
-```conf
+```text
 203.0.113.0  hostname=node-01
 203.0.113.1  hostname=node-02 
 ```
@@ -86,7 +76,7 @@ omit the `hostname=` string entirely to use the system's default hostname.
 If you SSH into your nodes as a user other than `root`, you need to configure `hosts` according to those user names. Use
 the `ansible_user` variable to set the login user. For example:
 
-```conf
+```text
 203.0.113.0  hostname=ansible-01  ansible_user=example
 ```
 
@@ -96,7 +86,7 @@ If you use an SSH key other than `~/.ssh/id_rsa` for logging into your nodes, yo
 the `hosts` file with the `ansible_ssh_private_key_file` variable. For example, to log into a Lightsail instance using
 two different SSH keys supplied by AWS.
 
-```conf
+```text
 203.0.113.0  hostname=ansible-01  ansible_ssh_private_key_file=~/.ssh/LightsailDefaultKey-us-west-2.pem
 203.0.113.1  hostname=ansible-02  ansible_ssh_private_key_file=~/.ssh/LightsailDefaultKey-us-east-1.pem
 ```
@@ -110,7 +100,7 @@ and `claim_room` variables.
 
 To find your `claim_token` and `claim_room`, go to Netdata Cloud, then click on your Space's name in the top navigation,
 then click on **Manage your Space**. Click on the **Nodes** tab in the panel that appears, which displays a script with
-`token` and `room` strings. 
+`token` and `room` strings.
 
 ![Animated GIF of finding the claiming script and the token and room
 strings](https://user-images.githubusercontent.com/1153921/98740235-f4c3ac00-2367-11eb-8ffd-e9ab0f04c463.gif)
@@ -123,7 +113,7 @@ claim_rooms: XXXXX
 ```
 
 Change the `dbengine_multihost_disk_space` if you want to change the metrics retention policy by allocating more or less
-disk space for storing metrics. The default is 2048 Mib, or 2 GiB. 
+disk space for storing metrics. The default is 2048 Mib, or 2 GiB.
 
 Because we're connecting this node to Netdata Cloud, and will view its dashboards there instead of via the IP address or
 hostname of the node, the playbook disables that local dashboard by setting `web_mode` to `none`. This gives a small