Reference configuration files for using Jellyfin with NGINX.
https://docs.icedterminal.com/en/linux/jellyfin
The config files are used with my own custom build of NGINX. Things you will not have access to with a vanilla build (mainline) are commented out. This being Brotli and HTTP3. I have left these in if you want to use a custom build.
| # UPDATED 17 February 2019 | |
| # Redirect all HTTP traffic to HTTPS | |
| server { | |
| listen 80; | |
| listen [::]:80; | |
| server_name www.domain.com domain.com; | |
| return 301 https://$host$request_uri; | |
| } | |
| # SSL configuration |
| # /etc/nginx/sites-available/default | |
| # Phoenix LiveView Nginx configuration - Reverse proxy to Phoenix app running on localhost | |
| # All lines with # managed by certbot are placed automatically by [certbot](https://certbot.eff.org) | |
| # Replace $YOUR_SITE_NAME with your url host unless line is followed with # managed by Certbot | |
| # Default server configuration | |
| # | |
| server { | |
| listen [::]:443 ssl ipv6only=on; # managed by Certbot |
This guide was written because I don't particularly enjoy deploying Phoenix (or Elixir for that matter) applications. It's not easy. Primarily, I don't have a lot of money to spend on a nice, fancy VPS so compiling my Phoenix apps on my VPS often isn't an option. For that, we have Distillery releases. However, that requires me to either have a separate server for staging to use as a build server, or to keep a particular version of Erlang installed on my VPS, neither of which sound like great options to me and they all have the possibilities of version mismatches with ERTS. In addition to all this, theres a whole lot of configuration which needs to be done to setup a Phoenix app for deployment, and it's hard to remember.
For that reason, I wanted to use Docker so that all of my deployments would be automated and reproducable. In addition, Docker would allow me to have reproducable builds for my releases. I could build my releases on any machine that I wanted in a contai
| FROM nginx AS build | |
| WORKDIR /src | |
| RUN apt-get update && \ | |
| apt-get install -y git gcc make g++ cmake perl libunwind-dev golang && \ | |
| git clone https://boringssl.googlesource.com/boringssl && \ | |
| mkdir boringssl/build && \ | |
| cd boringssl/build && \ | |
| cmake .. && \ | |
| make |
Поддержать в тех проектах, в которых уже существует поддержка (в них сейчас нет кнопки Поддержать, показывается Моя поддержка, что не дает поддержать проект еще раз). (дополнительные изменения - для оценки)Поддержать
| 日時: | 2019-06-01 |
|---|---|
| 作: | voluntas |
| バージョン: | 19.06.2 |
| URL: | https://voluntas.github.io/ |
Putting cryptographic primitives together is a lot like putting a jigsaw puzzle together, where all the pieces are cut exactly the same way, but there is only one correct solution. Thankfully, there are some projects out there that are working hard to make sure developers are getting it right.
The following advice comes from years of research from leading security researchers, developers, and cryptographers. This Gist was [forked from Thomas Ptacek's Gist][1] to be more readable. Additions have been added from
| # The directory Mix will write compiled artifacts to. | |
| /_build | |
| # If you run "mix test --cover", coverage assets end up here. | |
| /cover/ | |
| # The directory Mix downloads your dependencies sources to. | |
| /deps/ | |
| # Where 3rd-party dependencies like ExDoc output generated docs. |
| defmodule DrainStop do | |
| @moduledoc """ | |
| DrainStop Attempts to gracefully shutdown an endpoint when a normal shutdown | |
| occurs. It first shuts down the acceptor, ensuring that no new requests can be | |
| made. It then waits for all pending requests to complete. If the timeout | |
| expires before this happens, it stops waiting, allowing the supervision tree | |
| to continue its shutdown order. | |
| DrainStop should be installed in your supervision tree *after* the | |
| EndPoint it is going to drain stop. |