Selfhosted
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!
view the rest of the comments
upgrade all things by default
https://github.com/topgrade-rs/topgrade/
This is also a great way to just break everything you've set up.
that's a lot of FUD, topgrade just upgrades using all package managers you have, it doesn't do the upgrades itself bypassing the manager that installed it, or package authors.
The issue is more that trying to upgrade everything at the same time is a recipe for disaster and a troubleshooting nightmare. Once you have a few interdependent services/VMs/containers/environments/hosts running, what you want to do is upgrade them separately, one at a time, then restart that service and anything that connects to it and make sure everything still works, then move on to updating the next thing.
If you do this shotgun approach for the sake of expediency, what happens is something halfway through the stack of upgrades breaks connectivity with something else, and then you have to go digging through the logs trying to figure out which piece needs a rollback.
Even more fun if two things in the same environment have conflicting dependencies, and one of them upgrades and installs its new dependency version and breaks whatever manual fix you did to get them to play nice together before, and good luck remembering what you did to fix it in that one environment six months ago.
It's not FUD, it's experience.
I've been doing that for years. Rollbacks are very rare, to the point that it doesn't make much of a difference whether I do them all at once or not, other than spending more time to do it.
If I wasn't using containers for everything, sure. Otherwise it's a bit of an excessive concern.
This is a bad idea for a number of reasons. Most obvious issue is that it doesn't guarantee anything in the way of actually fixing vulnerabilities, because some project you use may not even be scanning their own work.
what's the alternative? Write a PR yourself?
Yup. Really easy in most cases if you're just upgrading a dependency version of something to the next minor release up, but then it has to pass all the project CI tests, and get an actual maintainer to tag it for release. That's how open source works though.
That may work for a handful of projects. It'd be my full time job if I did it for everything I run. Also, I might simply suggest maintainers to adopt dependabot or an alternative before I spend time with manual changes. These things should be automated.
Well a PR means an upstream fix for the project. If you want to scan all your local running things, by all means change whatever you want, but it will just be potentially wiped out by the tool you mentioned if running.
dependabot is a tool for repos, not to apply local changes
I'm aware, but then you mentioned "manual changes", which connotes "local changes". Putting up a PR with changes isn't considered a manual anything.
It doesn't. Manual as in a PR with upgrades that you're suggesting yourself, as opposed to running dependabot.
If I have to open a PR myself, that's very much a manual change.
I don't even know what you're talking about now, so I'm going to stop responding. If Dependabot was already enabled for a project, you probably wouldn't need to worry, so that negates this entire thread. 🙄
exactly my point, I'd suggest automating that before I bothered with PRs that upgrade versions, as it's a waste of time.