(Justin)
Tech nerd from Sweden
Self hosting can save a lot of money compared to Google or aws. Also, self hosting doesn’t make you vulnerable to DDOS, you can be DDOSed even without a home server.
You don’t need VLANs to keep your network secure, but you should make sure than any self hosted service isn’t unnecessarily opens up tot he internet, and make sure that all your services are up to date.
What services are you planning to run? I could help suggest a threat model and security policy.
It’s an algorithm for determining how fast to upload packets. This article just talks about how to enable it.
Here’s the Wikipedia section about it: https://en.wikipedia.org/wiki/TCP_congestion_control#TCP_BBR
The gist is that instead of only throttling upload rate based on packet loss, BBR constantly measures roundtrip delay (ping) to determine how much bandwidth is available.
Yeah, there’s definitely a learning curve since it’s so different from docker, but there are some good tutorials and everything just makes sense. All the error messages are googlable and everything fits together so well.
Kubernetes has user accounts that you could use to restart containers in an unprivileged way. Create a role and role binding that gives the “delete Pod” permission to a service account. Kind makes it very easy to run Kubernetes without any setup. You’d just need to convert your docker compose files to Deployments, Services, and PersistentVolumes.
If converting to a kubernetes setup is too big of a leap, you could maybe try to write a C program that uses setuid to gain docker privileges in a restricted way.
Probably easiest to just have a cronjob that restarts the container regularly, though.
Your internet/wifi seems really overloaded, average ping rtt should be under 100ms, not 712ms. Your wifi signal might be bad, a computer may be downloading/uploading a lot of data, or there is an issue with your internet line.
Double check your wifi signal and computer traffic, maybe try using a direct wired ethernet connection and disconnecting all other computers. Otherwise, contact your ISP with these ping results and speed results from speedtest.net.
Check for PSI stalling in htop (add PSI meters for cpu, ram, and io in the config menu), to rule out your system being overloaded. Check internet connectivity with ping 1.1.1.1, and see why registry is timing out with curl -v https://registry-1.docker.io/v2/
You can also test your dns servers if you think that they are an issue with
dig registry-1.docker.io @1.1.1.1
dig registry-1.docker.io @194.168.4.100
If the dig command outputs differ from each other, then it is likely that your ISP’s DNS servers are faulty and you should switch nameservers to 1.1.1.1 and 1.0.0.1 like the other commenter said.
docker compose isn’t really scalable. If you need automatic, hgih availability load balancing, you should look into Kubernetes Ingress.
I’m not an economics major, but maybe something like a blind auction every year, and if you owned the domain last year, you also have the option of matching the highest bidder to keep the domain.
The biggest flaw with a system like that is that it would still discourage trying to buy an already owned domain, since you could pay for it, but not actually get it if the owner exercises their matching right. But it would definitely discourage domain squatting since the more other people want your domain, the more you have to pay to keep it.
scp is one of the best options. You could also try sshfs if you want something more interactive.
This wiki page has an example on how to do automatic updates on a normal install of nixos:
https://nixos.wiki/wiki/Automatic_system_upgrades
But this won’t work for nixos-generate because nixos-generate doesn’t have a configuration.nix file in the booted system.
Here is the code I use for my nixos-generate flake that I use to generate all of the nixos images in my homelab:
The way this works is that it includes the flake source code as a folder in the nix store on the booted system, and the nixos-upgrade timer will then use the flake to build an updated version of itself. Note that nixos-generate uses the packages output of the flake, while nixos-upgrade uses the nixosConfigurations output of the flake. I have written the flake so that they build identical systems, but it means there’s some code that I had to write twice in flake.nix.
Feel free to try it out yourself, though note that you will probably have to rip out the agenix stuff to get it to build.
Nixos isnt really that user friendly yet, but insanely powerful once you understand how it works. Feel free to ask questions if anything seems confusing.
NixOS works really well as an image based server. Use nixos-generate to create a pre-configured image and put it on a flash drive/PXE share, and you’re good to go. Automatic updates are a bit confusing and not really documented, but doable. I have code examples.
There’s a wid range of opinions on this. Some people only access their services via tunnel, some people open most of their services up to the internet, as long as they’re authenticated. One useful option for https services is to put them behind a reverse proxy that require oauth authentication, which allows you to have services over the internet, without increasing your attack surface. But that breaks apps like Nextcloud and Lemmy, so it’s not a universal option.
That requires running either systemd or dockerd to work.
Docker containers often need to be restarted if they crash, I’m not aware of a solution for this that isn’t a monolithic service orchestrator, like systemd, dockerd, or containerd.
I’ve never used it, but I believe cockroachdb is also an option for multi-region replication.
In Swedish, we have the word “riktig”, but I guess that’s a bit of a shifted cognate, since it means “real”.
I think Lemmy is glitching out here. My comment was a reply to a now deleted comment by just_another_person. It seems that after the comment was deleted, it messed up how the thread appears. Sorry for the confusion.
OP is asking for a guard dog to keep robbers from walking through their unlocked door. I’m telling OP to just lock their door and don’t bother with a guard dog.
I respectfully disagree. Containers are 100% the right choice in this situation. They provide the defense-in-depth and access controls that combat the threats that OP is targeting by using ClamAV.
The goal isn’t securing a single database through a single attack vector. And it’s not like ClamAV would help you with that, either. The goal is preventing attackers from using your infra’s broad attack surface to get inside, and then persisting and pivoting to get to that database.
It’s just not true that you can get the same level of security by running everything bare-metal, especially as a one-man, self-hosted operation.
Coops are still about the money. They’re about saving money by sharing resources with fellow workers/consumers, and maintaining democratic control over the company. You’re not going to get rich from a coop (without embezzlement), but you and your coowners will be cutting out the middle man. Obviously, it only makes sense for industries that you’re heavily invested in.