• 2 Posts
  • 82 Comments
Joined 1 year ago
cake
Cake day: April 27th, 2024

help-circle


  • Actual answer for 3:

    • put jellyfin behind a proper reverse proxy. Ideally on a separate host / hardware firewall, but nginx on the same host works fine as well.
    • create subdomain, let’s say sub.yourdomain.com
    • forward traffic, for that subdomain ONLY, to jellyfin in your reverse proxy config
    • tell your relatives to put sub.yourdomain.com into their jellyfin app

    All the fear-mongering about exposing jellyfin to the internet I have seen on here boils down to either

    • “port forwarding is a bad idea!!”, which yes, don’t do that. The above is not that. Or
    • “people / bots who know your IP can get jellyfin to work as a 1-bit oracle, telling you if a specific media file exists on your disk” which is a) not an indication for something illegal, and b) prevented by the described reverse proxy setup insofar as the bot needs to know the exact subdomain (and any worthwhile domain-provider will not let bots walk your DNS zone).

    (Not saying YOU say that; just preempting the usual folklore typically commented whenever someone suggests hosting jellyfin publicly accessible)


















  • Managing 30+ machines with NixOS in a single unified config, currently sitting at a total of around 17k lines of nix code.

    In other words, I have put a lot of time into this. It was a very steep learning curve, but it’s paid for itself multiple times over by now.

    For “newcomers”, my observations can be boiled down to this: if you only manage one machine, it’s not worth it. Maaaaaybe give home-manager a try and see if you like it.

    Situation is probably different with things like Silverblue (IMO throwing those kinds of distros in with Guix and NixOS is a bit misleading - very different philosophy and user experience), but I can only talk about Nix here.

    With Nix, the real benefit comes once you handle multiple machines. Identical or similar configurations get combined or parametrized. Config values set for Host A can be reused and decisions be made automatically based on it in Host B, for example:

    • all hosts know my SSH pub keys from first boot, without ever having to configure anything in any of them
    • my NAS IP is set once, all hosts requiring NAS access just reuse it implicitly
    • creating new proxmox VMs just means adding, on average, 10 lines of nix config (saying: your ID will be this, you will run that service) and a single command, because the heavy lifting and configuring has already been done, once -…