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
I don't have the link here, but essentially yes, nextcloud can update it's own app code in it's image because you have to mount the code to your own filesystem. This means that between docker images you can have a mismatch of the code that you have stored and the code that the image is expecting, which frequently causes mismatches for me. This is an antipattern. The code should be stored in the image, not as a volume mount. There should never be a mismatch of code in a docker image - that's the whole point. The configuration could be out of date sure, or if there's a data file that's needed, that's expected. The actual running code thought, that should never be on a mountable volume.
Next time you update the image you will probably be greeted with a "Nextcloud needs to update". That should not exist. You already pulled the image, that should be everything you need to do. The caveats are extensions, kind of a grey area in my book, but I know it's not a clean pattern with those either. (The best one I've seen lets you pin the extension version with environment variables or a config file, and then once again you are in control of when they update, and no running code is stored outside of the image.)
You can disable the web updater in the config which is the default when deploying via docker. The only time i had a mismatch is when i migrated from a nativ debian installation to a docker one and fucked up some permissions. And that was during tinkering while migrating it. Its solid for me ever since.
Again, there is no official nextcloud auto updater, OP chose to use an auto updater which bricked OPs setup (a plugin was disabled).
Thanks, I'll disable that. I'm extra salty right now because I had to rollback a bad version and had to rebuild some of my config over the last week. I got into version hell because the code on the volume (which is why I'm pissed at it) said that I couldn't run the image that I had set. So I pinned an earlier version, but then there were extensions that were pinned to a later one and said that I couldn't rollback and didn't start. I had to end up redoing the whole drive manually, forcing specific versions in the version.php and the config.php to finally make it work (Why is it in two places). Then after all that I had to run the upgrade command. Extremely annoying, and a waste of time for me. Other docker containers if I need to pin a version? I just.. pin the version. Nextcloud is the only one I've seen where they store code on my volume and then pin specific versions to it.