this post was submitted on 21 Sep 2024
31 points (94.3% liked)

Self-hosting

2830 readers
1 users here now

Hosting your own services. Preferably at home and on low-power or shared hardware.

Also check out:

founded 2 years ago
MODERATORS
 

Hey guys!

I want to convert my now corebooted Thinkpad T430 into a Nextcloud server and possibly more (Syncthing, maybe Tor, maybe more)

1 500GB SSD, 1 1TB SSD

Currently runs Fedora Kinoite, I could rebase to something like secureblue uCore, Fedora IoT, uBlue uCore, ...

Not sure if those would have broken configs though.

Maybe I would prefer something with slower pace, but tbh the pace of CentOS bootc becoming a thing is quite frustrating. This would likely be the perfect 'install and forget' distro for many, a KDE Image would be there in no time.

I wouldnt want to use a traditional distro, even though a base Debian or AlmaLinux/ Rockylinux (what the hell was that of a hydra? Cut off one head, spawn 2? what are the differences??) could just be fine. I used Debian in the past, it really just works.

I would like

  • Nextcloud AIO docker image, maybe with podman? It is supposedly more secure but the world runs on Docker, and all is fine. Podman is a pain quite often.
  • some nice management like Cockpit
  • dyn DNS, for example with NoIP, best free
  • secure ssh, that should be no issue
  • btrfs? or zfs? with backups to a secondary drive
  • automatic updates with snapshot creation. Atomic system would be easiest here.
  • easy to use and secure reverse proxy, with DynDNS for reliable address on the internet. NGINX, Traefik, Caddy, what is the best here??

Here I am not sure if I should use 1TB + 1TB, or 500GB used and 1TB backup. BTRFS backups can be incremental.

while I made a list of BTRFS tools I still have no idea what the best tool for this job is.

top 16 comments
sorted by: hot top controversial new old
[–] poVoq 4 points 2 months ago* (last edited 2 months ago) (1 children)

Nextcloud runs fine via Podman. Stick with Fedora, cockpit and btrfs.

Btrbk is good for snapshots and automated backups.

If the 500gb is a NVMe drive then the database will benefit from the extra r/w speed.

Nginx is great for reverse-proxying. Dehydrated is the no-BS option to generate certs, but Certbot also works.

OVH gives you free dyndns and an email address with every domain you register, good option for self-hosting.

[–] boredsquirrel 1 points 2 months ago (1 children)

Thanks for the tips!

Both SSDs are SATA and I want to LUKS encrypt both too.

So automatic updates could work, but I guess I would need to manually reboot as there is no remote LUKS unlock option. Debian has one?

That would also be a reason against Fedora with its very fast release cycle.

[–] poVoq 2 points 2 months ago (1 children)

I would carefully think about what realistic threat scenario full disk encryptio protects you from.

On a server that runs 24/7 at-rest disk encryption usually helps very little, as it will be nearly always unencrypted. But it comes with significant footguns potentially locking you out of the system and even preventing you from accessing your data. IMHO in most cases and especially for beginners I would advise against it for a home based server.

[–] boredsquirrel 1 points 2 months ago* (last edited 2 months ago) (2 children)

Hm, so when using Nextcloud, is the db itself encrypted or something?

All my devices are encrypted.

Access to the decrypted data requires RAM access, or even a cold boot attack. There are people that only use their USB 3.0 ports and desolder all the rest, because normal (non thunderbolt) USB is pretty safe and has no access to the RAM, unlike PCIe, SATA etc.

This would be fun and certaily possible modifying the hardware to fit those SSDs still inside the case could be fun too.

I have 4 enclosures for that, and using Ethernet would mean the Wifi Card (Intel AX3000, a modded 200 for mPCIe) could be removed.

https://www.spiegel.de/netzwelt/web/hardware-hacker-wie-man-einen-laptop-vor-angreifern-schuetzt-a-955702.html

Or access to the server via ssh (fail2ban, strong keys) or the admin or user nextcloud accounts (again with strong passwords and possibly TOTP or webauthn).

I already fiddled with the required Nextcloud Addons for TOTP and it worked great. Webauthn is an Android/GrapheneOS limitation poorly, maybe that gets fixed some day.

The issue of course is upgrades. I should do a second post on that topic. There are solutions for that, like mounting encrypted partitions and running Nextcloud on there. This could be automated.

For the obvious raid attack, I would have a udev rule that detects when AC is disconnected and then performs a clean shutdown.

[–] poVoq 1 points 2 months ago* (last edited 2 months ago) (1 children)

No the Nextcloud DB is not excrypted, but neither is your LUKS file system while the computer is running. Anyone getting access to the server while it is running, can access all the data unencrypted. For a server this is the much more likely scenario than for a laptop, which might get stolen while turned off.

At-rest disk encryption is useful for servers in co-location hosting, where a 3rd party might be able to pull a disk from the system, or if you are a large data-center that regularly discards old drives with customer data, and you want to ensure that no 3rd party can access that data from the discarded drives.

[–] boredsquirrel 1 points 2 months ago (1 children)

Yes the threat model is people pulling out the drive, of course.

How should they get access to the server when it is running? You still need to connect to it and log in, which wouldnt be the case.

[–] poVoq 1 points 2 months ago (1 children)

It is possible that people get access to your server while it is running via known or unkown software vulnerabilities, but that isn't really the point... all I am saying is that if you host your server at home, it is unlikely that at-rest disk-encryption does you any good and it certainly doesn't help to protect against illicit remote access.

What it does "help" is preventing you from remotely accessing your own server if it rebooted for some reason... and many other such footguns that you will experience sooner or later.

[–] boredsquirrel 1 points 2 months ago

Yes this is true. That is why a separate method would be needed, to log into and hand the password to the LUKS decrypt of the server.

I heard Debian can do this with ssh in the initramfs?

Sounds like a hella pain of course.

Alternatively I thought about using a security key to unlock, and in scenarios where I am worried about getting hardware stolen, I can pull it out and need to manually enter the password.

[–] boredsquirrel 1 points 2 months ago

The threat scenario is currently very harmless, but I had situations where Raids could be likely. This is always a shitty case, you need to hide a backup laptop in a different location etc.

But honestly I just find this security hacking a ton of fun.

[–] seaQueue@lemmy.world 3 points 2 months ago (1 children)

Does the distro even matter as long as you're comfortable with it? Most of your services (if not all) can be managed as containers. Kind of the same deal with your filesystem choice, as long as you're comfortable with it and keep regular backups you can use anything.

[–] boredsquirrel 1 points 2 months ago

Yes it does. Fedora Atomic and others could be problematic with Docker, while Docker may be less secure or whatever but is also easier.

Also the distros packages matter, etc.

[–] tux7350@lemmy.world 2 points 2 months ago* (last edited 2 months ago)

I'm going to suggest something a bit more out there. You can setup this whole thing with NixOS. I have a bunch of docker containers that run as a systemd service, declared with Nix and personally, I like it very much. It's also got everything else you want but the atomic upgrades are top tier in NixOS.

For example if you want NoIP and Cockpit just add this bit to your configuration.nix

    environment.SystemPackages =[
        pkgs.noip
        pkgs.cockpit
    ];

Adding something like docker or podman is just as easy with a one line like

    virtualisation.docker.enable = true;

There is always a bit of a learning curve when doing anything with Nix but I find the buy in to be worth it. Here's a blog post about converting docker compose files over to the Nix format. This really isnt necessary as you could just make the systemd service run a oneshot against a docker compose file but this blog has a lot of nice examples.

https://mrupnikm.github.io/en/posts/nix-docker-containers/

If you have any questions please let me know :D

[–] leetnewb@beehaw.org 2 points 2 months ago (1 children)

Atomic automatic updates with snapshot creation? Maybe consider opensuse microOS if you are going headless...didn't quite understand from your description. I have a VPS running microOS that has been doing its automatic updates/reboot thing for a year+ now without a single issue. Opensuse's rolling stuff works very well, and you get native btrfs and snapper integration out of the box.

Easy to use reverse proxy - I really like Caddy. Reading/writing the config for that clicks better for me than others.

I like the novelty of using filesystem tools for backups, but can't shake the feeling that tools like restic and borg are more widely deployed and battle tested.

[–] boredsquirrel 1 points 2 months ago (1 children)

Yes microOS ticks those 2 boxes.

Fedora on its own doesnt do backups at all, which I find crazy.

rpm-ostree or bootc though are better, as they allow rebasing, resetting etc. This is not possible with microOS, which is a huge dealbreaker for having a server that will never have the need to be reinstalled.

I will try Caddy! Did you use NGINX before?

[–] leetnewb@beehaw.org 1 points 2 months ago* (last edited 2 months ago) (1 children)

Re reverse proxies, not exactly. Tried reading vanilla nginx configs and trying to understand nginx proxy manager, couldn't grasp either. Also gave haproxy a shot.

rpm-ostree

I guess I don't exactly understand the value of rebasing the core system. Small atomic core with snapshot-based rollbacks, with containerized beyond core stuff seems to get you 99% of the way there, no?

[–] boredsquirrel 2 points 2 months ago

Rebasing is not important, for the most people.

I like to try variations of the same system, like Fedora Kinoite, uBlue kinoite-main, uBlue Aurora, secureblue Kinoite-main, went back.

But resetting is the key.

Also rebasing would allow you to switch from normal deployment to a local image host, like in your LAN. This could already be worth it if all your family uses the same system, even more a company.

You can do uBlue style stuff at home on your own server, mostly with podman and buildah