Just a bit or a wandering mind on my part but one of the issues in the back of my mind is what happens to whatever self hosting I setup if something happens to me.

Ideally I’d like to be able to know that in case of emergency Id be able rely on a good friend or two to keep things going.

My thought was that would require some common design patterns/ processes and standardisation.

I also have these thoughts because eventually Id like to support other family members with self hosted services at their places. Standardising hardware, configurations etc makes that much simpler.

How have others approached this?

  • helpimnotdrowning@lemmy.sdf.org
    link
    fedilink
    English
    arrow-up
    9
    ·
    4 months ago

    I’ve acknowledged that, while convenient, my (small) setup is still a burden that I would be asking someone to take. If your friends don’t already share your passion or knowledge for Linux/Docker/the intricacies of <whatever you may be running>, I doubt they’d be willing to take on what you leave them.

    My friends had a family member who had a giant setup of Raspberry Pi’s that did Pi-hole, Home Assistant, F@H, among many other services and machines (there were like 6 Pi s!). They passed some time ago, and there’s just no one in the family who was willing to take on the responsibility to learn how to manage everything that was going on—services have been slowly degrading/going down since then.

    Those who rely on your services will just go back to using Google Drive, watch-anime-free.org.ru, and pressing “Open LAN world” in the Minecraft client. I don’t think it’s okay, but if you’re out of the game, you won’t be there to object.


    That is to say, if you DO have friends that are knowing and willing, you need to leave plenty of good documentation. I haven’t been one to write much of anything, and I’ve already fucked up my shell profiles again because of no documentation, but I can give some general pointers:

    • What runs where?
    • Why are things configured in certain ways? (ie “$GameServer gets 4gb because going over creates GC stutters”, “$IP is blocked because of telemetry”, “$File is symlinked to /dev/null to effectively delete/override a rule from $SomewhereElse”)
    • List rules and their exceptions. (ie “Service ports are numbered this way because it looks nice”, “Except $Port because it conflicts with $SystemService”)
    • List things even if they’re from personal preference (ie “Service ports are numbered this way because it looks nice”, tells user that these are effectively meaningless and things shouldn’t break by changing these, barring common sense)

    Basically, leave meaningful comments that explain why something is the way that it is. You should be able to use this documentation yourself as reference material. Keep this documentation updated regularly, as frequently quoted “bad documentation is worse than no documentation” (or something like that)

    (sorry if this last section in particular doesn’t make much sense, I haven’t slept in $hours. feel free to ask for clarification!)

    • abeorch@lemmy.mlOP
      link
      fedilink
      English
      arrow-up
      3
      ·
      4 months ago

      Yeah I have some friends. Id like to make it easier for them. (With some recognition as well)