this post was submitted on 13 Mar 2024
71 points (90.8% liked)

Selfhosted

39271 readers
183 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
 

You may have noticed a few of my posts here, I am very interested in self-hosting and what advice can you give to a newbie? maybe some literature, video, I don’t know~

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 49 points 6 months ago* (last edited 6 months ago) (4 children)

I have multiple servers with about two dozen self-hosted services I run. It all started ten years ago, torrenting shows and then automating. And now everything in my life is self-hosted and backed up. But if I showed my current configuration to me 10 years ago, it would look undoable, completely out of reach. So my suggestion to you is to pick one project that you like, build it. Make mistakes. Fix those mistakes. If you want to access it from outside your network, use WireGuard so that nobody else can have access to your system and find your mistakes for you.

Don't ask for advice. Don't ask for opinions. That's like going into a religion conference and asking which is the right God. You're going to have a bunch of very passionate people telling you a bunch of things you don't understand when all you want to do is tinker. So fuck all those people, just start tinkering.

Finally, Don't host any mission critical shit until you have backups that are tested after multiple iterations. I have fucked up so bad that I have had to reformat discs. I have fucked up so bad that data has just gone missing. I have fucked up so bad that discs have overflowed with backups and corrupted the data and the backups themselves. It was all fun as shit. Because none of it was important. Everything important was somewhere else. The only rule is the 3-2-1 rule, otherwise go fuck up and come back when you dead end on an issue.

Pro tip, use ZFS and take snapshots before you make any changes. Then you can roll back your system if you fuck up. I just implemented it this year and it has saved me so many headaches.

[–] [email protected] 7 points 6 months ago

I definitely agree on starting to tinker right away and to setup snapshot/backup for your stuff and then break it. It also makes one learn how to roll back and restore which is as important as setting up the snapshot/backup in the first place.

[–] [email protected] 5 points 6 months ago (1 children)

Ditto. Started 20 years ago with one service I wanted. Complicated it a little more every time some new use case or interesting trinket came up, and now it's the most complicated network in the neighborhood. Weekend projects once a year add up.

If you have the resources, experiment with new services on a completely different server than everything else. The testing-production model exists for a reason: backups are good, but restoring everything is a pain in the ass.

I also like to keep a text editor open and paste everything I'm doing, as I do it, into that window. Clean it up a little, and you've got documentation for when you eventually have to change/fix it.

[–] [email protected] 4 points 6 months ago (1 children)

I also like to keep a text editor open and paste everything I’m doing, as I do it, into that window. Clean it up a little, and you’ve got documentation for when you eventually have to change/fix it.

Smart stuff that is leaving me feeling dumb for not having thought of it myself, shell history is a poor substitute.

[–] [email protected] 3 points 6 months ago* (last edited 6 months ago) (1 children)

For linux this is as easy as script , ex:
[user@fedoragaming ~]$ script 20240313InstallingJellyfin.log
Script started, output log file is '20240313InstallingJellyfin.log'.
[user@fedoragaming ~]$ exit
exit
Script done.

edit: and for Windows I recommend using putty, it can also save sessions to logs.

[–] [email protected] 2 points 6 months ago
[–] [email protected] 3 points 6 months ago

Wow, all hail MiltownClown, our Self-host mascot. That's some impressive host count! I wouldn't want to manage all that (I'm a documentation fiend, so that just feels like a lot of work).

Great advice, and I'd like to reiterate your ideas about backup and snapshotting. This ability to revert near-instantly is just fantastic, and 90% of the reason I've been running VM's on my laptops for 15+ years.

OP - separate everything into lab and production, starting with your network. Test everything in your lab, then move it to production when you've ironed out the kinks.

[–] [email protected] 0 points 6 months ago

Pro tip, use ZFS and take snapshots before you make any changes

Yes, but BTRFS does the same and is way easier for beginners :).