And it failed spectacularly.
We only needed a simple form, but we wanted to be fancy, so we used “nextcloud forms”.
The docker image automatically updated the install to nextcloud 30, but the forms app requires nextcloud 29 or lower. No warning whatsoever. It’s an official app, couldn’t they wait that it was ready for NC 30 before launching it? The newsletter boasts “NC hub 9 is the best thing after sliced bread” yet i don’t see any difference both in visual or performance compared to NC hub 2
Conclusion: we made our business to rely on nextcloud forms as a signup form, but the only reason we were using it was disabled who knows how many weeks ago.
Lol. Do not blame others for your incompetence. If you have automatically updates enabled then that is your fault when it breaks things. Just pin the major version with a tag like nextcloud:29 or something. Upgrading major versions automatically in production is a terrible decision.
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.
If you say
Thing:latestand then redeploy your compose file or what not,
well, you’re getting the latest!
I run latest with watchtower on so much shit
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?
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.
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:
https://nextcloud.com/blog/nextcloud-forms-to-keep-your-surveys-private/
It’s not unreasonable to get pissed when 6 months after that blog post it doesn’t support the latest release anymore.
The lifecycle can be found with a single online search. Here https://github.com/nextcloud/server/wiki/Maintenance-and-Release-Schedule
Releases are maintained for roughly a year.
Set yourself a notification if you forget it otherwise.
Exactly, they have a release schedule, why their own plugin, that they’re heavily promoting as a feature, isn’t following that? If for some reason the forms app isn’t ready for that date, why not postponing the launch instead of having it broken for who know how many months?
It’s not a plugin made by someone else in their free time. They knew that by updating to NC 30 that feature that was marketed just 6 months ago would be disabled, so at least have the decency to write it in the release notes. I subscribe to the newsletter and the RSS for what, just enjoy the marketing buzzwords?
It’s like if Microsoft releases an operating system with a buggy and broken taskbar because of a rushed self imposed deadline and fixes it one year later.
Okay, let’s be angry at the company and frown a lot at what happened. Gurr, bad company, evil.
And now think of what you’d rather have - a working system, or a reason to be angry? If you have something that integrated with something else, lock it down at a specific version so you control the upgrade and know those versions work 100% of the time together. “Latest” is just asking for trouble - be it in a docker image, in dependencies or elsewhere. It’s absolutely not a “best practice” if it isn’t even a code smell or an outright bug. You could’ve had a slightly outdated version, which won’t be “exploitable” - you wouldn’t have enough time to exploit anything in that time, especially with smaller companies and obscure exploits.
Instead of putting out the fire, you could’ve been now looking into the upgrade, seeing on UAT or Test or whatever that forms aren’t supported, chilling till they are supported or complaining that they aren’t.
Upgrades breaking shit is like programming / devops 101, and a huge reason for technical debt in very old projects. Leaving all that to chance is just irressponsible.
the upgrade command is sent manually, it’s not automated and it’s not unattended. It would have made ZERO difference if i tagged 29 and then in test tagged 30. The upgrade would have not failed, it would have given ZERO warnings, I would have seen that everything worked as expected (because who tests the useless survey that is filled once a semester?) and I would have pushed the update to production.
Who tests the useless survey? Everyone with regression tests. Like dude, everything you talk about has been written “in blood” from years of hosting production systems. If the useless survey is needed, then write a test for it, or a testcase to manually try it. Don’t just upgrade, see that the app is up and push to prod, that’s not testing, that’s asking for trouble.