pyrosis

Well I use a fire stick with smartube and jellyfin. Works just fine for my needs. YMMV

I remember the old videos of rockets exploding on launch pads when we were first building them. We have come a long way.

I suspect they will just learn something new from this and they will last even longer.

That's what I said. Cow on top of cow is bad. Pretty sure ext4 isn't on option on opnsense. UFS or zfs. Which is the only reason I mentioned it at all when presented with that choice.

I have been considering just installing Debian on a small PC then the jellyfin media player application set to auto start. I can think of a few different ways to get this done maybe with a couple user accounts.

I like the idea of being able to change the application that automatically starts. Maybe I want to try Kodi again. I would just change the startup app.

Get your firewall right then maybe add fail2ban.

You could also consider IDs/IPs on your primary router/firewall if this is internal. If not you can install surricata on a public server. Obviously if you go with something as powerful as surricata you no longer need fail2ban.

Keep a sharp eye on any users with sudo. Beyond that consider docker as others have mentioned.

It does add to security because it allows the developers a bit more control of what packages are utilized for their applications. It creates a more predictable environment.

It seems that way but it performs better than zfs on top of zfs. The only os I ran into that with was opnsense when I was playing with a virtualized firewall.

Within guests these days I just use XFS, UFS, or NTFS depending on the os. The hypervisor can have zfs or ceph.

I'm spoiled now. I prefer ubiquiti equipment for my network, security camera, and even door access.

However, if you prefer completely open source I can recommend opnsense and openwrt. Personally I prefer a single point of configuration... So all ubiquiti for me.. It makes it easy to restore a complete network configuration as you are discovering is a pain.

Maybe start with the new cloud gateway max as a router if you are interested.

When I was experimenting with this it didn't seem like you had to distribute the cert to the service itself. As long as the internal service was an https port. The certificate management was still happening on the proxy.

The trick was more getting the host names right and targeting the proxy for the hostname resolution.

Either way IP addresses are much easier but it is nice to observe a stream being completely passed through. I'm sure it takes a load off the proxy and stabilizes connections.

This would be correct if you are terminating ssl at the proxy and it's just passing it to http. However, if you can enable SSL on the service it's possible to take advantage of full passthru if you care about such things.

I use using docker networks but that's me. They are created for every service and it's easy to target the gateway. Just make sure DNS is correct for your hostnames.

Lately I've been optimizing remote services for reverse proxy passthru. Did you know that it can break streams momentarily and make your proxy work a little harder if your host names don't match outside and in?

So in other words if you want full passthru of a tcp or udp stream to your server without the proxy breaking it then opening a new stream you would have to make sure the internal network and external network are using the same fqdn for the service you are targeting.

It actually can break passthru via sni if they don't use the same hostname and cause a slight delay. Kinda matters for things like streaming videos. Especially if you are using a reverse proxy and the service supports quic or http2.

So a reverse proxy entry that simply passes without breaking the stream and resending it might ook like...

Obviously you would need to get the http port working on jellyfin and have ipv6 working with internal DNS in this example.

server {
    listen 443 ssl;
    listen [::]:443 ssl;  # Listen on IPv6 address

    server_name jellyfin.example.net;

    ssl_certificate /path/to/ssl_certificate.crt;
    ssl_certificate_key /path/to/ssl_certificate.key;

    location / {
        proxy_pass https://jellyfin.example.net:8920;  # Use FQDN
        ...
    }
}

Have you considered the increase in disk io and that hypervisor prefer to be in control of all hardware? Including disks...

If you are set on proxmox consider that it can directly share your data itself. This could be made easy with cockpit and the zfs plugin. The plugin helps if you have existing pools. Both can be installed directly on proxmox and present a separate web UI with different options for system management.

The safe things here to use are the filesharing and pool management operations. Basically use the proxmox webui for everything it permits first.

Either way have fun.