summaryrefslogtreecommitdiffstats
path: root/docs/netdata-agent/configuration/running-the-netdata-agent-behind-a-reverse-proxy
diff options
context:
space:
mode:
Diffstat (limited to 'docs/netdata-agent/configuration/running-the-netdata-agent-behind-a-reverse-proxy')
-rw-r--r--docs/netdata-agent/configuration/running-the-netdata-agent-behind-a-reverse-proxy/README.md8
-rw-r--r--docs/netdata-agent/configuration/running-the-netdata-agent-behind-a-reverse-proxy/Running-behind-apache.md229
-rw-r--r--docs/netdata-agent/configuration/running-the-netdata-agent-behind-a-reverse-proxy/Running-behind-caddy.md15
-rw-r--r--docs/netdata-agent/configuration/running-the-netdata-agent-behind-a-reverse-proxy/Running-behind-h2o.md47
-rw-r--r--docs/netdata-agent/configuration/running-the-netdata-agent-behind-a-reverse-proxy/Running-behind-haproxy.md54
-rw-r--r--docs/netdata-agent/configuration/running-the-netdata-agent-behind-a-reverse-proxy/Running-behind-lighttpd.md34
-rw-r--r--docs/netdata-agent/configuration/running-the-netdata-agent-behind-a-reverse-proxy/Running-behind-nginx.md71
7 files changed, 196 insertions, 262 deletions
diff --git a/docs/netdata-agent/configuration/running-the-netdata-agent-behind-a-reverse-proxy/README.md b/docs/netdata-agent/configuration/running-the-netdata-agent-behind-a-reverse-proxy/README.md
index 00fe63af..a0810bb5 100644
--- a/docs/netdata-agent/configuration/running-the-netdata-agent-behind-a-reverse-proxy/README.md
+++ b/docs/netdata-agent/configuration/running-the-netdata-agent-behind-a-reverse-proxy/README.md
@@ -1,7 +1,7 @@
# Running the Netdata Agent behind a reverse proxy
If you need to access a Netdata agent's user interface or API in a production environment we recommend you put Netdata behind
-another web server and secure access to the dashboard via SSL, user authentication and firewall rules.
+another web server and secure access to the dashboard via SSL, user authentication and firewall rules.
A dedicated web server also provides more robustness and capabilities than the Agent's [internal web server](/src/web/README.md).
@@ -12,7 +12,7 @@ We have documented running behind
[Lighttpd](/docs/netdata-agent/configuration/running-the-netdata-agent-behind-a-reverse-proxy/Running-behind-lighttpd.md),
[Caddy](/docs/netdata-agent/configuration/running-the-netdata-agent-behind-a-reverse-proxy/Running-behind-caddy.md),
and [H2O](/docs/netdata-agent/configuration/running-the-netdata-agent-behind-a-reverse-proxy/Running-behind-h2o.md).
-If you prefer a different web server, we suggest you follow the documentation for nginx and tell us how you did it
+If you prefer a different web server, we suggest you follow the documentation for nginx and tell us how you did it
by adding your own "Running behind webserverX" document.
When you run Netdata behind a reverse proxy, we recommend you firewall protect all your Netdata servers, so that only the web server IP will be allowed to directly access Netdata. To do this, run this on each of your servers (or use your firewall manager):
@@ -26,9 +26,9 @@ The above will prevent anyone except your web server to access a Netdata dashboa
You can also use `netdata.conf`:
-```
+```text
[web]
- allow connections from = localhost 1.2.3.4
+ allow connections from = localhost 1.2.3.4
```
Of course, you can add more IPs.
diff --git a/docs/netdata-agent/configuration/running-the-netdata-agent-behind-a-reverse-proxy/Running-behind-apache.md b/docs/netdata-agent/configuration/running-the-netdata-agent-behind-a-reverse-proxy/Running-behind-apache.md
index 1f7274d5..23e4ae23 100644
--- a/docs/netdata-agent/configuration/running-the-netdata-agent-behind-a-reverse-proxy/Running-behind-apache.md
+++ b/docs/netdata-agent/configuration/running-the-netdata-agent-behind-a-reverse-proxy/Running-behind-apache.md
@@ -1,4 +1,4 @@
-# Netdata via Apache's mod_proxy
+# Running Netdata behind Apache's mod_proxy
Below you can find instructions for configuring an apache server to:
@@ -29,6 +29,7 @@ Also, enable the rewrite module:
```sh
sudo a2enmod rewrite
```
+
## Netdata on an existing virtual host
On any **existing** and already **working** apache virtual host, you can redirect requests for URL `/netdata/` to one or more Netdata servers.
@@ -37,29 +38,29 @@ On any **existing** and already **working** apache virtual host, you can redirec
Add the following on top of any existing virtual host. It will allow you to access Netdata as `http://virtual.host/netdata/`.
-```conf
+```text
<VirtualHost *:80>
- RewriteEngine On
- ProxyRequests Off
- ProxyPreserveHost On
+ RewriteEngine On
+ ProxyRequests Off
+ ProxyPreserveHost On
+
+ <Proxy *>
+ Require all granted
+ </Proxy>
- <Proxy *>
- Require all granted
- </Proxy>
+ # Local Netdata server accessed with '/netdata/', at localhost:19999
+ ProxyPass "/netdata/" "http://localhost:19999/" connectiontimeout=5 timeout=30 keepalive=on
+ ProxyPassReverse "/netdata/" "http://localhost:19999/"
- # Local Netdata server accessed with '/netdata/', at localhost:19999
- ProxyPass "/netdata/" "http://localhost:19999/" connectiontimeout=5 timeout=30 keepalive=on
- ProxyPassReverse "/netdata/" "http://localhost:19999/"
+ # if the user did not give the trailing /, add it
+ # for HTTP (if the virtualhost is HTTP, use this)
+ RewriteRule ^/netdata$ http://%{HTTP_HOST}/netdata/ [L,R=301]
+ # for HTTPS (if the virtualhost is HTTPS, use this)
+ #RewriteRule ^/netdata$ https://%{HTTP_HOST}/netdata/ [L,R=301]
- # if the user did not give the trailing /, add it
- # for HTTP (if the virtualhost is HTTP, use this)
- RewriteRule ^/netdata$ http://%{HTTP_HOST}/netdata/ [L,R=301]
- # for HTTPS (if the virtualhost is HTTPS, use this)
- #RewriteRule ^/netdata$ https://%{HTTP_HOST}/netdata/ [L,R=301]
+ # rest of virtual host config here
- # rest of virtual host config here
-
</VirtualHost>
```
@@ -67,16 +68,16 @@ Add the following on top of any existing virtual host. It will allow you to acce
Add the following on top of any existing virtual host. It will allow you to access multiple Netdata as `http://virtual.host/netdata/HOSTNAME/`, where `HOSTNAME` is the hostname of any other Netdata server you have (to access the `localhost` Netdata, use `http://virtual.host/netdata/localhost/`).
-```conf
+```text
<VirtualHost *:80>
- RewriteEngine On
- ProxyRequests Off
- ProxyPreserveHost On
+ RewriteEngine On
+ ProxyRequests Off
+ ProxyPreserveHost On
- <Proxy *>
- Require all granted
- </Proxy>
+ <Proxy *>
+ Require all granted
+ </Proxy>
# proxy any host, on port 19999
ProxyPassMatch "^/netdata/([A-Za-z0-9\._-]+)/(.*)" "http://$1:19999/$2" connectiontimeout=5 timeout=30 keepalive=on
@@ -87,8 +88,8 @@ Add the following on top of any existing virtual host. It will allow you to acce
# for HTTPS (if the virtualhost is HTTPS, use this)
RewriteRule "^/netdata/([A-Za-z0-9\._-]+)$" https://%{HTTP_HOST}/netdata/$1/ [L,R=301]
- # rest of virtual host config here
-
+ # rest of virtual host config here
+
</VirtualHost>
```
@@ -97,7 +98,7 @@ Add the following on top of any existing virtual host. It will allow you to acce
If you want to control the servers your users can connect to, replace the `ProxyPassMatch` line with the following. This allows only `server1`, `server2`, `server3` and `server4`.
-```
+```text
ProxyPassMatch "^/netdata/(server1|server2|server3|server4)/(.*)" "http://$1:19999/$2" connectiontimeout=5 timeout=30 keepalive=on
```
@@ -113,26 +114,28 @@ nano /etc/apache2/sites-available/netdata.conf
with this content:
-```conf
+```text
<VirtualHost *:80>
- ProxyRequests Off
- ProxyPreserveHost On
-
- ServerName netdata.domain.tld
- <Proxy *>
- Require all granted
- </Proxy>
+ ProxyRequests Off
+ ProxyPreserveHost On
+
+ ServerName netdata.domain.tld
+
+ <Proxy *>
+ Require all granted
+ </Proxy>
- ProxyPass "/" "http://localhost:19999/" connectiontimeout=5 timeout=30 keepalive=on
- ProxyPassReverse "/" "http://localhost:19999/"
+ ProxyPass "/" "http://localhost:19999/" connectiontimeout=5 timeout=30 keepalive=on
+ ProxyPassReverse "/" "http://localhost:19999/"
+
+ ErrorLog ${APACHE_LOG_DIR}/netdata-error.log
+ CustomLog ${APACHE_LOG_DIR}/netdata-access.log combined
- ErrorLog ${APACHE_LOG_DIR}/netdata-error.log
- CustomLog ${APACHE_LOG_DIR}/netdata-access.log combined
</VirtualHost>
```
-Enable the VirtualHost:
+Enable the VirtualHost:
```sh
sudo a2ensite netdata.conf && service apache2 reload
@@ -142,15 +145,15 @@ sudo a2ensite netdata.conf && service apache2 reload
_Assuming the main goal is to make Netdata running in HTTPS._
-1. Make a subdomain for Netdata on which you enable and force HTTPS - You can use a free Let's Encrypt certificate
-2. Go to "Apache & nginx Settings", and in the following section, add:
-
-```conf
-RewriteEngine on
-RewriteRule (.*) http://localhost:19999/$1 [P,L]
-```
+1. Make a subdomain for Netdata on which you enable and force HTTPS - You can use a free Let's Encrypt certificate
+2. Go to "Apache & nginx Settings", and in the following section, add:
-3. Optional: If your server is remote, then just replace "localhost" with your actual hostname or IP, it just works.
+ ```text
+ RewriteEngine on
+ RewriteRule (.*) http://localhost:19999/$1 [P,L]
+ ```
+
+3. Optional: If your server is remote, then just replace "localhost" with your actual hostname or IP, it just works.
Repeat the operation for as many servers as you need.
@@ -165,49 +168,49 @@ Then, generate password for user `netdata`, using `htpasswd -c /etc/apache2/.htp
**Apache 2.2 Example:**\
Modify the virtual host with these:
-```conf
- # replace the <Proxy *> section
- <Proxy *>
- Order deny,allow
- Allow from all
- </Proxy>
-
- # add a <Location /netdata/> section
- <Location /netdata/>
- AuthType Basic
- AuthName "Protected site"
- AuthUserFile /etc/apache2/.htpasswd
- Require valid-user
- Order deny,allow
- Allow from all
- </Location>
+```text
+ # replace the <Proxy *> section
+ <Proxy *>
+ Order deny,allow
+ Allow from all
+ </Proxy>
+
+ # add a <Location /netdata/> section
+ <Location /netdata/>
+ AuthType Basic
+ AuthName "Protected site"
+ AuthUserFile /etc/apache2/.htpasswd
+ Require valid-user
+ Order deny,allow
+ Allow from all
+ </Location>
```
Specify `Location /` if Netdata is running on dedicated virtual host.
**Apache 2.4 (dedicated virtual host) Example:**
-```conf
+```text
<VirtualHost *:80>
- RewriteEngine On
- ProxyRequests Off
- ProxyPreserveHost On
-
- ServerName netdata.domain.tld
-
- <Proxy *>
- AllowOverride None
- AuthType Basic
- AuthName "Protected site"
- AuthUserFile /etc/apache2/.htpasswd
- Require valid-user
- </Proxy>
-
- ProxyPass "/" "http://localhost:19999/" connectiontimeout=5 timeout=30 keepalive=on
- ProxyPassReverse "/" "http://localhost:19999/"
-
- ErrorLog ${APACHE_LOG_DIR}/netdata-error.log
- CustomLog ${APACHE_LOG_DIR}/netdata-access.log combined
+ RewriteEngine On
+ ProxyRequests Off
+ ProxyPreserveHost On
+
+ ServerName netdata.domain.tld
+
+ <Proxy *>
+ AllowOverride None
+ AuthType Basic
+ AuthName "Protected site"
+ AuthUserFile /etc/apache2/.htpasswd
+ Require valid-user
+ </Proxy>
+
+ ProxyPass "/" "http://localhost:19999/" connectiontimeout=5 timeout=30 keepalive=on
+ ProxyPassReverse "/" "http://localhost:19999/"
+
+ ErrorLog ${APACHE_LOG_DIR}/netdata-error.log
+ CustomLog ${APACHE_LOG_DIR}/netdata-access.log combined
</VirtualHost>
```
@@ -217,8 +220,8 @@ Note: Changes are applied by reloading or restarting Apache.
If you want to enable CSP within your Apache, you should consider some special requirements of the headers. Modify your configuration like that:
-```
- Header always set Content-Security-Policy "default-src http: 'unsafe-inline' 'self' 'unsafe-eval'; script-src http: 'unsafe-inline' 'self' 'unsafe-eval'; style-src http: 'self' 'unsafe-inline'"
+```text
+ Header always set Content-Security-Policy "default-src http: 'unsafe-inline' 'self' 'unsafe-eval'; script-src http: 'unsafe-inline' 'self' 'unsafe-eval'; style-src http: 'self' 'unsafe-inline'"
```
Note: Changes are applied by reloading or restarting Apache.
@@ -242,7 +245,7 @@ exceed that threshold, and `mod_evasive` will add your IP address to a blocklist
Our users have found success by setting `DOSPageCount` to `30`. Try this, and raise the value if you continue to see 403
errors while accessing the dashboard.
-```conf
+```text
DOSPageCount 30
```
@@ -255,100 +258,92 @@ To adjust the `DOSPageCount` for a specific virtual host, open your virtual host
`/etc/httpd/conf/sites-available/my-domain.conf` or `/etc/apache2/sites-available/my-domain.conf` and add the
following:
-```conf
+```text
<VirtualHost *:80>
- ...
- # Increase the DOSPageCount to prevent 403 errors and IP addresses being blocked.
- <IfModule mod_evasive20.c>
- DOSPageCount 30
- </IfModule>
+ ...
+ # Increase the DOSPageCount to prevent 403 errors and IP addresses being blocked.
+ <IfModule mod_evasive20.c>
+ DOSPageCount 30
+ </IfModule>
</VirtualHost>
```
See issues [#2011](https://github.com/netdata/netdata/issues/2011) and
[#7658](https://github.com/netdata/netdata/issues/7568) for more information.
-# Netdata configuration
+## Netdata configuration
You might edit `/etc/netdata/netdata.conf` to optimize your setup a bit. For applying these changes you need to restart Netdata.
-## Response compression
+### Response compression
If you plan to use Netdata exclusively via apache, you can gain some performance by preventing double compression of its output (Netdata compresses its response, apache re-compresses it) by editing `/etc/netdata/netdata.conf` and setting:
-```
+```text
[web]
enable gzip compression = no
```
Once you disable compression at Netdata (and restart it), please verify you receive compressed responses from apache (it is important to receive compressed responses - the charts will be more snappy).
-## Limit direct access to Netdata
+### Limit direct access to Netdata
You would also need to instruct Netdata to listen only on `localhost`, `127.0.0.1` or `::1`.
-```
+```text
[web]
bind to = localhost
```
or
-```
+```text
[web]
bind to = 127.0.0.1
```
or
-```
+```text
[web]
bind to = ::1
```
-
-
You can also use a unix domain socket. This will also provide a faster route between apache and Netdata:
-```
+```text
[web]
bind to = unix:/tmp/netdata.sock
```
Apache 2.4.24+ can not read from `/tmp` so create your socket in `/var/run/netdata`
-```
+```text
[web]
bind to = unix:/var/run/netdata/netdata.sock
```
-_note: Netdata v1.8+ support unix domain sockets_
-
At the apache side, prepend the 2nd argument to `ProxyPass` with `unix:/tmp/netdata.sock|`, like this:
-```
+```text
ProxyPass "/netdata/" "unix:/tmp/netdata.sock|http://localhost:19999/" connectiontimeout=5 timeout=30 keepalive=on
```
-
-
If your apache server is not on localhost, you can set:
-```
+```text
[web]
bind to = *
allow connections from = IP_OF_APACHE_SERVER
```
-*note: Netdata v1.9+ support `allow connections from`*
-
`allow connections from` accepts [Netdata simple patterns](/src/libnetdata/simple_pattern/README.md) to match against the connection IP address.
## Prevent the double access.log
apache logs accesses and Netdata logs them too. You can prevent Netdata from generating its access log, by setting this in `/etc/netdata/netdata.conf`:
-```
+```text
[logs]
access = off
```
@@ -357,7 +352,5 @@ apache logs accesses and Netdata logs them too. You can prevent Netdata from gen
Make sure the requests reach Netdata, by examining `/var/log/netdata/access.log`.
-1. if the requests do not reach Netdata, your apache does not forward them.
-2. if the requests reach Netdata but the URLs are wrong, you have not re-written them properly.
-
-
+1. if the requests do not reach Netdata, your apache does not forward them.
+2. if the requests reach Netdata but the URLs are wrong, you have not re-written them properly.
diff --git a/docs/netdata-agent/configuration/running-the-netdata-agent-behind-a-reverse-proxy/Running-behind-caddy.md b/docs/netdata-agent/configuration/running-the-netdata-agent-behind-a-reverse-proxy/Running-behind-caddy.md
index b7608b30..f43a7a27 100644
--- a/docs/netdata-agent/configuration/running-the-netdata-agent-behind-a-reverse-proxy/Running-behind-caddy.md
+++ b/docs/netdata-agent/configuration/running-the-netdata-agent-behind-a-reverse-proxy/Running-behind-caddy.md
@@ -1,15 +1,6 @@
-<!--
-title: "Netdata via Caddy"
-custom_edit_url: "https://github.com/netdata/netdata/edit/master/docs/Running-behind-caddy.md"
-sidebar_label: "Netdata via Caddy"
-learn_status: "Published"
-learn_topic_type: "Tasks"
-learn_rel_path: "Configuration/Secure your nodes"
--->
+# Running Netdata behind Caddy
-# Netdata via Caddy
-
-To run Netdata via [Caddy v2 proxying,](https://caddyserver.com/docs/caddyfile/directives/reverse_proxy) set your Caddyfile up like this:
+To run Netdata via [Caddy v2 reverse proxy,](https://caddyserver.com/docs/caddyfile/directives/reverse_proxy) set your Caddyfile up like this:
```caddyfile
netdata.domain.tld {
@@ -34,5 +25,3 @@ netdata.domain.tld {
You would also need to instruct Netdata to listen only to `127.0.0.1` or `::1`.
To limit access to Netdata only from localhost, set `bind socket to IP = 127.0.0.1` or `bind socket to IP = ::1` in `/etc/netdata/netdata.conf`.
-
-
diff --git a/docs/netdata-agent/configuration/running-the-netdata-agent-behind-a-reverse-proxy/Running-behind-h2o.md b/docs/netdata-agent/configuration/running-the-netdata-agent-behind-a-reverse-proxy/Running-behind-h2o.md
index 276b72e8..f2dc45b8 100644
--- a/docs/netdata-agent/configuration/running-the-netdata-agent-behind-a-reverse-proxy/Running-behind-h2o.md
+++ b/docs/netdata-agent/configuration/running-the-netdata-agent-behind-a-reverse-proxy/Running-behind-h2o.md
@@ -1,12 +1,3 @@
-<!--
-title: "Running Netdata behind H2O"
-custom_edit_url: "https://github.com/netdata/netdata/edit/master/docs/netdata-agent/configuration/running-the-netdata-agent-behind-a-reverse-proxy/Running-behind-h2o.md"
-sidebar_label: "Running Netdata behind H2O"
-learn_status: "Published"
-learn_topic_type: "Tasks"
-learn_rel_path: "Configuration/Secure your nodes"
--->
-
# Running Netdata behind H2O
[H2O](https://h2o.examp1e.net/) is a new generation HTTP server that provides quicker response to users with less CPU utilization when compared to older generation of web servers.
@@ -15,23 +6,23 @@ It is notable for having much simpler configuration than many popular HTTP serve
## Why H2O
-- Sane configuration defaults mean that typical configurations are very minimalistic and easy to work with.
+- Sane configuration defaults mean that typical configurations are very minimalistic and easy to work with.
-- Native support for HTTP/2 provides improved performance when accessing the Netdata dashboard remotely.
+- Native support for HTTP/2 provides improved performance when accessing the Netdata dashboard remotely.
-- Password protect access to the Netdata dashboard without requiring Netdata Cloud.
+- Password protect access to the Netdata dashboard without requiring Netdata Cloud.
-## H2O configuration file.
+## H2O configuration file
-On most systems, the H2O configuration is found under `/etc/h2o`. H2O uses [YAML 1.1](https://yaml.org/spec/1.1/), with a few special extensions, for it’s configuration files, with the main configuration file being `/etc/h2o/h2o.conf`.
+On most systems, the H2O configuration is found under `/etc/h2o`. H2O uses [YAML 1.1](https://yaml.org/spec/1.1/), with a few special extensions, for it’s configuration files, with the main configuration file being `/etc/h2o/h2o.conf`.
You can edit the H2O configuration file with Nano, Vim or any other text editors with which you are comfortable.
After making changes to the configuration files, perform the following:
-- Test the configuration with `h2o -m test -c /etc/h2o/h2o.conf`
+- Test the configuration with `h2o -m test -c /etc/h2o/h2o.conf`
-- Restart H2O to apply tha changes with `/etc/init.d/h2o restart` or `service h2o restart`
+- Restart H2O to apply tha changes with `/etc/init.d/h2o restart` or `service h2o restart`
## Ways to access Netdata via H2O
@@ -52,7 +43,7 @@ hosts:
### As a subfolder of an existing virtual host
-This method is recommended when Netdata is to be served from a subfolder (or directory).
+This method is recommended when Netdata is to be served from a subfolder (or directory).
In this case, the virtual host `netdata.example.com` already exists and Netdata has to be accessed via `netdata.example.com/netdata/`.
```yaml
@@ -72,7 +63,7 @@ hosts:
### As a subfolder for multiple Netdata servers, via one H2O instance
-This is the recommended configuration when one H2O instance will be used to manage multiple Netdata servers via subfolders.
+This is the recommended configuration when one H2O instance will be used to manage multiple Netdata servers via sub-folders.
```yaml
hosts:
@@ -100,12 +91,12 @@ Of course you can add as many backend servers as you like.
Using the above, you access Netdata on the backend servers, like this:
-- `http://netdata.example.com/netdata/server1/` to reach Netdata on `198.51.100.1:19999`
-- `http://netdata.example.com/netdata/server2/` to reach Netdata on `198.51.100.2:19999`
+- `http://netdata.example.com/netdata/server1/` to reach Netdata on `198.51.100.1:19999`
+- `http://netdata.example.com/netdata/server2/` to reach Netdata on `198.51.100.2:19999`
### Encrypt the communication between H2O and Netdata
-In case Netdata's web server has been [configured to use TLS](/src/web/server/README.md#enabling-tls-support), it is
+In case Netdata's web server has been [configured to use TLS](/src/web/server/README.md#enable-httpstls-support), it is
necessary to specify inside the H2O configuration that the final destination is using TLS. To do this, change the
`http://` on the `proxy.reverse.url` line in your H2O configuration with `https://`
@@ -141,31 +132,27 @@ For more information on using basic authentication with H2O, see [their official
If your H2O server is on `localhost`, you can use this to ensure external access is only possible through H2O:
-```
+```text
[web]
bind to = 127.0.0.1 ::1
```
-
-
You can also use a unix domain socket. This will provide faster communication between H2O and Netdata as well:
-```
+```text
[web]
bind to = unix:/run/netdata/netdata.sock
```
In the H2O configuration, use a line like the following to connect to Netdata via the unix socket:
-```yaml
+```text
proxy.reverse.url http://[unix:/run/netdata/netdata.sock]
```
-
-
If your H2O server is not on localhost, you can set:
-```
+```text
[web]
bind to = *
allow connections from = IP_OF_H2O_SERVER
@@ -181,7 +168,7 @@ the connection IP address.
H2O logs accesses and Netdata logs them too. You can prevent Netdata from generating its access log, by setting
this in `/etc/netdata/netdata.conf`:
-```
+```text
[logs]
access = off
```
diff --git a/docs/netdata-agent/configuration/running-the-netdata-agent-behind-a-reverse-proxy/Running-behind-haproxy.md b/docs/netdata-agent/configuration/running-the-netdata-agent-behind-a-reverse-proxy/Running-behind-haproxy.md
index 9d2aff67..04bd3283 100644
--- a/docs/netdata-agent/configuration/running-the-netdata-agent-behind-a-reverse-proxy/Running-behind-haproxy.md
+++ b/docs/netdata-agent/configuration/running-the-netdata-agent-behind-a-reverse-proxy/Running-behind-haproxy.md
@@ -1,16 +1,6 @@
-<!--
-title: "Netdata via HAProxy"
-custom_edit_url: "https://github.com/netdata/netdata/edit/master/docs/netdata-agent/configuration/running-the-netdata-agent-behind-a-reverse-proxy/Running-behind-haproxy.md"
-sidebar_label: "Netdata via HAProxy"
-learn_status: "Published"
-learn_topic_type: "Tasks"
-learn_rel_path: "Configuration/Secure your nodes"
--->
-
-# Netdata via HAProxy
-
-> HAProxy is a free, very fast and reliable solution offering high availability, load balancing,
-> and proxying for TCP and HTTP-based applications. It is particularly suited for very high traffic websites
+# Running Netdata behind HAProxy
+
+> HAProxy is a free, very fast and reliable solution offering high availability, load balancing, and proxying for TCP and HTTP-based applications. It is particularly suited for very high traffic websites
> and powers quite a number of the world's most visited ones.
If Netdata is running on a host running HAProxy, rather than connecting to Netdata from a port number, a domain name can
@@ -18,14 +8,14 @@ be pointed at HAProxy, and HAProxy can redirect connections to the Netdata port.
Netdata at `https://example.com` or `https://example.com/netdata/`, which is a much nicer experience then
`http://example.com:19999`.
-To proxy requests from [HAProxy](https://github.com/haproxy/haproxy) to Netdata,
+To proxy requests from [HAProxy](https://github.com/haproxy/haproxy) to Netdata,
the following configuration can be used:
## Default Configuration
For all examples, set the mode to `http`
-```conf
+```text
defaults
mode http
```
@@ -38,7 +28,7 @@ A simple example where the base URL, say `http://example.com`, is used with no s
Create a frontend to receive the request.
-```conf
+```text
frontend http_frontend
## HTTP ipv4 and ipv6 on all ips ##
bind :::80 v4v6
@@ -50,7 +40,7 @@ frontend http_frontend
Create the Netdata backend which will send requests to port `19999`.
-```conf
+```text
backend netdata_backend
option forwardfor
server netdata_local 127.0.0.1:19999
@@ -69,7 +59,7 @@ An example where the base URL is used with a subpath `/netdata/`:
To use a subpath, create an ACL, which will set a variable based on the subpath.
-```conf
+```text
frontend http_frontend
## HTTP ipv4 and ipv6 on all ips ##
bind :::80 v4v6
@@ -92,7 +82,7 @@ frontend http_frontend
Same as simple example, except remove `/netdata/` with regex.
-```conf
+```text
backend netdata_backend
option forwardfor
server netdata_local 127.0.0.1:19999
@@ -107,14 +97,14 @@ backend netdata_backend
## Using TLS communication
-TLS can be used by adding port `443` and a cert to the frontend.
+TLS can be used by adding port `443` and a cert to the frontend.
This example will only use Netdata if host matches example.com (replace with your domain).
### Frontend
This frontend uses a certificate list.
-```conf
+```text
frontend https_frontend
## HTTP ##
bind :::80 v4v6
@@ -139,11 +129,11 @@ In the cert list file place a mapping from a certificate file to the domain used
`/etc/letsencrypt/certslist.txt`:
-```txt
+```text
example.com /etc/letsencrypt/live/example.com/example.com.pem
```
-The file `/etc/letsencrypt/live/example.com/example.com.pem` should contain the key and
+The file `/etc/letsencrypt/live/example.com/example.com.pem` should contain the key and
certificate (in that order) concatenated into a `.pem` file.:
```sh
@@ -156,7 +146,7 @@ cat /etc/letsencrypt/live/example.com/fullchain.pem \
Same as simple, except set protocol `https`.
-```conf
+```text
backend netdata_backend
option forwardfor
server netdata_local 127.0.0.1:19999
@@ -172,30 +162,30 @@ backend netdata_backend
To use basic HTTP Authentication, create an authentication list:
-```conf
+```text
# HTTP Auth
userlist basic-auth-list
group is-admin
# Plaintext password
- user admin password passwordhere groups is-admin
+ user admin password YOUR_PASSWORD groups is-admin
```
You can create a hashed password using the `mkpassword` utility.
```sh
- printf "passwordhere" | mkpasswd --stdin --method=sha-256
+ printf "YOUR_PASSWORD" | mkpasswd --stdin --method=sha-256
$5$l7Gk0VPIpKO$f5iEcxvjfdF11khw.utzSKqP7W.0oq8wX9nJwPLwzy1
```
-Replace `passwordhere` with hash:
+Replace `YOUR_PASSWORD` with hash:
-```conf
+```text
user admin password $5$l7Gk0VPIpKO$f5iEcxvjfdF11khw.utzSKqP7W.0oq8wX9nJwPLwzy1 groups is-admin
```
Now add at the top of the backend:
-```conf
+```text
acl devops-auth http_auth_group(basic-auth-list) is-admin
http-request auth realm netdata_local unless devops-auth
```
@@ -204,7 +194,7 @@ http-request auth realm netdata_local unless devops-auth
Full example configuration with HTTP auth over TLS with subpath:
-```conf
+```text
global
maxconn 20000
@@ -293,5 +283,3 @@ backend netdata_backend
http-request set-header X-Forwarded-Port %[dst_port]
http-request set-header Connection "keep-alive"
```
-
-
diff --git a/docs/netdata-agent/configuration/running-the-netdata-agent-behind-a-reverse-proxy/Running-behind-lighttpd.md b/docs/netdata-agent/configuration/running-the-netdata-agent-behind-a-reverse-proxy/Running-behind-lighttpd.md
index 637bc064..48b9b2c9 100644
--- a/docs/netdata-agent/configuration/running-the-netdata-agent-behind-a-reverse-proxy/Running-behind-lighttpd.md
+++ b/docs/netdata-agent/configuration/running-the-netdata-agent-behind-a-reverse-proxy/Running-behind-lighttpd.md
@@ -1,26 +1,17 @@
-<!--
-title: "Netdata via lighttpd v1.4.x"
-custom_edit_url: "https://github.com/netdata/netdata/edit/master/docs/netdata-agent/configuration/running-the-netdata-agent-behind-a-reverse-proxy/Running-behind-lighttpd.md"
-sidebar_label: "Netdata via lighttpd v1.4.x"
-learn_status: "Published"
-learn_topic_type: "Tasks"
-learn_rel_path: "Configuration/Secure your nodes"
--->
-
-# Netdata via lighttpd v1.4.x
+# Running Netdata behind lighttpd v1.4.x
Here is a config for accessing Netdata in a suburl via lighttpd 1.4.46 and newer:
-```txt
+```text
$HTTP["url"] =~ "^/netdata/" {
proxy.server = ( "" => ("netdata" => ( "host" => "127.0.0.1", "port" => 19999 )))
proxy.header = ( "map-urlpath" => ( "/netdata/" => "/") )
}
```
-If you have older lighttpd you have to use a chain (such as below), as explained [at this stackoverflow answer](http://stackoverflow.com/questions/14536554/lighttpd-configuration-to-proxy-rewrite-from-one-domain-to-another).
+If you have older lighttpd you have to use a chain (such as below), as explained [at this Stack Overflow answer](http://stackoverflow.com/questions/14536554/lighttpd-configuration-to-proxy-rewrite-from-one-domain-to-another).
-```txt
+```text
$HTTP["url"] =~ "^/netdata/" {
proxy.server = ( "" => ("" => ( "host" => "127.0.0.1", "port" => 19998 )))
}
@@ -31,19 +22,16 @@ $SERVER["socket"] == ":19998" {
}
```
-
-
If the only thing the server is exposing via the web is Netdata (and thus no suburl rewriting required),
then you can get away with just
-```
+```text
proxy.server = ( "" => ( ( "host" => "127.0.0.1", "port" => 19999 )))
```
-Though if it's public facing you might then want to put some authentication on it. htdigest support
-looks like:
+Though if it's public facing you might then want to put some authentication on it. `htdigest` support looks like:
-```
+```text
auth.backend = "htdigest"
auth.backend.htdigest.userfile = "/etc/lighttpd/lighttpd.htdigest"
auth.require = ( "" => ( "method" => "digest",
@@ -55,14 +43,12 @@ auth.require = ( "" => ( "method" => "digest",
other auth methods, and more info on htdigest, can be found in lighttpd's [mod_auth docs](http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_ModAuth).
-
-
It seems that lighttpd (or some versions of it), fail to proxy compressed web responses.
To solve this issue, disable web response compression in Netdata.
-Open `/etc/netdata/netdata.conf` and set in [global]\:
+Open `/etc/netdata/netdata.conf` and set in `[global]`:
-```
+```text
enable web responses gzip compression = no
```
@@ -71,5 +57,3 @@ enable web responses gzip compression = no
You would also need to instruct Netdata to listen only to `127.0.0.1` or `::1`.
To limit access to Netdata only from localhost, set `bind socket to IP = 127.0.0.1` or `bind socket to IP = ::1` in `/etc/netdata/netdata.conf`.
-
-
diff --git a/docs/netdata-agent/configuration/running-the-netdata-agent-behind-a-reverse-proxy/Running-behind-nginx.md b/docs/netdata-agent/configuration/running-the-netdata-agent-behind-a-reverse-proxy/Running-behind-nginx.md
index f2dd137d..c0364633 100644
--- a/docs/netdata-agent/configuration/running-the-netdata-agent-behind-a-reverse-proxy/Running-behind-nginx.md
+++ b/docs/netdata-agent/configuration/running-the-netdata-agent-behind-a-reverse-proxy/Running-behind-nginx.md
@@ -2,19 +2,19 @@
## Intro
-[Nginx](https://nginx.org/en/) is an HTTP and reverse proxy server, a mail proxy server, and a generic TCP/UDP proxy server used to host websites and applications of all sizes.
+[Nginx](https://nginx.org/en/) is an HTTP and reverse proxy server, a mail proxy server, and a generic TCP/UDP proxy server used to host websites and applications of all sizes.
The software is known for its low impact on memory resources, high scalability, and its modular, event-driven architecture which can offer secure, predictable performance.
## Why Nginx
-- By default, Nginx is fast and lightweight out of the box.
+- By default, Nginx is fast and lightweight out of the box.
-- Nginx is used and useful in cases when you want to access different instances of Netdata from a single server.
+- Nginx is used and useful in cases when you want to access different instances of Netdata from a single server.
-- Password-protect access to Netdata, until distributed authentication is implemented via the Netdata cloud Sign In mechanism.
+- Password-protect access to Netdata, until distributed authentication is implemented via the Netdata cloud Sign In mechanism.
-- A proxy was necessary to encrypt the communication to Netdata, until v1.16.0, which provided TLS (HTTPS) support.
+- A proxy was necessary to encrypt the communication to Netdata, until v1.16.0, which provided TLS (HTTPS) support.
## Nginx configuration file
@@ -22,23 +22,23 @@ All Nginx configurations can be found in the `/etc/nginx/` directory. The main c
Configuration options in Nginx are known as directives. Directives are organized into groups known as blocks or contexts. The two terms can be used interchangeably.
-Depending on your installation source, you’ll find an example configuration file at `/etc/nginx/conf.d/default.conf` or `etc/nginx/sites-enabled/default`, in some cases you may have to manually create the `sites-available` and `sites-enabled` directories.
+Depending on your installation source, you’ll find an example configuration file at `/etc/nginx/conf.d/default.conf` or `etc/nginx/sites-enabled/default`, in some cases you may have to manually create the `sites-available` and `sites-enabled` directories.
You can edit the Nginx configuration file with Nano, Vim or any other text editors you are comfortable with.
After making changes to the configuration files:
-- Test Nginx configuration with `nginx -t`.
+- Test Nginx configuration with `nginx -t`.
-- Restart Nginx to effect the change with `/etc/init.d/nginx restart` or `service nginx restart`.
+- Restart Nginx to effect the change with `/etc/init.d/nginx restart` or `service nginx restart`.
## Ways to access Netdata via Nginx
### As a virtual host
-With this method instead of `SERVER_IP_ADDRESS:19999`, the Netdata dashboard can be accessed via a human-readable URL such as `netdata.example.com` used in the configuration below.
+With this method instead of `SERVER_IP_ADDRESS:19999`, the Netdata dashboard can be accessed via a human-readable URL such as `netdata.example.com` used in the configuration below.
-```conf
+```text
upstream backend {
# the Netdata server
server 127.0.0.1:19999;
@@ -69,10 +69,10 @@ server {
### As a subfolder to an existing virtual host
-This method is recommended when Netdata is to be served from a subfolder (or directory).
+This method is recommended when Netdata is to be served from a subfolder (or directory).
In this case, the virtual host `netdata.example.com` already exists and Netdata has to be accessed via `netdata.example.com/netdata/`.
-```conf
+```text
upstream netdata {
server 127.0.0.1:19999;
keepalive 64;
@@ -112,9 +112,9 @@ server {
### As a subfolder for multiple Netdata servers, via one Nginx
-This is the recommended configuration when one Nginx will be used to manage multiple Netdata servers via subfolders.
+This is the recommended configuration when one Nginx will be used to manage multiple Netdata servers via sub-folders.
-```conf
+```text
upstream backend-server1 {
server 10.1.1.103:19999;
keepalive 64;
@@ -159,16 +159,16 @@ Of course you can add as many backend servers as you like.
Using the above, you access Netdata on the backend servers, like this:
-- `http://netdata.example.com/netdata/server1/` to reach `backend-server1`
-- `http://netdata.example.com/netdata/server2/` to reach `backend-server2`
+- `http://netdata.example.com/netdata/server1/` to reach `backend-server1`
+- `http://netdata.example.com/netdata/server2/` to reach `backend-server2`
### Encrypt the communication between Nginx and Netdata
-In case Netdata's web server has been [configured to use TLS](/src/web/server/README.md#enabling-tls-support), it is
+In case Netdata's web server has been [configured to use TLS](/src/web/server/README.md#enable-httpstls-support), it is
necessary to specify inside the Nginx configuration that the final destination is using TLS. To do this, please, append
the following parameters in your `nginx.conf`
-```conf
+```text
proxy_set_header X-Forwarded-Proto https;
proxy_pass https://localhost:19999;
```
@@ -189,7 +189,7 @@ printf "yourusername:$(openssl passwd -apr1)" > /etc/nginx/passwords
And then enable the authentication inside your server directive:
-```conf
+```text
server {
# ...
auth_basic "Protected";
@@ -202,40 +202,35 @@ server {
If your Nginx is on `localhost`, you can use this to protect your Netdata:
-```
+```text
[web]
bind to = 127.0.0.1 ::1
```
You can also use a unix domain socket. This will also provide a faster route between Nginx and Netdata:
-```
+```text
[web]
bind to = unix:/var/run/netdata/netdata.sock
```
-*note: Netdata v1.8+ support unix domain sockets*
-
At the Nginx side, use something like this to use the same unix domain socket:
-```conf
+```text
upstream backend {
server unix:/var/run/netdata/netdata.sock;
keepalive 64;
}
```
-
If your Nginx server is not on localhost, you can set:
-```
+```text
[web]
bind to = *
allow connections from = IP_OF_NGINX_SERVER
```
-*note: Netdata v1.9+ support `allow connections from`*
-
`allow connections from` accepts [Netdata simple patterns](/src/libnetdata/simple_pattern/README.md) to match against the
connection IP address.
@@ -243,7 +238,7 @@ connection IP address.
Nginx logs accesses and Netdata logs them too. You can prevent Netdata from generating its access log, by setting this in `/etc/netdata/netdata.conf`:
-```
+```text
[logs]
access = off
```
@@ -252,18 +247,18 @@ Nginx logs accesses and Netdata logs them too. You can prevent Netdata from gene
By default, netdata compresses its responses. You can have nginx do that instead, with the following options in the `location /` block:
-```conf
- location / {
- ...
- gzip on;
- gzip_proxied any;
- gzip_types *;
- }
+```text
+location / {
+ ...
+ gzip on;
+ gzip_proxied any;
+ gzip_types *;
+}
```
To disable Netdata's gzip compression, open `netdata.conf` and in the `[web]` section put:
-```conf
+```text
[web]
enable gzip compression = no
```
@@ -278,5 +273,3 @@ If you get an 502 Bad Gateway error you might check your Nginx error log:
```
If you see something like the above, chances are high that SELinux prevents nginx from connecting to the backend server. To fix that, just use this policy: `setsebool -P httpd_can_network_connect true`.
-
-