refactors the Nginx configuration for the following points:
- update tls version to include 1.3 by default. so far it was not included by default to make room for previous versions of Nginx, but since 2018 Debian stable has included Nginx in version 1.14.1, and tls 1.3 is available since Nginx 1.13.0.
- clearly indicate that new minimum required version.
- update outdated ssl_ciphers to remove cipher required to support android 4.4, since that version is unsupported since March 2020.
- reordered configuration in sections for easier maintenance: performance optimizations are separated from the vital application/websocket parts.
- move parts that always require manual configuration at the top: peertube host and server name, use server_name
- move peertube host to a more flexible upstream block: it allows to configure it in one place instead of 3, and is future-proof regarding load-balancing.
- simplified port 80 block: Let’s Encrypt supports 301 redirects.
- group certificate-related config together.
- remove reslover config: it defaults to /etc/resolv.conf which is more than enough.
- align values with their neighbors for easier reading
- always specify units
- always specify default values when they differ from the values set
- use ’m’ for minutes, ’M’ for megabytes
- add consensual optimizations wrt file serving:
- add timeout optimizations
- add file descriptor cache optimizations
- enable sendfile with chunk size > rate limit
- enable threading
- tcp optimizations
- point to further, more system-specific optimizations in the section description
- CDN configuration reduced to one line change
- support/docker/production/docker-compose.yml: addition of a nginx
image reusing support/nginx/peertube nginx conf to improve performance,
and lessen setup differences between the docker-compose install and the
typical production install.
- support/docker/production/docker-compose.yml: postgres 10 -> postgres
12, redis 4 -> redis 5. Postgres major updates implies manual upgrade.
- support/nginx/peertube: HTTP -> HTTPS redirection is now commented
by default, to allow its reuse in support/docker/production/docker-compose.yml.
* Remove hard-coded 8GB upload limit in client
Ideally we'd know what the specific server's configured upload limit
is before starting, but this 8GB limit is not useful if an administrator
has changed the nginx post limit on the server.
* Better docs for admins about client_max_body_size
Seems like some admins already tweak this value up or down to allow
for different maximum video upload sizes. The current codebase has no
other server-side limits that I'm aware of, and I've been routinely
uploading quite large videos to my instance.
This patch replaces the somewhat incorrect (or outdated?) 'hard limit'
comment with some advice about allocating enough space for nginx and
communicating the limit with your users.
Of course it would be better if this configuration could be unified with
PeerTube's config somehow. I'm not sure whether the best option there is
to turn off nginx's buffering here and let PeerTube handle the entire upload
(can we do this only for the video upload API endpoint?) or whether we want
PeerTube to generate nginx configs in a more automated way layer. In any case,
this patch is intended as an incremental improvement.
This goes against the recommendations (preloading should be opt-in). Putting it in the example makes it likely that people enable it without knowing what it means.
https://hstspreload.org/?domain=peertube.social#opt-in
Without gzip explicitly enabled, load times suffer from transferring
over a megabyte of plaintext javascript. With gzip enabled, the bundle
is down to about 300K, and loads much faster.
This change does not enable gzip on files that are already compressed,
so images, fonts, and videos will be sent without the CPU overhead.
- added precisions and suggestions about how to generate Let's Encrypt certificates. Users have reported their installations didn't work when the problem came from missing certificates (false positives).
- security defaults of Nginx follow the basic robustness principle "be conservative in what you send, be liberal in what you accept", which isn't enough with modern security standards, so we should be picky with the cipher suites we use, among other things. Extra comments (especially for the TLS1.3 protocol support parameter) make the requirement of a recent Nginx installation obvious, and the downgrade alternative remains clear to the system administrator.
All in all, we should aknowledge users will most often copy and paste the configuration files. Making them secure by default may force a few users to read their configuration, but on the long run we are making the fediverse more secure.
Since I've come to modify a bit the Nginx config in `support/doc/production.md`, I've merged it with the template so that they stay consistent.
Chocobozzz