How do you keep up?
-
[email protected]replied to [email protected] last edited by
First off, backups of the configs any user data that you can't torrent should the inevitable happen.
Then set time aside to do updates, I spend Wednesday evenings updating and improving my setup.
Then find a way to track update announcements, I use both an RSS reader and newrealeases.io to know when something I run gets an update
-
[email protected]replied to [email protected] last edited by
Gentoo.
Daily automatic updates of the OS.
Services and containers are updated at random when i have time.
Its been many years, I have fun doing it.
Not a chore.
-
[email protected]replied to [email protected] last edited by
Similar to the others although I have messed with Ubuntu, CentOS, Fedora, and even a few others for like a day or two each.
At the moment I am using Fedora. My drives are raided and my main storage has all the data and the docker config directory’s.
Using docker for everything, watchtower for updates, and pertained to manage the containers with a gui. All the containers are directed to /mnt/drive/allMyData. In there is my data folders. Shows, movies, plex configs for recording over the air, ebooks, documents, etc.
Mainly I set it up this way so I can easily change distros if I wanted to and have all my services back up in an hour or so.
I started a text file that contains the command lines I have used to start all of my docker containers. This way if I need to I reference it and use the exact same commands mapped volumes to the same folders. Now I am back up and running in a few clicks. No need to backup the container if all the data in it is setup in folders in my main data directory.
However I am running a separate hardware raid setup prior to os. This way all my data stays safe as a separate volume.
-
[email protected]replied to [email protected] last edited by
I run Debian on most of my systems and run all of my services in docker (with rare exceptions for node_exporter or stable core tools). My base systems get automatic security upgrades, and then I'll manually check in every few weeks whenever I feel like it.
My services in docker are version locked to a specific major version (when there's a tag available) so I can usually re-pull to get minor version updates freely without breaking issues. My few more finnickey services get manual upgrades from me every 6 months or so only.
I usually stick to an OS version for as long as I can, and to that aim I stick to LTS versions with long support windows.
4 major versions in 12mo is...a lot. Especially if those include breaking changes for you. Yikes
-
[email protected]replied to [email protected] last edited by
Is it exposed to the internet?
Mine is local only so I’m not as diligent with updates. I push them like once every 2-3 weeks. Some containers automatically update but some don’t because in the past that has broken associated scripts
-
[email protected]replied to [email protected] last edited by
I have automatic updates on everything. If it breaks, I fix it when I have time. If I don't, it remains broken.
I could also just not do updates, but I like new features.
-
[email protected]replied to [email protected] last edited by
In life? Amphetamines.
-
[email protected]replied to [email protected] last edited by
I learned that I can't rely on someone else's recipes: in my case it was abandoned/badly configured unraid apps. I now exclusively use a docker compose yml where i control and tag specific versions. I intentionally stay behind 2 versions on nextcloud (stable = alpha; oldstable = beta), and for databases i stay on the LTS. Then i import the calendar from endoflife.date in my calendar app to see if i have to move the target up a bit.
Every once in a while i go there and i update manually everything
-
[email protected]replied to [email protected] last edited by
Unraid + Unifi network equipment. Everything is scheduled and automatic, with the exception of large Unraid updates, but those are only every ~6 months. Every night mover from cache SSD - > HDD array, then checks for plugin updates, then docker container updates, if Monday morning SSD trim, and if 1st of the month does an array parity check/repair.
After all that if it's Monday morning, Unifi will check for firmware then software updates.
Sometimes a docker container will get a breaking update maybe once a year, and then I just go look @ documentation and see what needs to be changed to the config to fix.
-
[email protected]replied to [email protected] last edited by
Use Debian LTS or Ubuntu LTS (10 years support with free Ubuntu Pro). Turn on automatic unattended updates. Upgrade OS when you're bored one of those years.
-
[email protected]replied to [email protected] last edited by
I have rss feeds for my main service updates so I know what new features I have, the services mostly run in podman containers and update automatically each Monday. I also have daily backups (timed to run just before the update on monday) in case anything does break.
If it breaks I fix it depending on how much I want/need it, mostly it's a matter of half an hour to fix it and with my current NixOS/Podman system I haven't yet needed to fix anything this year so it breaks infrequently.
Also why are you using Kubernetes on a single host if you want minimal maintenance? XD
My recommendation is to switch to just managing containers, you should just be able to export the volumes out of kubernetes and import them as normal volumes, as long as they're mounted in the right place you keep your data and if it doesn't work just try again. Not like you need to destroy the current system to slowly replace it.
-
[email protected]replied to [email protected] last edited by
If it works, I don't update unless I'm bored or something. I also spread things out on multiple machines, so there's less chance of stuff happening like you describe with the charts feature going away. My NAS is pretty much just a NAS now.
You can probably backup your configs/data, upgrade, then deploy jellyfin again, restore, and reconfigure. You should probably backup your data on your ZFS pool. But, I recently updated to the latest TrueNas Scale from ~5 year old FreeBSD version of TrueNas and the pools still worked fine (none of the "apps" or jails worked, obviously). The upgrade process even ported my service configurations over. I didn't care about much of the data in the pools, so only backed up the most important stuff.
-
[email protected]replied to [email protected] last edited by
In the business world it's pretty common to do staged or switchover upgrades: test new version in a lab environment, iron out the install/config details. Then upgrade a single production server and do a test with a small group of users. Or, build new servers with the new stuff, have a set of users run on it for a while, in this way you can always just move those users back to a known good server.
How do you do this at home? VMs for lots of stuff, or duplicate hardware for NAS type stuff (I've read of running TrueNAS in a VM).
To borrow from the preparedness community: if you have 1 you have none, if you have 2 you have 1. As an example, the business world often runs mission-critical systems in a redundant setup in regionally-different data centers, so a storm won't take them down. The question is how to reproduce this idea in a home lab environment.
-
[email protected]replied to [email protected] last edited by
Ansible.
-
[email protected]replied to [email protected] last edited by
I've got backups. Haven't updated or looked at my server in months. If I'm ever compromised by missing security updates, I just load a backup and regenerate all keys.
-
[email protected]replied to [email protected] last edited by
You might want to think about running a “stable” or “LTS” OS and spin up things in Docker instead. That way you only have to do OS level updates very rarely.
-
[email protected]replied to [email protected] last edited by
I learned this the hard way as well... I did a big OS update on mine once and it broke almost every application running on it. Docker worked perfectly still. I transferred everything I could to Docker after that.
-
[email protected]replied to [email protected] last edited by
This is not practical for a home setup. Not because it would be expensive for more hardware or whatever, but because as soon as you have multiple systems doing the same thing, their state diverges and for pretty much anything that is popular for selfhosting you cannot merge them again or mirgrate users between them without loosing anything. Distributed databases alone are a huge pita, and maintaining such redundant setups would be a million times more effort than just making sure that you can easily and quickly atomically roll back failed updates
-
[email protected]replied to [email protected] last edited by
As I said "how to reproduce this in a home setup".
I'm running multiple machines, paid little for all of them, and they all run at pretty low power. I replicate stuff on a schedule, I and have a cloud backup I verify quarterly.
If OP is thinking about how to ensure uptime (however they define it) and prevent downtime due to upgrades, then looking at how Enterprise does things (the people who use research into this very subject performed by universities and organizations like Microsoft and Google), would be useful.
Nowhere did I tell OP to do things this way, and I'd thank you to not make strawmen of my words.
-
[email protected]replied to [email protected] last edited by
I don't update unless I'm bored
Hahahaha, one of my kind!
My upgrades usually occur because I'm setting up a new system anyway, that way my effort is building for tomorrow in addition to the upgrades, and I get testing time to ensure changeover is pretty smooth.