39
submitted 3 months ago by abeorch@lemmy.ml to c/selfhosted@lemmy.world

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?

top 18 comments
sorted by: hot top controversial new old
[-] tofubl@discuss.tchncs.de 18 points 3 months ago* (last edited 3 months ago)

Not about design patterns, but about making preparations: https://github.com/potatoqualitee/eol-dr

[-] Tippon@lemmy.dbzer0.com 6 points 3 months ago

That's a really good idea, thanks for the link :)

[-] abeorch@lemmy.ml 2 points 3 months ago

Useful I have some of this but not other bits. A bit morbid but Im interested in what the break glass mechanism would be.

[-] tofubl@discuss.tchncs.de 1 points 3 months ago

It's not my Github, but I think you'd do something like print and store in a safe place your trusted party has access to. My SO has my Keepass password stored in their password safe and theoretically knows (and hopefully will recall when the need arises) how to find my Keepass file, for example.

In short, it's trust. And then there's the fact that they would never voluntarily touch this stuff anyway. 😅

[-] abeorch@lemmy.ml 1 points 3 months ago

Yes definitely. Trust is the key

[-] helpimnotdrowning@lemmy.sdf.org 9 points 3 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 , 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.ml 3 points 3 months ago

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

[-] lemmyvore@feddit.nl 9 points 3 months ago

Write a document that describes the main points of your setup. That's about it. You don't have to teach them everything, just guide them. Like, if you use a certain Linux distro and Docker just say "I use Docker on Debian and the compose files are in that directory". That should be enough to get someone started if they know Linux and Docker, and if they don't they're not going to learn it from your doc, they should go looking for someone who does.

Let's face it, many of our self-hosted setups are DIY setups we make as a hobby. If you really want an out-of-the-box experience that can be administered by a non-techy there will be limits to what you can achieve.

[-] abeorch@lemmy.ml 2 points 3 months ago

Yeah . Im good with writing and try to keep things up to date ( try being the word)

Im also trying to template and standardise - Maybe need to think about a deployment process or something.

[-] Lifebandit666@feddit.uk 6 points 3 months ago

When I die my friends will miss me like usual. Then the Plex server will go down and they'll miss me all over again.

[-] thayer@lemmy.ca 3 points 3 months ago* (last edited 3 months ago)

My wife and I share a KeePass database for all of our credentials, including the keys to our digital kingdom. I document our LAN design, server setup, and general maintenance notes, which are synced between all of our devices via SyncThing.

I add notes and quick instructions to the important credentials, like "See Proxmox.md to start this service", or "This password decrypts our file server drive...to do this, open a terminal and paste the following..."

She is comfortable pasting commands into a terminal already, so if anything ever happens to me I am confident she or my son will at least be able to access our data and move it to a more user-friendly format.

Edit: Had way too many words lol

[-] abeorch@lemmy.ml 2 points 3 months ago
[-] thayer@lemmy.ca 1 points 3 months ago

Yep, that's the one. We use KeePassDX on mobile and KeePassXC on the desktop.

[-] anzo@programming.dev 3 points 3 months ago

Another consideration would be building communities around platforms and instances. That's how many of the open source world thrives!

[-] abeorch@lemmy.ml 1 points 3 months ago

Yeah this was what I was thinking. Interested in what people have out there. I dont like reinventing the wheel - Id probably make it an irregular polygon

[-] anzo@programming.dev 1 points 3 months ago

There are different approaches or sentiments that bring people together. There's for example the left-politics platform disroot.org and they have also developed some solutions of their own (as in not only hosting, but coding). Autistici colective has this calendar called ganzo or similar iirc. That's something amazing to me.

[-] abeorch@lemmy.ml 1 points 3 months ago

Im 'between' jobs at the moment. opportunities for connecting through community projects is attractive right now.

[-] abeorch@lemmy.ml 1 points 3 months ago

Interesting - I will have a look at disroot.org. Im not immediately understanding them but thats probably because where I encounter it I try to read whats available in Spanish to start.

this post was submitted on 12 Jul 2024
39 points (95.3% liked)

Selfhosted

39677 readers
462 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 1 year ago
MODERATORS