A short story on why I still go through the effort of self hosting servers and some things it taught me recently.
  • ericjmorey@programming.devEnglish
    1·
    1 month ago

    Nice article.

    why bother? Why I self host

    Most of this article is not purely about that question, but I dislike clickbait, so I’ll actually answer the question from the title: Two reasons.

    First of all, I like to be independent - or at least, as much as I can. Same reason we have backup power, why I know how to bake bread, preserve food, and generally LARP as a grandmother desperate to feed her 12 grandchildren until they are no longer capable of self propelled movement. It makes me reasonably independent of whatever evil scheme your local $MEGA_CORP is up to these days (hint: it’s probably a subscription).

    It’s basically the Linux and Firefox argument - competition is good, and freedom is too.

    If that’s too abstract for you, and what this article is really about, is the fact that it teaches you a lot and that is a truth I hold to be self-evident: Learning things is good & useful.

    Turns out, forcing yourself to either do something you don’t do every day, or to get better at something you do occasionally, or to simply learn something that sounds fun makes you better at it. Wild concept, I know.

    Contents

    Introduction
    My Services
    Why I self host
    Reasoning about complex systems
    Things that broke in the last 6 months
    Things I learned (or recalled) in the last 6 months

    • You can self host VS Code
    • UPS batteries die silently and quicker than you think
    • Redundant DNS is good DNS
    • Raspberry PIs run ARN, Proxmox does not
    • zfs + Proxmox eat memmory and will OOM kill your VMS
    • The mystery of random crashes (Is it hardware? It’s always hardware.)
    • SNMP(v3) is still cool
    • Don’t trust your VPS vendor
    • Gotta go fast
    • CIFS is still not fast
    • Blob storage, blob fish, and file systems: It’s all “meh”
    • CrowdSec

    Conclusion

    • FlightyPenguin@lemmy.worldEnglish
      0·
      1 month ago

      Highly recommend. I moved my web hosting from my home server to a CPX11 server for better uptime (my tinkering around in the homelab was always bringing things down) and couldn’t be happier. It’s dirt cheap (cheaper than shared web hosting, even), performant (performance is better than shared web hosting) and reliable. With a 20TB bandwidth limit at the lowest tier, I can reverse proxy for most of my homelab, too.

  • schizo@forum.uncomfortable.businessEnglish
    0·
    1 month ago

    Good post; kinda surprised sshfs is outperforming cifs and makes me need to take a second look at that because, boy, do I ever not like how samba performs, though I’m willing to chalk some of that up to configuration weirdness on my end since I have samba configured to allow any version of Windows that could ever connect to smb/cifs shares to be able to. (Retro computing yay.)

    Also, I’d also like to toss in iDrive e2 as a cheap S3 blob storage provider.

    I’m paying ~$30 a year for 1tb, with “free” egress. (They operate on the IT’S ON SALE! pricing nonsense so your price will certainly vary because well, it’s always on sale, but always different amounts but $30 is the usualish price.)

    You get zero useful support, less than the best performance I’ve ever seen, but it’s shockingly cheap and in the last ~2 years (out of the VA datacenter) I’ve had exactly ONE downtime where it wasn’t working, for about three hours.

    Good enough to stuff server backups and object storage for a couple of websites.

    Oh, and “free” egress means up to 3x the amount you have stored, so it’s probably bad if your majority use is going to be public downloads, but if it’s not, it’ll probably never be an issue; I have like 600gb of backups sitting there so lots of buffer.

    • tal@lemmy.todayEnglish
      0·
      1 month ago

      CIFS supports leases. That is, hosts will try to ask for exclusive access to a file, so that they can assume that it hasn’t changed.

      IIRC sshfs just doesn’t care much about cache coherency across hosts and just kind of assumes that things haven’t changed underfoot, uses a timer to expire the cache.

      considers

      Honestly, with inotify, it’d probably be possible to make a newer sshfs that does support leases.

      I suspect that the Unixy thing to do is to use NFSv4 which also does cache coherency correctly.

      It is easy to deploy sshfs, though, so I do appreciate why people use it; I do so myself.

      kagis to see if anyone has benchmarks

      https://blog.ja-ke.tech/2019/08/27/nas-performance-sshfs-nfs-smb.html

      Here are some 2019 benchmarks that show NFSv4 to generally be the most-performant.

      The really obnoxious thing about NFSv4, IMHO, is that ssh is pretty trivial to set up, and sshfs just requires a working ssh connection and sshfs software installed, whereas if you want secure NFSv4, you need to set up Kerberos. Setting up Kerberos is a pain. It’s great for large organizations, but for “I have three computers that I want to make talk together”, it’s just overkill.

      EDIT: I’d also add that I kind of wish that Linux authentication were somewhat more-unified in general in 2024. You’ve got:

      • SSH keys (ssh, sshfs, mosh, tunneling network traffic over ssh connections).

      • /etc/shadow passwords (the above with ssh, plus plenty of other services like CUPS).

      • Wireguard keys

      • GPG keys (email, git commits)

      • X.509 certs (email, TLS, smartcard applications)

      • Kerberos (NFSv4, CIFS at least optionally)

      Then you’ve got various keyrings and credential caches, like ssh-agent, gpg-agent, Gnome has some keyring that can wrap ssh-agent, web browsers have a keyring…

      I mean, there’s kind of a lot of overlap among all these. Maybe one system would be too far, but I’d kind of like to have things more-unified than they are today.

      EDIT2: Apparently inotify() doesn’t let one block the operation that one is monitoring, so probably can’t use it to implement leases.