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

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

1 files changed, 35 insertions, 47 deletions

diff --git a/src/registry/README.md b/src/registry/README.md
index d976528c7..97db113f7 100644
--- a/src/registry/README.md
+++ b/src/registry/README.md
@@ -1,12 +1,3 @@
-<!--
-title: "Registry"
-description: "Netdata utilizes a central registry of machines/person GUIDs, URLs, and opt-in account information to provide unified cross-server dashboards."
-custom_edit_url: "https://github.com/netdata/netdata/edit/master/src/registry/README.md"
-sidebar_label: "Registry"
-learn_status: "Published"
-learn_rel_path: "Configuration"
--->
-
 # Registry
 
 Netdata provides distributed monitoring.
@@ -14,21 +5,21 @@ Netdata provides distributed monitoring.
 Traditional monitoring solutions centralize all the data to provide unified dashboards across all servers. Before
 Netdata, this was the standard practice. However it has a few issues:
 
-1.  due to the resources required, the number of metrics collected is limited.
-2.  for the same reason, the data collection frequency is not that high, at best it will be once every 10 or 15 seconds,
+1. due to the resources required, the number of metrics collected is limited.
+2. for the same reason, the data collection frequency is not that high, at best it will be once every 10 or 15 seconds,
     at worst every 5 or 10 mins.
-3.  the central monitoring solution needs dedicated resources, thus becoming "another bottleneck" in the whole
+3. the central monitoring solution needs dedicated resources, thus becoming "another bottleneck" in the whole
     ecosystem. It also requires maintenance, administration, etc.
-4.  most centralized monitoring solutions are usually only good for presenting _statistics of past performance_ (i.e.
+4. most centralized monitoring solutions are usually only good for presenting _statistics of past performance_ (i.e.
     cannot be used for real-time performance troubleshooting).
 
 Netdata follows a different approach:
 
-1.  data collection happens per second
-2.  thousands of metrics per server are collected
-3.  data do not leave the server where they are collected
-4.  Netdata servers do not talk to each other
-5.  your browser connects all the Netdata servers
+1. data collection happens per second
+2. thousands of metrics per server are collected
+3. data do not leave the server where they are collected
+4. Netdata servers do not talk to each other
+5. your browser connects all the Netdata servers
 
 Using Netdata, your monitoring infrastructure is embedded on each server, limiting significantly the need of additional
 resources. Netdata is blazingly fast, very resource efficient and utilizes server resources that already exist and are
@@ -46,31 +37,30 @@ etc.) are propagated to the new server, so that the new dashboard will come with
 
 The registry keeps track of 4 entities:
 
-1.  **machines**: i.e. the Netdata installations (a random GUID generated by each Netdata the first time it starts; we
+1. **machines**: i.e. the Netdata installations (a random GUID generated by each Netdata the first time it starts; we
     call this **machine_guid**)
 
-  For each Netdata installation (each `machine_guid`) the registry keeps track of the different URLs it has accessed.
+    For each Netdata installation (each `machine_guid`) the registry keeps track of the different URLs it has accessed.
 
-2.  **persons**: i.e. the web browsers accessing the Netdata installations (a random GUID generated by the registry the
+2. **persons**: i.e. the web browsers accessing the Netdata installations (a random GUID generated by the registry the
     first time it sees a new web browser; we call this **person_guid**)
 
-  For each person, the registry keeps track of the Netdata installations it has accessed and their URLs. 
+    For each person, the registry keeps track of the Netdata installations it has accessed and their URLs.
 
-3.  **URLs** of Netdata installations (as seen by the web browsers)
+3. **URLs** of Netdata installations (as seen by the web browsers)
 
-  For each URL, the registry keeps the URL and nothing more. Each URL is linked to _persons_ and _machines_. The only
+    For each URL, the registry keeps the URL and nothing more. Each URL is linked to _persons_ and _machines_. The only
   way to find a URL is to know its **machine_guid** or have a **person_guid** it is linked to it.
 
-4.  **accounts**: i.e. the information used to sign-in via one of the available sign-in methods. Depending on the
-    method, this may include an email, or an email and a profile picture or avatar.
+4. **accounts**: i.e. the information used to sign-in via one of the available sign-in methods. Depending on the method, this may include an email, or an email and a profile picture or avatar.
 
 For _persons_/_accounts_ and _machines_, the registry keeps links to _URLs_, each link with 2 timestamps (first time
 seen, last time seen) and a counter (number of times it has been seen). *machines_, _persons_ and timestamps are stored
-in the Netdata registry regardless of whether you sign in or not. 
+in the Netdata registry regardless of whether you sign in or not.
 
 ## Who talks to the registry?
 
-Your web browser **only**! If sending this information is against your policies, you 
+Your web browser **only**! If sending this information is against your policies, you
 can [run your own registry](#run-your-own-registry)
 
 Your Netdata servers do not talk to the registry. This is a UML diagram of its operation:
@@ -95,7 +85,7 @@ We believe, it can do it...
 
 **To turn any Netdata into a registry**, edit `/etc/netdata/netdata.conf` and set:
 
-```conf
+```text
 [registry]
     enabled = yes
     registry to announce = http://your.registry:19999
@@ -106,7 +96,7 @@ Restart your Netdata to activate it.
 Then, you need to tell **all your other Netdata servers to advertise your registry**, instead of the default. To do
 this, on each of your Netdata servers, edit `/etc/netdata/netdata.conf` and set:
 
-```conf
+```text
 [registry]
     enabled = no
     registry to announce = http://your.registry:19999
@@ -120,7 +110,7 @@ This is it. You have your registry now.
 You may also want to give your server different names under the node menu (i.e. to have them sorted / grouped). You can
 change its registry name, by setting on each Netdata server:
 
-```conf
+```text
 [registry]
     registry hostname = Group1 - Master DB
 ```
@@ -131,7 +121,7 @@ So this server will appear in the node menu as `Group1 - Master DB`. The max nam
 
 Netdata v1.9+ support limiting access to the registry from given IPs, like this:
 
-```conf
+```text
 [registry]
     allow from = *
 ```
@@ -152,15 +142,16 @@ against the name-pattern.
 Please note that this process can be expensive on a machine that is serving many connections. The behaviour of the
 pattern matching can be controlled with the following setting:
 
-```conf
+```text
 [registry]
     allow by dns = heuristic
 ```
 
 The settings are:
--   `yes` allows the pattern to match DNS names.
--   `no` disables DNS matching for the patterns (they only match IP addresses).
--   `heuristic` will estimate if the patterns should match FQDNs by the presence or absence of `:`s or alpha-characters.
+
+- `yes` allows the pattern to match DNS names.
+- `no` disables DNS matching for the patterns (they only match IP addresses).
+- `heuristic` will estimate if the patterns should match FQDNs by the presence or absence of `:`s or alpha-characters.
 
 ### Where is the registry database stored?
 
@@ -168,14 +159,13 @@ The settings are:
 
 There can be up to 2 files:
 
--   `registry-log.db`, the transaction log
-
-      all incoming requests that affect the registry are saved in this file in real-time.
+- `registry-log.db`, the transaction log
 
--   `registry.db`, the database
+    all incoming requests that affect the registry are saved in this file in real-time.
 
-      every `[registry].registry save db every new entries` entries in `registry-log.db`, Netdata will save its database
-      to `registry.db` and empty `registry-log.db`.
+- `registry.db`, the database
+  
+    every `[registry].registry save db every new entries` entries in `registry-log.db`, Netdata will save its database to `registry.db` and empty `registry-log.db`.
 
 Both files are machine readable text files.
 
@@ -183,9 +173,9 @@ Both files are machine readable text files.
 
 Beginning with `v1.30.0`, when the Netdata Agent's web server processes a request, it delivers the `SameSite=none`
 and `Secure` cookies. If you have problems accessing the local Agent dashboard or Netdata Cloud, disable these
-cookies by [editing `netdata.conf`](/docs/netdata-agent/configuration/README.md#edit-netdataconf):
+cookies by [editing `netdata.conf`](/docs/netdata-agent/configuration/README.md#edit-a-configuration-file-using-edit-config):
 
-```conf
+```text
 [registry]
     enable cookies SameSite and Secure = no
 ```
@@ -208,10 +198,8 @@ redirecting the browser back to itself hoping that it will receive the cookie. I
 registry will keep redirecting your web browser back to itself, which after a few redirects will fail with an error like
 this:
 
-```conf
+```text
 ERROR 409: Cannot ACCESS netdata registry: https://registry.my-netdata.io responded with: {"status":"redirect","registry":"https://registry.my-netdata.io"}
 ```
 
 This error is printed on your web browser console (press F12 on your browser to see it).
-
-