Ignore the peeps saying not to use a regular pci-e card. Old recc, ASmedia ones are ideal good for 4-6 ports. 8+ you need to dabble in LSI shenanigans. The ASmedia ones use way less power and are worth it if you don’t need 8+ ports. You get all the features you want, they look and act like real SATA ports.

Check these guides (not just applicable to unraid, I don’t use unraid, but they cater towards a “ez straightforward” crowd so they make relatively concise and vetted info dumps):

https://forums.unraid.net/topic/102010-recommended-controllers-for-unraid/

https://forums.unraid.net/topic/41340-satasas-controllers-tested-real-world-max-throughput-during-parity-check/

Yes that tracks with how OIDC setup works with my other services (you give the container the OIDC links and shared secrets so it knows how to talk to the OIDC and trust it).

I am digging this, thanks for keeping it updated and improving it!

I see that you say it’s feature complete / no user stuff; but it’d really mesh well if it took OIDC authentication. Don’t need it to make users or anything, just instead of the password popup the OIDC provider is asked for confirmation that whatever user registered with the OIDC is logged in. That’d let me leverage extra 2FA protection from the OIDC provider and juice on that one-login life.

Now I have no experience making OIDC crap work nor how it even works behind the scenes, so I can’t help :( sorry; just wishful thinking.

Also saw on your github - hope our newly shit-out gestapo don’t bother you!

Not if you annotate your data volume with said ‘noexec’ which prevents execution from anything in the data volume. It looks like this, you can slam it on any volume you like - no volumes should have executables in them anyways.

Also I’m pretty sure ‘noexec’ is the default, so that’s by default protected. But I can’t confirm that from a quick search so not 100% on that.

‘/mnt/data:/container/place/it/wants:rw,noexec,nosuid,nodev,Z’

‘rw’ means read/write. You can change it to ‘ro’ for read-only if the volume shouldn’t write to it (maybe a config file).

Z is for selinux that means “only one program can read/write tho this”. You can change it to ‘z’ lowercase in case more than one needs to read/write. Only case I’ve found for little z is crowdsec needing to watch Caddy’s log for blocking.

So overall, the idea is that your volume mounts can’t be used to execute arbitrary binaries AND the image file system is frozen so that arbitrary binaries cannot be loaded into the image (which is by default all executable, a requirement to run anything in it). So if someone was able to hack into an internet-facing container, they won’t be able to load up whatever they want. They’ll be limited to what’s built into the image (which ideally are secure and limited in scope).

As always you store data you want to keep in the volumes section.

With read-only you prevent new binaries from being added in the image space. You can add ‘noexec’ to your volumes/tmpfs preventing binaries to the areas that are writable. Then ideally you are using an image with minimal surface area (e.g., only sh and the exact binaries needed to make it go) and it’s very secure! It’s still plenty secure without a minimal image.

Thanks! This’ll def help me get tooled up for podman :)

Care to share your quartet? I’m just getting into the quads with trixie out - and I haven’t gotten this working yet…

The permissions do seem intense; if you’re getting by without maybe those aren’t quite needed!

Great to hear! It’s seriously slick and “just works”. With those security features up you can tout them on the cloud offering too :)

No what I said isn’t about user registration; it’s about adding these to the docker-compose.yml:

        read_only: true
        user: 6969:6969

to prevent running as root and making the file system read-only. The API needs to be exposed without a VPN or other proxy login since my parents’ can’t handle that, so if I was able to implement these recommended security steps I’d feel like I could open up the container to the internet at large without too much risk.

Per this issue https://github.com/linkwarden/linkwarden/issues/799 it seems like there’s a lot of steps to take to get these settings to work.

It would be also ideal if I didn’t have to give the container (but not a deal-breaker):

        cap_add:
          - CAP_SYS_ADMIN
          - CAP_SYS_CHROOT

as the issue also states is required for the headless chrome scraper browser.

I am using it internally now and it’s really good, but to open it up for my parents (which I think they’d dig) I’d definitely want these security settings on without major issues. Linkwarden is an internet-facing application so these recommended security practicies are in its wheel-house, feature-wise, as well.

Hope that helps clear up my comment!

This is a fantastic tool, but I’d love to confidently expose the API to the internet for the shortcut. To do that you need read-only and running as a user; I saw that that’s not a thing that works from the issues.

Any thoughts on getting those security features working? Cause the app itself is so smooth I’d let my parents use it and be confident they wouldn’t need to be herded constantly.

Other user summarized very well.

No I have accrued knowledge of those things over time, no one stop shop that I know of. But knowing these things exist and their general use are half the battle!

I was lazy with the “Authentik wall” because I couldn’t remember what they called it. It is the “proxy” option in their “provider” section https://docs.goauthentik.io/add-secure-apps/providers/proxy/ . There are many guides for Authentik at least, it’s complicated but you only need to do specific things for it to work - and most tell you and the rest are applicable via matching similar looking things.

OIDC is an open login protocol many things support. I think jellyfin can use it with a plugin, but keep in mind that regular user creation still exists so it’s not a security and convenience feature like for most things, it’s just a convenience feature.

DMZ is de militarized zone. I used the acronym to mean a gap between your system and a system that deals directly with the outside Internet. That gap is the VM separation. LXC containers and docker containers do not have that separation, I deploy Internet-facing stuff in a VM as extra insurance in case they get zero-day-hacked; it means the rest of my server will hopefully not get ransomwared.

Incus is an alternative to proxmox, but less needy since it doesn’t require its own Linux kernel. Zabbly is a package source (vs built-in Debian sources) that has the web ui in it. See their documentation for installation, it tells you how to add the Zabbly package; use the “stable” version if you do use incus.

“In the compose” means in the docker-compose.yml file.

‘Cap-drop: all’ is an entry you can make in the docker-compose file. It increases security. All of the ones I listed are entries you can add to the docker-compose file. You’ll likely need a

tmpfs: /tmp

In the compose file you use read only.

Podman is the superior alternative to docker, and Podman quadlets are a way to deploy containers (they have a couple ways, like docker does - you don’t need a docker-compose.yml file to run docker containers). But it’s new and doesn’t have the community knowledge support via searching like docker does.

Hope that helps!

I am not familiar with deploying client side certificates unfortunately. I hope it works, if the certificate is at the OS level and the application will use it, I feel it will work… not sure, in-browser feels straight forward at least

Reading jellyfin’s issues it’s clear its web ui and API cannot be allowed to talk to the general internet.

I’d push for a VPN solution first. Tailscale or wireguard. If you’re happy with cloudflare sniffing all traffic and that they make take it away suddenly someday use their tunnel with authentication.

The only other novel solution I’d suggest is putting jellyfin behind an Authentik wall (not OIDC, though you can use OIDC for users after the wall). That puts security on Authentik, and that’s their only job so hopefully that works. I’d use that if VPN (tailscale or wireguard) are problematic for access. The downside is that jellyfin apps will not be able to connect, only web browsers that can log into the Authentik web ui wall.

Flow would go caddy/other reverse proxy -> Authentik wall for jellyfin -> jellyfin

I’d put everything in docker, I’d put caddy and Authentik in a VM for a DMZ (incus + Zabbly repo web ui to manage the VM), I’d set all 3 in the compose to read-only, user:####:####, cap-drop all, no new privileges, limited named networks.

Podman quadlets would be even better security than docker, but there’s less help for that (for now). Do docker and get something working to start, then grow from there

If you’ve got Debian already installed, I cannot resist advocating for Incus (stable branch from Zabbly repo with web ui https://blog.simos.info/how-to-install-and-setup-the-incus-web-ui/) in lieu of proxmox. Does the same thing but you don’t have to rip out the kernel Debian uses.

With Debian 13 you have access to podman quadlets, use that for any non-vm needs. The ease of docker compose files easily removes reason for programs in LXC containers, and podman removes reason for docker in an LXC. LXC is left only for programs that aren’t containerized. VMs for security DMZ. Podman for bulk of stuff you want.

Good luck!

Thanks for taking the time to go into detail on this, it helps because I just haven’t been able to put acronyms to actionable meaning from just reading blogs and posts.

How do things outside the LAN talk to things inside the LAN that have ULA addresses (which I’m assuming are equivalent of 10.0.0.0/16 idea)? Will devices that are given ULA addresses be NAT’d just like IPv4 or will they not be able to talk to the outside world on IPv6?

Edit: I am getting more what you said; you answered this: the ULA addresses will not be able to talk to the outside world on IPv6 so those devices will be IPv4-only to websites that use IPv6 too. Follow-on Q would then be, is kludging NAT for IPv6 not a better solution versus ULA addresses? Or is the clear answer just use IPv6 as intended and let the devices handle their privacy with IPv6 privacy extensions?

I see now that a limitation I just understood for IPv4 (expose one port from one device only on the router) isn’t a thing for IPv6 working without NAT, every device on a LAN can be given a world wide routable address and expose the same port. Interesting, in my home I don’t think I’d ever run into that, but I can see issues like that pile up quick in big deployments.

Thanks for taking the time to explain all of this in detail!

I gather people talk like NAT is a rung of hell, but I guess it works because I never think of it. Maybe it becomes shittastic at multiple NATs? With one router it seems straight forward to have port forwarding.

I do not understand why I want better inbound connections - but maybe if I get hit with a cgnat then I’ll understand?

Mobile devices are largely IPv6-only now, messing with VPN to home. The IPv6-to-4 conversion seems to be shoddy for my mobile carrier.

Not here for what it represents, just want it to work.

I haven’t run into NAT issues that I’ve noticed, would IPv6 avoid issues with cgnat that people complain about? (If/when it happens in the future)

I know, but when you get captcha’d all of the time you feel like you’re kinda winning (but not really of course). I don’t want them to just have a nice fingerprint of my devices without having to try at all. I see others have mentioned “IPv6 privacy extensions” that let the devices cycle the multitude of IPv6 address space to keep a semblance of privacy - that seems to be the “default” solution

I see, I saw someone else mention “IPv6 privacy extensions”. So basically it’s up to the individual devices to handle privacy instead of the router doing it for them in IPv6 land