I am loving OIDC giving a single login for all the things I’ve got going, I see it as a near-essential for adding new services!

Read-only is easy! You just need to confine where the writes happen. You use volumes for stuff you want to remember were written and tmpfs for stuff you don’t want to remember. Tmpfs for /tmp if needed, volume for the DB, good to go. It is super useful for security since only what is included in the container can be executed greatly reducing the attack area. No way to introduce a new excutable to the container! (you set noexec for tmpfs/volumes)

I’ve seen difficult setups like a “work directory” where key files, executables, and temp files go. That structure can’t be secured, avoid that. Basically the temp files go in somewhere that’s not a big pile of a “work directory” - like /tmp - and then that structure once again works!

Of course I wouldn’t say no to an LCARS theme either…

Any plans for OIDC and read-only/non-root/no-cap container running?

I have a USB drive with the key on it. The primary purpose for LUKS for me is so that drives I replace don’t need to be wiped, so I just leave the USB drive in all the time. Makes it so it boots automatically.

If I lived in a place I owned, I’d stash a rpi somewhere deep and have it do network dropbear automatic unlock to protect the data if the server is nicked. Till then it’s yolo

The smlight slzb-mr2 does both and is PoE - makes it more robust. HA comp goes down? Restarts? USB port change and now the passthrough fails? With an independent LAN coordinator the zigbee network is fine. I don’t have threads stuff (yet) but I assume the same applies.

I’ve had no issues, the Ukrainians already got this solved. Get from Ali express (Ukrainians don’t produce them, they’re busy being bombed)

So you don’t need that set up. Moca is well designed to be Omni-directional.

You do need to put a moca filter in that shitass box between the cable that comes from the outside world and whatever hellsplitting is going on in there. That’s to keep your personal moca network inside so peeps can’t snoop (it’s also encrypted) or cause interference elsewhere.

Note that you may need to update your splitters and coax wall keystones to be 1+ GHz friendly for Moca. I found where I am has “black” rings on the coax wall keystones that only did the regular cable freq and Moca failed to work. Replaced with modern “blue” rings that do the Moca freq range. And splitters involved in the routing too.

I have the line in inside, in a panel. It splits 3 ways, and I use that 3 way splitter as a “dumb switch”, replaced with a Moca friendly one. Moca filter between splitter and line in.

I have modem/router in living room, connected to a switch. Switch also connects to a Moca adapter. Computer in bed room, connected to Moca adapter. I get ballin’ 1 Gbps up and down at the same time (within my network of course, real internet speeds are ass

May these facts I typed from memory help you achieve your networking dreams :)

Arch’s design is key for user devices - it gets you the fixes you need now with good enough guard rails that usually it’s all good!

But that’s not the design you want for a 24/7 server that’s likely headless. You want that server to have the security updates and to get them installed asap without worry about stability. Literally for years now I’ve never had unattended upgrades cause any issue, and I’ve taken that system from 11 to 13 now. And I’ll look at in a month (maybe) while it continues to do DNS and serve up vidz

Debian on a laptop would be akin to a skeleton waiting on food/water; you’ll get that fix for sleep in 14 (maybe). It’s workable - just like Arch is workable for a server - but it’s just not the ideal role.

Both designs exist for a reason though, and that’s cause they both have their strengths!

Reading that is wild

Why are you doing Arch on a server? You want to tinker forever and read the update notes like a hawk lest the server implode forever?

Arch isn’t gonna be noticeably leaner than Debian.

Get Debian, install docker and/or podman, set unattended upgrades, and then install Incus if you need VMs or containers down the line. You can stick on ZFS and it’ll be fine, you already have BTRFS for basic mirrors. Install Cockpit and you’ll have a nice GUI. Try not to think you have to fiddle with settings, the maintainers for each package/service have set it so it works for most people (and we’re most people!); you’ll only need to intervene on an handful of package configs. All set and it’s not proprietary.

One of the best uses of encryption is that you can pull drives that die and not have to try to wipe them as they die or smash them. They’re encrypted so it’s just gibberish. Mostly the reason to encrypt.

I auto-unlock with two things: a USB drive I put in the computer that it looks for and another computer on the network that hosts an unlock file. I’m not defending against nation-states or the Gestapo, regular rubes won’t notice the pi zero hidden that hosts the network file. USB drive is for just-in-case so I don’t have to type that long ass password ever.

I didn’t try hard, but I’m not sure how to make auto-unlocking more secure.

I put a tiny NAS in my parents’ house (cheapest ARM synology 2-bay). It backs up their computers (a first, of course, but the photos are safe now!) and my server sends its TBs to there too. Upfront is large because you need to put in two big drives plus a lil NAS. But no $/mo, thanks parents.

For over a few TB Hetzner and the like really hit hard (€21/mo for 10TB at Hetzner storage box). Depends how much disposable income you have/want to ensure data is good. Now-a-days €21/mo is like 1 Disney/Hulu/bullshit, that price is obviously over inflated but it makes you feel less bad about spending it on cold, hard, remote backups of your big ass data.

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.

I’ve been thinking about using client-side certificates that are validated by Caddy to bypass the Authentik wall (proxy provider) I use. I’ll give it a shot some time, it’s a good idea