docs - add dns_resolvers and permissions to Linux

docs/integrations.md

@@ -2,8 +2,6 @@
 
 ## Docker
 
-### Introduction
-
 You can get official prebuilt Docker images of bunkerized-nginx for x86, x64, armv7 and aarch64/arm64 architectures on Docker Hub :
 ```shell
 $ docker pull bunkerity/bunkerized-nginx
@@ -20,8 +18,6 @@ To use bunkerized-nginx as a Docker container you have to pass specific environm
 
 <img src="https://github.com/bunkerity/bunkerized-nginx/blob/dev/docs/img/docker.png?raw=true" />
 
-### Usage
-
 To demonstrate the use of the Docker image, we will create a simple "Hello World" static file that will be served by bunkerized-nginx.
 
 **One important thing to know is that the container runs as an unprivileged user with UID and GID 101. The reason behind this behavior is the security : in case a vulnerability is exploited the attacker won't have full privileges inside the container. But there is also a downside because bunkerized-nginx (heavily) make use of volumes, you will need to adjust the rights on the host.**
@@ -108,14 +104,10 @@ services:
 
 ## Docker autoconf
 
-### Introduction
-
 The downside of using environment variables is that the container needs to be recreated each time there is an update which is not very convenient. To counter that issue, you can use another image called bunkerized-nginx-autoconf which will listen for Docker events and automatically configure bunkerized-nginx instance in real time without recreating the container. Instead of defining environment variables for the bunkerized-nginx container, you simply add labels to your web services and bunkerized-nginx-autoconf will "automagically" take care of the rest.
 
 <img src="https://github.com/bunkerity/bunkerized-nginx/blob/dev/docs/img/autoconf-docker.png?raw=true" />
 
-### Usage
-
 First of all, you will need a network to allow communication between bunkerized-nginx and your web services :
 ```shell
 $ docker network create services-net
@@ -249,14 +241,10 @@ When your container is not needed anymore, you can delete it as usual. The autoc
 
 ## Docker Swarm
 
-### Introduction
-
 Using bunkerized-nginx in a Docker Swarm cluster requires a shared folder accessible from both managers and workers (anything like NFS, GlusterFS, CephFS or even SSHFS will work). The deployment and configuration is very similar to the "Docker autoconf" one but with services instead of containers. A service based on the bunkerized-nginx-autoconf image needs to be scheduled on a manager node (don't worry it doesn't expose any network port for obvious security reasons). This service will listen for Docker Swarm events like service creation or deletion and generate the configuration according to the labels of each service. Once configuration generation is done, the bunkerized-nginx-autoconf service will send a reload order to all the bunkerized-nginx tasks so they can load the new configuration.
 
 <img src="https://github.com/bunkerity/bunkerized-nginx/blob/dev/docs/img/swarm.png?raw=true" />
 
-### Usage
-
 **We will assume that a shared directory is mounted at the /shared location on both your managers and workers. Keep in mind that bunkerized-nginx and autoconf are running as unprivileged users with UID and GID 101. You must set the rights and permissions of the subfolders in /shared accordingly.**
 
 In this setup we will deploy bunkerized-nginx in global mode on all workers and autoconf as a single replica on a manager.
@@ -437,16 +425,12 @@ When your service is not needed anymore, you can delete it as usual. The autocon
 
 ## Kubernetes
 
-### Introduction
-
 **This integration is still in beta, please fill an issue if you find a bug or have an idea on how to improve it.**
 
 Using bunkerized-nginx in a Kubernetes cluster requires a shared folder accessible from the nodes (anything like NFS, GlusterFS, CephFS or even SSHFS will work). The bunkerized-nginx-autoconf acts as an Ingress Controller and connects to the k8s API to get cluster events and generate a new configuration when it's needed. Once the configuration is generated, the Ingress Controller sends a reload order to the bunkerized-nginx instances running in the cluster.
 
 <img src="https://github.com/bunkerity/bunkerized-nginx/blob/dev/docs/img/kubernetes.png?raw=true" />
 
-### Usage
-
 **We will assume that a shared directory is mounted at the /shared location on your nodes. Keep in mind that bunkerized-nginx and autoconf are running as unprivileged users with UID and GID 101. You must set the rights and permissions of the subfolders in /shared accordingly.**
 
 First of all, you will need to setup the shared folders :
@@ -730,8 +714,6 @@ spec:
 
 ## Linux
 
-### Introduction
-
 **This integration is still in beta, please fill an issue if you find a bug or have an idea on how to improve it.**
 
 List of supported Linux distributions :
@@ -742,8 +724,6 @@ List of supported Linux distributions :
 
 Unlike containers, Linux integration can be tedious because bunkerized-nginx has a bunch of dependencies that need to be installed before we can use it. Fortunately, we provide a helper script to make the process easier and automatic. Once installed, the configuration is really simple, all you have to do is to edit the `/opt/bunkerized-nginx/variables.env` configuration file and run the `bunkerized-nginx` command to apply it.
 
-### Usage
-
 First of all you will need to install bunkerized-nginx. The recommended way is to use the official installer script :
 ```shell
 $ curl -fsSL https://TODO -o /tmp/bunkerized-nginx.sh
@@ -775,6 +755,7 @@ Here is the example configuration file that needs to be written at `/opt/bunkeri
 ```conf
 HTTP_PORT=80
 HTTPS_PORT=443
+DNS_RESOLVERS=8.8.8.8 8.8.4.4
 SERVER_NAME=www.example.com
 AUTO_LETS_ENCRYPT=yes
 ```
@@ -783,6 +764,7 @@ Important things to note :
 - Replace www.example.com with your own domain (it must points to your server IP address if you want Let’s Encrypt to work)
 - Automatic Let’s Encrypt is enabled thanks to `AUTO_LETS_ENCRYPT=yes` (since the default is `AUTO_LETS_ENCRYPT=no` you can remove the environment variable to disable Let’s Encrypt)
 - The default values for `HTTP_PORT` and `HTTPS_PORT` are `8080` and `8443` hence the explicit declaration with standard ports values
+- Replace the `DNS_RESOLVERS` value with your own DNS resolver(s) if you need nginx to resolve internal DNS requests (e.g., reverse proxy to an internal service)
 
 You can now apply the configuration by running the **bunkerized-nginx** command :
 ```shell

docs/quickstart_guide.md

@@ -256,6 +256,7 @@ Example of a basic configuration file :
 ```conf
 HTTP_PORT=80
 HTTPS_PORT=443
+DNS_RESOLVERS=8.8.8.8 8.8.4.4
 SERVER_NAME=www.example.com
 AUTO_LETS_ENCRYPT=yes
 USE_REVERSE_PROXY=yes
@@ -491,6 +492,7 @@ Example of a basic configuration file :
 ```conf
 HTTP_PORT=80
 HTTPS_PORT=443
+DNS_RESOLVERS=8.8.8.8 8.8.4.4
 SERVER_NAME=www.example.com
 AUTO_LETS_ENCRYPT=yes
 # Case 1 : the PHP-FPM instance is on the same machine
@@ -502,6 +504,38 @@ LOCAL_PHP_PATH=/opt/bunkerized-nginx/www
 #REMOTE_PHP_PATH=/app
 ```
 
+Don't forget that bunkerized-nginx runs as an unprivileged user/group both named `nginx`. When using a local PHP-FPM instance, you will need to take care of the rights and permissions of the socket and web files.
+
+For example, if your PHP-FPM is running as the `www-data` user, you can create a new group called `web-users` and add `nginx` and `www-data` into it :
+```shell
+$ groupadd web-users
+$ usermod -a -G web-users nginx
+$ usermod -a -G web-users www-data
+```
+
+Once it's done, you will need to tweak your PHP-FPM configuration file (e.g., `/etc/php/7.3/fpm/pool.d/www.conf`) to edit the default group of the processes and the permissions of the socket file :
+```conf
+[www]
+...
+user = www-data
+group = web-users
+...
+listen = /run/php/php7.3-fpm.sock
+listen.owner = www-data
+listen.group = web-users
+listen.mode = 0660
+...
+```
+
+Last but not least, you will need to edit the permissions of `/opt/bunkerized-nginx/www` to make sure that nginx can read and PHP-FPM can write (in case your PHP app needs it) :
+```shell
+$ chown root:web-users /opt/bunkerized-nginx/www
+$ chmod 750 /opt/bunkerized-nginx/www
+$ find /opt/bunkerized-nginx/www/* -exec chown www-data:nginx {} \;
+$ find /opt/bunkerized-nginx/www/* -type f -exec chmod 740 {} \;
+$ find /opt/bunkerized-nginx/www/* -type d -exec chmod 750 {} \;
+```
+
 ## Multisite
 
 If you have multiple services to protect, the easiest way to do it is by enabling the "multisite" mode. When using multisite, bunkerized-nginx will create one server block per server defined in the `SERVER_NAME` environment variable. You can configure each servers independently by adding the server name as a prefix.
@@ -830,6 +864,7 @@ Example of a basic configuration file :
 ```conf
 HTTP_PORT=80
 HTTPS_PORT=443
+DNS_RESOLVERS=8.8.8.8 8.8.4.4
 SERVER_NAME=app1.example.com app2.example.com
 MULTISITE=yes
 AUTO_LETS_ENCRYPT=yes
@@ -847,3 +882,7 @@ app2.example.com_LOCAL_PHP_PATH=/opt/bunkerized-nginx/www/app2.example.com
 #app2.example.com_REMOTE_PHP=myapp.example.local
 #app2.example.com_REMOTE_PHP_PATH=/app
 ```
+
+Don't forget that bunkerized-nginx runs as an unprivileged user/group both named `nginx`. When using a local PHP-FPM instance, you will need to take care of the rights and permissions of the socket and web files.
+
+See the [Linux section of PHP application](#id5) for more information.

tests/Dockerfile-fedora

@@ -9,4 +9,6 @@ rm -f /lib/systemd/system/local-fs.target.wants/*; \
 rm -f /lib/systemd/system/sockets.target.wants/*udev*; \
 rm -f /lib/systemd/system/sockets.target.wants/*initctl*; \
 rm -f /lib/systemd/system/basic.target.wants/*;\
-rm -f /lib/systemd/system/anaconda.target.wants/*;
+rm -f /lib/systemd/system/anaconda.target.wants/*;\
+rm -f /lib/systemd/system/*tmpfiles*;\
+rm -f /lib/systemd/user/*tmpfiles*;\