aboutsummaryrefslogtreecommitdiffhomepage
path: root/support/nginx
Commit message (Collapse)AuthorAgeFilesLines
* Remove hard-coded 8GB upload limit in client (#1293)Micah Elizabeth Scott2018-12-071-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | * 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.
* Create redundancy endpointChocobozzz2018-12-041-2/+7
|
* Add comments in nginx regarding blocks that can be safely removedChocobozzz2018-09-171-1/+3
|
* Don't include `preload` flag in sample HSTS headerFelix Ableitner2018-09-111-1/+1
| | | | | 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
* make HSTS opt-in and leave it to the reverse-proxyRigel Kent2018-09-091-1/+5
|
* Only enable gzip for HTML/CSS/JSMicah Elizabeth Scott2018-08-241-2/+4
| | | | | No compression on JSON endpoints, in order to protect from potential compression+encryption data leak attacks (like BREACH)
* Add gzip support to the sample nginx configurationMicah Elizabeth Scott2018-08-241-0/+5
| | | | | | | | | 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.
* 404 on unknown thumbnailChocobozzz2018-07-241-7/+8
|
* Add cors to static route in nginx templateChocobozzz2018-07-241-0/+16
|
* (nginx) remove headers now dealt with helmetRigel Kent2018-07-181-3/+0
|
* Fix static avatars/thumbnails cacheChocobozzz2018-07-171-1/+2
|
* Increase upload limit to 8GB (test)Chocobozzz2018-06-291-3/+3
|
* Revert "Selective route permission to use embeds, fixes #322 in a better way ↵Chocobozzz2018-03-201-6/+0
| | | | | (#364)" (#365) This reverts commit d40cd86bf56973d7217ad44737e3890b6e7f1ad5.
* Selective route permission to use embeds, fixes #322 in a better way (#364)Rigel Kent2018-03-201-0/+6
|
* Remove X-Frame options in nginx config (#322)Valvin2018-03-051-1/+0
| | | `X-Frame-Options DENY;` doesn't permit sharing using iframe
* Fix nginx configuration that do not work with import-videos scriptChocobozzz2018-03-011-1/+1
|
* Try to improve production guideChocobozzz2018-02-161-8/+14
|
* Precisions and security enhancements to the production guide (#287)Rigel Kent2018-02-141-14/+37
| | | | | | | | - 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.
* Peertube home in /var/www instead of /homeChocobozzz2018-01-231-3/+3
|
* Don't serve previews with nginxChocobozzz2018-01-181-1/+1
| | | | We need to maintain a cache in the node process
* nginx optimizationsChocobozzz2018-01-181-0/+21
|
* Update production guideChocobozzz2018-01-151-2/+4
| | | | | Use release that already contains build files. It requires a specific directories tree but I think it would be fine.
* Remove unused webserver configurationChocobozzz2018-01-112-53/+5
| | | | And update nginx configuration with a rate limit
* change nginx config to fix deprecation of a old module (#175)Fernandez, ReK22018-01-061-1/+1
|
* Add ability to unfollow a serverChocobozzz2017-11-272-0/+6
|
* Fix nginx https templateChocobozzz2017-10-191-1/+1
|
* Increase client_max_body_size in NGinx templateChocobozzz2017-10-172-2/+2
|
* Add peertube https nginx templateChocobozzz2016-11-251-0/+61
|
* Update NGinx template (uploads -> videos)Chocobozzz2016-10-261-1/+1
|
* Update NGinx that bypass /static/webseed (better performances)Chocobozzz2016-10-101-0/+21
|
* Add nginx example fileChocobozzz2016-06-031-0/+27