They’re releasing a new version every two month or so and dropping them rapidly from support, pinning it with a tag means that in 12 months the install would be exploitable.
Now, I did directly to production because this is low priority stuff, but it would have happened even with a testing stage. I would have never noticed that the forms apps was disabled, the system disabled it without any notification.
You would expect that an official app supports the latest release, no?
This wasn’t an app released by a nobody in their free time, this is a main feature heavily advertised in their blog. Look by yourself:
nextcloud.com/…/nextcloud-forms-to-keep-your-surv…
It’s not unreasonable to get pissed when 6 months after that blog post it doesn’t support the latest release anymore.
scrubbles@poptalk.scrubbles.tech 1 month ago
Docker images should never self update - that’s an anti pattern. They should be static code. The only time I would expect a docker image to “auto update” is if I was using the “latest” or “stable” tag and Compose/Kubernetes/I repull the image - but the image should never update itself.
Yes, OP bit off more than they could chew. Nextcloud, however, is breaking the entire purpose of Docker images by having an auto-updater at all.
GBU_28@lemm.ee 1 month ago
If you say
Thing:latestand then redeploy your compose file or what not,
well, you’re getting the latest!
scottmeme@sh.itjust.works 1 month ago
I run latest with watchtower on so much shit
possiblylinux127@lemmy.zip 1 month ago
That is a very bad idea. Use the stable tag instead. Better yet, create an Ansible playbook that updates the containers in bulk and then manually run it when you have time.
ShortN0te@lemmy.ml 1 month ago
What are you talking about? If you are not manual (or by something like watchtower) pull the newest image it will not update by itself.
I have never seen an auto-update feature by nextcloud itself, can you pls link to it?
scrubbles@poptalk.scrubbles.tech 1 month ago
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.)
ShortN0te@lemmy.ml 1 month ago
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).