New updater: Planning

[LukasReschke]

Since I am super annoyed by the fact that the old web updater is broken all the time, @MorrisJobke and me sat together and came up with this proposal on what a new updater app should do.

Basically I do believe it's a quick task to get something more reliable than the forked updater and we can easily do that as independent small PHP script. – I'll see what I can work together, since the updater we ship now is anyways inherently broken we need something fixed anyways. I have lost complete trust in the updater app and want something small that does LESS magic but that MORE reliable.

@schiessle @karlitschek Any more input on below thoughts?

Update procedure

Use case: Replaces all Nextcloud files with the new ones. It doesn't perform the Nextcloud migration steps or so. The goal is to have a minimal viable product that "just works and doesn't eat data", we can add improvements on top of that later. The steps are divided in different AJAX requests so that we don't run into timeouts. (Don't is such an hard word. I guess there are still possibilities, but less.)

Step 1: Verify that the folder does not contain some custom subfolders or files. If so: Bail out.
Step 1a: Check write permissions on all folders. If not there: Bail out.
Step 2: Set nextcloud into maintenance mode
Step 3: Copy all folders (except data) into "data/updater-$instanceid/backups/nextcloud-X-Y-Z/
Step 4: Download nextcloud folder to $DATADIR/updater-$instanceid/downloads/nextcloud-$versionnumber
Step 5: Extract Nextcloud in the downloads folder and verify integrity of download. If integrity check fails: Bail out.
Step 6: Grep over core/shipped.json and remove all apps that are shipped from the apps folder
Step 7: Overwrite an "index.php", "public.php" and "ocs/v1.php" that just serve a 503 and show an "Update in progress warning"
Step 8: Delete all files except:
- the files of step 7 (to serve 503 on all endpoints - they are overwritten anyways)
- data/
- config/ (except config/config.sample.php)
- non-shipped themes (default & example to be deleted)
- non-shipped apps (see shipped.json for folder to be deleted)
- updater/index.php (and the CSS, JS files that the updater needs ?!?)
Step 9: Move downloaded nextcloud folder into the web root, except updater
Step 10: Replace updater.php PHP file that does the updating steps
Step 11: Disable maintenance mode
Step 12: Goto /.. to trigger web updater

After every step the current step gets written to "data/updater-$instanceid/.update-step" so that if the connection fails by the user the step can be resumed.

Restore procedure ("Aka undo upgrade")

Use case: If an update fails in one of the 11 steps mentioned before it should be possible to get back to a state before the update. This doesn't catch cases where the Nextcloud migration steps fail. The steps are divided in different AJAX requests so that we don't run into timeouts.

Step 1: Verify that the folder does not contain some custom subfolders or files. If so: Bail out.
Step 1a: Check write permissions on all folders. If not there: Bail out.
Step 2: Set nextcloud into maintenance mode
Step 3: Create an "index.php", "public.php" and "ocs/v1.php" that just serve a 503 and show an "Update in progress warning"
Step 4: Remove all except data and config
Step 5: Copy back $DATADIR/updater-$instanceid/backups/nextcloud-X-Y-Z/ (automatically detect latest) to the web root
Step 6: Replace updater.php PHP file that does the updating steps
Step 7: Disable maintenance mode

Remarks

• REALLY ESSENTIAL: During testing: kill the connection in every step ...the upgrade then needs to resume fine if the user comes back
• Updater screen is only accessible for properly authenticated admins (see the magic Lukas implemented in oC for that - Harden updater authentication owncloud/core#22276)

Future improvements (to be filed as different tickets later)

• manual changes to .htaccess/.user.ini: either show the user the backup and the current new version or try to put as many as possible in the database/config file

[schiessle]

I would delete the backup after the upgrade was successfully to avoid that people try to restore the backup manually later.

[LukasReschke]

I would delete the backup after the upgrade was successfully to avoid that people try to restore the backup manually later.

Good point. We could do that as cronjob entry in Nextcloud itself because we know that if the cronjob runs then the update was successful.

[MorrisJobke]

The cronjob makes sense 👍

[karlitschek]

good thinking. have you looked at the other existing tickets about the updater? a lot of thoughts went into this in the last 12 month

[karlitschek]

i would also recommend to fix the issues before we do yet another rewrite

[LukasReschke]

i would also recommend to fix the issues before we do yet another rewrite

Sorry. But I do not see any way that we can fix the current updater easily. It relies on shell_exec and whatever. I don't see any way to keep the current updater, we should do it right which is quicker than fixing this mess.

I volunteer to write a new one that will work and does exactly what is described, I won't touch the existing one. It's a mess that I won't touch. It's inherently broken as the past has shown all the time. It does too much magic and not even works on hosted systems at all. Just moving files is no super advanced magic after all and won't take a long time to write… (bold statement: Tomorrow evening we should have something)

Note: To make the current updater work with systems that have shell_exec disabled (aka probably 90% out there) it needs a major rewrite anyways. I see some work with regard to that ongoing in ownCloud core's master but I do massively doubt that this will work reliable. Plus it doesn't solve the problem for older instances.

Also if we have a simple updater script we can also offer this as "one file" upgrade solution for existing ownCloud users. We first expected that the updater works but well … it's currently completely broken 🙈

[rigrig]

Is it necessary to turn on maintenance mode while downloading and extracting the update files?
Doing that first would shorten the downtime, and if they fail the old version would still be running. (I expect especially the download might fail)

So instead of

2: turn maintenance
3: backup current files
4: download update
5: extract update

it would do

2: download update
3: extract update
4: turn maintenance on
5: backup current files

[MorrisJobke]

@rigrig Good point 👍

@LukasReschke Could we change the order?

[MorrisJobke]

So instead of

2: turn maintenance
3: backup current files
4: download update
5: extract update

it would do

2: download update
3: extract update
4: turn maintenance on
5: backup current files

I will do this in the next iteration of the updater