Yeah, and I assume future me will be even dumber than present day me, so I try to make it really easy for him to find out what he needs to know.

Another good tip is to put timestamps and increase the length of your bash history. That way when I log in half a year from now I’ll know what I was up to.

All of your issues can be solved by a backup. My host went out of business. I set up a new server, pulled my backups, and was up and running in less than an hour.

I’d recommend docker compose. Each service gets its own folder inside your docker folder. All volumes are a folder in the services folder. Each night, run a script that stops all of them, starts duplicati, backs up to a remote server or webdav share or whatever, and then starts them back up again. If you want to be extra safe, back up to two locations. It’s not that complicated if it’s just your own services.

There’s no forgetting where I have something hosted. If I ssh to service.domain.tld I’m on the right server. My services are all in docker compose. All in a ~/docker/service folder, that contains all the volumes for the service. If there’s anything that needed doing, like setting up a docker network or adding a user in the cli, I have a readme file in the service’s root directory. If I need to remember literally anything about the server or service, there’s an appropriately named text file in the directory I would be in when I need to remember it.

If you just want a diagram or something, there are plenty of services online that will generate one in ASCII for you so you can make yourself a nice “network topology” readme to drop in your servers’ home directory.

Landlords are familiar with utility install people and how unpredictable they can be. Even if they get mad, this will put the blame squarely on someone else so it’s probably a good option for you. “I dunno why he put it there. You know how utility guys are. It’s the only place he’d put my hookup.”

Second this. Landlords don’t want their stuff screwed up by inexperienced tenants’ diy projects, and they don’t want to pay for something they think it’s unnecessary. I’d get an estimate for a pro to do it (could be a guy off Craigslist or whatever, just someone who does this for a living) and then just ask the landlord if they’d be alright with you paying to get it done. They’ll probably want to know exactly what they’re going to do, and they’ll likely say yes, especially since you say they already have coax running through the house.

Just FYI, koofr has a lifetime deal with 1tb costing $120. At about $4 a month for storj, you’re looking at a cost savings in just under 3 years. So if you intend to keep the storage, and assume koofr will still be there in 3 years, that’s another good way to go.

I should probably figure out discord one of these days. Thanks for letting me know that’s where to go for this project.

Wow, I asked the right person. Thanks for the info!

I’m getting a bit concerned with logseq. It’s just kind of backwards to have a web app packaged as a desktop/android app that can be hosted on a server, but you can’t store your files there. I get that they want to monetize sync, but they’re kind of bending over backwards here to not have what’s inherently a pretty reasonable feature in a web based app, and it makes me concerned about what they’re going to do with the project in the future.

Is there a way to embed portions of one page into another page, such that if you edit it on either the change shows up on both, like in logseq?

The documentation is actually pretty good, but i’ve not been able to find that feature, if it exists. That’s probably the last thing keeping me on logseq.

Everyone else is telling you to stay local, which is great advice, as far as it goes. But you said you want to host your website publicly available, so i’d recommend getting a cheap vps and starting there. It’s not on your network, so if you screw up with security, worst case is you start again from scratch. I’d recommend the cheapest virmach VM you can get, with Debian or Ubuntu, if you like snaps.

First things first, set up ssh with key based logins, with a passphrase on a non standard port (doesn’t provide security, but it will keep your logs from getting innundated immediately). Install UFW, and block all incoming traffic, allow all outgoing traffic, and limit traffic to your ssh port. Install docker and add your user to the docker group. Start learning how to use docker, compose, and as your first container, set up duplicati to back up your docker directory (including all your volumes, which I would store as folders inside your docker directory) somewhere else. I’d set it up to run every evening after you go to bed, and i’d also set a cron script to bring down all your containers before you back up, then bring them back up. Just in case.

I’ve previously had a problem with my server becoming unresponsive when running immich. It’s been a while, but I remember there being some kind of memory leak having to do with immich. It was in their GitHub issues and everything. On my system it would take about a day and a half and then ssh, along with everything else, would become unresponsive. Rebooting would fix it for a day and a half. I stopped running immich and it hasn’t happened since. I suppose you could try using a cron job to restart immich periodically and see if that resolves your problem.

I’ve read that best practice is to do a database dump, in addition to backing up all the data files. It’s my understanding that there’s a slight chance of corrupting something in the database if you don’t stop the service first, since something could be changed while you’re doing your backup.

The easiest solution for me, as well as for being able to just restore my files and start the service again somewhere else, is to stop, backup, and restart. It’s down for less than 5 minutes while i’m asleep. If I expected better uptime than that I wouldn’t be trying to self host.

FYI, if you run vaultwarden using docker compose with your data volume as a folder, all you have to do is bring it down for like 1minute, make a backup of the folders, and bring it back up. I use a cron script to do this nightly. When my vps host went out of business, I restored my docker folder to a new vps and was up and running again in a couple minutes. Also, you could easily restore it to a virtual machine, if you like. Docker with compose is extremely portable.

That’s pretty neat. I might start doing that, just for kicks.

Now that’s the kind of paranoid I was hoping to see in here. High five, pal.

Can you explain why you use onion repos? I’ve never heard of that, and I’ve heard of kind of a lot of things.

If you have the option to host physical hardware from your friend’s house, I’d go that route for the whole thing. Set it up so they can access your media server locally, maybe even immich, and VPN in for everything yourself, that way you don’t have to expose ports, except the wireguard port. Don’t acquire new content from their network unless you do it behind a good VPN with a killswitch and they know and are OK with what you’re doing.

I would personally rather have my documents, photos and media collection on a computer a friend has physical custody of than in the cloud, but that’s on you and your friend. I prefer to host vaultwarden and a notification server, in my case, gotify, on the cheapest vps I could find, which was about 12 bucks a year last I checked.

I’d also set up a tor hidden service for ssh, just so you have another way in, in case something comes up. Or you could get a cheap cellular modem and a yearly Sim card. In the US, red pocket is a good choice, with a limited option available for less than 50 bucks a year. You never know when their ISP is going to do something weird, and you’ll be able to figure it out a lot easier if you have a reliable way into your server.

You should probably think about backups too. You can obviously do a backup before you go, but you’re going to want to back up at least your new photos while you’re gone. I’d suggest looking at koofr lifetime storage plans, as they’re pretty cheap for the size.

That’s basically the same as my writeup from when I did it. Except I also had a -k all on update-initramfs. Not sure about the switches, so I’ll look into them. Thanks.

I was a bit surprised at it as well, but it doesn’t for me running Debian headless. If I reboot after a kernel update it’ll try to boot into the new kernel and fail waiting for the initramfs, but it’ll boot just fine into the previous kernel. Once I update the initramfs it works fine.

If you know what resources you used to set it up, I’d be curious to take a look and see if I missed something.