I've written a series of blog posts about a "hands-off" self-hosting setup intended for relative beginners. (cyclicircuit.prose.sh)
from cyclicircuit@lemmy.dbzer0.com to selfhosted@lemmy.world on 01 Jul 17:06
https://lemmy.dbzer0.com/post/48066303

Recently, I’ve found myself walking several friends through what is essentially the same basic setup:

After realizing that this setup is generally pretty good for relative newcomers to self-hosting and is pretty stable (in the sense that it runs for a while and remains up-to-date without much human interference) I decided that I should write a few blog posts about how it works so that other people can set it up for themselves.

As of right now, there’s:

Coming soon:

Constructive feedback is always appreciated.

EDIT: Forgot to mention that I am planning a backups article

#selfhosted

threaded - newest

myrmidex@belgae.social on 01 Jul 17:45 next collapse

Nice, thanks for that! Bonus points for using DockGE, I prefer that over portainer as well!

alekwithak@lemmy.world on 01 Jul 17:49 next collapse

Hell yeah, dude.

selokichtli@lemmy.ml on 01 Jul 17:52 next collapse

This is appreciated. As a hobbyist, I feel like my setup is hold by pins.

EDIT: I rely on Nextcloud, BTW.

hperrin@lemmy.ca on 01 Jul 17:55 next collapse

This is very cool, but also very dangerous. Many projects release versions that need some sort of manual intervention to be updated, and automatically updating to new versions on docker can lead to data loss in those situations.

Here’s a recent example from Immich:

github.com/immich-app/immich/releases/…/v1.133.0

It is my humble opinion that teaching newbies to do automatic updates will cause them to lose data and break things, which will probably sour them from ever self hosting again.

Automatic OS updates are fine, and docker update notifications are fine, but automatic docker updates are just too dangerous.

cyclicircuit@lemmy.dbzer0.com on 01 Jul 17:59 next collapse

That’s reasonable, however, my personal bias is towards security and I feel like if I don’t push people towards automated updates, they will leave vulnerable, un-updated containers exposed to the web. I think a better approach would be to push for backups with versioning. I forgot to add that I am planning a “backups with Syncthing” article as well, I will take this into consideration, add it to the article, and use it as a way to demonstrate recovery in the event of such an issue.

Onomatopoeia@lemmy.cafe on 01 Jul 18:19 next collapse

My experience after 35 years in IT: I’ve had 10x more outages caused by automatic updates than everything else combined.

Also after 35 years of running my own stuff at home, and practically never updating anything, I’ve never had an outage caused by a lack of updates.

Let’s not act like auto updates is without risk. Just look at how often Microsoft has to roll out a fix for something an update broke. Inexperienced users are going to be clueless when an update breaks something.

We should be teaching new people how to manage systems, this includes proper update checks on a cycle, with appropriate validation that everything works afterwards, and the ability to roll back if there’s an issue.

This isn’t an Enterprise where you simply can’t manually manage updates across hundreds or thousands of servers, and tens of thousands of workstations - this is a single admin, small environment.

I do monthly update checks, update where I feel it’s warranted, and verify systems afterwards.

Mordikan@kbin.earth on 01 Jul 18:48 next collapse

This is really the truth. Auto-updating is really bad form when you are getting into server management. The first admin position I had back in the day had the rule that no automatic updates are to run, a manual update can only be run after 1 month of that update being released, and it had to accompanying documentation confirmed before it could be approved. The one time we did not follow that we ended up having to re-image the server in question from backup (as that was the quickest solution to getting it back online).

cyclicircuit@lemmy.dbzer0.com on 01 Jul 20:12 next collapse

I don’t disagree with any of that, I’m merely making a different value judgement - namely that a breach that could’ve been prevented by automatic updates is worse than an outage caused by the same.

I will however make this choice more explicit in the articles and outline the risks.

WhyJiffie@sh.itjust.works on 01 Jul 21:56 next collapse

with properly limited access the breach is much, much less likely, and an update bringing down an important service at the bad moment does not need to be a thing

ikidd@lemmy.world on 02 Jul 21:55 collapse

Don’t expose anything outside of the tailnet and 99% of the potential problems are gone. Noobs should not expose services across a firewall. Period.

MrShankles@reddthat.com on 02 Jul 22:17 collapse

Well, you just saved me a bunch of time trying to figure out how to auto-update my humble little server. Granted, I only have Plex and Samba Share right now, but I like the principle. Hell, an update once blanked my smb config file for whatever reason

Now auto-backups are another thing; because I would like to use a .tar file, but then it leads me down a rabbit hole because I don’t know how to repair Grub if needed for a restore, or what Grub really even is vs Bios… I’ve just been learning as I go

I’m a few weeks away from getting a couple parts for an upgrade, and then it’ll be some fun. I want to redo it from scratch and maybe set up proxmox and change my file system to zfs, then start looking at docker, figure out Jellyfin and look at some ARR stuff… maybe tailscale or headscale. Idk, it’s just fun cause it’s a hobby. I just haven’t had the storage or ram really, but soon

WhyJiffie@sh.itjust.works on 01 Jul 21:53 next collapse

it’ll still cause downtime, and they’ll probably have a hard time restoring from backup for the first few times it happens, if not for other reason then stress. especially when it updates the wrong moment, or wrong day.

they will leave vulnerable, un-updated containers exposed to the web

that’s the point. Services shouldn’t be exposed to the web, unless the person really knows what they are doing, took the precautions, and applies updates soon after release.

exposing it to the VPN and to tge LAN should be plenty for most. there’s still a risk, but much lower

“backups with Syncthing”

Consider warning the reader that it will not be obvious if backups have stopped, or if a sync folder on the backup pc is in an inconsistent state because of it, as errors are only shown on the web interface or third party tools

cyclicircuit@lemmy.dbzer0.com on 01 Jul 22:33 collapse

Yeah I agree with the warnings. One of the things I’m trying to ensure I get across accurately (which will be discussed later in the series) is how to do monitoring. Making sure backups are functioning properly would need to be a part of that.

LandedGentry@lemmy.zip on 02 Jul 14:41 next collapse

I’m with you on this. It has to feel at least somewhat low-fuss/turnkey or people aren’t going to stick with it. The people who don’t get this are the same people who can’t see why Plex is more popular than Jellyfin despite the latter’s overall superiority

rumba@lemmy.zip on 02 Jul 22:22 next collapse

Been in it since the web was a thing. I agree wholeheartedly. If people don’t run auto updates and newbies will not run manual updates, You’re just teaching them how to make vulnerabilities.

Let them learn how to fix an automatic update failure rather than how to recover from ransomware. No contest here.

non_burglar@lemmy.world on 03 Jul 14:05 collapse

You say this as though security is naturally a consideration for most docker images.

talentedkiwi@sh.itjust.works on 01 Jul 18:51 next collapse

I use diun for update notifications. I wish there was something that could send me a notification, and if I gave it an okay or whatever it would apply the update. Maybe with release notes for the latest version so I could quickly judge if I need to do anything besides update.

illusionist@lemmy.zip on 01 Jul 20:07 collapse

Immich is still unstable. This shouldn’t happen to a stable project.

What it tells me is that you need a regular backup

hperrin@lemmy.ca on 01 Jul 20:54 collapse

This absolutely can happen to stable projects. This has happened with Mastodon many times, and Mastodon has been stable for years.

It also has happened with Nextcloud many times, and again, Nextcloud has been stable for years.

It’s not a stability thing, it’s an automation thing. We as devs can only automate so much. At a certain point, it becomes up to you, as the administrator, to manually change things. Things like infrastructure changes, and database migrations, where the potential downtime if we automate it is something we need to consider.

illusionist@lemmy.zip on 01 Jul 21:04 collapse

Your probably right, you can’t catch each bug I guess

cyclicircuit@lemmy.dbzer0.com on 01 Jul 18:15 next collapse

Naturally, the same day that I publish this, I discover that Watchtower is semi-abandoned, so I’m gonna have to look into alternatives to that…

irmadlad@lemmy.world on 01 Jul 18:40 next collapse

Just call me Mr. BuzzKill. LOL I learned that there is a fork at watchtower.devcdn.net. Deployed it yesterday, and for the first round of updates, everything went as it should. No runs, no drips, no errors. Time will tell.

cyclicircuit@lemmy.dbzer0.com on 01 Jul 19:33 collapse

Sweet! Thank you! I’ll test it out and update the blog posts to reflect that

possiblylinux127@lemmy.zip on 02 Jul 13:51 collapse

Podman has optional autoupdates

FarraigePlaisteach@lemmy.world on 01 Jul 18:57 next collapse

In case it’s of help, a common problem I find with guides in general is that they assume I don’t already use Apache (or some other service), and describe as though I’m starting with a clean system. As a newbie, it’s hard to know what damage the instructions will do to existing services, or how to adapt the instructions.

Since docker came along it’s gotten easier, and I’ve learned enough about ports etc to be able to avoid collisions. But it would be great if guides and tutorials in general covered that situation.

cyclicircuit@lemmy.dbzer0.com on 01 Jul 19:34 collapse

Hmmmm that’s a good point. I’ll try to work. that in P: cause Tailscale can cause issues if you’re already doing Wireguard or something.

oyzmo@lemmy.world on 01 Jul 19:00 next collapse

Thanks 😊👌🏻

some_guy@lemmy.sdf.org on 01 Jul 19:07 next collapse

Even though I’m already experienced in self-hosting, I absolutely love that you’re making this available. We need more on-ramps for newbies. Cheers!

gedaliyah@lemmy.world on 01 Jul 19:42 next collapse

This is great, thanks!

Wispy2891@lemmy.world on 01 Jul 20:29 next collapse

Set up automatic updates

Immich

You like to live dangerously, right?

metaStatic@kbin.earth on 01 Jul 20:41 next collapse

Raid is a backup

nis@feddit.dk on 01 Jul 20:59 collapse

Here. You dropped this: /s

cyclicircuit@lemmy.dbzer0.com on 01 Jul 22:35 next collapse

Yeah a little xD but FWIW this article series is based on what I personally run (and have set up for several friends) and its been doing pretty well for at least a year.

But I have backups which can be used to recover from the issues with breaking updates.

possiblylinux127@lemmy.zip on 02 Jul 13:50 collapse

Photoprism > Immich

curled@lemmy.dbzer0.com on 02 Jul 14:29 collapse

I haven’t tried photoprism in a while, but when I tried it, it wasn’t even close.

Photoprism seems more suited if you’re a photographer to index your professional work where immich aims to be a google photos/icloud alternative.

Immich has native mobile apps to do the syncing and provide a (great) interface for search, it has much better multi-user support, including sharing albums, and much more features than I’m willing to type out here.

The only thing missing, for me at least, is better support for local files to eliminate the need for another gallery app/file picker.

hperrin@lemmy.ca on 01 Jul 21:21 next collapse

Something really fun I found out recently, when my friend lost all access to his system except for a single WebDAV share by accidentally turning off all his remote admin access:

If you write “b” to /proc/sysrq-trigger, it will immediately reboot the system (like holding down the reset button, so inherently a bit dangerous).

He was running Nephele with / mounted as the share, so luckily he just uploaded that file with a single “b” in it, and all his remote admin stuff came back up after the reboot.

WhyJiffie@sh.itjust.works on 01 Jul 21:42 collapse

that’s horrible and funny at the same time.

I will assume they fixed that vuln later

hperrin@lemmy.ca on 02 Jul 00:29 collapse

That’s not a vulnerability. That’s intended and desired behavior. It was really useful in this case too.

I should mention that the WebDAV share is password protected, so only he has access to do that.

WhyJiffie@sh.itjust.works on 02 Jul 12:07 collapse

ok, a backdoor then. can they overwrite any file with it?

hperrin@lemmy.ca on 02 Jul 16:00 collapse

It’s their machine. It’s a front door.

lol_idk@lemmy.ml on 03 Jul 14:25 next collapse

Did I miss the part where we set up the server?

anzo@programming.dev on 03 Jul 14:56 collapse

Try Pangolin instead of cloudfare, though it requires a VPS (e.g. oracle free tier, or pay €1/month to ionos)