Update stuck if initiate by an non javascript brower

[Gomez]

Expected behaviour

Update should start and finish without a js browser or human.

Actual behaviour

After replacing all files on the server, i tried to wget the website to
start the upgrade progress. But this fails and the cloud stucks in
maintenance mode. The same happens if i open the cloud with lynx - the
console browser.

Steps to reproduce

Update a cloud and hit it wit wget, it will be stuck in maintenance mode.

@DeepDiver1975 mentioned javascript is needed for the update.

Is this needed? If a crawler or your smartphone hit the cloud in the
meantime, it will be stuck in maintenance mode.

[blizzz]

I did not try this yet, but i rely also this working. A it worked before, i'd say it is a regression.

[wtpritz]

Saw this with 4.x, also happens when updating from repo using apt-get. Will try to find ref to issue/resolution in previous version.

[blizzz]

No, with 4.0 and 4.5 series it works

[wtpritz]

Sorry, you're right - could have sworn issue was in older version.

[MTGap]

The update must be done by a human. It should eventually be changed so that only the admin can initiate the update, all other users will be blocked with maintenance mode. This probably won't happen anytime soon, so a pull request would be appreciated.

[DeepDiver1975]

The update must be done by a human.

maybe - but not through the browser.

Just think about a distributed installation with load balanced web servers.
In such a scenario we need to disconnnect the web servers from the db, migrate the db and startup the web servers again.

In such a scenario I think pure sql migration scripts are necessary or at least a php script which will process the migration on command line.

[MTGap]

The update process was moved to a dedicated file: core/ajax/update.php

Is this satisfactory?

[DeepDiver1975]

If it can be called like that:

php update.php

and it will not throw back html 😈

[DeepDiver1975]

I think we need to split the update logic from the view rendering and the we can implement a cli view on top

[DeepDiver1975]

in addition it would be great - for this case - to have a database backed field which is triggering the maintenance page.
As long as the script is running no browser can access the cloud. (will most probably only work for non sqlite databases but that's okay for this case ;-) )

[MTGap]

You can't rely on the database during an update to store the maintenance status. That's why it's stored in the config file.

[DeepDiver1975]

In a load balanced setup setting the flag in the confg file is suboptimal.
And allow the web server access to the database during migration is dangerous.

We have to give the system operators the possibility to perform the update in a save and proper way.

Maybe we need a second database user - one for the web server operations and one for the database migrations.
Within the migration script we disable the regular web server user and after migration we enable it again.

On the web server code handle the inaccessible database properly.

[DeepDiver1975]

again this is only relevant for non sqlite ;-)

[Gomez]

I like

php update.php

Split the update logic from the view rendering sounds good. This can be a first step to make "php update.php" possible.

For non load balanced setups its than possible to update over cli. With Load balanced setups you can still automate the shutdown of the load balanced do the update on one server and reactivate the load balanced.

I am willing to help, but i think i am not experienced enough to do it on my own.

[DeepDiver1975]

@MTRichards @msrex I'd consider this EE relevant

[msrex]

Agreed.

[msrex]

any progress?

[DeepDiver1975]

@MTGap ^

[dragotin]

Back in the days, Bugzilla had a script called checksetup. That could be called every time from console. If the setup was ok, it returned that, if not, it updated the setup/installation automatically and with interactivity where needed. I know from personal experience that that was a very nice experience from the administrator POV.

I suggest to develop a similar script for ownCloud, which could be a thin wrapper around php update.php as a first step.

[jancborchardt]

Fixed through #3963, backport yes/no is discussed there.

[blizzz]

No, it is not fixed by #3963

The PR seperates the code to decouple it from JS, but it still requires an additional piece of code to kick off the upgrade.

[karlitschek]

@blizzz Can you try to write a small cli upgrade.php ?

[blizzz]

Yes, though not before Monday.

[Gomez]

@blizzz ping me i will do a test!

[blizzz]

Fixed by #4047 and #4072