PupBiru

kinda the same reason people suggest something like linux mint over slackware, gentoo, arch, etc… mint is easy to install and is preconfigured to be an easy to use user desktop environment. you can configure any other option to be have like that, but they tend to be a bit more “DIY”, which is great if you know what you’re doing!

dedicated NAS OSes will have good software out of the box that make it easy to configure and manage various common disk-related configurations (RAID, SMB, NFS, etc). you can certainly do all this yourself, but it might not have a pretty, unified user interface, or you might have to deal with software that isn’t compatible with some version of a library that’s in your distro of choice… all resolvable things, but they take time to solve: anywhere from installing a package manually to applying a kernel patch and recompiling the kernel to get something to work

i’d avoid BIOS-based RAID… it doesn’t really offer many benefits over linux-based raid like MDADM, and MDADM offers a LOT of up-sides for portability, repairability, diagnostics, etc

so i just did a quick search and apparently

Starting with Gitea 1.19, Gitea Actions are available as a built-in CI/CD solution.

*edited:

also they support being a package repo, including container registry

not related to backup solution, but this is a great time to get some home monitoring sorted! put prometheus on it, run prometheus at home too, and have them monitor each other… great way to know why/when things aren’t working in general, but adds another level of confidence that your data are nice and safe

so what you ideally want is people to ONLY be able to access your backend service through caddy, so caddy should be the only one with ports publicly accessible, yes

caddy running in the same docker network as your services can talk to those services on their original ports; they don’t need to even be mapped to the host! in this case, you have 3 containers: caddy, service 1, service 2… caddy is the only one that needs to have ports forwarded and you can just forward caddy:443 and no need to worry! then caddy can talk directly to services:80 or services:443 (docker containers show up to other docker containers by their container name! so if you run eg: docker run … —name lemmy, then caddy in the same docker network would be able to connect to http://lemmy:80!)

… but if you forward say service 1 and 2 on :8443 and :9443 (without firewall, and even with it makes me uncomfortable - that’s 1 step away from a subtle security problem), someone could be able to access <yourserver>:8443, right? so they don’t have to go through caddy to get to the backend service… for some services, that can be a big deal in ways that it’s difficult to understand, so it’s best to just not allow it if possible

an alternative is to make sure your services are firewalled so that nobody from the internet can hit them, but caddy still can… but i like this less, because it’s less explicit what’s happening so it’s easier to forget about

if you’re only going to be using those services through the proxy, it can also be a useful security upgrade to not forward their ports at all, and run caddy inside docker to connect to them directly!

if you forward the ports (without firewalling them), people can connect to them directly which can be a security risk (for example, many services require a proxy to add the x-forwarded-for header to show which IP address originally made the request… if users can access the service directly, they can add this header themselves and make it appear as though they came from anywhere! even 127.0.0.1, which can sometimes bypass things like admin authentication)

useful thing to remember about these systems: you fuck up and it’s a high likelihood literally nobody at the company can do any work because all their files are inaccessible

that’s like… $10000/hr in lost man hours alone, let alone reputation from not being able to respond to customers accurately, possibly missed SLAs or other contract obligations

unless your company is all about tech, it’s highly unlikely your IT team has the skills necessary to take on that level of responsibility

totally agree with that! however, from our experience with reddit and the threadiverse, it would have been nice (not expected!) if there’d been a little bit more of a mature alternative: if we had native apps, more stability, etc…

since OSS is so damn important, it’d be worth hedging our bets: don’t expect github to implode, but understand that OSS is too important to leave in the hands of a single organisation so we should have reasonable ideas and options for what would be a good federated alternative

im sure projects that deal with things like privacy and getting around national internet blocking (things that have been removed from github for censorship or “copyright” reasons) would be keen on having options