Merge branch 'master' of sleepmap.de:websites/sleepmap

* 'master' of sleepmap.de:websites/sleepmap:
  content/pages/music/deviser.rst: Escaping backslash in name.
  content/pages/music/deviser.rst: Add empty row.
  content/blog/201610-uwsgi.rst: Adding finished article on nginx + uwsgi on arch linux.
  content/blog/201610-uwsgi.rst: Introduction to uwsgi article added.
  content/blog/201609-letsencrypt.rst: Update the Content-Security-Policy header information after a test showing differing behavior between the services.
  content/blog/201609-letsencrypt.rst: Finished article about letsencrypt with configuration examples and recommendations... what a monster.

3 files changed, 2169 insertions, 9 deletions

diff --git a/content/blog/201609-letsencrypt.rst b/content/blog/201609-letsencrypt.rst
index a4ec1d6..a6d6c61 100644
--- a/content/blog/201609-letsencrypt.rst
+++ b/content/blog/201609-letsencrypt.rst
@@ -1,9 +1,9 @@
 Let's encrypt it all
 ####################
 
-:date: 2016-09-28 20:00
-:modified: 2016-09-29 20:00
-:tags: archlinux, letsencrypt, openssl
+:date: 2016-09-29 20:00
+:modified: 2016-09-30 04:00
+:tags: acme, archlinux, certbot, certificate, dovecot, hidden service, letsencrypt, nginx, openssl, owncloud, postfix, prosody, roundcube, security, ssl, systemd, tls, vpn
 :category: admin
 :slug: lets-encrypt-it-all
 :summary: A short review on half a year of using |website-letsencrypt| for my services.
@@ -12,6 +12,8 @@ Let's encrypt it all
 | For a couple of months now I have been using |website-letsencrypt| to generate free and valid certificates for all the services I run.
 | In many places the free |wiki-certificate_authority| (short CA) has spread like wild-fire. From small to large scale services, many adopted it and |blog-letsencrypt-1_million_certificates|.
 | As a visitor to this website you have probably noticed the small green lock sign next to the address bar. The certificate used for this website is accepted to be valid by your browser (and also by your operating system).
+| If you're up for some background knowledge, just read on. If you're up for some hands-on technical stuff, `jump right on to the howto </2016/lets-encrypt-it-all/#letsencrypt-howto>`_.
+| Just note: This is a veeeeeeery long article in any case.
 |
 
 Certificate Authority
@@ -37,10 +39,10 @@ More Flaws
 | Well... it will come to no surprise: |blog-turktrust_fiasko| and will happen (again).
 | In a way this would also be a perfect time to ask yourself, if encrypted traffic is all that secure after all. A little paranoia never hurt.
 |
-| The certificates with which the CAs sign other certificates and thereby *trust* them are called **root certificates** and are usually shipped by your operating system and/or your web browser. These bundles are used by all applications that understand encrypted traffic to check whether the connection they are about to make is trusted by a CA.
+| The certificates with which the CAs sign other certificates and thereby *trust* them are called *root certificates* and are usually shipped by your operating system and/or your web browser. These bundles are used by all applications that understand encrypted traffic to check whether the connection they are about to make is trusted by a CA.
 | Now, there is no way of telling whether your CA bundle is sufficient or harmful, but at some point you have to trust your operating system. You do trust your operating system, don't you? Well, |news-microsoft_certificate_blacklist|.
 | To circumvent this flaw in turn, Google and Mozilla introduced |wiki-certificate_pinning| in their browsers, which can detect fraudulent certificates for some domains by checking against checksums (derived from a |wiki-hash_function|) of the root certificate with which these domains are signed. These checksums (or sometimes called *hashes*) are shipped with the browser, which should make you wonder, if you can trust those either.
-| If you learned more about how this all works, you would probably consider moving to the woods far away from all this.
+| Sometimes I think, that the more one learns about the topic, the further one wants to move into the woods...
 |
 
 Self-sign
@@ -63,15 +65,603 @@ Encrypt the interwebz
 | While self-signed and |website-cacert| certificates were becoming increasingly limiting and the sometimes high costs of buying a trusted certificate kept many from encrypting their traffic all together, the services *certified* by the usual CAs on the other hand stood in the light of false pretense to be *more secure* than the formerly named.
 | |website-letsencrypt| has indeed come to restore the balance and free what should be free: Encrypted traffic.
 | By issuing |wiki-intermediate_certificate|, which were cross-signed by |website-identrust|, |website-letsencrypt| is able to sign and thereby trust certificates it deems valid according to its |github-letsencrypt| validation system.
+| Their system is fully automated (implementing |wiki-acme|), easy (and in many ways) to use and doesn't suffer from the above mentioned pitfalls of the usual validation process.
 |
 
 Using letsencrypt
 _________________
-| Their software is by now packaged for all major Linux distributions (and as a matter of fact, the Internet runs on Linux), so acquiring a valid certificate for your website has become so easy, it's insane.
+
+|letsencrypt-howto|
+
+| The |website-letsencrypt| software bundle is by now packaged for all major Linux distributions (and as a matter of fact, the Internet runs on Linux), so acquiring a valid certificate for your website has become so easy, it's insane.
 | Let me tell you about how I do things on |website-archlinux| on this very server.
+| Although |website-letsencrypt| lets you freely handle the |wiki-acme| handshake yourself (if you want to do it manually or with |website-letsencrypt_acme_clients|), the community around it wrote a |website-python| based piece of software, that does just that. It's called |website-certbot| .
+| While some may argue its backward-compatibility is just dangerous, one could also argue the other way round: Unsecured webservers, running super old |website-python| versions, because their admins can't or won't update, is very dangerous.
+| In any case: Every sofware has bugs (some more severe than others), but those are also more likely to get fixed faster, the more people stumble upon them.
+| A unifying piece of software such as |website-certbot| is very useful and eases the overall spreading of |website-letsencrypt| .
+| Nonetheless, if you're able to do the |wiki-acme| challenge manually and it makes sense in your scenario, you might want to consider that.
+|
+
+certbot
+-------
+| |website-archlinux| has |website-certbot| in its repositories, so just install the latest version and all of its dependencies:
+
+  .. code:: bash
+
+    pacman -Sy certbot
+
+| Now would be a good time to have a look at |eff-certbot-nginx-howto| about |website-nginx| in conjunction with |website-certbot|.
+| |website-archlinux| of course also has a very |wiki-arch-letsencrypt| on the topic in its wiki.
+| At this point I am assuming |website-nginx| is already installed, configured for non-encrypted service and we want to generate certificates for the following domains: **www.domain.tld**, **domain.tld**, **cloud.domain.tld**, **www.cloud.domain.com**, **mail.domain.tld**, **www.mail.domain.tld** (using |wiki-san|).
+| Currently the certbot plugin for |website-nginx| is still experimental, so I will refrain from using it and use the webroot method instead.
+|
+
+nginx preparation
+-----------------
+| Let us have a look at how to configure |website-nginx|, so it will be prepared for the |wiki-acme| challenge.
+|
+
+Snippets
+++++++++
+
+* we require a directory (*.well-known/acme-challenge/*), that is writable by |website-certbot| (*root*) to place a challenge response on each domain
+* the directory must be servable (readable) by |website-nginx| (usually running with the user and group *http*)
+
+| As the directory can be the same for all the challenges on your server, you can of course just create one and redirect all requests from the outside to it. We will use */srv/http/letsencrypt/* for it and define a configuration block, that we can include anywhere we need it.
+|
+
+* */etc/nginx/letsencrypt-challenge.conf*
+
+  .. code:: nginx
+
+		location ~ /\.well-known/acme-challenge {
+		  root /srv/http/letsencrypt;
+		  default_type "text/plain";
+		}
+
+| This will tell nginx to look inside of */srv/http/letsencrypt* for requests to *./well-known/acme-challenge* on a domain, where we include this.
+|
+| The following short example is an overview of */etc/nginx/nginx.conf*. Yours might look different and this one is here for demonstrational purposes only!
+| Anyhow, I like to separately include the configuration for the different subdomains/domains here, so they will not get mixed up and it will be easier to add or disable functionality.
+|
+
+* */etc/nginx/nginx.conf*
+
+  .. code:: nginx
+
+    worker_processes auto;
+    error_log /var/log/nginx/error.log;
+    events {
+      worker_connections 1024;
+    }
+    http {
+      include mime.types;
+      default_type application/octet-stream;
+      gzip on;
+      sendfile on;
+      keepalive_requests 55;
+      keepalive_timeout 55;
+      # pelican blog
+      include domain.conf;
+      # ownCloud
+      include cloud.domain.conf;
+      # roundcube mail interface available only through VPN
+      include mail.domain.conf;
+    }
+
+| The initial configuration already shows, that we now have three services that will need to be covered by the certificate, which we want to get. The |website-roundcube| webmail service I picked for demonstrational purposes as a hidden service. This is not meant to badmouth their security, but to show that you can hide your service behind a :abbr:`VPN (Virtual Private Network)`, if you choose to.
+| To achieve something like that, you can use the |website-nginx| geo plugin. When you setup a VPN infrastructure, this will lead to you having a separate connection to your server within a |wiki-private_network|. For the sake of simplicity let us assume your server will have **172.16.0.1** and your client computer **172.16.0.2** as IPs in this setup.
+| On your server you can now explicitely look for the correct client and allow or deny access. Another block for the |website-nginx| configuration can be used to let you include this in your domain configurations:
+|
+
+* */etc/nginx/geoblock.conf*
+
+  .. code:: nginx
+
+   geo $is_allowed{
+     default 0;
+     172.16.0.2 1;
+   }
+
+| Here we define a variable called *is_allowed*, which initially defaults to 0. If the request to your server is coming from the IP **172.16.0.2** *is_allowed* will be set to 1.
+| **Note**: Add this snippet to your hidden service's configuration file right at the top!
+|
+| There is one downside to this though, if you choose to have a |website-letsencrypt| certificate for the hidden service: You have to specify an extra check, that excludes calls to *.well-known/acme-challenge* from the geo block and makes it publicly accessible.
+| For that to happen you can define another block for multiple inclusion.
+|
+
+* */etc/nginx/letsencrypt-request-check.conf*
+
+  .. code:: nginx
+
+    if ($request_uri ~ \.well-known/acme-challenge) {
+      set $is_allowed 1;
+    }
+    if ($is_allowed = 0){
+      return 301 https://domain.tld$request_uri;
+    }
+
+| This snippet will set the previously introduced variable *is_allowed* to 1, if the request was correct and will permanently redirect to the main website otherwise.
+| As it makes sense to have https enabled on all of your services, the permanent redirect is added to this configuration snippet. You could also separate it out if you like.
+| **Note**: You must include *letsencrypt-request-check.conf* **after** *geoblock.conf*, but **before** *letsencrypt-challenge.conf*!
+|
+| You will have to include the above snippets in your configuration for each of your subdomains/domains and make sure that */srv/http/letsencrypt/* has sufficient permissions.
+| This will roughly look as follows:
+|
+
+* */etc/nginx/domain.conf* & */etc/nginx/cloud.domain.conf*
+
+  .. code:: nginx
+
+    server {
+      listen  80;
+      listen [::]:80;
+      # ...
+      include letsencrypt-challenge.conf;
+      # ...
+    }
+
+|
+
+* */etc/nginx/mail.domain.conf*
+
+  .. code:: nginx
+
+    include geoblock.conf;
+    server {
+      listen  80;
+      listen [::]:80;
+      # ...
+      include letsencrypt-request-check.conf;
+      include letsencrypt-challenge.conf;
+      # ...
+    }
+
+|
+
+certbot staging
++++++++++++++++
+| |website-certbot| has a mode called *staging* that basically gets a *"test certificate"* for you, so you can try if everything is working as expected. Sounds safe? Let's do it (as root or with sudo)!
+
+  .. code:: bash
+
+     certbot certonly \
+       --staging \
+       --agree-tos \
+       --renew-by-default \
+       --email valid@domain.tld \
+       --webroot -w /srv/http/letsencrypt \
+         -d domain.tld \
+         -d www.domain.tld \
+         -d cloud.domain.tld \
+         -d www.cloud.domain.tld \
+         -d mail.domain.tld \
+         -d www.mail.domain.tld
+
+| All domains are defined seprately using the *-d* flag. The above command will give you an error, if something goes wrong and that usually is quite explicit.
+| **Note**: It is very important to test your setup with the staging environment first, because the production environment is rate-limited (and half-baked certs will not do you any good).
+| If everything went right, you will now have an intermediate certificate, that in itself is still useless.
+| Let's go for the real deal then, shall we?
+
+  .. code:: bash
+
+     certbot certonly \
+       --agree-tos \
+       --renew-by-default \
+       --email valid@domain.tld \
+       --webroot -w /srv/http/letsencrypt \
+         -d domain.tld \
+         -d www.domain.tld \
+         -d cloud.domain.tld \
+         -d www.cloud.domain.tld \
+         -d mail.domain.tld \
+         -d www.mail.domain.tld
+
+| This should return a success message, with the note, that your certificate has been saved to */etc/letsencrypt/live/domain.tld/fullchain.pem* and until when that certificate is valid.
+| Congratulations! You just generated a signed certificate, that is valid for the above domains and is recognized by operating systems and browsers!
+|
+
+
+Production
+----------
+| Before we can include the certificate in the |website-nginx| configuration for each domain though, it is time to think about proper |wiki-ssl_tls| settings (|wiki-cipher_suite|, |wiki-ssl_protocols|, |wiki-dh_params|) and security headers (|mozilla-content_security_policy|, |mozilla-cross_origin_resource_sharing|, |mozilla-http_strict_transport_security|, |mozilla-x_content_type_options|, |mozilla-x_frame_options|, |mozilla-x_xss_protection|).
+| Luckily, already a lot of other people have thought about these issues and provided their expertise. Just look at |github-nginx_config|, |blog-ssl_security_on_nginx| or at the |mozilla-ssl_config_generator|.
+|
+
+moar snippets
++++++++++++++
+| To include safe settings for |website-nginx| in all domain configurations, we will create some more snippets and will be happy about this form of reusability!
+|
+
+* */etc/nginx/tls.conf*
+
+  .. code:: nginx
+
+    ssl_certificate /etc/letsencrypt/live/domain.tld/fullchain.pem;
+    ssl_certificate_key /etc/letsencrypt/live/domain.tld/privkey.pem;
+    ssl_session_cache shared:SSL:50m;
+    ssl_session_timeout 1d;
+    ssl_session_tickets off;
+    ssl_dhparam /etc/nginx/dhparam.pem;
+    ssl_protocols TLSv1.2;
+    ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
+    ssl_prefer_server_ciphers on;
+    ssl_stapling on;
+    ssl_stapling_verify on;
+    ssl_trusted_certificate /etc/letsencrypt/live/domain.tld/fullchain.pem;
+    resolver 8.8.8.8;
+
+| **Note**: I chose a very modern approach towards **ssl_protocols** by enabling only *TLSv1.2* at this point. Depending on your clients, you might want to use *'TLSv1 TLSv1.1 TLSv1.2'* instead.
+| To generate the needed *dhparam.pem* (2048 bits recommended) we can use |website-openssl| as root:
+
+  .. code:: bash
+
+    openssl dhparam -out /etc/nginx/dhparam.pem 2048	
+
+* */etc/nginx/security_headers.conf*
+
+  .. code:: nginx
+
+    add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;";
+    add_header X-Content-Type-Options nosniff;
+    add_header X-Frame-Options "SAMEORIGIN";
+    add_header X-XSS-Protection "1; mode=block";
+    add_header X-Robots-Tag "none";
+
+| A little note on the **Content-Security-Policy** here: Usually one would try to have the targets (**default-src**, **connect-src**, **img-src**, **script-src**, **style-src**) be set to *'self'*. Due to the inline :abbr:`CSS (Cascading Style Sheets)` and Javascript in services such as |website-owncloud| and |website-roundcube|, this is not possible though, so *'unsafe_inline'* and *'unsafe_eval'* have to be added as well for some of them.
+| At this point you could of course also choose to create differing *'security_headers'* inclusions for the services you run.
+| Depending on which are running, you will want to monitor your developer console in your browser closely after using this security header. It will tell you, if CFP is blocking some resource (and possibly making it unusable).
+
+domain configurations
++++++++++++++++++++++
+
+| Following are the three different configurations for the services (I won't go into detail about |readthedocs-uwsgi| here, but in a coming article I will).
+
+* */etc/nginx/domain.conf*:
+
+  .. code:: nginx
+
+    # redirect all unencrypted traffic to https
+    server {
+      listen 80 default_server;
+      server_name domain.tld www.domain.tld;
+      return 301 https://domain.tld$request_uri;
+    }
+
+    # redirect all traffic to www. to the plain url
+    server {
+      listen 443 ssl;
+      listen [::]:443 ssl;
+      server_name www.domain.tld;
+      return 301 https://domain.tld$request_uri;
+    }
+
+    server {
+      listen 443 default_server;
+      listen [::]:443 ssl default_server;
+      server_name domain.tld;
+      include tls.conf;
+      # your pelican blog resides here
+      root /srv/http/websites/domain.tld;
+      # make sure to log
+      access_log /var/log/nginx/access.domain.log;
+      error_log /var/log/nginx/error.domain.log;
+      error_page 403 404 /404/index.html;
+      error_page 500 502 503 504  /50x.html;
+      # include security headers
+      include security_headers.conf;
+      add_header Content-Security-Policy "default-src 'self'; connect-src 'self'; img-src 'self'; script-src 'self'; style-src 'self'";
+      # include the letsencrypt snippet
+      include letsencrypt-challenge.conf;
+
+      location / {
+        index index.html index.htm;
+        try_files $uri $uri/ $uri/index.html;
+      }
+
+      location = /robots.txt {
+        allow all;
+        log_not_found off;
+        access_log off;
+      }
+
+      location = /50x.html {
+        root /usr/share/nginx/html;
+      }
+    }
+
+|
+
+* */etc/nginx/cloud.domain.conf*
+
+  .. code:: nginx
+
+    # redirect all unencrypted traffic to https
+    server {
+      listen 80;
+      listen [::]:80;
+      server_name cloud.domain.tld www.cloud.domain.tld;
+      return 301 https://cloud.domain.tld$request_uri;
+    }
+
+    # redirect www. to the plain domain
+    server {
+      listen 443 ssl;
+      listen [::]:443 ssl;
+      server_name www.cloud.domain.tld;
+      return 301 https://cloud.domain.tld$request_uri;
+    }
+
+    server {
+      listen 443 ssl;
+      listen [::]:443 ssl;
+      server_name cloud.domain.tld;
+      include tls.conf;
+      error_page 403 /core/templates/403.php;
+      error_page 404 /core/templates/404.php;
+      # make sure to log
+      access_log /var/log/nginx/access.cloud.domain.log;
+      error_log /var/log/nginx/error.cloud.domain.log;
+      #this is to avoid Request Entity Too Large error
+      client_max_body_size 10G;
+      # include security headers (the rest are set by ownCloud itself already)
+      add_header Content-Security-Policy "default-src 'self'; connect-src 'self'; img-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline' 'unsafe-eval'";
+      add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;";
+      # include the letsencrypt snippet
+      include letsencrypt-challenge.conf;
+
+      location = /robots.txt {
+        allow all;
+        log_not_found off;
+        access_log off;
+      }
+
+      location ~ ^/(?:\.htaccess|data|config|db_structure\.xml|README) {
+        deny all;
+        log_not_found off;
+        access_log off;
+      }
+
+      location ~ ^(.+\.php)(.*)$ {
+        include uwsgi_params;
+        uwsgi_modifier1 14;
+        uwsgi_pass unix:/run/uwsgi/owncloud.sock;
+        uwsgi_intercept_errors on;
+      }
+
+      location / {
+        root /usr/share/webapps/owncloud;
+        index index.php;
+        rewrite ^/.well-known/host-meta /public.php?service=host-meta last;
+        rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json last;
+        rewrite ^/.well-known/carddav /remote.php/dav/ redirect;
+        rewrite ^/.well-known/caldav /remote.php/dav/ redirect;
+        rewrite ^(/core/doc/[^\/]+/)$ $1/index.html;
+        rewrite ^/caldav(.*)$ /remote.php/dav$1 redirect;
+        rewrite ^/carddav(.*)$ /remote.php/dav$1 redirect;
+        rewrite ^/webdav(.*)$ /remote.php/dav$1 redirect;
+        try_files $uri $uri/ /index.php;
+      }
+
+      location ~ ^/.(?:jpg|jpeg|gif|bmp|ico|png|css|js|swf)$ {
+        expires 30d;
+        access_log off;
+      }
+    }
+
+|
+
+* */etc/nginx/mail.domain.conf*
+
+  .. code:: nginx
+
+    # include the geoblock snippet
+    include geoblock.conf;
+
+    # redirect all unencrypted traffic to https
+    server {
+      listen 80;
+      listen [::]:80;
+      server_name mail.domain.tld www.mail.domain.tld;
+      return 301 https://mail.domain.tld$request_uri;
+    }
+
+    # redirect www. to the plain domain
+    server {
+      listen 443;
+      listen [::]:443 ssl;
+      server_name www.mail.domain.tld;
+      return 301 https://mail.domain.tld$request_uri;
+    }
+    server {
+      listen 443 ssl;
+      listen [::]:443 ssl;
+      server_name mail.domain.tld;
+      include tls.conf;
+      # make sure to log
+      access_log /var/log/nginx/access.mail.domain.log;
+      error_log /var/log/nginx/error.mail.domain.log;
+      root /usr/share/webapps/roundcubemail;
+      #this is to avoid Request Entity Too Large error
+      client_max_body_size 20M;
+      # include security headers
+      include security_headers.conf;
+      add_header Content-Security-Policy "default-src 'self'; connect-src 'self'; img-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'";
+      # include the request-check snippet
+      include letsencrypt-challenge.conf;
+      # include the letsencrypt snippet
+      include letsencrypt-challenge.conf;
+
+      location / {
+        index index.php;
+        try_files $uri $uri/$args @roundcubemail;
+      }
+
+      location @roundcubemail {
+        include uwsgi_params;
+        uwsgi_modifier1 14;
+        uwsgi_pass unix:/run/uwsgi/roundcubemail.sock;
+      }
+
+      location ~ ^/favicon.ico$ {
+        root /usr/share/webapps/roundcubemail/skins/classic/images;
+        log_not_found off;
+        access_log off;
+        expires max;
+      }
+
+      location = /robots.txt {
+        allow all;
+        log_not_found off;
+        access_log off;
+        expires 30d;
+      }
+
+      # Deny serving some files
+      location ~ ^/(composer\.json-dist|composer\.json|package\.xml|CHANGELOG|INSTALL|LICENSE|README\.md|UPGRADING|bin|config|installer|program\/(include|lib|localization|steps)|SQL|tests)$ {
+        deny all;
+      }
+
+      # Deny serving files beginning with a dot, but allow letsencrypt acme-challenge
+      location ~ /\.(?!well-known/acme-challenge) {
+        deny all;
+        access_log off;
+        log_not_found off;
+      }
+    }
+
+| As you can see here, you have to exclude *.well-known/acme-challenge/* from denying access to all directories beginning with a dot.
+|
+
+Bringing it up
+++++++++++++++
+You should now check your |website-nginx| configuration (as root):
+
+  .. code:: bash
+
+    nginx -t
+
+| This should tell you if something is wrong. Make sure to fix all problems, else |website-nginx| will not come back up after restarting it!
+| If all is well, restart the web server (as root):
+
+  .. code:: bash
+
+    systemctl restart nginx
+
+| Et voila! Your website should now serve over https!
+| You might want to use the |website-mozilla_observatory| now to scan for issues in your setup and to optimize it.
 |
+
+Postfix
++++++++
+Your mail server can also use this certificate now (if your |wiki-mx_record| points to one of the domains the certificate was issued for).
+
+* */etc/postfix/main.cf*
+
+  .. code:: ini
+
+    smtpd_tls_cert_file = /etc/letsencrypt/live/domain.tld/fullchain.pem
+    smtpd_tls_key_file = /etc/letsencrypt/live/domain.tld/privkey.pem
+
+Dovecot
++++++++
+The same counts for your :abbr:`IMAP (Internet Message Access Protocol)` server:
+
+* */etc/dovecot/dovecot.conf*
+
+  .. code:: ini
+
+    ssl_cert = </etc/letsencrypt/live/domain.tld/fullchain.pem
+    ssl_key = </etc/letsencrypt/live/domain.tld/privkey.pem
+
+Prosody
++++++++
+| The :abbr:`XMPP (Extensible Messaging and Presence Protocol)`/Jabber server is unfortunately not able to directly access the data in */etc/letsencrypt/live/domain.tld*, because it runs as its own user (*prosody*).
+| You can work around this issue by either changing many permissions, or copy the set of files over to */etc/prosody/certs/* and set these up in your configuration.
+| I recommend the latter, as otherwise you will have to change many file and directory permissions, that are seemingly handled by |website-certbot| and thus lower the overall security of your system.
 |
 
+* */etc/prosody/prosody.cfg.lua*
+
+  .. code:: lua
+
+    ssl = {
+      certificate = "/etc/prosody/certs/fullchain.pem";
+      key = "/etc/prosody/certs/privkey.pem";
+    }
+
+Renewal
+-------
+| During the creation of the certificate you might have already seen, that it is only valid for 90 days. This is ultimately not a bad thing, as now you will have a very easy time renewing it.
+| When using |website-certbot| for the first time to create your real certificate, it automatically saved a configuration file for your domain under */etc/letsencrypt/renewal/domain.tld.conf*.
+| This is a perfect time for testing it (as root):
+
+  .. code:: bash
+
+    certbot renew --dry-run
+
+| Did everything run smoothly? Great! You can now have |website-certbot| renew your certificate, once it is due.
+| |website-eff| recommends running the renewal twice daily for the chance to stay online in case |website-letsencrypt| has to revoce its root certificate for some reason (let us hope that won't happen...).
+| On |website-archlinux| a |website-systemd| service and timer would be the way to do it.
+|
+
+* */etc/systemd/system/certbot.service*
+
+  .. code:: ini
+
+    [Unit]
+    Description=Let's Encrypt renewal
+
+    [Service]
+    Type=oneshot
+    ExecStart=/usr/bin/certbot renew --quiet --agree-tos
+    ExecStartPost=/usr/bin/cp --remove-destination /etc/letsencrypt/live/domain.tld/fullchain.pem /etc/letsencrypt/live/domain.tld/privkey.pem /etc/prosody/certs/
+    ExecStartPost=/usr/bin/chown prosody /etc/prosody/certs/fullchain.pem ; /usr/bin/chown prosody /etc/prosody/certs/privkey.pem ; /usr/bin/chmod u-w,g-r,o-r /etc/prosody/certs/privkey.pem
+    StandardError=syslog
+    NotifyAccess=all
+    KillSignal=SIGQUIT
+    PrivateDevices=yes
+    PrivateTmp=yes
+    ProtectSystem=full
+    ReadWriteDirectories=/etc/letsencrypt /etc/prosody/certs
+    ProtectHome=yes
+    NoNewPrivileges=yes
+
+| **Note**: If not using |website-prosody| it's safe to remove */etc/prosody/certs* from the **ReadWriteDirectories** directive and get rid of the **ExecStartPost** directives all together. They are there for providing |website-prosody| with the certificate in a safe manner.
+|
+
+* */etc/systemd/system/certbot.timer*
+
+  .. code:: ini
+
+    [Unit]
+    Description=Daily renewal of Let's Encrypt's certificates
+
+    [Timer]
+    OnCalendar=daily
+    RandomizedDelaySec=1day
+    Persistent=true
+
+    [Install]
+    WantedBy=timers.target
+
+| The above timer will start the renewal process daily with a random time offset.
+| You can now easily start the service (as root):
+
+  .. code:: bash
+
+    systemctl start certbot
+
+| Enable and start its timer:
+
+  .. code:: bash
+
+    systemctl enable certbot.timer
+    systemctl start certbot.timer
+
+| Enjoy your encrypted services!
+
+
 .. |blog-letsencrypt-1_million_certificates| raw:: html
 
   <a href="https://letsencrypt.org/2016/03/08/our-millionth-cert.html" target="_blank">the amount of issued certificates has grown over 1 million in just four months</a>
@@ -168,3 +758,123 @@ _________________
 
   <a href="https://archlinux.org" target="_blank">Arch Linux</a>
 
+.. |wiki-acme| raw:: html
+
+  <a href="https://en.wikipedia.org/wiki/Automated_Certificate_Management_Environment" target="_blank">ACME</a>
+
+.. |website-python| raw:: html
+
+  <a href="https://www.python.org/" target="_blank">Python</a>
+
+.. |website-certbot| raw:: html
+
+  <a href="https://certbot.eff.org/" target="_blank">certbot</a>
+
+.. |eff-certbot-nginx-howto| raw:: html
+
+  <a href="https://certbot.eff.org/#arch-nginx" target="_blank">what the EFF has to tell you</a>
+
+.. |wiki-arch-letsencrypt| raw:: html
+
+  <a href="https://wiki.archlinux.org/index.php/Certbot" target="_blank">useful article</a>
+
+.. |website-nginx| raw:: html
+
+  <a href="https://www.nginx.org/" target="_blank">nginx</a>
+
+.. |letsencrypt-howto| raw:: html
+
+  <a name="letsencrypt-howto"></a>
+
+.. |website-roundcube| raw:: html
+
+  <a href="https://roundcube.net/" target="_blank">roundcube</a>
+
+.. |readthedocs-uwsgi| raw:: html
+
+  <a href="https://uwsgi-docs.readthedocs.io/en/latest/" target="_blank">uWSGI</a>
+
+.. |wiki-private_network| raw:: html
+
+  <a href="https://en.wikipedia.org/wiki/Private_network#Private_IPv4_address_spaces" target="_blank">private network</a>
+
+.. |website-letsencrypt_acme_clients| raw:: html
+
+  <a href="https://letsencrypt.org/docs/client-options/" target="_blank">another client</a>
+
+.. |wiki-san| raw:: html
+
+  <a href="https://en.wikipedia.org/wiki/Subject_Alternative_Name" target="_blank">Subject Alternative Name (SAN)</a>
+
+.. |wiki-cipher_suite| raw:: html
+
+  <a href="https://en.wikipedia.org/wiki/Cipher_suite" target="_blank">cipher suite</a>
+
+.. |wiki-ssl_protocols| raw:: html
+
+  <a href="https://en.wikipedia.org/wiki/Transport_Layer_Security#History_and_development" target="_blank">protocols</a>
+
+.. |wiki-dh_params| raw:: html
+
+  <a href="https://en.wikipedia.org/wiki/Diffie-Hellman_key_exchange" target="_blank">Diffie-Hellman key exchange</a>
+
+.. |wiki-ssl_tls| raw:: html
+
+  <a href="https://en.wikipedia.org/wiki/Transport_Layer_Security" target="_blank">SSL/TLS</a>
+
+.. |mozilla-content_security_policy| raw:: html
+
+  <a href="https://wiki.mozilla.org/Security/Guidelines/Web_Security#Content_Security_Policy" target="_blank">Content Security Policy (CSP)</a>
+
+.. |mozilla-cross_origin_resource_sharing| raw:: html
+
+  <a href="https://wiki.mozilla.org/Security/Guidelines/Web_Security#Cross-origin_Resource_Sharing" target="_blank">Cross-origin Resources Sharing (CORS)</a>
+
+.. |mozilla-http_strict_transport_security| raw:: html
+
+  <a href="https://wiki.mozilla.org/Security/Guidelines/Web_Security#HTTP_Strict_Transport_Security" target="_blank">HTTP Strict Transport Security (HSTS)</a>
+
+.. |mozilla-x_content_type_options| raw:: html
+
+  <a href="https://wiki.mozilla.org/Security/Guidelines/Web_Security#X-Content-Type-Options" target="_blank">X-Content-Type-Options</a>
+
+.. |mozilla-x_frame_options| raw:: html
+
+  <a href="https://wiki.mozilla.org/Security/Guidelines/Web_Security#X-Frame-Options" target="_blank">X-Frame-Options (XFO)</a>
+
+.. |mozilla-x_xss_protection| raw:: html
+
+  <a href="https://wiki.mozilla.org/Security/Guidelines/Web_Security#X-XSS-Protection" target="_blank">X-XSS-Protection</a>
+
+.. |github-nginx_config| raw:: html
+
+  <a href="https://gist.github.com/plentz/6737338" target="_blank">this</a>
+
+.. |blog-ssl_security_on_nginx| raw:: html
+
+  <a href="https://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx.html" target="_blank">this</a>
+
+.. |mozilla-ssl_config_generator| raw:: html
+
+  <a href="https://mozilla.github.io/server-side-tls/ssl-config-generator/" target="_blank">Mozilla's SSL config generator for web servers</a>
+
+.. |website-owncloud| raw:: html
+
+  <a href="https://owncloud.org" target="_blank">ownCloud</a>
+
+.. |website-mozilla_observatory| raw:: html
+
+  <a href="https://observatory.mozilla.org" target="_blank">Mozilla Observatory</a>
+
+.. |wiki-mx_record| raw:: html
+
+  <a href="https://en.wikipedia.org/wiki/MX_record" target="_blank">MX record</a>
+
+.. |website-systemd| raw:: html
+
+  <a href="https://www.freedesktop.org/wiki/Software/systemd/" target="_blank">systemd</a>
+
+.. |website-prosody| raw:: html
+
+  <a href="https://prosody.im" target="_blank">prosody</a>
+
diff --git a/content/blog/201610-uwsgi.rst b/content/blog/201610-uwsgi.rst
new file mode 100644
index 0000000..a2e0d26
--- /dev/null
+++ b/content/blog/201610-uwsgi.rst
@@ -0,0 +1,1449 @@
+Securely serving webapps using uWSGI
+####################################
+
+:date: 2016-10-08 09:00
+:modified: 2016-10-08 05:00
+:tags: application server, archlinux, cgit, mediawiki, nginx, owncloud, php, python, redis, roundcube, security, sockets, systemd, uwsgi, webapps, wordpress
+:category: admin
+:slug: securely-serving-webapps-using-uwsgi
+:summary: An introductory on securely and dynamically serving many webapps with the help of |website-nginx| and |website-uwsgi| with |website-systemd| on |website-archlinux|
+:authors: David Runge
+
+| Ever since I have been running my own |website-archlinux| box to serve my services, I used |website-nginx| in conjunction with |website-uwsgi|.
+| So instead of using |website-php-fpm| and be limited to just |website-php|, I can use a single application server to do all of them (|wiki-cgi|, |website-python|, |website-php| and even the stuff I don't use, such as |website-ruby|, |website-mono|, |website-java|, |website-lua|, |website-perl|, |website-webdav|). They are all separately installable as plugins.
+| Static sites, such as this, default to being served by |website-nginx| directly of course.
+| Over time I found |website-uwsgi| to be a very versatile and powerful piece of software that has many advantages (over e.g. |website-apache|):
+
+* socket activation
+* webapp encapsulation and jailing
+* self-healing
+* being able to separetely manage services
+* exit after idle
+
+| I'll explain the services I use (|website-mantisbt|, |website-roundcube|, |website-owncloud|, |website-mailman|, |website-stikked|, |website-wordpress|, |website-postfixadmin|, |website-phpmyadmin|, |website-cgit|, |website-mediawiki|, |website-etherpad| ) along with configuration examples and their possible pitfalls.
+| In my last post about `Let's Encrypt <../2016/lets-encrypt-it-all>`_ I already showed some examples on how to configure |website-nginx| for the use with |website-uwsgi|. Let's jump right in.
+|
+
+Preparing nginx
+_______________
+
+| |website-nginx| can serve dynamic websites only indirectly, because it is a web server for static content (|wiki-html|, |wiki-css|, |wiki-javascript|, images, videos, compressed files, etc.), unlike |website-apache|, which uses plugins to take care of many scripting languages (|website-php| and the like).
+| In combination with |website-uwsgi| you are able to direct calls to dynamic content to something that handles those best: an application server. Meanwhile |website-nginx| will keep on serving the remaining static content.
+| This form of encapsulation has some noticeable security advantages, as every webapp is handled by a separate instance of that application server (and not your web server, which is less likely to blow up in your face because of security flaws in the used scripting language), and that in turn is only accessible through your web server.
+| Obviously this also makes it possible to use |website-nginx| as a |wiki-load_balancing| and |wiki-proxy_server|, as you can have one machine serve your domains and just redirect the traffic to other machines plainly serving the webapps.
+| I will keep to examples using a single machine (for brevity).
+|
+| |website-nginx| ships with */etc/nginx/uwsgi_params* holding a set of parameters for the application server, that are set to some of the web server's internally used variables.
+| |website-uwsgi| uses a list of modifiers, that are explained in more detail in the list of |doc-uwsgi_packet_descriptions| and of which some correspond to the usage of certain script languages.
+| When redirecting to a webapp |website-nginx| uses *uwsgi_pass* in conjunction with the *uwsgi_modifier1* stating the type of application:
+
+  .. code:: nginx
+
+     include uwsgi_params;
+     uwsgi_modifier1 14;
+     uwsgi_pass unix:/run/uwsgi/mywebapp.sock;
+
+|
+
+Hardening uWSGI
+_______________
+| |website-uwsgi| is quite a complex piece of software, but fortunately has a pretty well documented feature set and code base.
+| The way it is used in a |website-systemd| context on |website-archlinux| can be improved though (and will hopefully in the future).
+| I'm currently only using socket activation for my webapps (not in |doc-uwsgi_emperor_mode|), so all examples will be about how to set that up correctly.
+| Following are the current service and socket file shipped with the package in the |website-arch_community_repo|.
+
+* */usr/lib/systemd/system/uwsgi-secure@.service*
+
+  .. code:: ini
+
+    [Unit]
+    Description=uWSGI service unit
+    After=syslog.target
+
+    [Service]
+    ExecStart=/usr/bin/uwsgi --ini /etc/uwsgi/%I.ini
+    ExecReload=/bin/kill -HUP $MAINPID
+    ExecStop=/bin/kill -INT $MAINPID
+    Restart=always
+    Type=notify
+    StandardError=syslog
+    NotifyAccess=all
+    KillSignal=SIGQUIT
+
+    [Install]
+    WantedBy=multi-user.target
+
+|
+
+* */usr/lib/systemd/system/uwsgi-secure@.socket*
+
+  .. code:: ini
+
+    [Unit]
+    Description=Socket for uWSGI %I
+
+    [Socket]
+    # Change this to your uwsgi application port or unix socket location
+    ListenStream=/run/uwsgi/%I.sock
+
+    [Install]
+    WantedBy=sockets.target
+
+| As the *@* in the service/socket files already suggest: You start them using a configuration file (to be found in */etc/uwsgi/*) name as parameter, similar to:
+
+  .. code:: bash
+
+    systemctl start uwsgi-secure@mywebapp
+
+| When using socket activation, you would do
+
+  .. code:: bash
+
+    systemctl start uwsgi-secure@mywebapp.socket
+
+| which will then start the *uwsgi@mywebapp.service* automatically, once the socket is accessed by your web server.
+| Starting your webapp in this context generally means, using a configuration file for uwsgi, found in */etc/uwsgi/mywebapp.ini*.
+| Let's pretend that *mywebapp* is a |website-PHP| application. This is an abbreviated example of how your configuration might look like:
+
+* */etc/uwsgi/mywebapp.ini*
+
+  .. code:: ini
+
+    [uwsgi]
+    # name the process
+    procname-master = mywebapp
+    # define the plugin
+    plugins = php
+    # define a master process for this app
+    master = true
+    # this is where the socket resides 
+    socket = /run/uwsgi/%n.sock
+    # we want to use this user and group (or any other)
+    uid = http
+    gid = http
+    # give this application a maximum of 10 processes
+    processes = 10
+
+    # dynamic scaling
+    # minimum amount of workers/processes to keep at all times
+    cheaper = 2
+    # increase workers/processes by step
+    cheaper-step = 1
+
+    # mark as idle after 10 minutes
+    idle = 600
+    # kill the webapp when it is idle
+    die-on-idle = true
+
+    # allow no other extenseion than .php
+    php-allowed-ext = .php
+    # fix our application in this directory
+    php-docroot = /usr/share/webapps/mywebapp
+    # set the standard index
+    php-index = index.php
+    php-set = date.timezone=Europe/Berlin
+    # the application needs access to the following directories
+    php-set = open_basedir=/tmp/:/usr/share/webapps/mywebapp:/etc/webapps/mywebapp
+    # this is where we save our sessions
+    php-set = session.save_path=/tmp
+
+    # mywebapp needs the following PHP extensions
+    php-set = extension=curl.so
+    php-set = extension=gd.so
+    php-set = extension=imagick.so
+    php-set = extension=intl.so
+    php-set = extension=mysqli.so
+    php-set = extension=pdo_mysql.so
+
+| As you can see: You can (and should) setup your own |website-php| environment for your webapp. All settings will only be available to that specific app (alongside global settings found in */etc/php/php.ini*, */etc/php/conf.d/*).
+| My suggestion is to disable all system-wide |website-php| settings and then start to build settings for all your applications. This is much safer, than e.g. an extensive *open_basedir* for all applications. On top: Many applications will not need all the extensions enabled, so just enable the ones they need!
+|
+| You probably also noticed the *idle* and *die-on-idle* settings here. This will make |website-uwsgi| exit itself, when it is not needed after a given time. This feature will not work with the provided service files however, because |website-systemd| will restart the service automatically (given the above service files). Once |website-uwsgi| is running, it might exit, but will start again immediately, which is not a resource gentle approach at all.
+| The application server provides a non-zero, non-one exit code upon exiting by itself. To |website-systemd| this by default means *failure* though. So, how do we fix that and what kind of exit codes does |website-uwsgi| actually give?
+| To find out about that, let's dig into *uwsgi.h* in the |website-uwsgi| source code (at the time of writing version *2.0.14*), where we will find the following:
+
+* *uwsgi-2.0.14/uwsgi.h*
+
+  .. code:: c
+
+    #define UWSGI_RELOAD_CODE 17
+    #define UWSGI_END_CODE 30
+    #define UWSGI_EXILE_CODE 26
+    #define UWSGI_FAILED_APP_CODE 22
+    #define UWSGI_DE_HIJACKED_CODE 173
+    #define UWSGI_EXCEPTION_CODE 5
+    #define UWSGI_QUIET_CODE 29
+    #define UWSGI_BRUTAL_RELOAD_CODE 31
+    #define UWSGI_GO_CHEAP_CODE 15
+
+| As you can see, we have exit code *15*, *17*, *29* and *30* reserved for non-failing exits, while *26* is used in |doc-uwsgi_emperor_mode| and *22*, *5*, *173*, *31* are used for failed exits or even worse.
+| |website-systemd| however treats every non-zero exit code in its services as a failure and therefore would not start the service again, once it killed itself and was started by socket activation again afterwards.
+| Luckily, the many configuration possibilities of service files come to help. Here is what I came up with (with added hardening):
+
+* */etc/systemd/system/uwsgi-private@.service*
+
+  .. code:: ini
+
+    [Unit]
+    Description=uWSGI service unit
+    After=syslog.target
+
+    [Service]
+    ExecStart=/usr/bin/uwsgi --ini /etc/uwsgi/%I.ini
+    Type=notify
+    SuccessExitStatus=15 17 29 30
+    StandardError=syslog
+    NotifyAccess=all
+    KillSignal=SIGQUIT
+    PrivateDevices=yes
+    PrivateTmp=yes
+    ProtectSystem=full
+    ReadWriteDirectories=/etc/webapps /var/lib/
+    ProtectHome=yes
+    NoNewPrivileges=yes
+
+    [Install]
+    WantedBy=multi-user.target
+
+|
+
+* */etc/systemd/system/uwsgi-private@.service*
+
+  .. code:: ini
+
+    [Unit]
+    Description=Socket for uWSGI %I
+
+    [Socket]
+    # Change this to your uwsgi application port or unix socket location
+    ListenStream=/run/uwsgi/%I.sock
+
+    [Install]
+    WantedBy=sockets.target
+
+| While the socket file is just a copy of the original, I have tweaked the service.
+| This way the above mentioned exit codes are treated as success, instead of failure by |website-systemd| and each |website-uwsgi| instance will get its own private temporary directory below */tmp/*.
+| Additionally, the */home*, */root* and */run/user* directories appear empty and system directories, such as */boot*, */usr* and */etc* are read-only to the service.
+| Because of configuration and temporary data, I excluded */etc/webapps* and */var/lib* from the above rules.
+| For further information on these settings, have a look at the |website-systemd_exec|.
+|
+| Now a proper starting via socket activation, (harmless) suicide of the service and a re-activation (again via socket) can take place!
+|
+
+Webapps
+_______
+| I will go through many examples, that facilitate this setup (some with varying backends though).
+| For brevity and due to `my earlier post <../2016/lets-encrypt-it-all>`_ I will only explain whatever happens within |website-nginx|'s server directive (whether you choose to serve your webapps encrypted or not, is not up to me, although I would always encourage encryption!).
+|
+
+MantisBT
+--------
+| For a couple of weeks now, I have been maintaining |website-mantisbt| in the |website-aur|, since it was dropped from the |website-arch_community_repo| earlier and I always wanted to try a self-hosted bug tracker. It is a |website-php| based application, that is actively maintained, but ironically also still features many bugs (and then there was that change to |wiki-php7|).
+| It is |archwiki-mantisbt|, but once you get the grip on it, it's actually quite nice and has a bunch of interesting features.
+|
+| Here is, how I serve it on a subdomain
+
+* */etc/nginx/mantisbt.conf*
+
+  .. code:: nginx
+
+    # ...
+
+    location ~ ^/(admin|core|doc|lang) {
+      deny all;
+      access_log off;
+      log_not_found off;
+    }
+
+    location / {
+      index index.php;
+      try_files $uri $uri/ @mantisbt;
+    }
+
+    location @mantisbt {
+      include uwsgi_params;
+      uwsgi_modifier1 14;
+      uwsgi_pass unix:/run/uwsgi/mantisbt.sock;
+    }
+
+    location ~  \.php?$ {
+      include uwsgi_params;
+      uwsgi_modifier1 14;
+      uwsgi_pass unix:/run/uwsgi/mantisbt.sock;
+    }
+
+    # Deny serving files beginning with a dot, but allow letsencrypt acme-challenge
+    location ~ /\.(?!well-known/acme-challenge) {
+      access_log off;
+      log_not_found off;
+      deny all;
+    }
+
+    # ...
+
+|
+
+* */etc/uwsgi/mantisbt.ini*
+
+  .. code:: ini
+
+    [uwsgi]
+    procname-master = mantisbt
+    plugins = php
+    master = true
+    socket = /run/uwsgi/%n.sock
+    uid = http
+    gid = http
+    processes = 10
+    cheaper = 2
+    cheaper-step = 1
+    idle = 600
+    die-on-idle = true
+
+    php-allowed-ext = .php
+    php-docroot = /usr/share/webapps/mantisbt
+    php-index = index.php
+    php-set = date.timezone=Europe/Berlin
+    php-set = open_basedir=/tmp/:/usr/share/fonts/TTF:/usr/share/webapps/mantisbt:/usr/share/webapps/mantisbt/core:/etc/webapps/mantisbt
+    php-set = session.save_path=/tmp
+    php-set = session.gc_maxlifetime 21600
+    php-set = session.gc_divisor 500
+    php-set = session.gc_probability 1
+    php-set = post_max_size=64M
+    php-set = upload_max_filesize=64M
+    php-set = always_populate_raw_post_data=-1
+
+    php-set = extension=curl.so
+    php-set = extension=gd.so
+    php-set = extension=imagick.so
+    php-set = extension=intl.so
+    php-set = extension=mysqli.so
+    php-set = extension=pdo_mysql.so
+
+|
+
+Roundcube
+---------
+| I have used the excellent webmail frontend for many years now and it just keeps getting better, I think. I would not want to miss its nice features ranging from |wiki-sieve| and |website-gnupg| integration, to password reset and simple folder management.
+|
+
+* */etc/nginx/roundcube.conf*
+
+  .. code:: nginx
+
+    # ...
+
+    location / {
+      index index.php;
+      try_files $uri $uri/$args @roundcubemail;
+    }
+
+    location @roundcubemail {
+      include uwsgi_params;
+      uwsgi_modifier1 14;
+      uwsgi_pass unix:/run/uwsgi/roundcubemail.sock;
+    }
+
+    location ~ ^/favicon.ico$ {
+      root /usr/share/webapps/roundcubemail/skins/classic/images;
+      log_not_found off;
+      access_log off;
+      expires max;
+    }
+
+    location = /robots.txt {
+      allow all;
+      log_not_found off;
+      access_log off;
+      expires 30d;
+    }
+
+    # Deny serving some files
+    location ~ ^/(composer\.json-dist|composer\.json|package\.xml|CHANGELOG|INSTALL|LICENSE|README\.md|UPGRADING|bin|config|installer|program\/(include|lib|localization|steps)|SQL|tests)$ {
+      deny all;
+    }
+
+    # Deny serving files beginning with a dot, but allow letsencrypt acme-challenge
+    location ~ /\.(?!well-known/acme-challenge) {
+      deny all;
+      access_log off;
+      log_not_found off;
+    }
+
+    # ...
+
+|
+
+* */etc/uwsgi/roundcubemail.ini*
+
+  .. code:: ini
+
+    [uwsgi]
+    procname-master = roundcubemail
+    plugins = php
+    socket = /run/uwsgi/%n.sock
+    master = true
+    uid = http
+    gid = http
+    processes = 10
+    cheaper = 2
+    cheaper-step = 1
+    idle = 60
+    die-on-idle = true
+    ; create a cache with 1000 items named roundcube
+    cache2 = name=roundcube,items=1000
+
+    php-allowed-ext = .php
+    php-docroot = /usr/share/webapps/roundcubemail
+    php-index = index.php
+    php-set = date.timezone=Europe/Berlin
+    php-set = session.save_path=/tmp
+    php-set = session.save_handler=uwsgi
+    php-set = session.gc_maxlifetime 21600
+    php-set = session.gc_divisor 500
+    php-set = session.gc_probability 1
+    php-set = open_basedir=/tmp/:/usr/share/webapps/roundcubemail/:/etc/webapps/roundcubemail/:/var/cache/roundcubemail/:/var/log/roundcubemail/:/secure/location/of/gnupg/keys/for/enigma:/usr/bin/gpg:/usr/bin/gpg-agent
+    php-set = post_max_size=64M
+    php-set = upload_max_filesize=64M
+    php-set = error_reporting=E_ALL
+    php-set = log_errors=On
+    php-set = extension=exif.so
+    php-set = extension=iconv.so
+    php-set = extension=intl.so
+    php-set = extension=imap.so
+    php-set = extension=mcrypt.so
+    php-set = extension=pdo_mysql.so
+    php-set = extension=pspell.so
+    php-set = extension=zip.so
+
+|
+
+ownCloud
+--------
+| I guess the open-source cloud solution |website-owncloud| has by now reached many homes and work places. It has so many useful features (extended by apps), that it is hard to keep track.
+| In any case it is very useful for synchronizing your contacts, calendars and files between many devices and enables you to share files with other |website-owncloud| users or the general public.
+|
+
+* */etc/nginx/owncloud.conf*
+
+  .. code:: nginx
+
+    # ...
+
+    location = /robots.txt {
+      allow all;
+      log_not_found off;
+      access_log off;
+    }
+
+    location ~ ^/(?:\.htaccess|data|config|db_structure\.xml|README) {
+      deny all;
+      log_not_found off;
+      access_log off;
+    }
+
+    location ~ ^(.+\.php)(.*)$ {
+      include uwsgi_params;
+      uwsgi_modifier1 14;
+      uwsgi_pass unix:/run/uwsgi/owncloud.sock;
+      uwsgi_intercept_errors on;
+    }
+
+    location / {
+      root /usr/share/webapps/owncloud;
+      index index.php;
+      rewrite ^/.well-known/host-meta /public.php?service=host-meta last;
+      rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json last;
+      rewrite ^/.well-known/carddav /remote.php/dav/ redirect;
+      rewrite ^/.well-known/caldav /remote.php/dav/ redirect;
+      rewrite ^(/core/doc/[^\/]+/)$ $1/index.html;
+      rewrite ^/caldav(.*)$ /remote.php/dav$1 redirect;
+      rewrite ^/carddav(.*)$ /remote.php/dav$1 redirect;
+      rewrite ^/webdav(.*)$ /remote.php/dav$1 redirect;
+      try_files $uri $uri/ /index.php;
+    }
+
+    location ~ ^/.(?:jpg|jpeg|gif|bmp|ico|png|css|js|swf)$ {
+      expires 30d;
+      access_log off;
+    }
+
+    # ...
+
+|
+
+* */etc/uwsgi/owncloud.ini*
+
+  .. code:: ini
+
+    [uwsgi]
+    procname-master = owncloud
+    plugins = php
+    master = true
+    socket = /run/uwsgi/%n.sock
+    uid = http
+    gid = http
+    processes = 10
+    cheaper = 2
+    cheaper-step = 1
+    idle = 600
+    die-on-idle = true
+
+    owncloud_data_dir = /absolute/path/to/where/your/data/resides
+    owncloud_writable_apps_dir = /absolute/path/to/writable/apps
+    chdir = %(owncloud_data_dir)
+
+    php-allowed-ext = .php
+    php-docroot = /usr/share/webapps/owncloud
+    php-index = index.php
+    php-set = date.timezone=Europe/Berlin
+    php-set = open_basedir=%(owncloud_data_dir):%(owncloud_writable_apps_dir):/tmp/:/usr/share/webapps/owncloud:/etc/webapps/owncloud:/dev/urandom:/run/redis/redis.sock
+    php-set = session.save_path=/tmp
+    php-set = session.gc_maxlifetime 21600
+    php-set = session.gc_divisor 500
+    php-set = session.gc_probability 1
+    php-set = post_max_size=1000M
+    php-set = upload_max_filesize=1000M
+    php-set = always_populate_raw_post_data=-1
+    php-set = max_input_time=120
+    php-set = max_execution_time=60
+    php-set = memory_limit=256M
+
+    php-set = extension=bz2.so
+    php-set = extension=curl.so
+    php-set = extension=exif.so
+    php-set = extension=gd.so
+    php-set = extension=imagick.so
+    php-set = extension=intl.so
+    php-set = extension=gmp.so
+    php-set = extension=iconv.so
+    php-set = extension=mcrypt.so
+    php-set = extension=pdo_mysql.so
+    php-set = extension=redis.so
+    php-set = extension=sockets.so
+    php-set = extension=xmlrpc.so
+    php-set = extension=xsl.so
+    php-set = extension=zip.so
+
+    cron = -15 -1 -1 -1 -1 curl --silent https://owncloud.domain.tld/cron.php 1>/dev/null
+
+| You can see here, that |website-uwsgi| is also able to launch a timed command through its *cron* directive. In this case I am using it to have the call to *cron.php* also be handled by the application server, instead of writing a timer service or using crontab.
+
+Mailman
+-------
+| The mailing list software |website-mailman| has been around for ages. The |website-python|-based scripts, templates and |wiki-cgi| frontend are used all around the globe in small to large-scale setups.
+| Due to its age and the sometimes very quirky adoptation of the software by several Linux distributions, |website-mailman| has a not so trivial setup (after all you have to connect it to your :abbr:`MTA (Mail Transfer Agent)` and serve its web-frontend).
+| It was slightly annoying to set it up in my case, but eventually it all worked out.
+|
+
+* */etc/nginx/mailman.conf*
+
+  .. code:: nginx
+
+    # ...
+
+    # Send all access to / to uwsgi
+    location / {
+      gzip off;
+      include uwsgi_params;
+      uwsgi_modifier1 9;
+      uwsgi_pass unix:/run/uwsgi/mailman.sock;
+    }
+
+    # Set alias for accessing /icons
+    location /icons {
+      alias /usr/lib/mailman/icons;
+      autoindex on;
+    }
+
+    # Set alias for accessing /archives
+    location /archives {
+      alias /var/lib/mailman/archives/public;
+      autoindex on;
+    }
+
+    # Deny serving files beginning with a dot, but allow letsencrypt acme-challenge
+    location ~ /\.(?!well-known/acme-challenge) {
+      access_log off;
+      log_not_found off;
+      deny all;
+    }
+
+    # ...
+
+| You might wonder about the */archives* location at this point. I setup my |website-mailman| instance to serve the archive there, instead of *pipermail*:
+
+* */etc/mailman/mm_cfg.py*
+
+  .. code:: python
+
+    # ...
+
+    DEFAULT_URL_PATTERN = 'https://%s/'
+    PUBLIC_ARCHIVE_URL = 'https://%(hostname)s/archives/%(listname)s'
+
+    # ...
+
+| I am also removing the useless */mailman/cgi-bin/* suffix, because I can.
+|
+
+* */etc/uwsgi/mailman.ini*
+
+  .. code:: ini
+
+    [uwsgi]
+    procname-master = mailman
+    master = true
+    plugins = cgi
+    socket = /run/uwsgi/%n.sock
+    processes = 1
+    threads = 2
+    cheaper-step = 1
+    idle = 120
+    die-on-idle = true
+    uid = http
+    gid = http
+    cgi = /=/usr/lib/mailman/cgi-bin
+    cgi-index = listinfo
+
+| As you can see, the frontend does not require a lot of special treatment at all.
+|
+| There is one pitfall however, which leads us right back to the above proposed |website-systemd| service file. It does not allow the changing of users or rather acquiring of new privilegdes.
+| Unfortunately, that is just what |website-mailman| does...
+|
+
+* */etc/systemd/system/uwsgi@.service*
+
+  .. code:: ini
+
+    [Unit]
+    Description=uWSGI service unit
+    After=syslog.target
+
+    [Service]
+    ExecStart=/usr/bin/uwsgi --ini /etc/uwsgi/%I.ini
+    Type=notify
+    SuccessExitStatus=15 17 29 30
+    StandardError=syslog
+    NotifyAccess=all
+    KillSignal=SIGQUIT
+    PrivateDevices=yes
+    PrivateTmp=yes
+    ProtectSystem=full
+    ReadWriteDirectories=/etc/webapps
+    ProtectHome=yes
+
+    [Install]
+    WantedBy=multi-user.target
+
+| My proposed fix for this is to leave out *NoNewPrivileges=yes* for now, as ugly as this may seem. |website-mailman| seems to be the only webapp I have encountered so far, that requires this.
+|
+
+Stikked
+-------
+| The |website-php|-based little webapp |website-stikked| is able to be your own little |website-pastebin| replacement. There are also some nice :abbr:`cli (command line interface)`'s around for it.
+|
+
+* */etc/nginx/stikked.conf*
+
+  .. code:: nginx
+
+    # ...
+
+    location / {
+      index index.php;
+      try_files $uri $uri/ @stikked;
+    }
+
+    location @stikked {
+      rewrite ^/(.*)$ /index.php?/$1 last;
+    }
+
+    location ~ \.php?$ {
+      include uwsgi_params;
+      uwsgi_modifier1 14;
+      uwsgi_pass unix:/run/uwsgi/stikked.sock;
+    }
+
+    # Deny serving some directories
+    location ^~ ^/(application|system)/ {
+      deny all;
+    }
+
+    # Serve some static files
+    location ~* ^.+(favicon.ico|static|robots.txt) {
+      expires 30d;
+    }
+
+    # Deny serving files beginning with a dot, but allow letsencrypt acme-challenge
+    location ~ /\.(?!well-known/acme-challenge) {
+      access_log off;
+      log_not_found off;
+      deny all;
+    }
+
+    # ...
+
+|
+
+* */etc/uwsgi/stikked.ini*
+
+  .. code:: ini
+
+    [uwsgi]
+    procname-master = stikked
+    plugins = php
+    master = true
+    socket = /run/uwsgi/%n.sock
+    uid = http
+    gid = http
+    processes = 10
+    cheaper = 2
+    cheaper-step = 1
+    idle = 120
+    die-on-idle = true
+    cache2 = name=stikked,items=1000
+
+    php-allowed-ext = .php
+    php-index = index.php
+    php-docroot = /usr/share/webapps/Stikked
+    php-set = date.timezone=Europe/Berlin
+    php-set = open_basedir=/tmp/:/usr/share/webapps/Stikked/:/etc/webapps/stikked/
+    php-set = session.save_path=stikked
+    php-set = session.save_handler=uwsgi
+    php-set = session.gc_maxlifetime 21600
+    php-set = session.gc_divisor 500
+    php-set = session.gc_probability 1
+    php-set = extension=gd.so
+    php-set = extension=mysqli.so
+
+    # cleanup pastes every 5 minutes
+    cron = -5 -1 -1 -1 -1 curl --silent https://stikked.domain.tld/index.php/cron/stringFromConfig
+
+| Again, I am using |website-uwsgi|'s cron functionality. This time to call |website-stikked| to make it delete old pastes from time to time.
+|
+
+Wordpress
+---------
+| Although I try really hard to get around |website-wordpress| wherever I can by now, it is used by many for their websites and I am also still responsible for a few instances myself. According to its |wiki-wordpress|, the |website-php|-based :abbr:`CMS (content management system)` has reached a worldwide coverage of more than 25%.
+| That's pretty crazy, considering its |wiki-wordpress_vulnerabilities|.
+
+* */etc/nginx/wordpress.conf*
+
+  .. code:: nginx
+
+    # ...
+
+    index index.php;
+
+    ## Global restrictions
+    location = /favicon.ico {
+      log_not_found off;
+      access_log off;
+    }
+
+    location = /robots.txt {
+      allow all;
+      log_not_found off;
+      access_log off;
+    }
+
+    # Deny all attempts to access hidden files such as .htaccess, .htpasswd, .DS_Store (Mac).
+    # Keep logging the requests to parse later (or to pass to firewall utilities such as fail2ban)
+    location ~ /\. {
+      deny all;
+    }
+
+    # Deny access to any files with a .php extension in the uploads directory
+    # Works in sub-directory installs and also in multisite network
+    # Keep logging the requests to parse later (or to pass to firewall utilities such as fail2ban)
+    location ~* /(?:uploads|files)/.*\.php$ {
+      deny all;
+    }
+
+    ## WordPress multisite subdirectory rules.
+    # This order might seem weird - this is attempted to match last if rules below fail.
+    # http://wiki.nginx.org/HttpCoreModule
+    location / {
+      try_files $uri $uri/ /index.php?$args;
+    }
+
+    # Directives to send expires headers and turn off 404 error logging.
+    location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
+      expires 24h;
+      log_not_found off;
+    }
+
+    # Add trailing slash to */wp-admin requests.
+    rewrite /wp-admin$ $scheme://$host$uri/ permanent;
+
+    # Directives to send expires headers and turn off 404 error logging.
+    location ~* ^.+\.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|rss|atom|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$ {
+      access_log off;
+      log_not_found off;
+      expires max;
+    }
+
+    # Uncomment one of the lines below for the appropriate caching plugin (if used).
+    #include global/wordpress-ms-subdir-wp-super-cache.conf;
+    #include global/wordpress-ms-subdir-w3-total-cache.conf;
+
+    # Rewrite multisite '.../wp-.*' and '.../*.php'.
+    if (!-e $request_filename) {
+      rewrite /wp-admin$ $scheme://$host$uri/ permanent;
+      rewrite ^/[_0-9a-zA-Z-]+(/wp-.*) $1 last;
+      rewrite ^/[_0-9a-zA-Z-]+(/.*\.php)$ $1 last;
+    }
+
+    # Pass all .php files on to uwsgi
+    location ~ \.php$ {
+      include uwsgi_params;
+      uwsgi_modifier1 14;
+      uwsgi_pass unix:/run/uwsgi/wordpress.sock;
+    }
+
+    ## Errors
+    # redirect server error pages to the static page /50x.html
+    error_page   500 502 503 504  /50x.html;
+    location = /50x.html {
+      root   /usr/share/nginx/html;
+    }
+
+    # ...
+
+| This setup is also ready for |website-wordpress|' |website-wordpress_network|.
+|
+
+* */etc/uwsgi/wordpress.ini*
+
+  .. code:: ini
+
+    [uwsgi]
+    procname-master = wordpress
+    plugins = php
+    master = true
+    socket = /run/uwsgi/%n.sock
+    uid = http
+    gid = http
+    processes = 10
+    cheaper = 2
+    cheaper = 1
+    idle = 360
+    die-on-idle = true
+    cache2 = name=wordpress,items=1000
+
+    php-allowed-ext = .php
+    php-docroot = /srv/http/websites/domain.tld
+    php-index = index.php
+    php-set = date.timezone=Europe/Berlin
+    php-set = open_basedir=/srv/http/websites/domain.tld:/tmp/:/usr/share/pear/
+    php-set = upload_max_filesize=24M
+    php-set = post_max_filesize=64M
+    php-set = post_max_size=64M
+    php-set = session.save_path=/tmp
+    php-set = session.save_handler=uwsgi
+    php-set = session.gc_maxlifetime 21600
+    php-set = session.gc_divisor 500
+    php-set = session.gc_probability 1
+
+    php-set = extension=gd.so
+    php-set = extension=iconv.so
+    php-set = extension=mysqli.so
+
+    ; run wp-cron.php job for wordpress every 10 minutes
+    cron = -10 -1 -1 -1 -1 curl --silent https://domain.tld/wp-cron.php 1>/dev/null
+
+| Yet again, the calling of *wp-cron.php* is taken care of by |website-uwsgi| directly.
+|
+
+PostfixAdmin
+------------
+| When using |website-postfix| as your *MTA* and |website-mariadb| as a backend for your user data, |website-postfixadmin| is a very nice and easy choice to add, delete and change accounts, forwards, etc. for all the domains you run.
+| Nevertheless, this is most likely one of those webapps you might want to hide behind a geoblocker and use a :abbr:`VPN (Virtual Private Network)` to access it.
+
+* */etc/nginx/postfixadmin.conf*
+
+  .. code:: nginx
+
+    # ...
+
+    location / {
+      index index.php;
+    }
+
+    # pass all .php or .php/path urls to uWSGI
+    location ~ ^(.+\.php)(.*)$ {
+      include uwsgi_params;
+      uwsgi_modifier1 14;
+      uwsgi_pass unix:/run/uwsgi/postfixadmin.sock;
+    }
+
+    location ~ ^/(config|installer|composer.json-dist|.htaccess|CHANGELOG|INSTALL|LICENSE|README.md|UPGRADING) {
+      access_log off;
+      log_not_found off;
+      deny all;
+    }
+
+    # Serve some static files
+    location ~* ^.+(robots.txt) {
+      allow all;
+      log_not_found off;
+      access_log off;
+      expires 30d;
+    }
+
+    # Deny serving files beginning with a dot, but allow letsencrypt acme-challenge
+    location ~ /\.(?!well-known/acme-challenge) {
+      access_log off;
+      log_not_found off;
+      deny all;
+    }
+
+    # ...
+
+|
+
+* */etc/uwsgi/postfixadmin.ini*
+
+  .. code:: ini
+
+    [uwsgi]
+    procname-master = postfixadmin
+    master = true
+    plugins = php
+    socket = /run/uwsgi/%n.sock
+    uid = http
+    gid = http
+    processes = 10
+    cheaper = 2
+    cheaper-step = 1
+    idle = 120
+    die-on-idle = true
+
+    php-allowed-ext = .php
+    php-docroot = /usr/share/webapps/postfixAdmin
+    php-index = index.php
+    php-set = date.timezone=Europe/Berlin
+    php-set = open_basedir=/tmp/:/usr/share/webapps/postfixAdmin/:/etc/webapps/postfixadmin/:/usr/share/doc/postfixadmin/
+    php-set = session.save_path=/tmp
+    php-set = session.gc_maxlifetime 21600
+    php-set = session.gc_divisor 500
+    php-set = session.gc_probability 1
+    php-set = extension=mysqli.so
+    php-set = extension=imap.so
+
+| As you would suspect, what this application needs, is not much.
+| I recommend having a very close look at the configuration file though!
+|
+
+phpMyAdmin
+----------
+| If you don't feel like writing |wiki-sql| statements to modify your databases, there is |website-phpmyadmin| available to offer a pretty extensive administrative backend.
+| This |website-php| webapp is another one I would not necessarily offer for public access (especially not over plain http).
+|
+
+* */etc/nginx/phpmyadmin.conf*
+
+  .. code:: nginx
+
+    # ...
+
+    client_max_body_size 200M;
+
+    location / {
+      index index.php;
+    }
+
+    location ~ ^(.+\.php)(.*)$ {
+      include uwsgi_params;
+      uwsgi_modifier1 14;
+      uwsgi_pass unix:/run/uwsgi/phpmyadmin.sock;
+    }
+
+    # Serve some static files
+    location ~* ^.+(print.css|favicon.ico|robots.txt) {
+      expires 30d;
+    }
+
+    location ~ ^/(setup|CONTRIBUTING.md|ChangeLog|DCO|LICENSE|README|RELEASE-DATE*|composer.json) {
+      deny all;
+    }
+
+    # Deny serving files beginning with a dot, but allow letsencrypt acme-challenge
+    location ~ /\.(?!well-known/acme-challenge) {
+      access_log off;
+      log_not_found off;
+      deny all;
+    }
+
+    # ...
+
+|
+
+* */etc/uwsgi/phpmyadmin.ini*
+
+  .. code:: ini
+
+    [uwsgi]
+    procname-master = phpmyadmin
+    plugins = php
+    master = true
+    socket = /run/uwsgi/%n.sock
+    uid = http
+    gid = http
+    processes = 10
+    cheaper = 2
+    cheaper-step = 1
+    idle = 600
+    die-on-idle = true
+
+    php-allowed-ext = .php
+    php-docroot = /usr/share/webapps/phpMyAdmin
+    php-index = index.php
+    php-set = date.timezone=Europe/Berlin
+    php-set = open_basedir=/tmp/:/usr/share/webapps/phpMyAdmin:/etc/webapps/phpmyadmin
+    php-set = session.save_path=/tmp
+    php-set = session.gc_maxlifetime 21600
+    php-set = session.gc_divisor 500
+    php-set = session.gc_probability 1
+    php-set = post_max_size=64M
+    php-set = upload_max_filesize=64M
+    php-set = extension=bz2.so
+    php-set = extension=mysqli.so
+    php-set = extension=mcrypt.so
+    php-set = extension=zip.so
+
+|
+
+cgit
+----
+| The blazingly fast |wiki-cgi| web-interface for |website-git| - the amazing :abbr:`VCS (version control system)` - is a must for everyone self-hosting some repositories.
+| |website-cgit| does not require a database, is themeable and very configurable. In conjunction with lightweight access control systems, such as |website-gitosis|, you get a very fast and flexible setup.
+|
+
+* */etc/nginx/cgit.conf*
+
+  .. code:: nginx
+
+    # ...
+
+    location ~* ^.+(cgit.(css|png)|favicon.ico|robots.txt|\.well-known/acme-challenge) {
+      expires 30d;
+    }
+
+    location / {
+      try_files $uri @cgit;
+    }
+
+    location @cgit {
+      gzip off;
+      include uwsgi_params;
+      uwsgi_modifier1 9;
+      uwsgi_pass unix:/run/uwsgi/cgit.sock;
+    }
+
+    location = /50x.html {
+      root /usr/share/nginx/html;
+    }
+
+    # ...
+
+|
+
+* */etc/uwsg/cgit.ini*
+
+  .. code:: ini
+
+    [uwsgi]
+    procname-master = cgit
+    master = true
+    plugins = cgi
+    socket = /run/uwsgi/%n.sock
+    uid = http
+    gid = http
+    processes = 1
+    threads = 2
+    cheaper-step = 1
+    idle = 120
+    die-on-idle = true
+    cgi = /usr/lib/cgit/cgit.cgi
+
+|
+
+Mediawiki
+---------
+| The well-known wiki software |website-mediawiki| is used in a variety of projects and useful in many contexts.
+| I use it mainly for personal documentation, but it is of course also a great tool for collaborative knowledge representation (e.g. |website-wikipedia|, |website-archlinux_wiki|) and planning (e.g. |website-32c3_wiki|, |website-lac2016|).
+|
+
+* */etc/nginx/mediawiki.conf*
+
+  .. code:: nginx
+
+    # ...
+
+    location / {
+      index index.php;
+      try_files $uri $uri/ @mediawiki;
+    }
+    location @mediawiki {
+      rewrite ^/(.*)$ /index.php?title=$1&$args;
+    }
+    location ~ \.php5?$ {
+      include uwsgi_params;
+      uwsgi_modifier1 14;
+      uwsgi_pass unix:/run/uwsgi/mediawiki.sock;
+    }
+    location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
+      try_files $uri /index.php;
+      expires max;
+      log_not_found off;
+    }
+    # Restrictions based on the .htaccess files
+    location ^~ ^/(cache|includes|maintenance|languages|serialized|tests|images/deleted)/ {
+      deny all;
+    }
+    location ^~ ^/(bin|docs|extensions|includes|maintenance|mw-config|resources|serialized|tests)/ {
+      internal;
+    }
+    location ^~ /images/ {
+      try_files $uri /index.php;
+    }
+    # Deny serving files beginning with a dot, but allow letsencrypt acme-challenge
+    location ~ /\.(?!well-known/acme-challenge) {
+      access_log off;
+      log_not_found off;
+      deny all;
+    }
+
+    # ...
+
+|
+
+* */etc/uwsgi/mediawiki.ini*
+
+  .. code:: ini
+
+    [uwsgi]
+    procname-master = mediawiki
+    plugins = php
+    master = true
+    socket = /run/uwsgi/%n.sock
+    uid = http
+    gid = http
+    processes = 10
+    cheaper = 2
+    cheaper-step = 1
+    idle = 360
+    die-on-idle = true
+    cache2 = name=mediawiki,items=1000
+
+    php-allowed-ext = .php
+    php-docroot = /usr/share/webapps/mediawiki
+    php-index = index.php
+    php-set = date.timezone=Europe/Berlin
+    php-set = open_basedir=/tmp/:/usr/share/pear/:/usr/share/webapps/mediawiki/:/etc/webapps/mediawiki/:/var/lib/mediawiki/:/usr/bin/
+    php-set = include_path=.:/usr/share/pear
+    php-set = log_errors=On
+    php-set = display_errors=Off
+    php-set = error_reporting=E_ALL
+    php-set = upload_max_filesize=128M
+    php-set = post_max_filesize=128M
+    php-set = post_max_size=128M
+    php-set = session.save_path=/tmp
+    php-set = session.gc_maxlifetime 21600
+    php-set = session.gc_divisor 500
+    php-set = session.gc_probability 1
+    php-set = extension=gd.so
+    php-set = extension=iconv.so
+    php-set = extension=intl.so
+    php-set = extension=mysqli.so
+    php-set = extension=redis.so
+
+| |website-mediawiki| instances need proper |website-mediawiki_combating_spam|, especially, if you want to run them in the wild.
+| It is no fun to delete hundreds of spam bot users and pages (been there, done that, good times).
+| Make sure to spend some time with your configuration and monitor the wiki instance closely!
+|
+
+Etherpad
+--------
+| |website-etherpad| is a beast of its own, because it is a |website-nodejs| application, so it does not require any application server.
+| Although it is a very useful tool for collaborative work, I am suspicious of its code base, that builds upon a comparibly young |wiki-javascript| framework with sometimes questionable decision making.
+| Anyways, it is served similarly to serving a |website-uwsgi| application:
+
+* */etc/nginx/etherpad-lite.conf*
+
+  .. code:: nginx
+
+    location ~ ^/p/lac2016(.*) {
+      include pad.sleepmap-auth-lac2016.conf;
+      try_files $uri @etherpad-lite;
+    }
+
+    location / {
+      try_files $uri @etherpad-lite;
+    }
+
+    location @etherpad-lite {
+      proxy_pass http://localhost:9001;
+      proxy_redirect off;
+      proxy_buffering on;
+      proxy_request_buffering on;
+      proxy_read_timeout 150;
+      proxy_set_header Host $host;
+      proxy_set_header X-Real-IP $remote_addr;
+      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
+    }
+
+| As you can see, this is a proxy setup for all traffic going towards the *location*, which is then served by the *etherpad-lite.service* listening on port *9001*.
+|
+
+Sidenotes
+_________
+| You may have noticed the |website-redis| extension used in some of the webapps. The in-memory data structure store can be used to speed up (common) queries to your application.
+|
+| The shown *processes*, *cheaper*, *cheaper-step*, *idle* and *die-on-idle*, along with language specific settings (e.g. |website-php|) in the |website-uwsgi| configurations might of course require tweaking, depending on your setup and throughput.
+| Not all |website-php| webapps work with *session.save_handler=uwsgi*.
+| Make sure to tail your |website-nginx| *access* and *error* logs and follow the journal of any webapp you start using.
+
+  .. code:: bash
+
+    tail -f /var/log/nginx/access.domain.tld.log /var/log/nginx/error.domain.tld.log
+    journalctl -f -u uwsgi-secure@mywebapp -u uwsgi-secure@mywebapp2
+
+| All in all I hope this article will be somewhat helpful in setting up some (or all) of the above mentioned applications within the given framework of tools.
+| Enjoy a setup, where your webapps work on demand and you can selectively pull the plug on any of them, without touching your web server.
+
+
+.. |website-letsencrypt| raw:: html
+
+  <a href="https://letsencrypt.org" target="_blank">Let's Encrypt</a>
+
+.. |website-archlinux| raw:: html
+
+  <a href="https://archlinux.org" target="_blank">Arch Linux</a>
+
+.. |website-python| raw:: html
+
+  <a href="https://www.python.org/" target="_blank">Python</a>
+
+.. |website-nginx| raw:: html
+
+  <a href="https://www.nginx.org/" target="_blank">nginx</a>
+
+.. |website-roundcube| raw:: html
+
+  <a href="https://roundcube.net/" target="_blank">roundcube</a>
+
+.. |website-uwsgi| raw:: html
+
+  <a href="https://projects.unbit.it/uwsgi" target="_blank">uWSGI</a>
+
+.. |readthedocs-uwsgi| raw:: html
+
+  <a href="https://uwsgi-docs.readthedocs.io/en/latest/" target="_blank">uWSGI</a>
+
+.. |website-owncloud| raw:: html
+
+  <a href="https://owncloud.org" target="_blank">ownCloud</a>
+
+.. |website-systemd| raw:: html
+
+  <a href="https://www.freedesktop.org/wiki/Software/systemd/" target="_blank">systemd</a>
+
+.. |website-php-fpm| raw:: html
+
+  <a href="https://php-fpm.org/" target="_blank">php-fpm</a>
+
+.. |website-php| raw:: html
+
+  <a href="https://secure.php.net/" target="_blank">PHP</a>
+
+.. |wiki-cgi| raw:: html
+
+  <a href="https://en.wikipedia.org/wiki/Common_Gateway_Interface" target="_blank">CGI</a>
+
+.. |website-ruby| raw:: html
+
+  <a href="https://rack.github.io/" target="_blank">Ruby Rack</a>
+
+.. |website-mono| raw:: html
+
+  <a href="http://www.mono-project.com/" target="_blank">Mono</a>
+
+.. |website-java| raw:: html
+
+  <a href="https://www.java.com/en/" target="_blank">Java</a>
+
+.. |website-lua| raw:: html
+
+  <a href="https://www.lua.org/" target="_blank">Lua</a>
+
+.. |website-perl| raw:: html
+
+  <a href="https://www.perl.org/" target="_blank">Perl</a>
+
+.. |website-webdav| raw:: html
+
+  <a href="http://www.webdav.org/" target="_blank">WebDAV</a>
+
+.. |website-apache| raw:: html
+
+  <a href="https://httpd.apache.org/" target="_blank">Apache</a>
+
+.. |website-mailman| raw:: html
+
+  <a href="http://list.org/" target="_blank">Mailman</a>
+
+.. |website-stikked| raw:: html
+
+  <a href="https://github.com/claudehohl/Stikked" target="_blank">Stikked</a>
+
+.. |website-wordpress| raw:: html
+
+  <a href="https://wordpress.org" target="_blank">Wordpress</a>
+
+.. |website-postfixadmin| raw:: html
+
+  <a href="http://postfixadmin.sourceforge.net/" target="_blank">Postfixadmin</a>
+
+.. |website-phpmyadmin| raw:: html
+
+  <a href="https://www.phpmyadmin.net/" target="_blank">phpMyAdmin</a>
+
+.. |website-cgit| raw:: html
+
+  <a href="https://git.zx2c4.com/cgit/" target="_blank">cgit</a>
+
+.. |website-mediawiki| raw:: html
+
+  <a href="https://www.mediawiki.org/wiki/MediaWiki" target="_blank">MediaWiki</a>
+
+.. |website-mantisbt| raw:: html
+
+  <a href="https://mantisbt.org/" target="_blank">MantisBT</a>
+
+.. |wiki-html| raw:: html
+
+  <a href="https://en.wikipedia.org/wiki/HTML" target="_blank">HTML</a>
+
+.. |wiki-css| raw:: html
+
+  <a href="https://en.wikipedia.org/wiki/Cascading_Style_Sheets" target="_blank">CSS</a>
+
+.. |wiki-javascript| raw:: html
+
+  <a href="https://en.wikipedia.org/wiki/JavaScript" target="_blank">JavaScript</a>
+
+.. |wiki-load_balancing| raw:: html
+
+  <a href="https://en.wikipedia.org/wiki/Load_balancing_(computing)" target="_blank">load balancer</a>
+
+.. |wiki-proxy_server| raw:: html
+
+  <a href="https://en.wikipedia.org/wiki/Proxy_server" target="_blank">proxy</a>
+
+.. |doc-uwsgi_packet_descriptions| raw:: html
+
+  <a href="https://uwsgi-docs.readthedocs.io/en/latest/Protocol.html#packet-descriptions" target="_blank">packet descriptions</a>
+
+.. |website-aur| raw:: html
+
+  <a href="https://aur.archlinux.org" target="_blank">AUR</a>
+
+.. |website-arch_community_repo| raw:: html
+
+  <a href="https://www.archlinux.org/packages/?sort=&repo=Community&q=&maintainer=&flagged=" target="_blank">community repository</a>
+
+.. |wiki-php7| raw:: html
+
+  <a href="https://en.wikipedia.org/wiki/PHP#PHP7" target="_blank">PHP7</a>
+
+.. |archwiki-mantisbt| raw:: html
+
+  <a href="https://wiki.archlinux.org/index.php/MantisBT" target="_blank">non-trivial to setup</a>
+
+.. |doc-uwsgi_emperor_mode| raw:: html
+
+  <a href="https://uwsgi-docs.readthedocs.io/en/latest/Systemd.html?highlight=emperor#adding-the-emperor-to-systemd" target="_blank">Emperor mode</a>
+
+.. |website-systemd_exec| raw:: html
+
+  <a href="https://www.freedesktop.org/software/systemd/man/systemd.exec.html" target="_blank">systemd.exec manual</a>
+
+.. |wiki-sieve| raw:: html
+
+  <a href="https://en.wikipedia.org/wiki/Sieve_(mail_filtering_language)" target="_blank">sieve</a>
+
+.. |website-gnupg| raw:: html
+
+  <a href="https://gnupg.org/" target="_blank">GnuPG</a>
+
+.. |website-pastebin| raw:: html
+
+  <a href="http://pastebin.com/" target="_blank">pastebin</a>
+
+.. |wiki-wordpress| raw:: html
+
+  <a href="https://en.wikipedia.org/wiki/WordPress" target="_blank">Wikipedia article</a>
+
+.. |wiki-wordpress_vulnerabilities| raw:: html
+
+  <a href="https://en.wikipedia.org/wiki/WordPress#Vulnerabilities" target="_blank">long history of vulnerabilities</a>
+
+.. |website-postfix| raw:: html
+
+  <a href="http://postfix.org" target="_blank">Postfix</a>
+
+.. |website-mariadb| raw:: html
+
+  <a href="https://mariadb.org/" target="_blank">MariaDB</a>
+
+.. |wiki-sql| raw:: html
+
+  <a href="https://en.wikipedia.org/wiki/SQL" target="_blank">SQL</a>
+
+.. |website-git| raw:: html
+
+  <a href="https://git-scm.com/" target="_blank">git</a>
+
+.. |website-gitosis| raw:: html
+
+  <a href="https://github.com/tv42/gitosis" target="_blank">gitosis</a>
+
+.. |website-wikipedia| raw:: html
+
+  <a href="https://en.wikipedia.org/" target="_blank">Wikipedia</a>
+
+.. |website-archlinux_wiki| raw:: html
+
+  <a href="https://wiki.archlinux.org/" target="_blank">Arch Linux Wiki</a>
+
+.. |website-32c3_wiki| raw:: html
+
+  <a href="https://events.ccc.de/congress/2015/wiki/Main_Page" target="_blank">32C3</a>
+
+.. |website-lac2016| raw:: html
+
+  <a href="https://lac.linuxaudio.org/2016" target="_blank">LAC2016</a>
+
+.. |website-mediawiki_combating_spam| raw:: html
+
+  <a href="https://www.mediawiki.org/wiki/Manual:Combating_spam" target="_blank">spam protection</a>
+
+.. |website-redis| raw:: html
+
+  <a href="http://redis.io" target="_blank">redis</a>
+
+.. |website-etherpad| raw:: html
+
+  <a href="http://etherpad.org" target="_blank">Etherpad</a>
+
+.. |website-nodejs| raw:: html
+
+  <a href="https://nodejs.org" target="_blank">NodeJS</a>
+
+.. |website-wordpress_network| raw:: html
+
+  <a href="https://codex.wordpress.org/Create_A_Network" target="_blank">multisite feature</a>
+
diff --git a/content/pages/music/deviser.rst b/content/pages/music/deviser.rst
index 63f4339..d2660f1 100644
--- a/content/pages/music/deviser.rst
+++ b/content/pages/music/deviser.rst
@@ -1,12 +1,12 @@
-1)3\/1532
-#########
+1)3\\/1532
+##########
 
 :authors: David Runge
 
 About
 _____
 
-| 1)3\/1532 (*deviser*) is drone/noise/experimental soundscaping.
+| 1)3\\/1532 (*deviser*) is drone/noise/experimental soundscaping.
 | The aural journey leads to places like simple repetitve guitar tunes, loops, feedback manipulation, modified samples of field recordings, DIY analog synthesizers, toys and the like.
 | Experimentation for the greater good!
 |
@@ -28,6 +28,7 @@ ____
 | 2013-07-26 @ |camptipsy|
 | 2013-03-16 @ |zgk|, Berlin (with Dr. Nexus, Séamus O'Donnell, HURE & St. Genet)
 | 2012-12-01 @ |newyorck59|, Berlin (with HURE & Paro)
+|
 
 Listen
 ______