2.What do you wish you would have known as a beginner starting out?
Caddy. Once you try Caddy there's no turning back to Nginx or Apache.
this post was submitted on 30 Jul 2024
157 points (92.0% liked)
Selfhosted
39937 readers
358 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:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
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.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 1 year ago
MODERATORS
I wish I knew not to trust closed source self-hosted applications, such as Plex. Would have saved a lot of time and money.
Can you elaborate?
Plex is a great example here. I've been Hetzner customer for many many years, and bought a lifetime license to Plex. Only to receive few months later a notification from Plex that I am no longer allowed to self-host Plex for myself(and only myself) at Hetzner and that they will block all access to my self-hosted Plex instance. I tried to ask for leniency or a refund, but that was wasted effort as well.
In short, I was caught on a crossfire when for-profit company tried to please hollywood by attempting to reduce piracy, so they could get new VC funding.
...
I am now a happy Jellyfin user and warmly recommend all Plex users to try it, the Jellyfin community is awesome!
(Use your favourite search engine to look up "Hetzner Plex ban" for more details)
Are you still on Hetzner? How's their customer support in general?
Still with Hetzner yeah. Haven't had to deal with Hetzner customer support in the recent years at all, but they have been great in the past.
load more comments
(2 replies)
-
I've learned a number of tools I'd never used before, and refreshed my skills from when I used to be a sysadmin back in college. I can also do things other people don't loudly recommend, but fit my style (Proxmox + Puppet for VMs), which is nice. If you have the right skills, it's arbitrarily flexible.
-
What electricity costs in my area. $0.32/KWh at the wrong time of day. Pricier hardware could have saved me money in the long run. Bigger drives could also mean fewer, and thus less power consumption.
-
Google, selfhosting communities like this one, and tutorial-oriented YouTubers like NetworkChuck. Get ideas from people, learn enough to make it happen, then tweak it so you understand it. Repeat, and you'll eventually know a lot.
load more comments
(2 replies)
The big thing for #2 would be to seperate out what you actually need vs what people keep recommending.
General guidance is useful, but there's a lot of 'You need ZFS!' and 'You should use K8s!' and 'Use X software!'
My life got immensely easier when I figured out I did not need any features ZFS brought to the table, and I did not need any of the features K8s brought to the table, and that less is absolutely more. I ended up doing MergerFS with a proper offsite backup method because, well, it's shockingly low-complexity.
And I ended up doing Docker with a bunch of compose files and bind mounts, because it's shockingly low-complexity. And it's just running on Debian, instead of some OS that has a couple of layers of additional software to make things "easier" because, again, it's low-complexity.
I can re-deploy the entire stack on new hardware in about ~10 minutes (I've tested this a few times just to make sure my backup scripts work), and there's basically zero vendor tie-in or dependencies that you'd have to get working first since it's just a pile of tarballs and packages from the distro's package manager on, well, ANY distro.
I have made that migration myself going from a Raspberry PI 4 to a n100 based NAS. It was 10 minutes for the software stack as you said This not taking into account media migration which was done on the background over a few hours on WiFi (I had everything on an external hard drive at the time).
That last part is the only thing I would change about my self hosting solution. Yes, the NAS has a nice form factor, is power efficient and has so far been very optimal for my needs (no lag like rpi4), however I have seen they don’t really sell motherboard or parts to repair them. They want you to replace it with another one. Reason 2 on the same is vendor lock in. Depending on the options you select when creating the storage groups/pools (whatever they are called), you could be stuck needing to get something from the same vendor to read your data if the device stops working but the disks are salvageable. Reason 3 is they’ve had security incidents so a lot of the “features” I would not recommend using ever to avoid exposing your data to ransomware over the internet. I don’t trust their competitors either. I know how commercial software is made with the smallest amount of care for security best practices.
load more comments
(2 replies)
load more comments
(12 replies)
-
- Learning. If you ever found yourself tired of learning new things, your life is basically done.
- Cost. You already have an internet connection at home. It's practically a necessity these days. The connection is likely fast enough for most things. Renting even the most piddly of VPS is wildly expensive. Just throw a spare machine at it and go wild.
- Freedom. Your own data is constantly being collected, regurgitated, and sold back to you. More people need to care about this incessant invasion of our lives.
-
- Backups. 3 copies, on different forms of storage, in multiple PHYSICALLY distinct locations. Just when you have that teeny little imp in the back of your mind say "hmm, I should probably back up soon" -- stop everything you're doing and run a backup.
- Test your recovery! Backups are only good if you can recover from them. Many have lost data because they failed to ever fail-test their backups.
-
- Google. Legitimately the best skill you can ever attain is simply being able to search effectively and be able to learn jargon quickly. Once you have the lingo down, searches become clearer, quicker, more precise.
For #1 I would say not to focus on learning the same kind of thing that you started at some point recently. It took me a few months to get my local setup going since I would do it after work (also similar skills) and get tired of poking around.
At some point I gave up and started doing other things that brought me joy (video games, paint night with YouTube tutorials, movies/TV). When I finally decided to get back to it, it was enjoyable again. If I have to re-do it from scratch it could be done in probably a few hours or at most some nights after work and would be enjoyable since the annoying “got ya” lessons are somewhere on memory or some searches away that could be filtered much quicker.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:
| Fewer Letters | More Letters |
|---|---|
| CGNAT | Carrier-Grade NAT |
| DNS | Domain Name Service/System |
| Git | Popular version control system, primarily for code |
| HTTP | Hypertext Transfer Protocol, the Web |
| IP | Internet Protocol |
| NAS | Network-Attached Storage |
| NAT | Network Address Translation |
| NFS | Network File System, a Unix-based file-sharing protocol known for performance and efficiency |
| PiHole | Network-wide ad-blocker (DNS sinkhole) |
| Plex | Brand of media server package |
| RAID | Redundant Array of Independent Disks for mass storage |
| SMB | Server Message Block protocol for file and printer sharing; Windows-native |
| SSD | Solid State Drive mass storage |
| SSH | Secure Shell for remote terminal access |
| SSL | Secure Sockets Layer, for transparent encryption |
| TLS | Transport Layer Security, supersedes SSL |
| VPN | Virtual Private Network |
| VPS | Virtual Private Server (opposed to shared hosting) |
| ZFS | Solaris/Linux filesystem focusing on data integrity |
| k8s | Kubernetes container management package |
| nginx | Popular HTTP server |
20 acronyms in this thread; the most compressed thread commented on today has 4 acronyms.
[Thread #899 for this sub, first seen 30th Jul 2024, 23:35] [FAQ] [Full list] [Contact] [Source code]
I'll parrot the top reply from Reddit on that one: to me, self hosting starts as a learning journey. There's no right or wrong way, if anything I intentionally do whacky weird things to test the limits of my knowledge. The mistakes and troubles are when you learn. You don't really understand the significance of good backups until you had to restore from them.
Even in production, it differs wildly. I have customers whom I set up a bare metal Ubuntu in some datacenter for cheap, they've been running on that setup for 10 years. Small mom and pop shop, they will never need a whole cluster of machines. Then at my day job we're looking at things like Kubernetes and very heavyweight stacks because we handle a lot of traffic.
Some people self-host a PiHole on a Raspberry Pi and that's all they need. Some people have entire NAS setups with smart TVs accessing their Plex/Jellyfin servers for the whole extended family. I host my own emails, which is a pain in the ass to get working reliably and clean your IP reputation.
I guess the only thing you should know is, you need some time to commit to maintaining your stuff if you don't want it to break or get breached (if exposed to the Internet), and a willingness to learn because self hosting isn't a turnkey experience. It can be a turnkey installation but when your SD card/drives fails you're still on your own to troubleshoot and fix it. You don't set a NextCloud server to replace Google Drive with the expectation that you shove the server in a closet forever. Owning your infrastructure and data comes at a small but very important upkeep time investment.
I would've wished
- don't rush things into production.
- dont offer a service to a friend without really knowing and having the experience to keep it up when needed.
- dont make it your life. The services are there to help you, not to be your life.
- use docker. Podman is not yet ready for mainstream, in my experience. When the services move to podman officially it's time to move. Just because jellyfin offers official documentation for it, doesn't mean it'll work with podman (my experience)
- just test all services with the base docker install. If something isn't working, there may be a bug or two. Report if it is a bug. Hunt a bug down if you can. maybe it's just something that isn't documented (well enough) for a beginner.
- start on your own machine before getting a server. A pi is enough for lightweight stuff but probably not for a fast and smooth experience with e.g. nextcloud.
- backup.
- search for help. If not available in a forum. ask for help. Dont waste many many hours if something isnt working. But research it first and read the documentation.
Podman is not yet ready for mainstream, in my experience
My experience varies wildly from yours, so please don't take this bit as gospel.
Have yet to find a container that doesn't work perfectly well in podman. The options may not be the same. Most issues I've found with running containers boil down to things that would be equally a problem in docker. A sample:
- "rootless" containers are hard to configure. It can almost always be fixed with "--privileged" or some combination of permission flags. This would be equally true for docker; the only meaningful difference is podman tries to push everything into rootless. You don't have to.
- network filesystems cause headaches, especially smbfs + sqlite app. I've had to use NFS or ext4 inside a network-mounted image for some apps. This problem is identical for docker.
- container networking--for specific cases--needs to managed carefully. These cases are identical for docker.
And that's it. I generally run things once from the podman command line, then use podlet to create a quadlet out of that configuration, something you can't do with docker. If you are having any trouble with running containers under podman, try the --privileged shortcut, see that it works, and then double back if you think you really need rootless.
-
data stays local for the most part. Every file you send to the cloud becomes property of the cloud. Yeah, you get access, but so does the hosting provider, their 3rd party resources, and typical government compliances. Hard drives are cheap and fast enough.
-
not quite answering this right, but I very much enjoy learning and evolving. But technology changes and sometimes implementing new software like caddy/traefik on existing setups is a PITA! I suppose if I went back in time, I would tell myself to do it the hard way and save a headache later. I wouldn't have listened to me though.
-
Portainer is so nice, but has quirks. It's no replacement for the command line, but wow, does it save time. The console is nerdy, but when time is on the line, find a good GUI.
For item #1, self hosted solutions like home assistant also allow using “smart” devices without the cloud in some instances. You are not at the mercy of a vendor going out of business or dropping support and your devices becoming bricks.
Not all devices are compatible, but from what I’ve learned, I would never buy another device with so called “smart” features if it is not compatible with home assistant.
My reason for self hosting is being in control of my shit, and not the cloud provider.
I run jellyfin, soulseek, freshRSS, audiobookshelf and nextcloud. All of that on a pi 4 with an SSD attached and then accessible via wireguard. Also that sad is accessible as nfs share.
As I had already known Linux very well before I've started my own cloud, I didn't really had to learn much.
The biggest resource I could recommend is that GitHub repository where a huge amount of awesomely selfhosted solutions are linked.